情報処理安全確保支援士 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. S/MIME で送信者を証明する手段
   • 【問題文】「S/MIMEを用いてdを付与したメールを送信すれば、受信者はS/MIME証明書も受け取れるし、送信者が他者になりすましていないことも確認できる」
   • S/MIME ではメール本文とハッシュ値を秘密鍵で暗号化し“ディジタル署名”を生成します。したがって d には「ディジタル署名」が入ります。
2. 署名を確かめる行為
   • 【問題文】「その場合、R社の従業員が送信したメールのdをeすることができない。」
   • 署名のハッシュを公開鍵で復号し、本文のハッシュと照合する行為は“検証”です。よって e は「検証」となります。
3. ML の一斉配信で使う証明書登録対象
   • 【問題文】「(1) R社のプロジェクト管理者は、あらかじめ、GサービスにfのメールアドレスのS/MIME証明書を登録する。」
   • Gサービスが同報するのは「登録されたメンバ（以下、登録メンバという）のメールアドレス」。従って、証明書を登録する対象は「MLの登録メンバ」のアドレスです。よって f は「MLの登録メンバ」です。
4. 発行依頼するメールアドレス
   • 【問題文】「(2) R社のプロジェクト管理者は、あらかじめ、gのメールアドレスのS/MIME証明書の発行手続きをG社に依頼する。」
   • (1) で各メンバの証明書を登録する前提として、まず ML 自身が復号に使う証明書を取得しなければなりません。したがって、発行手続きを依頼するのは「ML」のメールアドレスです。よって g は「ML」となります。

誤りやすいポイント

• 署名と暗号化の混同
  「暗号化＝改ざん防止」と短絡し、“ディジタル署名”ではなく“暗号化”を選びがちです。
• 検証と復号の混同
  署名の真正性を確認する操作は復号ではなく検証です。
• ML 関連語の取り違え
  「ML」「登録メンバ」「プロジェクト管理者」の三者を整理せずに読むと、誰の証明書を登録・発行するのかを誤解しやすくなります。

FAQ