同一アカウント・Regionのinternet-facing ALBにregional web ACLを関連付けている。クライアントはALBへ直接アクセスし、信頼する前段プロキシはない。web ACLのdefault actionはAllowで、このルールの前に評価を終了するルールはない。
監査対象の直接定義したrate-based ruleはAggregateKeyType=IP、EvaluationWindowSec=300、Limit=2000である。ScopeDownStatementはURI pathが/api/loginと完全一致する要求だけを対象とするが、アクションは観測用のCountのままである。
送信元IPごとに直近5分の対象要求が多すぎる場合にアプリ到達前で遮断したい。別IPの低頻度要求と対象外URIはこのルールで巻き込まない。Countから遮断への切替は承認済みで、厳密な秒単位クォータは要求しない。
監査結果に基づく変更と確認として適切なものはどれか。
対象URI・送信元IP別・300秒の集計を維持し、CountからBlockへの変更と実際の遮断を確認する。WAFの推定によるレート制御を厳密なクォータと同一視しない。
詳細解説
信頼できる前段プロキシがないため、任意のヘッダー値を集計元にすると偽装等で制御を回避され得る。指定ヘッダーがない要求はそのルールで評価されないため、欠落時の扱いも確認が必要である。
300秒から60秒への変更は参照する期間を変える。2000件という値だけが同じでも、送信元IPごとに直近5分を評価する条件を維持できない。
現行の集計条件は要件に合うが、Countは遮断しない。条件を維持したBlockと、関連付け・評価順序・実際の最終actionを照合して防御状態を確認する。
CONSTANTはscope-downに一致する全要求をまとめる。別の送信元も同じ上限を共有するため、要件の送信元IP別制御とは異なる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料とALBへのweb ACL関連付け、評価順序、AggregateKeyType、EvaluationWindowSec、Limit、ScopeDownStatement、実効アクションを照合する。利用可能な承認済み検証環境では異なる送信元IPから対象URIへの高頻度・低頻度要求と対象外URIを比較し、時刻・WAFログのルール/action・アプリ到達を記録する。設定反映と検出の遅れを考慮する。
参考にした公式資料
確認できる内容
高頻度の対象IP・対象URIにBlockが適用され、別IPの低頻度要求と対象外URIがこのルールで遮断されないことを確認できる。Count記録だけで遮断完了とせず、2001件目や変更直後の即時遮断を保証しない。
理解のポイント
- AggregateKeyType
- EvaluationWindowSec
- ScopeDownStatement
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
集計対象・単位・評価期間を分ける
ScopeDownStatementに一致するURI path /api/loginだけを集計し、AggregateKeyType=IPで送信元IPごとに別の集計単位を作る。CONSTANTでは対象リクエスト全体を1単位にまとめるため、本問のIP別制御にならない。EvaluationWindowSec=300は直近5分の参照期間であり、チェックの実行間隔ではない。同じIPを共有する利用者も同じ単位に入るため、IP数を利用者数と同一視しない。
CountとBlock、IP情報の出所を監査する
Countは一致した要求を記録して後続評価を続けるため、このルールだけでは遮断しない。Blockは評価を終了して保護対象へ要求を渡さない。ALBへのweb ACL関連付けと、先行する終端Allow等がない評価順序も確認する。本問には信頼する前段プロキシがなく、クライアントが指定できるX-Forwarded-Forを送信元IPの代わりに信用しない。
設定値と実際の制御結果を照合する
WAFのrate-based ruleは推定に基づき動作し、2001件目の即時遮断のような厳密な上限一致を保証しない。設定反映やレート検出にも遅れがあり、集計関連設定の変更でカウントがリセットされる場合がある。ルール設定とWAFログの対象ルール・最終action、アプリへの到達を照合し、別IPと対象外URIへの影響も確認する。