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

解答の論理構成

1. 外部メールサーバのフィルタリングでは、送信ドメイン名がブラックリストに載ると当該ドメインのメールを “外部から受け取る” 際に拒否します。
   • 【問題文】「外部メールサーバにある、外部からのメールのフィルタリング機能」
   • K部長が懸念した①の文脈は「送信ドメイン名のブラックリストに当社のドメイン名を指定」した場合です。
2. 自社ドメインを名乗り、かつ社外（インターネット上）のサーバから届く“正規メール”が存在するかを確認します。
   • 【問題文】「サービスX内のメールサーバZは、M社専用であり、製品紹介のメールをM社の顧客に対して自動送信すると同時に、メールの写しをM社営業部員全員に送信している。送信の際には、送信者メールアドレスとしてM社のメールアドレスを使っている。」
3. 上記より、メールサーバZはインターネット上（社外）に設置され、M社ドメインを送信者欄に設定して営業部員へメールを配送します。
4. したがって、ブラックリストに自社ドメインを登録すると、この“メールサーバZから営業部員宛て”の正規メールが拒否されるため、K部長の発言①が成立します。
5. よって解答は「メールサーバZから営業部員宛てに送られるメール」です。

誤りやすいポイント

• 「社内メールサーバ」からの内部メールは FW/L3SW で完結するため影響を受けませんが、これと混同すると解答を誤ります。
• ドメイン偽装対策＝即ブラックリスト、と短絡し “自社が利用する外部サービス” を見落としがちです。
• 「顧客向けメールだけが届かない」と誤解するケースがありますが、営業部員へ送られる写しも遮断されます。

FAQ

解答の論理構成

1. フィルタリング方針
   • 外部メールサーバの機能について【問題文】
     「ホワイトリスト及びブラックリストには、送信元メールサーバのIPアドレスのリスト及び送信ドメイン名のリストがある。」
     「ホワイトリスト及びブラックリストの両方にマッチした場合は、ホワイトリストを優先する。」
   • まず送信ドメイン名が M 社のもの（社内ドメイン）であるメールをブラックリストに登録して遮断する案を採用。
2. 正規メールの遮断という副作用
   • 「サービスX内のメールサーバZ」は営業活動で必須の自動送信を行う。
   • その際「送信者メールアドレスとしてM社のメールアドレスを使っている。」ため、ドメイン名ブラックリストに一致してしまう。
   • K 部長が指摘した「①正規のメールも一部届かなくなるね」はこれを示す。
3. 正規メールだけを通すための追加ルール
   • メールサーバ Z は固定の送信元 IP アドレスを用いる前提。
   • ホワイトリストへ IP アドレスを登録すれば、同じメールが
     ・ドメイン名 → ブラックリストに一致
     ・IP アドレス → ホワイトリストに一致
     となり「ホワイトリストを優先する」仕様により受信が許可される。
4. したがって下線②の内容
   送信元メールサーバ Z の IP アドレスをホワイトリストに追加する、が最適解となる。

誤りやすいポイント

• 「ドメイン名をホワイトリストに登録」とすると攻撃者が同じドメインを偽装している場合も通過させてしまう。
• ブラックリストとホワイトリストの優先順位を逆に覚えていると結論が逆転する。
• SPF や DKIM など別方式の対策と混同し、外部メールサーバの機能範囲を超えた回答を書く。

FAQ

解答の論理構成

1. マルウェアYの通信方法
   ・「プロキシサーバを経由せずに、TCPポート番号8050を使用して、アクセスする」（図2）
   ⇒ PC が直接インターネットへ出ようとする。
2. FWで許可されている通信
   ・表2「項番1　送信元: プロキシサーバ　宛先: インターネット　サービス: 全て　動作: 許可」
   ・表2「項番9　送信元: PC　宛先: プロキシサーバ　サービス: 代替 HTTP（8080）　動作: 許可」
   ・表2「項番10　送信元: 全て　宛先: 全て　サービス: 全て　動作: 拒否」
   ⇒ PC からインターネット宛の直接通信は、該当する許可ルールがないため「項番10」で拒否。
3. よって、ポート番号8050による直接通信は FW で遮断される。
   以上から「FWのフィルタリングルールで遮断しているから」と解答できる。

誤りやすいポイント

• L3SW ではなく FW がインターネット向け通信を最終的に制御していることを見落とす。
• 表2の「項番1」「項番9」で“PC⇒インターネット”も許可されていると誤読する。いずれも宛先・送信元が限定されている。
• 「TCPポート番号8050」だけを遮断する特定ルールが存在すると想像し、デフォルト拒否ルールの効果を忘れる。

FAQ

解答の論理構成

1. 【問題文引用】
   「営業部では、SaaS型クラウドサービスであるサービスXを利用して顧客管理を行っている。サービスXには、営業部のPCから、HTTPのCONNECTメソッドを使用してプロキシサーバ経由でアクセスしており、プロキシサーバからサービスXへのアクセスにはポート番号2560を使用している。」
2. 表4のアクセス制御ルール
   • 項番1　CONNECT／443／許可
   • 項番2　CONNECT／全て／拒否
     → CONNECTでポート番号2560を使う通信は項番2に該当し、遮断されます。
3. 【問題文引用】
   「K部長：表4の設定では④業務に支障が出るので…」
   支障が出る＝遮断されたポート2560を用いる業務です。
4. ポート2560を使用するのは「サービスXを利用した顧客管理」だけであり、従って影響を受ける業務は顧客管理です。

誤りやすいポイント

• 「メール自動送信」や「製品紹介」などサービスXの副次機能に目を奪われ、本質である「顧客管理」を見落とす。
• ポート番号2560だけをキーワードにし、どの業務が依存しているかを追わない。
• 「営業部の業務」と大まかに答えてしまう（設問は具体的業務名を要求）。

FAQ

解答の論理構成

1. 業務要件の把握
   【問題文】には「サービスXには、営業部のPCから、HTTPのCONNECTメソッドを使用してプロキシサーバ経由でアクセスしており、プロキシサーバからサービスXへのアクセスにはポート番号2560を使用している。」とあります。
   つまり CONNECT 方式・ポート番号2560 が日常業務で必須です。
2. 現状ルール（表4）の確認
   表4 の初期設定は
   ・項番1　CONNECT／443／許可
   ・項番2　CONNECT／全て／拒否
   ・項番3　全て／全て／許可
   となっており、CONNECT で 443 以外のポートは「最初に一致したルール」で拒否されます。したがって 2560 は通信不可です。
3. 追加ルールの必要性
   K部長が「表4の設定では④業務に支障が出る」と指摘し、「⑤項番1と項番2の間に設定を1行追加」すると述べています。CONNECT 2560 を許可しないとサービスXが利用できず、まさに“業務に支障”です。
4. 追加ルールの具体内容
   項番1（CONNECT 443 許可）の直後に、同じく CONNECT でポート番号2560 を許可する行を追加すれば、業務通信のみ通し、それ以外の CONNECT は項番2で遮断されます。
   よって追加行は
   ・メソッド：CONNECT
   ・ポート番号：2560
   ・動作：許可
   となります。

誤りやすいポイント

• 「HTTPS＝443」と短絡し、サービスXのポート番号2560を見落とす。
• 追加行を項番2の後ろに置き、既に“拒否”とマッチして機能しない並び順ミス。
• 「HTTP メソッド＝GET/POST」と思い込み、CONNECT を許可し忘れる。
• 2560 を外向け FW に許可する設定と混同し、プロキシサーバの ACL での設定場所を誤る。

FAQ

解答の論理構成

1. 現状確認
   • 「表3 L3SWのフィルタリングルール」には、 「項番1　送信元：利用者セグメント2　宛先：開発サーバセグメント　サービス：全て　動作：許可」
     とあり、開発部の通常 PC（利用者セグメント2）から開発サーバへ自由に通信できる状態です。
2. リスクの指摘
   • 本文で「開発部のPCがマルウェアに感染してしまうと、そのマルウェアからアクセスされるリスクが高い」と述べられています。
3. 新しい運用方針
   • 「開発専用PCを数十台、開発サーバセグメント内に置き、ソフトウェアパッケージの開発を開発専用PC及び開発サーバだけで行う」とあるため、通常 PC が開発サーバに直接アクセスする必要はなくなります。
4. ルール変更の方向性
   • したがって「⑥L3SWのフィルタリングルールを変更」する目的は、感染した通常 PC から開発サーバヘの経路を遮断することです。
5. 結論
   • 項番1を「許可」から「拒否」に変更し、「利用者セグメント2 から開発サーバセグメントへの通信を拒否にする」とするのが最適解となります。

誤りやすいポイント

• 双方向とも遮断と勘違いし、項番2（開発サーバ→利用者セグメント2）まで拒否にしてしまう。運用上、ログ閲覧やファイル転送など開発サーバ側からの通信が必要なケースが残る場合もあります。
• 既存ルールを削除せず下位に新規追加すると、上位の「許可」が先にマッチし効果が出ません。必ず既存ルールの動作を「拒否」に変更するか、順序を入れ替える必要があります。
• FW だけで対策できると誤認し、L3SW の内部フィルタに触れないままにする。今回は社内セグメント間のアクセスなので L3SW が制御主体です。

FAQ

解答の論理構成

• 【問題文】では「運用サーバセグメントのサーバについては…運用管理専用PCを運用サーバセグメントに1台設置し…さらに、その運用管理専用PCでは、aを禁止することにした。」と記載されています。
• 運用管理専用PCは管理業務だけに利用する端末であり、不要な機能を持たせるほどマルウェア侵入面が増えます。
• 管理業務に直接関係しないソフトウェア（Web閲覧、メールクライアント、Officeツールなど）は、脆弱性や誤操作を介してマルウェア感染へつながる恐れがあります。
• したがって、運用管理専用PCにおいて禁止すべき事項は「運用サーバセグメントの管理に必要のないソフトウェアの利用」となります。

誤りやすいポイント

• 「インターネット接続の禁止」と短絡的に決め付けると、パッチ適用やツール取得ができなくなる場合があり、管理作業自体を阻害する恐れがあります。
• 「USB機器の使用禁止」だけでは、ネットワーク経由の攻撃を考慮できず不十分です。
• 端末操作そのものを禁止する回答では、管理専用PCの設置目的と矛盾します。

FAQ

解答の論理構成

1. 前提確認
   • 表5の「パスワード長」には「1字から14字まで」とあり、L1ハッシュの最長が分かります。
   • 同じく表5の「文字列分割」欄には「8字以上の場合は、前半7字と残りに分割」とあります。
   • 「パスワード文字種」欄には L1 が「英数字及び記号（合計69種）」、L2 が「英数字及び記号（合計95種）」とあります。
2. b の決定
   • 分割時に前半として扱う最大文字数は「前半7字」です。
   • よって $b＝7$ です。
3. c の決定
   • L1ハッシュは最大7文字までの前半を総当たりします。
   • 1文字長ごとの組合せは $69^i$（$i$ は文字数）なので、
     • 求める総ハッシュ数は ${\sum }_{i=1}^{7}69^i$。
   • よって $c＝69^i$ と表現します。
4. d の決定
   • L1ハッシュが対象とするパスワード全体の最大長は「14字」です。
   • よって $d＝14$ です。
5. e の決定
   • L2ハッシュは分割せず、文字種は「合計95種」です。
   • したがって 1文字長ごとの組合せは $95^i$。
   • よって $e＝95^i$ です。

誤りやすいポイント

• 分割が行われるのは「8字以上」のみという条件を読み落とし、7字未満でも分割すると誤解する。

FAQ

解答の論理構成

• 【問題文引用】
  「Sさん：ソルトを使用するとハッシュ値からパスワードを特定しにくくなります。」
• ハッシュ化のみの場合、同じパスワードは常に同じハッシュ値になります。攻撃者は使い回し可能なレインボーテーブルを作成し、一致する値を高速に検索できます。
• ソルトとは、各パスワードに固有のランダム値を付加してからハッシュを計算する仕組みです。
• 【問題文引用】表5「ソルトの使用の有無 なし」からわかるように、現状はソルト未使用であり、同じパスワードがあれば同じ16バイトのハッシュ値になります。
• ソルトを入れると、同じパスワードでもソルトが違えば入力文字列自体が異なるため、計算されるハッシュ値も変化します。
• したがって、攻撃者はユーザ間・サーバ間でハッシュ値を使い回せず、都度総当たり計算が必要になるため特定が困難になります。
• 以上から、模範解答「同じパスワードでもソルトが異なるとハッシュ値が変わるから」となります。

誤りやすいポイント

• 「ソルトを入れると暗号化される」と誤解し、ハッシュと暗号の違いを混同する。
• 「ソルトでハッシュ長が延びるから安全」と長さだけを理由にする。
• ソルトの目的を「ハッシュ値自体を秘匿する」と書き、ハッシュ関数の一方向性と取り違える。

FAQ