AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
- 監視ソフトウェアを導入したインスタンスを配置し、その Elastic Network Interface (ENI) を無差別 (プロミスキャス) モードでのパケットスニッフィングに設定して、VPC 全体のトラフィックを検査する。
- 2 つ目の VPC を作成し、アプリケーション VPC のすべてのトラフィックを、スケーラブルな仮想 IDS/IPS プラットフォームが稼働する 2 つ目の VPC へルーティングする。
- VPC 内で稼働する各サーバーでホストベースの route コマンドを設定し、すべてのトラフィックをスケーラブルな仮想 IDS/IPS プラットフォーム経由で送信する。
- 各ホストにエージェントを導入し、そのエージェントがネットワークトラフィックを収集して、検査のために IDS/IPS プラットフォームへ送信するように構成する。
A. 監視ソフトウェアを導入したインスタンスを配置し、その Elastic Network Interface (ENI) を無差別 (プロミスキャス) モードでのパケットスニッフィングに設定して、VPC 全体のトラフィックを検査する。
Amazon VPC では、ENI をプロミスキャス (無差別) モードにして他インスタンス宛のパケットを傍受することはできない。VPC のネットワークは仮想化されており、自分宛て以外のトラフィックはそもそも ENI に届かない。
オンプレミスのスイッチでミラーポートを作る発想をそのまま持ち込んだ、AWS では成立しない選択肢。「AWS ではパケットスニッフィングできない」は定番の頻出知識。
B. 2 つ目の VPC を作成し、アプリケーション VPC のすべてのトラフィックを、スケーラブルな仮想 IDS/IPS プラットフォームが稼働する 2 つ目の VPC へルーティングする。
「検査用の VPC にトラフィックを寄せる」という発想自体は現代の AWS でも使われる（Gateway Load Balancer とインスペクション VPC の構成）が、この選択肢はその実現手段に一切触れず、単に「すべてのトラフィックを 2 つ目の VPC へルーティングする」と述べているだけ。
とくに同一 VPC・同一サブネット内のインスタンス間トラフィックはルートテーブルで外へ迂回させられないため、VPC 内部の水平方向の通信を検査できない。数千台規模のインスタンス間通信を IDS/IPS に通すという要件には答えられていない。
C. VPC 内で稼働する各サーバーでホストベースの route コマンドを設定し、すべてのトラフィックをスケーラブルな仮想 IDS/IPS プラットフォーム経由で送信する。
ホスト上で route コマンドを使ってルーティングテーブルを書き換える方法は、OS のルーティングだけを変えても VPC 側の実際の経路制御には従わせられないうえ、数千台すべてのインスタンスで OS のルート設定を維持する運用は破綻する。
また、この方式は自ホストが送受信するトラフィックしか扱えず、しかもエージェントのように検査基盤へ確実に転送する仕組みも持たない。スケーラブルでも堅牢でもない。
D. 各ホストにエージェントを導入し、そのエージェントがネットワークトラフィックを収集して、検査のために IDS/IPS プラットフォームへ送信するように構成する。
各ホストに IDS/IPS エージェントを導入する方式なら、インスタンスが増えるほど検査能力も一緒に増える（＝水平スケールする）。AMI や起動テンプレート、Systems Manager などでエージェントを組み込めば、数千台規模でも配布・管理が現実的に回る。
エージェントは自ホストの NIC を通る全トラフィックを OS 内で直接観測できるため、VPC のパケットスニッフィング制約を回避しつつ、VPC 内部の東西トラフィックまで検査対象にできる。
「VPC ではネットワーク側で盗聴できない → ホスト側で採る」という AWS のセオリーに沿った、唯一実現可能な設計であり正解。
VPC で「他人のパケットを盗み見る」構成は作れない。ホスト側のエージェントで集めて送るのが定石。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 既存の VPC 内に IDS/IPS を実装したい | VPC はプロミスキャスモードのパケットキャプチャを許可しない。ネットワーク盗聴型の設計は最初に消える →選択肢（A）を消す |
| 数千台のインスタンスまでスケールする必要がある | インスタンス増加に比例して検査能力が増える方式が必要。ホストごとのエージェントは自然に水平スケールする →選択肢（D）が正解 |
| VPC 内のインスタンス間トラフィックも検査対象になる | 同一 VPC 内の通信はルートテーブルで別 VPC へ迂回させられないため、経路を寄せるだけの設計では取りこぼす →選択肢（B）を消す |
| 数千台規模での運用負荷・確実性 | 各サーバーで OS の route コマンドを手当てする方式は管理不能で、VPC の経路制御にも従わせられない →選択肢（C）を消す |
ひっかけポイント
- 選択肢 A の「ENI を無差別モードに設定」は、オンプレのミラーポートの発想。AWS の VPC では他インスタンス宛のパケットは届かないため、そもそも構成できない
- 選択肢 B は「検査用 VPC にトラフィックを集約する」という今どきの正しそうなキーワードで誘う。しかし Gateway Load Balancer やエンドポイントといった実現手段が一切なく、VPC 内部の東西トラフィックは迂回させられない
- 選択肢 C の route コマンドは「ホストベース」という語で D と紛らわしいが、OS のルート設定と、トラフィックを収集して検査基盤へ送るエージェントは別物
- 「スケーラブル」という語は B・C・D の 3 つに登場する。語ではなく仕組みが本当にスケールするかで判断する
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「サードパーティ製のセキュリティアプライアンスで、VPC を出入りするトラフィックをインラインで検査したい」 | Gateway Load Balancer + GWLB エンドポイントによるインスペクション VPC 構成が正解軸に。 |
| 「トラフィックのコピーを取得して、検査ツールでオフラインに分析したい」 | VPC トラフィックミラーリング（Nitro 世代インスタンス）が正解に。 |
| 「AWS マネージドで侵入検知・ドメイン/IP フィルタリングを実現したい」 | AWS Network Firewall（や、脅威検知だけなら Amazon GuardDuty）が正解軸に。 |
| 「拒否・許可された通信のメタデータ（送信元・宛先・ポート）だけ記録できればよい」 | VPC フローログで十分（パケット本体は不要）。 |
| 「Web アプリケーションへの攻撃（SQL インジェクション等）を防ぎたい」 | L7 の話になり AWS WAF（ALB / CloudFront にアタッチ）が正解に。 |
- 監視ソフトウェアを導入したインスタンスを配置し、その Elastic Network Interface (ENI) を無差別 (プロミスキャス) モードでのパケットスニッフィングに設定して、VPC 全体のトラフィックを検査する。
- 2 つ目の VPC を作成し、アプリケーション VPC のすべてのトラフィックを、スケーラブルな仮想 IDS/IPS プラットフォームが稼働する 2 つ目の VPC へルーティングする。
- VPC 内で稼働する各サーバーでホストベースの route コマンドを設定し、すべてのトラフィックをスケーラブルな仮想 IDS/IPS プラットフォーム経由で送信する。
- 各ホストにエージェントを導入し、そのエージェントがネットワークトラフィックを収集して、検査のために IDS/IPS プラットフォームへ送信するように構成する。