防御・検知（WAF / Shield / GuardDuty / Inspector 等）

このページで押さえる論点

• 防御の層（SG・NACL・WAF・Network Firewall・Shield の守備範囲）
• AWS WAF（ウェブ ACL・ルール・対象リソース）と ALB との連携
• AWS Shield（Standard と Advanced）による DDoS 対策
• AWS Network Firewall と AWS Firewall Manager
• 見つけるサービス（GuardDuty・Inspector・Macie・Security Hub・Detective）
• どのサービスを選ぶか（選択フロー）

セキュリティグループとネットワーク ACL の詳細は VPC のページで扱っています。

防御の層

攻撃は、通信の量で押し流すもの（DDoS）、通信の中身に悪意のある命令を混ぜるもの（SQL インジェクションなど）、許可していないポートや宛先への通信など、さまざまです。1 つのサービスですべては防げないので、層を重ねて守ります。

OSI 参照モデルでいうと、セキュリティグループ・ネットワーク ACL はレイヤー 3・4（IP アドレスとポート）、WAF はレイヤー 7（HTTP の中身）で判定します。SQL インジェクションや XSS（クロスサイトスクリプティング）はポート番号では見分けられないので、セキュリティグループでは防げず、WAF が必要です。

AWS WAF と ALB の連携

AWS WAF は Web アプリケーションファイアウォールです。ウェブ ACL（ルールをまとめたもの）を作り、保護したいリソースに関連付けます。関連付けできるのは、Application Load Balancer・CloudFront ディストリビューション・API Gateway の REST API・AppSync の GraphQL API・Cognito ユーザープール・App Runner・Verified Access などです。Network Load Balancer には関連付けできません（NLB はレイヤー 4 で動き、HTTP の中身を扱わないため）。

• ルールの評価: ウェブ ACL のルールは優先度（数字の小さい順）に評価され、ブロックや許可のルールに一致した時点で結果が決まります。どのルールにも一致しなければ、ウェブ ACL のデフォルトアクション（許可またはブロック）になります。
• ルールの種類: IP セット（特定の IP アドレスの許可・ブロック）、地理的一致（国単位の許可・ブロック）、文字列や正規表現の一致、SQL インジェクション・XSS の検出、レートベースルール（同じ IP などから一定時間に来たリクエストの数が上限を超えたらブロック）があります。
• マネージドルール: AWS や AWS Marketplace の販売者が用意したルールのセット（一般的な脆弱性対策、既知の悪い入力、ボット対策など）をそのまま使えます。
• アクション: 許可（Allow）・ブロック（Block）・カウント（Count = 一致した数を数えるだけで止めない。ルールを試すときに使う）・CAPTCHA などがあります。

ALB にウェブ ACL を関連付けると、リクエストはALB がターゲットに振り分ける前に WAF で検査され、ブロックされたリクエストは HTTP 403 が返ってターゲット（EC2 など）には届きません。CloudFront を前に置く構成では、CloudFront にウェブ ACL を付けると、攻撃をエッジ（利用者に近い拠点）で止められます。

AWS Shield による DDoS 対策

DDoS 攻撃（分散型サービス拒否攻撃）は、多数の機器から大量の通信を送りつけてサービスを止める攻撃です。AWS Shield には 2 つのレベルがあります。

DDoS に強い構成として、CloudFront や Route 53 などのエッジのサービスを前に置く、Auto Scaling で負荷を吸収する、WAF のレートベースルールで HTTP のフラッド攻撃を抑えるといった組み合わせもよく問われます。

AWS Network Firewall と AWS Firewall Manager

AWS Network Firewall は、VPC 全体の通信を検査するマネージドなファイアウォールです。ファイアウォールサブネットという専用のサブネットに、AZ ごとにファイアウォールエンドポイントを置き、ルートテーブルで「インターネットゲートウェイ・NAT ゲートウェイ・VPN・Direct Connect との間の通信がファイアウォールを通る」ように経路を設定します。

• ステートレスルール: パケットを 1 つずつ、前後の流れを見ずに判定します。
• ステートフルルール: 通信の流れ（接続の状態）を追いながら判定します。ドメイン名のリストで通信先を許可・拒否したり（例: 許可したドメイン以外への外向き通信を止める）、オープンソースの侵入防止システム Suricata 互換のルールで通信の中身を検査したりできます。

セキュリティグループやネットワーク ACL では「IP アドレスとポート」でしか判定できませんが、Network Firewall は「どのドメインへの通信か」「怪しいパターンを含むか」まで見られます。問題文に「VPC からの外向き通信を特定のドメインだけに制限」「VPC の境界で侵入防止（IPS）」とあれば Network Firewall です。Transit Gateway と組み合わせ、検査専用の VPC に集めて複数 VPC の通信をまとめて検査する構成もあります。

AWS Firewall Manager は、Organizations の複数のアカウントにまたがって、WAF のルール・Shield Advanced の保護・セキュリティグループ・Network Firewall などを一元的に設定・適用するサービスです。新しいアカウントやリソースが増えても、ポリシーが自動で適用されます。組織の管理は Organizations のページで扱っています。

見つけるサービス

見つけるサービスは攻撃を止めません。検出結果は Amazon EventBridge に送れるので、「GuardDuty が脅威を見つけたら Lambda で EC2 を隔離する」「SNS で担当者に通知する」のように、自動で対応する仕組みを組み合わせます。Organizations と組み合わせれば、委任管理者のアカウントから全アカウントの検出結果をまとめて管理できます。

どのサービスを選ぶか

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「NLB に WAF のウェブ ACL を関連付けて SQL インジェクションを防ぐ」→ ✕。WAF は NLB に付けられない。ALB・CloudFront・API Gateway などに付ける
• 「セキュリティグループで SQL インジェクションを防ぐ」→ ✕。SG は IP とポートしか見ない。リクエストの中身を見るのは WAF
• 「GuardDuty で攻撃をブロックする」→ ✕。GuardDuty は検出だけ。止めるには EventBridge ＋ Lambda や WAF・SG の変更を組み合わせる
• 「GuardDuty を使うには、先に VPC フローログや CloudTrail の証跡を設定する必要がある」→ ✕。基本のデータソースは有効にするだけで分析される
• 「Inspector で S3 の個人情報を探す」「Macie で EC2 の脆弱性を探す」→ ✕。脆弱性は Inspector、S3 の機密データは Macie
• 「Shield Standard を使うには申し込みが必要」→ ✕。追加料金なしで自動で有効。SRT やコスト保護が必要なら Advanced
• 「WAF のルールは上から全部評価され、最後に一致したルールで決まる」→ ✕。優先度の小さい順に評価し、最初に一致したブロック・許可のルールで決まる

まとめ: SAA 試験で押さえるポイント

• HTTP の中身（SQL インジェクション・XSS）・国・頻度で防ぐのは WAF。ALB・CloudFront・API Gateway などに付け、NLB には付けられない
• WAF のルールは優先度の小さい順に評価し、最初に一致したルールで決まる。一致しなければデフォルトアクション
• DDoS は Shield。Standard は無料・自動、Advanced は SRT・コスト保護・高度な保護
• VPC の出入口でドメインや侵入パターンまで検査するのは Network Firewall、複数アカウントへの一括適用は Firewall Manager
• 見つけるサービス: 脅威は GuardDuty、脆弱性は Inspector、S3 の機密データは Macie、集約は Security Hub、原因調査は Detective
• 見つけるだけでは止まらない。EventBridge で自動対応をつなぐ