情報処理安全確保支援士 2020年 秋期 午後1 問02

解答の論理構成

1. 問題文の確認
   • 引用︓「・ディレクトリへのアクセスは、標準でTCPポートの389番を使用する a を用いる。」
2. ポート番号から該当プロトコルを導出
   • TCPポート「389」はディレクトリサービスの標準プロトコル「LDAP（Lightweight Directory Access Protocol）」が割り当てられています。
3. 結論
   • よって a に入る英字5字以内のプロトコル名は「LDAP」です。

誤りやすいポイント

• 「LDAPS」と答えてしまう
  • 636番ポートを使うSSL/TLS版であり、389番ポートの条件に合いません。
• 「X.500」と混同する
  • X.500はディレクトリサービスのモデル名であって通信プロトコル名ではありません。
• FTPやHTTPなど他プロトコルのポート番号との取り違え

FAQ

解答の論理構成

1. 【問題文】には
   “PCのWebブラウザでは、HTTPSでアクセスするWebサーバのサーバ証明書が失効していないことを、RFC 6960で規定されているbを利用して確認できるようにしている。”
   とあります。
2. ここで鍵となる情報は
   ・“RFC 6960”
   ・“サーバ証明書が失効していないことを確認”
   の2点です。
3. 公開鍵基盤（PKI）において証明書失効情報をオンラインで照会するプロトコルは “OCSP（Online Certificate Status Protocol）” であり、これは “RFC 6960” で定義されています。
4. したがって、b に入るプロトコル名は “OCSP” が妥当です。
5. よって解答は
   b：OCSP
   となります。

誤りやすいポイント

• 「CRL（Certificate Revocation List）」と混同する
  RFC 6960はOCSPを定義しており、CRLはRFC 5280で扱われます。
• “OCSP” を “OSCP” と綴り間違える
  スペルミスでも減点対象になります。
• “OCSP Stapling” と答えてしまう
  OCSPはプロトコル名、OCSP StaplingはWebサーバ実装時の最適化技法で別概念です。

FAQ

解答の論理構成

1. 表3の項番1は「送信者から受信者まで暗号化された状態で、メールを送受信する。」と定義しています。
2. 「メールの通信を暗号化」とは、SMTP over TLSなどでMTA間・MUAからMTAまでを暗号化する方式を指します。
3. しかしメールは転送途中で必ずメールサーバ（内部メールサーバや外部メールサーバ）のディスクに一時保存されます。
4. その保存時点では、暗号化通信の保護は終了し、メール本文はサーバ内で平文のまま保管されることが一般的です。
5. よって「送信者から受信者まで」の経路にサーバ上の保存フェーズも含めると、通信暗号化だけでは表3の目的を満たせないという結論になります。
6. 以上から導く理由は「メールサーバ上では暗号化されていないため」です。

誤りやすいポイント

• TLSで通信路を守ればデータもずっと暗号化されていると誤解しがちです。
• S/MIMEやPGPのようなコンテンツ暗号化と、TLSのような通信経路暗号化を混同しやすいです。
• 「送信者から受信者まで」の範囲にサーバ内保存を含め忘れると、要件を読み違えます。

FAQ

解答の論理構成

1. 問題文は、通信経路の暗号化だけではなりすまし対策が不十分であることを示す箇所として、 “攻撃者が委託先を装ったcを用意するようななりすましは、送信元のcの真正性を確認して検出できる。”
   と記述しています。
2. 委託先を装うために攻撃者が準備する機器・サービスは、メールを受け付けて配送する装置である必要があります。したがって “c” にはメールの配送主体である「メールサーバ」が入るのが自然です。
3. 同じ文の後半に “送信者メールアドレスとして委託先のメールアドレスを使うようななりすましは検出できない” とあり、ここでは送信経路上のSMTPサーバ（＝メールサーバ）の真正性確認だけではメールアドレス詐称を防げないという対比が取られています。
4. 以上より、c に当てはまる語は「メールサーバ」です。

誤りやすいポイント

• 「ドメイン名」や「証明書」など、似た文脈の単語を入れたくなるが、攻撃者が“用意する”対象は装置・サービスそのものなので不適切です。
• “送信元の真正性の確認”を指す対象がユーザではなくサーバである点を取り違えると誤答になります。
• “メールアドレス詐称”との対比構造を読み落とすと、文意を逆に解釈してしまう恐れがあります。

FAQ

解答の論理構成

• 【問題文】では「（え）後でも参照する必要があるメールは、②復号できなくなる場合に備えて、復号してファイルサーバに保存する。」と記載されています。
• S/MIMEでは受信者の公開鍵で暗号化し、受信者が保持する秘密鍵で復号します。したがって秘密鍵を失えば復号は不可能になります。
• 「備えて」とあるのは、将来「秘密鍵が利用できなくなる」リスクを想定していることを示唆しています。
• S/MIME証明書自体が失効しても、秘密鍵さえ保持していれば過去メールの復号は可能なので、真に「復号できなくなる」原因は秘密鍵の喪失・削除です。
• 以上より解答は「復号に必要な秘密鍵を意図せず削除した場合」となります。

誤りやすいポイント

• 証明書の「失効＝復号不可」と誤解しがちですが、秘密鍵が残っていれば過去メールは復号できます。
• 「PCの故障」や「パスワード忘失」を理由に書くと、直接的には秘密鍵の消失を示していないため減点対象になります。
• 「公開鍵を削除」と書くミス。公開鍵は送信側が保持しており、受信側の復号には不要です。

FAQ

解答の導き方

1. d／e（（ア）・（イ）の箇所）

• 本文に「R社CAのようなプライベート認証局のルート証明書をPCに登録することが、委託先によっては禁止されており、その場合、R社の従業員が送信したメールのdをeすることができない」とあります。この文章は「ある種類の付加情報（メールに付けるもの）を受信側で確認（＝検証）できない」という意味です。
• 同じ箇所近くに「S/MIMEを用いてdを付与したメールを送信すれば、受信者はS/MIME証明書も受け取れるし、送信者が他者になりすましていないことも確認できる」とあることから、dは送信者の正当性（なりすましでないこと）と整合性を示す仕組みに該当します。これに合致するのは「ディジタル署名」です。
• また「検証できない」とある動詞に対応する語が必要で、署名の正当性を確認する行為は「検証」です。したがって d は ディジタル署名、e は 検証 と判断できます。
• 技術的根拠（S/MIMEの仕組み）も押さえます。S/MIMEではメッセージのハッシュ（ダイジェスト）を作成し、送信者の秘密鍵でそのハッシュに対して署名を行ってディジタル署名を生成します。受信者は添付されたS/MIME証明書から送信者の公開鍵を取得して同じハッシュを計算し、公開鍵で署名を検証します。検証には証明書のチェーン確認や失効確認が必要で、発行元のルート証明書が受信側で信頼されていることが前提になります。したがって、受信側でR社CAのルート証明書が登録されていないと署名の検証ができません。

1. f／g（（ウ）の提案（1）〜（6）の箇所）

• 本文に「Gサービスでは、メールをMLのメールアドレス宛てに送信すると、登録されたメンバのメールアドレス宛てに同報される」とあり、ML宛てメールはGサービスが登録メンバへ転送する仕組みであることが分かります。
• （ウ）の案では、(1)に「GサービスにfのメールアドレスのS/MIME証明書を登録する」、(2)に「あらかじめ、gのメールアドレスのS/MIME証明書の発行手続きをG社に依頼する」、(3)に「メール送信者は、gのメールアドレスのS/MIME証明書を使って暗号化したメールを送信する」、(4)に「Gサービスは、メールを復号する」、(5)に「Gサービスは、fのメールアドレスのそれぞれのS/MIME証明書を使い…再暗号化する」とあります。これを順に読むと、送信者はまずMLのアドレス（中継を受けるアドレス）用の証明書を使って暗号化し、GサービスがそのMLアドレスの秘密鍵で復号してから、登録メンバ個々の証明書で各人向けに再暗号化して配信する設計であることが分かります。
• したがって (1) に登録するのはMLに登録されている各メンバのメールアドレス（＝MLの登録メンバ）用の証明書であり、(2)/(3) で証明書を作る対象はML自体のメールアドレス（ML）です。よって f はMLの登録メンバ、g はMLです。
• なお本文にもある通り、この案はG社が「対応できない」と回答したため、実運用ではMLを使わず個別の委託先担当者のS/MIME証明書で暗号化して送信する運用にしたと記載されています。

誤りやすいポイント

• 「通信の暗号化（SMTP over TLS等）＝S/MIMEによる暗号化（エンドツーエンド）だ」と混同する。TLSはホップ間保護であり、中継サーバや保管領域では平文が扱われうる点を区別する必要があります。
• ディジタル署名を「メッセージ全体を送信者の秘密鍵で暗号化する」と誤解する。正しくはメッセージのハッシュに対して送信者の秘密鍵で署名を行い、受信者は公開鍵で署名を検証します。
• 署名付きメールに証明書が添付されるからといって、それだけで署名の「信頼性」が保証されるわけではない。証明書自身のチェーン検証や失効確認が必要です。
• MLのような複数受信者への配信では、エンドツーエンド暗号化には各受信者の公開鍵が必要か、あるいは中継側で復号・再暗号化する仕組みが必要で、その運用・信頼性・プライバシーの問題を見落としがちです。
• プライベートCAを使う場合、受信側でルート証明書を信頼できるように設定されていなければ署名検証や暗号化メールの復号ができない点を忘れないこと。

FAQ