戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

情報処理安全確保支援士 2009年 春期 午後201


公開鍵基盤の構築に関する次の記述を読んで、設問1~6に答えよ。

   A社は、持株会社(以下、グループ本部という)を中心とした企業グループの中の一社であり、従業員数1,200名の中堅機械製造会社である。業務は、製造業向けの製造機械の製造である。A社には、製造部門以外に、人事総務部、商品管理部、営業部、配送部、情報システム部がある。商品管理部は、在庫管理が主な業務であり、受注状況によって、商品の製造指示を行っている。営業部は、販売推進とA社のグループ会社である販売会社(以下、グループ販社という)からの受注業務を行っている。受注業務には、電話とファックスを利用してきた。  グループ本部では、従業員のワークライフバランスに積極的に取り組んでおり、A社の経営者も、具体的な施策を段階的に実施してきている。ワークライフバランスへの取組の一環として、製造部門以外の部署を対象とするテレワーク環境(以下、Tシステムという)を提供することになった。  また、営業部における受注業務において、誤った商品の納品や、数量の誤りが年に数件発生し、損失と信用の失墜を招いていたので、受注誤りを減らすためのシステム(以下、Nシステムという)の構築もTシステム構築と同時に行うことになった。  両システムの構築は、情報システム部のX課長とZ主任が担当することになり、2人は検討を開始した。   〔Tシステムの検討〕  X課長とZ主任は、まず、Tシステムにおける、ネットワーク接続方法を検討した。次は、そのときの会話である。    X課長:まず、Tシステムの構築に当たって、利用形態や用途を洗い出し、どのようなネットワーク接続方法が適切かを考えてみよう。  Z主任:はい。最初にテレワークでの利用形態ですが、人事総務部のまとめによれば、現時点での対象者は、育児休職、介護休職を取得中で、在宅での勤務を希望する従業員です。その後、段階的に対象者の範囲を広げていくことになっています。勤務場所については、自宅以外にサテライトオフィスも検討されています。  X課長:作業の内容については、社内で行う作業のほとんどが対象となる。外部から無制限に社内のシステムにアクセスできることは、セキュリティ上の大きなリスクとなるから、何らかの制限をかける必要がある。どこから、どのシステムにアクセスする必要があるか、説明してくれ。  Z主任:はい。まず、場所ですが、従業員の自宅とサテライトオフィスからアクセスする必要があります。利用する社内システムには、二つの形態があります。一つは、Webシステムの形態で、受注管理システム、発注管理システムとグループウェアがあります。もう一つは、クライアントサーバシステムの形態で、勤怠管理システムと電子メール(以下、メールという)があります。テレワークについての事前調査で、ほとんどの従業員は自宅でインターネットを利用できることが分かっています。サテライトオフィスについては、提供事業者に確認したところ、十分な帯域が確保されたインターネットが利用できるとのことでしたので、インターネットの利用を前提とすることはTシステムの実現上、問題ないようです。  X課長:費用の面からも、公衆回線や専用線よりもインターネットを利用した方がよいだろう。インターネットを利用することになると、セキュリティ面での要件を検討する必要がある。  Z主任:そうですね。インターネットを利用することから、通信の盗聴や改ざんを防ぐことと、利用者を確実に認証することが必要になります。  X課長:それでは、当社のシステム構築を行っているC社と相談して、Tシステムの通信はどのような仕組みにすべきか、検討してくれ。  Z主任:分かりました。    Z主任は、早速C社でセキュリティを担当しているD氏に連絡を取り、Tシステムにおける安全な通信方法について検討することにした。次は、そのときの会話である。    Z主任:Tシステムを、インターネットを利用して実現するために、IPsecを利用したVPNを構築したいと思いますが、どのようなことに注意する必要があるでしょうか。  D氏:テレワークで利用するPC(以下、テレワークPCという)は、社の社内ネットワークに直接接続されるのと同様の状態になりますので、社内で使われているPC(以下、社内PCという)と同様の管理が必要になります。  Z主任:テレワークPCについては、社内PCと同じアプリケーションプログラム、ウイルス対策ソフトが導入されたものを貸与することにします。それでよろしいでしょうか。  D氏:それだけでは不十分です。例えば、御社では、ウイルス定義ファイルが、社内に設置されている配布用のサーバだけから自動的に配布されるようになっています。そのため、テレワークPCについては、①VPNで御社の社内ネットワークに接続されていないときに問題が起こる可能性がありますので、その対策が必要です。    D氏は、起こる可能性のある問題と、その対策方法について説明した。    Z主任:分かりました。対策を講じます。それから、不正な接続を防ぐために、信頼性の高い認証を行わなければならないと思いますが、どのような方法をとったらよいでしょうか。  D氏:利用者IDとパスワードによる認証ですと、総当たり攻撃などによって、正当な利用者以外の者が接続できてしまうリスクを無視できません。クライアント証明書を併用した認証方式を採用してはいかがでしょうか。  Z主任:そのようにしたいと思います。    数日後、Z主任はD氏との検討の結果を取りまとめ、D氏にも同席してもらい、X課長に報告した。    Z主任:Dさんと検討した結果、暗号化にはIPsec、認証にはクライアント証明書を利用することにしました。  X課長:分かった。運用上、秘密鍵とクライアント証明書の取扱いには注意が必要だ。そのことも考慮して、C社とともに作業に入ってくれ。  Z主任:そのように手配します。  X課長:ところで、現在広く使われている暗号方式には、暗号強度の問題や脆弱性の問題がある、と聞いたことがあるのですが、どのようなことでしょうか。  D氏:それは、米国国立標準技術研究所(NIST)が定めた、米国政府機関のコンピュータシステムの調達基準のことです。表に示す暗号アルゴリズムを利用したシステムなどの調達は2010年までしか認められていません。
情報処理安全確保支援士試験(平成21年度 春期 午後2 問01 表01)
 D氏:この理由の一つは、コンピュータの性能が上がることによって、数年後には、現在広く利用されている、鍵長aビットのRSA公開鍵から秘密鍵が推測される可能性があり、②電子署名の対象のデータの改ざんやなりすましが行われる可能性があることです。これに対しては、鍵長を更に長くすることが求められます。もう一つは、ハッシュ関数として現在広く利用されているbには、ある条件下でcの衝突を意図的に起こすことができる、という脆弱性が発見されていることです。この脆弱性を攻撃されると、電子署名の信頼性が損なわれます。  X課長:なるほど。表の暗号アルゴリズムの問題には今から対策を講じておく必要があるわけですね。  D氏:はい。日本でも政府機関に対して、内閣官房情報セキュリティセンターが2013年度までに対応するように求めています。  X課長:これらは政府機関の基準だが、我々のような民間企業でも、暗号アルゴリズムの問題を考慮してシステムを構築した方がよさそうですね。  D氏:新規に構築するシステムですので、暗号アルゴリズムの問題を考慮した方がよいと考えます。  X課長:Z主任、この件についても、要求仕様を作る上で、十分に気をつけてくれ。  Z主任:はい、分かりました。   〔Nシステム要件の検討〕  続いて、X課長とZ主任は、受注誤りへの対応を行うために、営業部のY主任を交えて、Nシステムの要件を洗い出すことにした。次は、そのときの会話である。    X課長:これまでの電話とファックスによる受注が、どのようなフローで行われているかを確認しよう。Y主任、説明してくれ。  Y主任:はい。まず、電話による受注処理ですが、営業部の従業員が電話を受け、その内容を注文票に記入します。注文票の内容を、同じ従業員が、社内システムの受注管理システムに入力します。商品管理部は、受注管理システムを参照して在庫情報を確認し、製造指示作業を始めます。次に、ファックスによる受注処理ですが、営業部の従業員が、受け取ったファックスの内容を、受注管理システムに入力するようになっています。以後は電話による受注処理と同じです。  X課長:どのような受注誤りが多いのかね。  Y主任:受注誤りで多いのは、受注管理システムへの型番や数量の入力間違いです。  X課長:それでは、表計算ソフトを使って電子化した注文票を、送付してもらってはどうだろうか。そうすれば、受注管理システムとの連携は、比較的容易に構築できるだろう。  Z主任:注文票には、グループ販社の担当者の氏名や電話番号、お客様の事業状況などがうかがい知れる項目が含まれていますので、グループ販社の発注担当者と当社営業部担当者間の機密性を確保することが必要です。  X課長:それでは、電子化された注文票の送付方法について検討することにしよう。    電子化された注文票を安全に送付する方法について、再び、D氏に相談することにした。次は、そのときの会話である。    X課長:電子化された注文票は、注文票を作成したグループ販社と当社の者だけが、内容を知ることができるようにしたいと考えています。電子化された注文票を、インターネットを使って安全に送付する方法として、どのようなものがあるか教えてほしいのですが。  D氏 :送付する方法としては、メールを利用する方法と、Web システムを利用する方法があります。どちらの方法でも、暗号化を利用すれば、安全に送付することができます。  Z主任:Web システムを利用する場合は、SSL で暗号化された通信路を使って送付することになりますよね。メールを利用する場合は、どのような方法で行うのですか。  D氏 :はい、S/MIME という方法があります。これは、RFC で規定されており、多くのメールソフトが標準で実装しています。S/MIME を使うと、メールの暗号化と電子署名を行うことができます。SSL も S/MIME も公開鍵基盤(PKI)の上で動作しますので、まず、認証局(CA)が必要となります。これには、認証事業者の CA(以下、商用 CA という)を利用することもできますし、御社で構築、運用する CA(以下、自営 CA という)を利用することもできます。利用者は、自分自身の秘密鍵と公開鍵の対(以下、鍵ペアという)を生成します。CA は、この公開鍵に対して公開鍵証明書(以下、証明書という)を発行します。御社での CA の設置運用状況は、どうなっていますか。  X課長:はい、グループ本部では、既に証明書ポリシと認証局運用規程(以下、CP/CPS という)を策定しており、ルートCAが自営 CA として設置されています。グループ企業はこのルートCAの利用が可能です。また、グループ企業独自のルートCAを設置してもよいことになっており、商用 CA と自営 CA のいずれで実現しても構わないことになっています。  Z主任:今回の場合、証明書の発行をタイムリに行う必要があると思うので、独自のルートCAを設置した方がよいと思います。  X課長:そうだな。グループ本部のルートCAを利用するのではなく、当社独自のルートCAを設置することにしよう。  D氏 :分かりました。  X課長:この場合、商用 CA を利用するか、自営 CA を利用するかは何を基準にして決めればよいのですか。  D氏 :まず、だれが証明書を利用するのかが基準になります。不特定の利用者を対象とする場合は、商用 CA を利用しなければなりませんが、利用者の範囲が限られる場合は、自営CAを利用しても構いません。次に、自営CAの構築費用及び証明書発行費用を含む運用費用と、商用CAの費用との比較によって決めるのが一般的です。  Z主任:今回の場合、利用者がグループ販社と当社に限定されるので、利用者の範囲という観点では、自営CAでも問題なさそうですね。後は、費用と手間の観点での検討が必要ということですね。自営CAを運用する場合、どのようなことをしないといけないのでしょうか。  D氏 :構築段階では、自営CAで発行する証明書の種類を決めたり、証明書発行の手順や運用体制を決めたりしなければなりません。これらを文書化してCP/CPSを策定する必要があります。運用段階の主な作業は、証明書の発行と証明書失効リストの発行です。  X課長:自営CAの構築はどのように行うのでしょうか。  D氏 :自営CAを構築する方法は幾つかあります。一つ目は、OSの機能やオープンソースソフトウェア(OSS)を使う方法です。二つ目は、アプライアンス製品を使う方法です。三つ目は、市販されているCAソフトを使う方法です。  Z主任:OSSを利用すると、構築費用はかなり下げることができますね。ただし、そのソフトウェアに精通した技術者が必要になると思いますが。  X課長:そうだな。Z主任、これらの情報を基に、電子化された注文票の送付方法をメールとWebシステムのどちらにするか、CAは自営CAと商用CAのどちらにするか、また、自営CAを利用する場合は、CAの構築方法も含めて検討してくれ。  Z主任:分かりました。   〔PKI構築の検討〕  数日後、X課長は、Z主任の検討結果が適切であるかを、D氏を交えて確認した。    Z主任:電子化された注文票の送付方法について検討したところ、Webシステムを利用した送付については、Webシステムの開発が必要ですので、すぐには開始できません。メールについては、証明書が用意できれば、すぐにでも開始できます。受注管理システムとの連携をスムーズに行うために、将来的にはWeb システムを利用することにして、しばらくの間は、メールにすることにしました。  X課長:そうか。CA についてはどうかね。  Z主任:T システムと N システムを合わせると、発行する証明書がかなりの数になります。そのため、多数の証明書を一括して発行できる証明書発行プログラムが必要になりますので、その開発費用も含め、3年間で掛かる総費用を算出してみました。なお、CP/CPS については、グループ本部の CP/CPS を流用することができますので、比較的容易に策定することができます。その結果、当社にとって最適な方式を採用した自営 CA を利用する場合が 359 万円、商用 CA を利用する場合が 654 万円となり、当社の場合、自営 CA を利用した方が安いとの結論に至りました。  D氏 :なるほど。しかし、証明書を発行するために、自営 CA の秘密鍵を使う必要があります。③自営 CA の秘密鍵が漏えいすると、グループ販社と御社に被害が及ぶことが想定されます。秘密鍵の漏えい防止対策を施すと、証明書発行に要する費用は、これよりは多くなると思います。  X課長:そのとおりだ。自営 CA の秘密鍵を安全に使うための手順を考慮して、証明書発行に要する費用を再度計算してくれ。  Z主任:分かりました。    Z主任は、自営 CA の秘密鍵を安全に使うための手順を考慮した費用を計算し、X課長に提示した。    Z主任:秘密鍵を安全に使うための手順を見直したところ、鍵管理のアプライアンス製品を導入することで、秘密鍵を安全に管理できることが分かりました。この製品を使用した場合の 3年間の総費用は 422 万円となり、やはり、自営 CA を利用する方が安くなります。  X課長:それでは、自営 CA を利用することにしよう。Web システムになったとしても CA は必要だからな。  Z主任:分かりました。ところで、利用者が証明書署名要求(CSR)を作成するためには、事前に、鍵ペアを生成しておく必要があります。また、CA で証明書発行を行うためには、利用者からCSRをもらう必要があります。  X課長:証明書発行プログラムとは別に、鍵ペアの生成プログラムと、CSR作成プログラムの開発が必要ということだな。ただ、今回の場合、証明書をTシステムとNシステムの利用に限定すれば、必ずしもCSRの作成までを、利用者に行ってもらう必要はないのではないでしょうか。  D氏:おっしゃるとおりです。今回のPKI構築の目的は、御社とグループ販社の担当者間のメールを、第三者が不正に閲覧することができなければよいわけですから、必ずしも、鍵ペアを利用者本人が生成しなくても、御社が生成すれば問題ないと考えます。鍵ペアを御社が生成するのであれば、CSR作成も御社で可能です。鍵ペアの生成プログラムとCSR作成プログラムは、証明書発行プログラムの一部として開発すれば、運用も容易になると思います。  X課長:そういうことだ。この方法を採用する方がよさそうだな。ただし、CP/CPSの中で、④利用者の鍵ペアの取扱いについて、きちんと決めておいた方がよさそうだ。Z主任、D氏とともに、テレワークを含め、証明書発行の運用フロー概要を作成してくれたまえ。  Z主任:分かりました。    翌日、Z主任は、証明書発行の運用フローをX課長に提示した。    Z主任:証明書発行の運用フローを、図1にまとめました。Tシステムで利用する証明書と、Nシステムで利用する証明書のいずれも、同じCAで発行するようにしています。また、鍵ペアの生成及びCSRの作成はCA運用者で行う方法を採用しています。
情報処理安全確保支援士試験(平成21年度 春期 午後2 問01 図01)
 X課長:ところで、利用者属性の真偽の確認は、どこで行うのかね。  Z主任:グループ販社の発注担当者の確認は、図1中のdで行います。テレワーク対象者の確認はeで行います。  X課長:登録局(RA)の役割を、利用申請者をよく知っている当社の従業員が担う形になるわけだな。鍵ペアと証明書は、利用申請者にどのような手段で渡すのかね。  Z主任:鍵ペアと証明書は、パスフレーズを使って暗号化し、メールで送付します。復号に必要なパスフレーズは、グループ販社の場合は郵送します。当社営業部担当者とテレワーク対象者の場合は、情報システム部に取りに来てもらいます。  X課長:分かった。ところで、実際の受注フローについては、どのようになるのかね。  Z主任:はい、図2にまとめました。
情報処理安全確保支援士試験(平成21年度 春期 午後2 問01 図02)
 X課長:グループ販社側で、注文メールの暗号化と署名、請書メールの復号と署名の検証に手間が掛かるが、最近のメールソフトでは、簡単な操作でこれらができるようになっているから、グループ販社にとっても、そんなに面倒な作業ではないだろう。受注管理システムへの入力は、注文票に組み込まれているプログラムで自動化することで、誤りが防げる。ところで、当社営業部担当者の証明書をグループ販社の発注担当者に送っておく必要があるが、どのようにするのかね。それから、グループ販社と当社ともに、メールの暗号化と署名の検証を行う必要がある。そのときに必要となる当社のf証明書は、いつ、どこに、どのようにして導入するかを手順書として整備する必要があるな。  Z主任:すみません、それらのことを忘れていました。当社営業部担当者の証明書の送付方法とf証明書の導入については、手順書を作成して配布するようにします。また、グループ販社での導入を支援できるように、営業部員への教育を検討します。  X課長:CP/CPSについても、営業部員がきちんと説明できるようにしておいてくれ。それから、⑤グループ販社では、証明書をNシステム以外の用途に使用しないように、徹底してくれ。  Z主任:分かりました。    その後、X課長とZ主任は、C社とともにTシステムとNシステムの構築を順に終え、運用を開始した。

設問1

本文中のac及びfに入れる適切な字句を、8字以内で答えよ。

模範解答

a:1,024 b:SHA-1 c:ハッシュ値 f:ルート

解説

解答の論理構成

  1. a の判定
    • 問題文には「鍵長 a ビットのRSA及びDSA」「鍵長aビットのRSA公開鍵から秘密鍵が推測される可能性」とあります。
    • 2000年代に“現在広く利用されている”RSA/DSA 鍵長として米国国立標準技術研究所(NIST)が移行を勧告したのは 1,024 ビットです。
    • よって a = 1,024 となります。
  2. bc の判定
    • 「ハッシュ関数として現在広く利用されているbには、ある条件下でcの衝突を意図的に起こすことができる」という記述があります。
    • 衝突脆弱性が報告され、当時最も普及していたハッシュ関数は SHA-1
    • 衝突を起こす対象は ハッシュ値
    • よって b = SHA-1、c = ハッシュ値 となります。
  3. f の判定
    • 問題文に「当社のf証明書は、いつ、どこに、どのようにして導入するかを手順書として整備」とあります。
    • メール暗号化/署名の相互運用で最初に各端末へ配布するのは CA の最上位証明書、すなわち ルート証明書です。
    • よって f = ルート となります。
  4. 以上より
    • a:1,024
    • b:SHA-1
    • c:ハッシュ値
    • f:ルート

誤りやすいポイント

  • a を “2,048” と勘違い
    2,048 ビットは「移行先」の推奨値であり「現在広く利用されている」長さではありません。
  • b に “SHA-2” を入れてしまう
    SHA-2 系列ではまだ衝突報告がなく、文中の脆弱性説明に一致しません。
  • ③ “c” を “メッセージ” と書く
    衝突が発生するのはメッセージそのものではなくハッシュ値です。
  • f を “中間” とする
    中間証明書は用途ごとに複数存在し得ますが、全端末で共通インストールが必要なのはルート証明書です。

FAQ

Q: なぜ 1,024 ビットが今では非推奨なのですか?
A: コンピュータの性能向上により総当たりや数値計算攻撃のコストが大幅に下がり、2048 ビット以上でないと十分な安全性が担保できなくなったためです。
Q: SHA-1 の衝突攻撃は実際に成功した例がありますか?
A: 2017 年に Google などが公開した “SHAttered” 攻撃で実証されています。これにより SHA-1 は事実上の利用停止勧告を受けています。
Q: ルート証明書はどこに格納するのが一般的ですか?
A: OS やブラウザ、メールクライアントが持つ信頼ストアへインポートします。企業環境では GPO や MDM で一括配布する方法がよく採られます。

関連キーワード: RSA, SHA-1, 衝突攻撃、ルート証明書、鍵長

設問2

本文中の下線①について、どのような問題が起こるかを、45字以内で述べよ。また、その対策を、50字以内で述べよ。

模範解答

問題:社内ネットワークに接続されないと、ウイルス定義ファイルが更新されない。 対策:インターネット上のウイルス定義ファイル配布サーバからも更新できるように、PCの設定を変更する。

解説

解答の論理構成

  1. 【問題文】には
    「ウイルス定義ファイルが、社内に設置されている配布用のサーバだけから自動的に配布される」とあります。
  2. さらに下線部①で
    「VPNで御社の社内ネットワークに接続されていないときに問題が起こる可能性」
    と指摘されています。
  3. テレワークPCが社内 VPN 外にいる間は社内サーバへ到達できず、定義ファイル更新が行えません。結果としてウイルス検知力が低下し、マルウェア感染リスクが高まることが“問題”です。
  4. “対策”としては、VPN なしでも最新版を取得できるようにする措置が妥当です。すなわち、インターネット上の公式配布サーバへも問い合わせられる設定を追加し、常に更新できるようにしておけばリスクを解消できます。

誤りやすいポイント

  • “問題”を「通信が暗号化されないこと」と勘違いしやすいですが、下線部①の文脈はウイルス対策運用です。
  • 「ウイルス定義ファイルが社外に漏えいする」と答えると論点ずれになります。漏えいではなく“未更新”が問題です。
  • “対策”を「VPN 常時接続を義務化」としてしまうと、利用者負荷や可用性への配慮が欠け、模範解答の趣旨と外れます。

FAQ

Q: 社内サーバをインターネット側へ公開するのは危険では?
A: 公開せずとも、ベンダ提供のインターネット配布サーバを利用すれば安全かつ確実に更新できます。
Q: VPN 接続時とインターネット直結時で更新元が二重になるが、優先順位は?
A: 様々な対策ソフトは複数サーバのフェイルオーバー設定が可能です。接続可否で自動的に切替えられます。
Q: テレワーク PC の管理者権限はユーザに与えてよい?
A: 不要な設定変更やマルウェア感染を防ぐため、原則として管理者権限は情報システム部が保持します。

関連キーワード: ウイルス対策ソフト、定義ファイル、VPN, 自動更新、配布サーバ

設問3

Tシステムにおいて、テレワーク対象者は、他人が社内ネットワークへ不正にアクセスしないようにするために、自分のテレワークPCに関して、運用する上でどのような点に注意する必要があるか。秘密鍵の漏えい防止の観点から二つ挙げ、それぞれ35字以内で述べよ。

模範解答

「テレワークPCの紛失、盗難対策を行う。」 または 「テレワークPCを他人に貸与しない。」 または 「テレワークPC以外に秘密鍵及び証明書を導入しない。」 または 「テレワークPCの利用者パスワードを堅ろうなものにする。」

解説

解答の論理構成

  1. Tシステムでは、テレワークPCが社内VPNに接続する際の認証として「クライアント証明書」を用います。
    引用:
    ・「暗号化にはIPsec、認証にはクライアント証明書を利用」
  2. クライアント証明書の利用には対応する秘密鍵が必須であり、鍵が漏えいすると「他人が社内ネットワークへ不正にアクセス」できてしまいます。
    引用:
    ・「秘密鍵とクライアント証明書の取扱いには注意が必要だ。」
  3. 秘密鍵はテレワークPC内に保存されるため、PC自体の紛失や貸与、複製などが漏えいリスクに直結します。
  4. したがって、利用者が行うべき対策は
    a. テレワークPC自体を守る(紛失・盗難・第三者使用の防止)
    b. 秘密鍵の格納先を限定し、他端末にコピーされないよう管理する
    c. テレワークPCへのログオンを強固にし、盗難時でも鍵が簡単に利用されないようにする
    となります。
  5. これらを秘密鍵漏えい防止の観点から整理すると、模範解答例のように
    ・「テレワークPCの紛失、盗難対策を行う。」
    ・「テレワークPC以外に秘密鍵及び証明書を導入しない。」
    などが適切な解答となります。

誤りやすいポイント

  • ウイルス定義ファイル更新などの「一般的なPC管理」を解答に書き、秘密鍵漏えい対策と直接結び付けられない。
  • 「パスワードを定期変更する」などVPNログオンのみを意識し、証明書・秘密鍵の所在管理を忘れる。
  • 秘密鍵をUSBメモリ等へコピーして保管する方法を“安全”と勘違いする。これは逆に漏えいリスクを高める。

FAQ

Q: テレワークPCを暗号化すれば秘密鍵漏えい対策は十分ですか?
A: 端末暗号化は有効ですが、紛失後にパスワードが突破される可能性もあります。貸与禁止や複製防止と併用してください。
Q: スマートカードに秘密鍵を入れればPC貸与の問題は解決しますか?
A: スマートカード方式も有効ですが、カード自体の紛失リスクが残るため、PIN 強化や二要素認証と合わせて運用が必要です。
Q: テレワークPCの利用者がパスワードを忘れた場合、管理者が秘密鍵を再発行しても良いですか?
A: 可能ですが、旧鍵を失効リストに載せ、証明書を更新する手順をCP/CPSで明確にしておく必要があります。

関連キーワード: クライアント証明書、秘密鍵管理、テレワーク、VPN, 認証

設問4

本文中の下線②について、秘密鍵の推測が成功したとして、どのようにすれば改ざんやなりすましができるか。その方法を、70字以内で述べよ。

模範解答

電子署名の対象のデータを改ざんした上で、そのハッシュ値から推測した秘密鍵で署名を生成し、本来の所有者と偽って送信する。

解説

解答の論理構成

  1. 問題文では「鍵長 a ビットのRSA公開鍵から秘密鍵が推測される可能性」があるとし、結果として「②電子署名の対象のデータの改ざんやなりすましが行われる」危険を指摘しています。
  2. 電子署名は、署名者だけが持つ秘密鍵でハッシュ値を暗号化し、受信者は対応する公開鍵で復号して真正性を検証する仕組みです。
  3. したがって攻撃者が秘密鍵を推測できれば、(1) 改ざん後のデータに対して新たにハッシュ値を算出し、(2) 推測済みの秘密鍵でそのハッシュ値に署名し、(3) 元の所有者になりすまして送信する――という手順で受信者に偽装データを正当なものとして信じ込ませることが可能になります。

誤りやすいポイント

  • 公開鍵だけで改ざんできると誤解する
    → 実際には「秘密鍵」が推測されたことが前提です。
  • ハッシュ値を再計算せずに既存の署名だけ付替えると考える
    → 元データを変えればハッシュ値も変わるため、新しい署名生成が必須です。
  • なりすましはメール送信者欄の変更だけで充分と思う
    → 電子署名による真正性検証を突破できなければ意味がありません。

FAQ

Q: 秘密鍵が推測されても暗号文の復号だけが問題になるのですか?
A: いいえ。復号だけでなく、推測した秘密鍵で新たな署名を生成できるため、改ざんやなりすましの危険がより深刻です。
Q: ハッシュ関数の衝突脆弱性と今回の攻撃は関係しますか?
A: 今回は「秘密鍵の推測」が主因であり、ハッシュ衝突を利用せずとも改ざんと署名生成が実現できます。
Q: 鍵長を長くする以外の対策はありますか?
A: 署名鍵の定期的な更新、耐量子暗号への移行、HSMでの鍵保護などが有効です。

関連キーワード: 電子署名、秘密鍵、ハッシュ関数、改ざん、なりすまし

設問5PKI構築について、(1)〜(3)に答えよ。

(1)本文中の下線③について、どのような被害が考えられるか。50字以内で述べよ。

模範解答

グループ販社の発注担当者の証明書が偽造され、偽の注文票が送られる可能性がある。

解説

解答の論理構成

  1. 下線③には
    「③自営 CA の秘密鍵が漏えいすると、グループ販社と御社に被害が及ぶ」
    とあります。
  2. 認証局(CA)の“秘密鍵”は、公開鍵証明書に署名して真正性を保証するための鍵です。これが漏えいすると第三者でも署名付き証明書を発行できてしまいます。
  3. 本文では、注文票をやり取りする相手は「グループ販社の発注担当者」です。攻撃者が偽造証明書を用いれば、A社は攻撃者を正規の担当者と誤信し、メール暗号化・署名検証を正常終了させてしまいます。
  4. すると、攻撃者は“偽の注文票”を送り付け、A社が誤った製品を製造・出荷する、もしくは不要な在庫・金銭損失が発生する――これが「被害が及ぶ」具体像です。
  5. よって模範解答の
    「グループ販社の発注担当者の証明書が偽造され、偽の注文票が送られる可能性」
    が導かれます。

誤りやすいポイント

  • 「通信の盗聴」や「メール内容の改ざん」を被害と書くとズレます。問題は「秘密鍵漏えい→証明書偽造→なりすまし」です。
  • 被害主体を「A社だけ」と考えがちですが、本文にあるとおり「グループ販社」と「御社(A社)」の双方に影響します。
  • “偽の請書”ではなく“偽の注文票”を送られる点を押さえてください。

FAQ

Q: 秘密鍵が漏えいすると、なぜ通信内容の復号も可能になるのでは?
A: ルート CA の秘密鍵は署名専用であり、暗号文の復号には使われません。漏えいによる主なリスクは「証明書の偽造」に伴うなりすましです。
Q: 証明書が偽造されても電子署名の検証は問題なく通るのですか?
A: はい。攻撃者が漏えいしたルート CA 秘密鍵で署名した証明書は正規のチェーンとして検証をパスします。その結果、受信側は送信者を正当と誤認します。
Q: 自営 CA の秘密鍵を守るための一般的な対策は?
A: ハードウェアセキュリティモジュール(HSM)など鍵管理用アプライアンスに格納し、オフライン運用や多要素認証でアクセスを厳格に制御します。

関連キーワード: 公開鍵基盤、認証局、秘密鍵漏えい、証明書偽造、なりすまし

設問5PKI構築について、(1)〜(3)に答えよ。

(2)本文中のdeに入れる適切な記号を、図1中の(ア)〜(サ)から選んで答えよ。

模範解答

d:(イ) e:(ケ)

解説

解答の論理構成

  1. 役割整理
    • 利用者属性の確認は登録局 (RA) の仕事です。本文には
      「登録局(RA)の役割を、利用申請者をよく知っている当社の従業員が担う形になるわけだな。」
      とあります。したがって、申請者を“よく知っている人物”が承認する工程を探します。
  2. グループ販社の発注担当者の確認箇所
    • グループ販社の担当者を“よく知っている”のは、日頃やり取りをしている「A社営業部担当者」です。
    • 図1の流れでは、グループ販社側から提出された申請書を「A社営業部担当者」が承認する工程は(イ) 「利用申請の承認」です。
    • よって、d = (イ)。
  3. テレワーク対象者の確認箇所
    • テレワーク対象者は自社社員なので、所属部署の「所属長」が最も利用者を把握しています。
    • 図1では、テレワーク対象者の申請書を「所属長」が承認する工程が(ケ) 「利用申請の承認」です。
    • よって、e = (ケ)。
  4. まとめ
    • d:(イ)
    • e:(ケ)

誤りやすいポイント

  • (ア)や(ク)など“申請書の作成”工程をRAだと誤認する
    申請はあくまで利用者側の行為で、属性確認が行われません。
  • (ウ)を選んでしまう
    (ウ)はCA運用者が行う“鍵ペア生成・証明書発行”であり、RA工程ではありません。
  • グループ販社とテレワーク対象者の承認者を逆に覚える
    グループ販社→営業部担当者、テレワーク対象者→所属長、という“知り得る立場”に注目するのがポイントです。

FAQ

Q: 登録局 (RA) と認証局 (CA) の違いは何ですか?
A: RAは「誰が誰であるか」を確認する窓口、CAは確認済みの公開鍵に「証明書」を発行する主体です。本問では(イ)・(ケ)がRA、(ウ)がCAに相当します。
Q: なぜグループ販社の確認を営業部担当者が行うのですか?
A: 営業部担当者が日常的に取引先と接しており、申請者の身元や権限を把握しているため、RAの要件「申請者をよく知る人物」を満たすからです。
Q: 所属長が承認するだけで十分なセキュリティが確保できますか?
A: 所属長は人事情報を通じて部下の異動・休職状況を把握しているため、テレワーク対象者の属性確認として合理的です。加えて、証明書失効手続や定期棚卸しで継続的にチェックする運用が前提となります。

関連キーワード: 公開鍵基盤、登録局、証明書発行、テレワーク、ワークフロー

設問5PKI構築について、(1)〜(3)に答えよ。

(3)本文中の下線④について、鍵ペアの取扱い上で注意すべき事項を、30字以内で述べよ。

模範解答

「CAにおいて、利用者の秘密鍵を厳重に管理する。」 または 「鍵ペアと証明書の送付後に、CAでは秘密鍵を削除する。」

解説

解答の論理構成

  1. 本文では、鍵ペアを「御社が生成」し「CSR作成も御社で可能」という運用を採用しています。
    引用:
    ・「鍵ペアを御社が生成するのであれば、CSR作成も御社で可能です。」
  2. その結果、利用者の秘密鍵が一時的に CA(A社)側に存在します。ここで X 課長が次の指示を出しています。
    引用:
    ・「ただし、CP/CPS の中で、④利用者の鍵ペアの取扱いについて、きちんと決めておいた方がよさそうだ。」
  3. 秘密鍵は漏えいすると重大な被害につながるため、CA 側で厳格に扱う必要があります。漏えいリスクを下げる実践的方法は、 ① CA 内で厳重に保管する、または
    ② 利用者への安全な送付後に CA 内の秘密鍵を消去する
    です。
  4. 以上より、設問の「鍵ペアの取扱い上で注意すべき事項」は「CA 側で利用者秘密鍵を厳重に管理(又は速やかに削除)」とまとめられます。
【解答】
鍵ペアと証明書送付後にCAで秘密鍵を削除する

誤りやすいポイント

  • 「利用者が鍵ペアを生成しないから安全」と思い込み、CA 側での秘密鍵保管リスクを見落とす。
  • 「秘密鍵を暗号化して渡すだけ」で満足し、CA に残った複製を削除し忘れる。
  • 取扱い手順を CP/CPS に反映させず、担当者交代時に運用が形骸化する。

FAQ

Q: 利用者自身に鍵ペアを生成させればこの問題は解消しますか?
A: はい。利用者端末で生成させれば CA に秘密鍵が残りません。ただし CSR 作成や教育コストが増加するため、案件に応じたトレードオフ検討が必要です。
Q: CA に秘密鍵が一切残らないようにする方法はありますか?
A: HSM(Hardware Security Module)を用い、生成直後に暗号化エクスポートせず廃棄する、またはゼロ化証明を取得してから削除する手順を設ける方法があります。
Q: CP/CPS に記載すべき具体項目は?
A: 鍵生成方法、保管媒体、移送手順、削除時期・方法、監査証跡の取得と保存期間などを明示します。

関連キーワード: 秘密鍵管理、自営CA, CP/CPS, HSM, CSR

設問6

本文中の下線⑤について、グループ販社の発注担当者が、証明書の使用制限に反して、第三者に対し、A社の自営CAで生成された秘密鍵を用いて署名したメールを送付した場合、メール受信者では、どのような問題が発生するか。また、その理由は何か。A社が自営CAを採用していることを考慮して、それぞれ20字以内、30字以内で述べよ。

模範解答

問題:署名の正当性を確認できない。 理由:A社CAのルート証明書を導入していないから

解説

解答の論理構成

  1. 利用範囲の制限
    • 本文では、X課長が「⑤グループ販社では、証明書をNシステム以外の用途に使用しないように、徹底してくれ。」と指示しています。
    • これは当該証明書が“社内限定 PKI”であり、想定された通信相手(A社・グループ販社間)だけが署名検証用の信頼ルートを導入していることを示唆します。
  2. 想定外の第三者へ送信した場合
    • 相談されたシナリオは「グループ販社の発注担当者が、証明書の使用制限に反して、第三者に対し、A社の自営CAで生成された秘密鍵を用いて署名したメール」を送付するケースです。
    • 第三者は A社の自営 CA を全く知らず、当然「ルート CA 証明書」をメールソフトにインポートしていません。
  3. 検証失敗のメカニズム
    • 電子署名の検証は「署名者証明書 → 中間 CA 証明書 → ルート CA 証明書」と信頼の連鎖をたどります。
    • ところが第三者の環境には「A社の自営CA」のルート証明書が存在しないため連鎖が切れます。
    • その結果、メールソフトは「この署名は信頼できない」または「検証できない」と表示します。
  4. したがって
    • 発生する問題:署名の正当性が確認できず、送信者の真正性や改ざん有無を受信者が判断できません。
    • 理由:第三者は A社 CA を信頼していない(ルート証明書未導入)ため、検証用公開鍵が取得できないからです。

誤りやすいポイント

  • 「秘密鍵を漏えいしたから改ざんされる」と短絡的に結論づける
    → 問われているのは“受信者側”の課題であり、漏えいではなく“信頼ルート不在”が本質です。
  • 「メールが復号できない」と回答する
    → 問題は暗号化ではなく署名検証です。暗号化なら公開鍵が必要ですが、本問は署名のみ。
  • 「自営CAだから必ず危険」と一般化する
    → 自営CA自体は問題ではなく、“信頼ルートを共有していない第三者”が検証できない点が焦点。

FAQ

Q: ルート証明書を配布すれば第三者も署名を検証できますか?
A: はい。第三者が A社 CA のルート証明書を信頼ストアへ登録すれば検証可能になります。
Q: 署名検証に失敗したメールは必ず拒否されますか?
A: 一般的なメールソフトは“警告”を表示するだけで内容閲覧は可能です。ポリシーで拒否設定も可能です。
Q: グループ販社が意図的に使用範囲を逸脱した場合の監査対策は?
A: 署名付きメールのログと CA 発行ログを照合し、不適切な送信先を検出する監査が有効です。

関連キーワード: 電子署名、ルート証明書、信頼連鎖、自営CA, 公開鍵基盤
戦国ITクイズ機能

\ せっかくなら /

情報処理安全確保支援士
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について