情報処理安全確保支援士 2011年 春期 午後1 問04

解答の論理構成

• 【問題文】の V-2 では「“Sサイトからいったんログアウトした後に、再びログインせずに、URLを直接指定することでSサイトの会員個人の専用情報ページを閲覧できた。”」と報告されています。
• 原因は、ログアウト操作を行っても サーバ側に残っているセッションが有効のまま であるため、ブラウザが同じセッション ID を送り続ければ認証済みとして扱われてしまう点にあります。
• この状況を防ぐためには、ログアウト時に 当該セッションを無効化（破棄） し、次回アクセス時にそのセッション ID が送られてきても認証情報として受け付けないようにしなければなりません。
• 選択肢を見ると
  ・「ア：クッキーにパスワードをセットする」…セキュリティを低下させる誤手段
  ・「イ：再認証を行う」…ログアウト処理そのものではなく追加操作になる
  ・「エ：ログを採取する」…脆弱性の根本対策にはならない
  ・「ウ：セッション情報を破棄する」…ログアウト時にすべき正しい対策
• したがって、a に入る処理は「ウ：セッション情報を破棄する」となります。

誤りやすいポイント

• 「再認証を行う」を選んでしまうミス
  ログアウト後に表示ページへ遷移する前に再認証させるという考え方は一見正しく見えますが、“ログアウト処理そのもの” としてはセッションの無効化が本質です。
• 「ログを採取する」で十分と誤解
  不正閲覧の証跡を残すことは重要ですが、防止策ではなく検知策。設問は防止策を求めています。
• セッション破棄＝クッキー削除と短絡的に考える
  ブラウザ側のクッキーを削除するだけではサーバ側に残るセッションが有効な限り再利用される恐れがあるので、必ずサーバ側でセッションを失効させる必要があります。

FAQ

解答の論理構成

1. 表1の「V-6」では
   ――「Webサーバへのコンテンツファイル転送時の通信を盗聴して、CNT-MGRのパスワードを窃取できた。」
   と報告されています。原因はFTPが平文で認証情報を送るためです。
2. これに対してK課長は
   ――「パスワードを複雑なものに設定し直した上で、コンテンツファイル転送時の認証方法をFTPの認証ではなくSSHのパスワード認証に変更しようと思います。」
   と述べています。
   つまり安全な転送経路としてSSHを利用する方針です。
3. SSH経由でファイルを転送する代表的なコマンドは
   ・scp（Secure Copy）
   ・sftp（SSH File Transfer Protocol）
   の二つです。いずれもSSHトンネル上で暗号化されたままファイルを送受信できるため、V-6の盗聴リスクを解消できます。
4. よって、N社の担当者が使用すべきコマンドは
   「scp」又は「sftp」
   となります。

誤りやすいポイント

• FTPのポート番号だけを変更すれば安全になると誤解し、暗号化プロトコルの導入まで考慮しない。
• SSH導入後も従来どおりftpクライアントを使えると勘違いし、平文転送を続けてしまう。
• rsyncを選ぶ場合でもオプションを誤り、SSHトンネルを確立せずに利用してしまう。

FAQ

解答の論理構成

1. 問題が示す脅威
   表1「V-5」には
   「“CNT-MGRのパスワードを推測して、WebサーバへのFTP接続を何度か試行し、最終的に成功した。”」
   とあり、パスワード総当たり・推測に弱い点が指摘されています。
2. 提示された改善方針
   K課長は「“コンテンツファイル転送時の認証方法をFTPの認証ではなくSSHのパスワード認証に変更”」と述べますが、これだけではパスワード推測の根本的リスクは残ります。
3. G氏の助言
   そこでG氏は
   「“SSHでは、IPアドレス制限に頼らなくても、認証方式をbにすることによって、更にアクセス者を限定できます。”」
   と指摘し、パスワード不要で推測攻撃を受けにくい方式への切替を勧めています。
4. 適切なSSH認証方式の特定
   ・IP制限に依存しない
   ・推測や辞書攻撃を困難にする
   ・ユーザ（N社担当者）ごとに秘密鍵を配布し、公開鍵のみをサーバに登録
   これら条件を同時に満たす一般的な方式は「公開鍵認証方式」です。
5. よって b に入る解答は
   公開鍵認証方式

誤りやすいポイント

• 「パスワードを複雑にする」だけで十分と判断してしまう。パスワード認証では攻撃面は残ります。
• 「多要素認証」や「証明書認証」などと回答しがちですが、SSHの標準的な呼称は「公開鍵認証方式」です。
• IPアドレス制限ができないという条件を見落とし、FW設定での対策を答えてしまう。

FAQ

解答の論理構成

1. 【問題文】には「FWではドロップログ（通信を拒否したログ）だけを収集している。」と明記されています。
2. 同じく下線①では「FWルールに違反してファイルを外部送信する試みの有無をシステム課の担当者が調べるための方法」を尋ねています。
3. ルール違反の通信は FW により拒否されるので、その結果は必ず「ドロップログ」に記録されます。
4. したがって、担当者が定期的にドロップログを点検・分析すれば、外部送信を試みた不正通信の有無と内容を把握できます。
5. 以上より「定期的にFWのドロップログを分析し、拒否した通信から調べる」とするのが最適解です。

誤りやすいポイント

• IDS/IPS の導入やパケットキャプチャなど、問題文に存在しない仕組みを回答に含めてしまう。
• 「許可ログ」を対象にするなど、実際には収集されていないログを前提に考えてしまう。
• 単に「FWログを確認」とだけ書き、どのログ（ドロップログ）をどのように見るかを具体的に示さない。

FAQ

解答の論理構成

1. 【問題文】では「スクリプトファイルに対して、読取り、書込み及び実行が可能である。」と明記されています。ここから、CNT-MGRは任意の Perl スクリプトを作成・配置・実行できることが分かります。
2. さらに「DB接続ツールの実行権限を削除」しても、Rアプリと同じく「Perl用のDB処理モジュール」を呼び出すコードを書けば DB に接続できる状態が残ります。
3. K 課長は「Rアプリで鍵長256ビットのAESを使って、会員データを暗号化…暗号鍵は定数としてスクリプト内に定義」と述べています。よって CNT-MGR がスクリプトを閲覧すれば暗号鍵も取得できます。
4. 以上より、N 社担当者は
   ・自作スクリプトで DB へ接続
   ・取得した暗号鍵で AES 復号
   ・画面やファイルに出力
   という手順で会員データを閲覧できます。
5. 残るリスクを封じる暫定策として、CNT-MGR から「全てのスクリプトファイル」へのアクセス権限を外せば、読み書きも実行もできず上記の手口は阻止できます。

誤りやすいポイント

• 「DB接続ツールの実行権限を削除」しただけで安全と誤解しがちですが、Perl から直接 DBI を呼び出せばツールは不要です。
• 暗号化＝安全と短絡し、スクリプト内の定数鍵を見落とすと脅威分析が不十分になります。
• 減らすべき権限は「DB接続」ではなく「スクリプトファイルへの全アクセス」である点に注意が必要です。

FAQ

解答の論理構成

1. 問題文には、下線④として
   「ほかのWebサイトで大量に盗まれた認証情報が悪用されてSサイトにログイン試行が行われ」
   とあります。これは、多数の“会員IDとパスワードの組合せ”を機械的に投入する典型的な“リスト型攻撃”です。
2. 攻撃者は短時間に多くのIDでログインを試行するため、同じ送信元（同一IPアドレス）から失敗が連続するという特徴が現れます。
3. 既にV‐1対策として「3回連続してログインが失敗したらアカウントをロック」する仕組みは導入予定ですが、これは「一つの会員ID」に対してのみ有効であり、リスト型攻撃ではIDを切り替えられるため無力です。
4. したがって検知条件は、 ・同一IPアドレス
   ・短い時間間隔（一定時間内）
   ・複数の会員IDでの試行
   ・一定回数以上の認証失敗
   を組み合わせることで、アカウントごとの閾値回避を許さず攻撃全体を検知・遮断できます。
5. 以上より模範解答の「一定時間内に同一IPアドレスから複数の会員IDでログイン試行し、かつ、一定回数以上認証失敗していること」が最適となります。

誤りやすいポイント

• 「認証失敗回数」だけに注目し、送信元IPや試行ID数を条件に含めない。これでは攻撃者がIPを変えたり成功率を上げた場合に見逃してしまいます。
• 「同一会員IDの失敗回数」で判断しようとする。問題文が指摘しているのは“IDをたびたび変える攻撃”であり、個別ID監視では検知できません。
• 条件に「時間制限」を忘れる。長期間にわたる少量試行は正常利用と区別しづらいため、時間的な窓を設けることが重要です。

FAQ