情報処理安全確保支援士 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. 保護対象と脅威の確認

• 本文に「開発サーバには、M社の機密情報であるソフトウェアパッケージのソースコードを保管している」とあり、開発サーバを保護する必要があります。
• 図2に「ネットワークで接続された、他のPC、サーバに感染を広げる」とあるように、開発部のPCが感染すると開発サーバへ横移動してしまうリスクがあります。本文にも「現状、開発部のPCがマルウェアに感染してしまうと、そのマルウェアからアクセスされるリスクが高い」と明記されています。

1. 現状のL3SWルールの把握（なぜ変更が必要か）

• 表3の項番1は「利用者セグメント2→開発サーバセグメント」を「許可」しており、項番2は逆方向を許可しています。したがって現状は利用者セグメント2から開発サーバセグメントへの通信が通る状態です。
• 表3の項番5・6は拒否ルールですが、注記に「項番の小さいものから順に、最初に一致したルールが適用される」とあるため、項番1等の許可ルールが先に評価され、項番5・6は実効がない状態になっています。よって単に項番5・6が存在するだけでは保護されません。

1. どの変更が目的を満たすか（論理）

• 対策の方針は、開発以外のPC（利用者セグメント2等）から開発サーバへのアクセスを遮断することです。一方で「開発専用PCを数十台、開発サーバセグメント内に置き…」とあるので、正当な開発作業は開発サーバセグメント内で完結させれば影響を避けられます。
• これを実現するには、L3SWにおいて「利用者セグメント2から開発サーバセグメントへの通信を拒否する」ルールを、項番1よりも前（＝優先的に評価される位置）に追加する必要があります。こうすれば最初に当該方向が拒否され、開発以外の端末からの不正アクセスは防げます。

誤りやすいポイント

• 方向の取り違え：遮断すべきは「利用者セグメント2→開発サーバセグメント」であり、逆向きを遮断しても感染端末からのアクセスは止まりません。
• 既存の拒否ルールを有効と誤認する：項番5・6が存在していても、ルール順（ファーストマッチ）により項番1等の許可が先に適用される点を見落とすと誤答します。
• 粗い全域拒否の副作用：表3の「全セグメント[1]」はDMZやインターネット等も含むため、これらを上位に置いてしまうとプロキシやウイルス定義の取得等の正当な通信が阻害されます。
• セグメント番号の混同：利用者セグメント1（営業・スタッフ側）と利用者セグメント2（開発部）を取り違えると、業務影響や保護対象が変わります。

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