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

解答の論理構成

1. 図2の接続先確認手順⑤には
   “もし、SSH接続する際に警告メッセージが表示され、接続が切断された場合、保守用中継サーバのフィンガプリントが変わったか、aという状況が想定される”
   と記載されています。
2. SSHクライアントが保持している既知ホスト情報と一致しない場合に警告が出る典型的な原因は
   ・サーバ側のホスト鍵（フィンガープリント）が変更された
   ・ユーザが意図していない別サーバに接続している
   の二つです。
3. 本文の前半では「保守用中継サーバのフィンガプリントが変わったか」という前者が既に示されているため、後者を a に補えば文意が完全になります。
4. したがって a には
   “接続先が保守用中継サーバではない”
   が入るのが論理的に妥当です。

誤りやすいポイント

• 「DNSが改ざんされた」「IP アドレスが変更された」など細かい原因を直接書くと、文全体の意味が限定され過ぎて減点対象となります。
• “フィンガプリントが改ざんされた” を重複して書くと、前半と同義になり選択肢が二つ揃わなくなります。
• “接続先が第三者サーバである可能性” と抽象化し過ぎると、設問の想定文とズレる場合があります。

FAQ

解答の論理構成

1. 図2では、保守用中継サーバの利用者ID op1／op2について、下線①で「当該利用者IDには、一般利用者の権限を与える」と明示しています。
2. 同じ図2には「保守用中継サーバでのコマンド実行及びその結果…が、保守用中継サーバ上に操作ログとして記録される」こと、さらに「SSH認証ログ及び操作ログへのアクセスには特権利用者の権限が必要」と記載されています。
3. つまり、保守員が用いる ID を「一般利用者の権限」に留めれば、操作ログを書き込むことはできても閲覧や削除には「特権利用者の権限」が必須となり、本人による改ざんや消去を防げます。
4. したがって、下線①の設定目的は「操作ログの改ざんや削除を防止するため」となります。

誤りやすいポイント

• 「最小権限の原則」と答えてしまい、具体的に“操作ログ”に触れない。
• 一般ユーザ権限では操作ログを書けないと誤解し、目的を「ログ出力のため」としてしまう。
• 「SSH 認証ログ」と混同し、操作ログ固有の保全目的を忘れる。

FAQ

解答の論理構成

1. 表1のbは、常時許可される送信元
   • 表1の項番3は「サービス：SSH」「動作：許可」「ログの記録：する」です。
   • 図2に「通常は保守PC－Aから」保守を行うと書かれており、保守PC-AはJ社内「PC-LAN」に常設されています。
   • したがって「保守PC-A」が常時 SSH で「保守用中継サーバ」へ接続できるようにする設定が項番3と判断できます。
     ⇒ b＝「保守PC-A」
2. 表1のcは、平常時は拒否される送信元
   • 項番4は「動作：拒否1)」で、注記1)に「保守PC-B又は保守PC-Cからの保守作業の際は…“許可” に変更」とあります。
   • 図2より「保守PC－B及び保守PC－Cは…スマートフォンでテザリングし、インターネットに接続する。固定のグローバルIPアドレスは付与されない」と明記されています。
   • 固定 IP が無いため送信元を個別 PC で識別できず、インターネット全体を送信元として扱い、作業時間だけ許可に切り替える運用になります。
     ⇒ c＝「インターネット」

誤りやすいポイント

• 「PC-LAN」や「DMZ」を送信元と誤認する
  （保守PC-B/C が社外から来ることを読み落とすミス）。
• 保守PC-B/C の IP を“スマートフォンのキャリア網のアドレス”と具体的に書こうとして原文から逸脱する。
• 項番の昇順適用ルールを無視して、項番4より前に項番3が評価される事実を忘れる。

FAQ

解答の論理構成

1. 通信の発生元・宛先を整理
   • 問題文より、プログラムHは「保守用中継サーバ」で動作し、下線部②で「インターネット上のサーバに通信を試みていた」ことが判明しています。
   • 図1のネットワーク構成で「保守用中継サーバ」は DMZ 内に配置されています。したがって発生元は DMZ、宛先はインターネットです。
2. FW（ファイアウォール）のフィルタリングルールを確認
   • 表1を見ると、DMZ からインターネットへの通信を対象にしているのは
     「6　DMZ　インターネット　全て　拒否　する」です。
3. ログ記録有無を確認
   • 項番6は「ログの記録」が「する」です。よってこのルールに合致したパケットは FW ログに必ず残ります。
4. 以上より、下線②の通信は表1「項番6」に該当します。

誤りやすいポイント

• 「拒否」ルール＝ログに残らないと思い込む
  項番6は拒否ですが「ログの記録」が「する」なので誤解しやすいです。
• ソースを「保守PC」だと早合点する
  プログラムHは DMZ 上のサーバで動いており、保守PC からのアクセスではありません。
• 「全て」サービスを見落とす
  他のルールに具体的なサービス名（SSH など）が並ぶため、任意ポート通信を見逃しがちです。

FAQ

解答の論理構成

1. 接続可否を決めるのはFWのルール
   表1の注記1)に「“保守PC-B又は保守PC-Cからの保守作業の際は、事前申請に記載された作業時間帯だけ、J社のシステム管理者が “許可” に変更する。」と記載されています。
2. 今回の事前申請の作業時間帯を確認
   図3に「保守PC-Cを使って6月14日7時から9時30分に行うという事前申請が出されていた。」とあります。
3. システム管理者は申請どおりFWを変更
   同じく図3に「事前申請に従って、J社のシステム管理者はFWの設定を変更した。」とあります。
4. よって、第三者が保守用中継サーバにSSH接続できたのは、FWが“許可”に変わっていた「6月14日の7時0分から6月14日の9時30分まで」の間となります。
5. 実際に不正アクセスが行われた時刻（7時30分の認証成功）はこの範囲内であり、範囲外での接続痕跡は確認されていません（図3のSSH認証ログ調査結果より）。

誤りやすいポイント

• SSH認証成功時刻「7時40分」や「9時10分」を期間の端点だと誤解し、FW設定が開放されていた全時間を答え忘れる。
• 6月16日のインシデント発覚日を起点に考えてしまい、期間を「6月16日」と誤記する。
• 事前申請の「7時」を「7時30分」と読み違える。申請時刻と実際のログ時刻は別物です。
• 「9時30分」を「9時10分」（保守作業終了）と取り違え、予定通り閉じられたFW設定解除時刻を答え損ねる。

FAQ

解答の論理構成

• 図5には「③鍵ペアの秘密鍵には、十分な強度のパスフレーズを設定する」と明記されています。
• 秘密鍵ファイル自体は保守PCに保存されるため、物理的にコピーされる／マルウェアに窃取される恐れがあります。
• そこでパスフレーズを掛け、鍵を使う際に追加の認証要素を要求することで、ファイルが流出しても即座に悪用できない状態にします。
• 以上より、設定目的は「保守員以外による秘密鍵の不正利用を防止し、盗難時でも攻撃を困難にすること」です。

誤りやすいポイント

• 「パスフレーズ＝公開鍵保護」と誤解し、秘密鍵側を守る意図を抜かす。
• 暗号強度の説明に終始し、運用時の“盗まれても使えない”観点を落とす。
• パスフレーズがユーザ識別のためと考え、真正性確保の説明だけにしてしまう。

FAQ

解答の論理構成

1. 問題文の前提
   ・S氏の提言として「保守用中継サーバ及び顧客管理サーバへのSSH接続の認証方式を、パスワード認証から公開鍵認証に変更する」という記述があります。
   ・図5には「SSHサーバの設定では、公開鍵認証を有効にするとともに、dを無効にする。」とあります。
2. 推論手順
   ① 引用のとおり認証方式を「パスワード認証から公開鍵認証に変更」するためには、公開鍵認証を有効にし、旧方式であるパスワード認証を無効にする必要があります。
   ② よって、空欄 d には無効化される旧方式「パスワード認証」が入るのが自然です。
3. 結論
   d に入る適切な字句は「パスワード認証」です。

誤りやすいポイント

• 「多要素認証」「チャレンジレスポンス」など高度な方式を連想し、図5の流れを読み落とすケース。
• 「鍵ペア」と聞いて“秘密鍵”や“公開鍵”を空欄に入れようとする早合点。
• 「公開鍵認証を有効に」とあるため“公開鍵認証”を無効にすると思い込む逆読み。

FAQ

解答の論理構成

1. 公開鍵認証では「公開鍵」と対になる「秘密鍵」を用いて認証を行います。図5には
   ――「公開鍵認証に使う鍵ペアは、各保守員が保守PCごとに作成し、管理する。」
   とあり、鍵ペアの存在が明示されています。
2. S氏の提言は「保守用中継サーバに保存しない運用」により第三者の流用を防ぐことです。本文には
   ――「顧客管理サーバへのSSH接続に必要eを利用されないように、保守用中継サーバに保存しない運用にしましょう。」
   ――「SSH Agent Forwarding…保守作業のSSH接続に必要なeの全てを保守PCにだけ保存する」
   と記載され、保守PC側だけに保持すべきファイルを示唆しています。
3. SSH Agent Forwarding が外部に持ち出さないのは “秘密鍵” です。公開鍵は相手先サーバへ配布する前提のため「保存しない」対象には該当しません。
4. 以上より、e に入る語は「秘密鍵」と判断できます。

誤りやすいポイント

• 公開鍵と秘密鍵の役割を逆に覚えるミス。公開鍵は配布しても安全、秘密鍵は厳重保管という基本を再確認しましょう。
• 「パスフレーズ」や「鍵ペア」全体と混同して解答するケース。設問は “利用されないように” とあるため、流出すると直接悪用される秘密鍵だけを指します。
• SSH Agent Forwarding を「踏み台サーバに鍵をコピーする機能」と誤解すること。実際は秘密鍵をローカル保持のまま代理署名を行う仕組みです。

FAQ

解答の論理構成

1. 問題文では、保守PC-B/Cを「VPN装置を介して又は直接、M社内のネットワークに接続」したうえで保守用中継サーバにアクセスさせる構想が示されています。
   引用：
   「Fさんは、保守PC-B及び保守PC-Cを、VPN装置を介して又は直接、M社内のネットワークに接続させた後に、インターネット経由で保守用中継サーバにアクセスさせることを考えた。」
2. その直後に、空欄 f が登場します。
   引用：
   「このとき、fことができれば、保守用中継サーバへのアクセスを表1の項番4のルールを変更することによって制限できる。」
3. 表1 項番4 は「送信元：c／宛先：保守用中継サーバ／サービス：SSH／動作：拒否」となっており、送信元条件を絞り込めば “拒否” を “許可” に置き換えて利用者限定のアクセス制御が可能です。
   したがって項番4で「許可」としたい対象を明確に特定できるよう、送信元に静的な値（＝固定 IP アドレス）を割り当てるのが最も直接的な方法になります。
4. VPN 接続や社内ネットワーク経由であっても、グローバル IP アドレスが変動するままでは FW ルールで個別ホストを指定できません。逆に「送信元IPアドレスを固定にする」ことで、FW の送信元欄に特定アドレスを記述し、アクセス元を限定できます。

誤りやすいポイント

• 「VPN で接続＝安全」と早合点し、FW 側での追加制御が不要と考えてしまう。
• 「DNS 名や証明書による制御」を想起しがちだが、FW の送信元欄は IP ベースで評価される点を見落とす。
• 表1 項番3（許可）と項番4（拒否）の違いを読み違え、送信元ではなく宛先側を固定すれば良いと誤答するケース。

FAQ