SAA-031
Application Load Balancerの背後で稼働するWebアプリケーションに対し、SQLインジェクションやクロスサイトスクリプティングを狙ったリクエストを、アプリケーションへ到達する前に遮断したいです。既知の攻撃パターンへの追随を自前のルール保守なしで続けられる構成として、最も適したものはどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：B. AWS WAFのWeb ACLをALBに関連付け、AWSマネージドルール（Core rule set / SQL database）を適用する
解説
SQLインジェクションやXSSはHTTPリクエストの中身（レイヤー7）を検査しないと判定できません。AWS WAFのWeb ACLをALBに関連付け、AWSが継続的に更新するマネージドルールグループを適用すれば、自前でシグネチャを保守せずに既知の攻撃パターンを遮断できます。
選択肢ごとの解説
A. サブネットのネットワークACLに、攻撃文字列を含むリクエストを拒否するインバウンドルールを追加する
ネットワークACLはサブネット境界でIPアドレス・プロトコル・ポートを評価するステートレスなフィルタで、HTTPリクエストの中身は見られません。
B. AWS WAFのWeb ACLをALBに関連付け、AWSマネージドルール（Core rule set / SQL database）を適用する
正解です。Web ACLをALBに関連付け、AWSマネージドルールグループを適用することで、レイヤー7の攻撃パターンをアプリケーション到達前に遮断できます。
C. ALBのセキュリティグループに、攻撃元IPアドレスを拒否するインバウンドルールを追加していく
セキュリティグループは送信元IPやポートといったレイヤー3/4の情報しか見ないため、リクエスト本文の攻撃文字列は判定できません。またセキュリティグループには拒否ルール自体が存在せず、許可ルールのみで構成されます。
D. AWS Shield Advancedを契約し、DDoS緩和機能で攻撃を含むリクエストを遮断する
AWS Shieldはレイヤー3/4を中心としたDDoS攻撃の緩和が目的で、SQLインジェクションやXSSのようなペイロード検査は行いません。Shield Advancedの契約にはAWS WAFの利用料が含まれますが、実際にリクエストを検査してブロックするのはWAFのルールです。
実務での使いどころ
AWS WAF は HTTP / HTTPS リクエストをレイヤー 7 で検査する Web アプリケーションファイアウォールで、Web ACL という単位でルールをまとめ、CloudFront ディストリビューション・Application Load Balancer・API Gateway・AppSync・Cognito ユーザープールなどに関連付けて利用する。ルールには、送信元 IP セット、レートベース（一定時間内のリクエスト数によるブロック）、文字列一致や正規表現一致、そして AWS やマーケットプレイスのベンダーが提供するマネージドルールグループがある。マネージドルールグループは AWS 側で継続的に更新されるため、自前でシグネチャを保守する運用が不要になる。 設計上の注意点として、まず「どこに関連付けるか」で防御位置が変わる。CloudFront に関連付ければエッジロケーションで攻撃を落とせるが、ALB に関連付けた場合はリクエストがリージョンまで到達してから評価される。また、マネージドルールを本番へ適用する際は、いきなり Block アクションにすると正規のリクエストまで落ちる可能性があるため、まず Count モードで一定期間動かし、CloudWatch メトリクスやサンプルリクエストで誤検知を確認してから Block に切り替えるのが定石である。WAF の課金は Web ACL 単位・ルール単位の月額とリクエスト数の従量課金で構成される。 SAA-C03 では「SQL インジェクション」「クロスサイトスクリプティング」「OWASP Top 10」「特定 IP からの大量リクエスト」といった語が出たら AWS WAF が正解になる。誤答にはセキュリティグループ（レイヤー 3/4・拒否ルールなし）、ネットワーク ACL（ステートレスな IP / ポートフィルタ）、AWS Shield（DDoS 緩和）が並ぶ。Shield と WAF の役割分担、および WAF を CloudFront に付けるか ALB に付けるかの判断も問われやすい。