1. 物語の舞台（誰が・何を・どこで）
-
会社とシステム
L社はECサイトを運営。買い物額に応じてポイントを付与する「Pシステム」をポイントサービス部が運用しています（図1参照）。問題文は、このPシステムのネットワーク構成と運用を前提に、脆弱性診断の計画づくりを読み解く形式です。 -
図1の大枠
本番環境とステージング環境があり、DMZ／DB-LAN／管理LANが分離。各サーバはサービス用NICと管理用NICを二つ持つこと、DMZ→DB-LANはFW1経由であることなどが注記で明示されています。ステージングのデータはテストデータです。 -
時間帯別トラフィック
受信量の比率：0–8時 2%、8–16時 55%、16–24時 43%。これが**診断時間帯の最適化（影響最小化）**に効いてきます。
2. 機器の役割（表1と図2の読み方）
-
N-IPS（ネットワーク型IPS）
「遮断モード」で稼働中。判定は①ホワイトリスト（登録IPは“脅威ではない”扱い）→②脅威通信判定の順で、最初に合致したルールが適用。いまはホワイトリストは空。ここ、設計議論や“なぜ無効化で検出項目が増えるか”の根拠になります。 -
FW1（DMZ⇔DB-LAN）
必要な通信だけ許可。通常はインターネット→ステージングWebは拒否、利用時だけ許可。 -
FW2（管理PCセグメント→各サーバ）
管理PCセグメント→本番/ステージングの各サーバは許可、それ以外は全拒否。のちに**特定通信の“送信元限定”**ルールへ修正され、接続点変更の話に直結します。 -
本番DBサーバの“ホスト型IPS”（図2）
①ホワイトリスト設定（登録IPのみ許可）と②侵入検知設定（脅威は拒否）から構成。拒否が発生すると“警告灯”が点灯し、運用が緊急対応体制に入る仕掛け。診断時に誤点灯を防ぐ設定変更の論点はここ。
3. 診断サービスの前提（PF診断とWeb診断）
-
診断の仕組み
診断PCから対象機器へ通信しレスポンスで脆弱性を確かめます。PF（プラットフォーム）診断は全ポートの検査でOS/ミドルの脆弱性を狙い、Web診断はWebアプリの脆弱性を狙う——という二本立てです。 -
Web診断の運用方針
診断用ユーザIDを作成してポイント付与しログイン診断、未ログインページも診断、不可逆なデータ更新が生じる検査はしない。この“診断用ID”は後のレビュー指摘の**「bを削除」**とつながります。
4. 診断計画ドラフト（表2）と会話の要点
-
会話：N-IPSを“無効化”するか
無効化するとより多くの脆弱性を検出し得るが、本物の攻撃も通ってしまうリスク。主任は「**N-IPSを無効化せず、設定変更（ホワイトリスト活用）**で対応すべき」と助言。内部（接続点a）からのPF診断も必要と指示。 -
表2：診断1/診断2の構成
診断1＝本番Webの脆弱性（ネット経路と内部接続点aの両方からPF＋Web診断）。診断2＝本番DBの脆弱性（接続点eからPF診断）。**「サービスダウンの恐れのある項目も含めて実施」**しつつ、不可逆更新は除外という枠組み。
5. 診断計画レビュー（指摘1〜3）が示す“正解の道筋”
-
指摘1（Web診断はステージングで）
本番影響を避けるためにWeb診断はステージングで実施。終わったらFW1を元に戻し、ステージングの「b」を削除せよ——この**b＝“診断用の利用者ID”**に当たるのがポイント。 -
指摘2（PF診断は本番で、でも影響最小化）
PFは本番でやる。ただしサーバ停止の影響を最小化するよう計画の一部（＝日時）を変更するのが筋。トラフィックが最も少ない0–8時がヒントです。 -
指摘3（警告灯が点かないよう事前調整）
運用グループに“機器設定の変更”を依頼し、診断中に誤検知→警告灯→社内混乱を避ける段取りを明示。これは本番DBのホスト型IPSのホワイトリスト＋侵入検知の扱いに紐づきます。
6. その後の運用側提案（FW2ルール修正による接続点変更）
-
経緯
新任がWeb管理PC→本番DBへログイン試行し警告灯が点灯。再発防止でFW2のルールを修正し、c宛の通信は、dからの通信だけをe（許可/拒否）に。これにより診断2の接続点を(e)→(d)に変更する必要が出た——という流れ。ここでc＝本番DBサーバ、d＝DB管理PC、e＝許可が読み解きの正解方向です。
7. 設問で“どこを拾えば点になるか”（問題文→根拠）
以下は“問題文のどの記述が根拠になっているか”の道案内です。
-
設問1(1)：①の理由
「N-IPSの脅威通信判定を無効」にするとこれまで遮断されていたPF診断の通信が通るため、“より多く検出”。根拠はN-IPSの遮断モードと判定順序の説明。 -
設問1(2)：②の設定変更
N-IPSに診断PCのIPをホワイトリスト登録。無効化せずに通したい通信だけ安全に通過させる狙い。 -
設問1(3)：aの接続点
会話で「図1中の接続点aに接続して診断」と主任が明言。図中の(a)を選ぶ。 -
設問2(1)：b の正体
「診断用の利用者ID」。Web診断をステージングで行った後、削除すべき対象として合致。 -
設問2(2)：③の計画変更（“何をどう”）
変更する項目＝日時、内容＝0–8時に実施（影響最小化）。受信量の比率が根拠。 -
設問2(3)：④で変える“機器と設定”
機器＝本番DBサーバ（ホスト型IPS）。診断PCのIPをホワイトリスト登録＋侵入検知設定を無効化で、警告灯の誤点灯と混乱を防止。 -
設問2(4)：c/d/e
運用の再発防止策の説明から、c＝本番DBサーバ、d＝DB管理PC、e＝許可が導けます。
8. ひっかけ・読み違いを避けるコツ
-
“無効化”と“ホワイトリスト”の混同
N-IPSの**無効化（危険）とホワイトリストで通す（安全側の例外）**はまったく別。判定順序（WL→脅威判定）を押さえると一本筋が通ります。 -
“Web診断は本番か？”問題
Web診断はステージング、PF診断は本番という住み分けがレビュー指摘で確定。設問で迷わないように。 -
“警告灯”の発火点
本番DBのホスト型IPSが拒否すると点灯。診断で不用意に点灯させない設定（WL登録や検知無効の一時化）が要件。 -
“最小影響”の裏付け
**時間帯比率（0–8時が2%）**を必ず根拠に使う。感覚論で“夜ならOK”では点になりにくい。 -
接続点の取り違え
診断1の“内部から”は接続点a、診断2は当初**(e)**だが、FW2ルール変更の提案で(d)へ——という前提更新に注意。
