AWS WAFとAWS Shieldのシナリオ判断
攻撃的なWeb要求、正当な利用者の誤遮断、DDoSの追加保護という事例から、WAFとShieldの使い方を判断します。ルールの作成・適用・動作を分けて検証します。
この単元で学ぶこと
- Web要求の条件から適切な防御を選ぶ
- CountとBlockおよび適用範囲を判断する
- DDoS保護の契約条件とアプリ責任を区別する
本文解説
1. 何を条件に止めるか HTTPヘッダーやURLのクエリを見て要求を止めたいならWAFが候補です。送信元とポートだけの制御では、同じHTTPS通信内の要求内容を区別できません。検査したい情報とルールの対象を合わせて、正当な業務要求が通ることも確認します。
2. Countの試験結果 新ルールをCountで試し、1000件中30件が一致したとします。これは一致率3%ですが、このルールが30件を遮断したことではありません。他ルールや最終動作は別に確認します。観測した要求が攻撃なのか正当なものなのかを調べてからBlock等への変更を判断します。
3. 入口の関連付け Web ACLを作っても実際のALBへ関連付けていなければ、その入口へ意図したルールは適用されません。CloudFront経由の入口と、別経路で到達できる入口がある場合も適用範囲を確認します。試験した一経路の成功を別の経路の保証として扱わないようにします。
4. 誤遮断の原因 正当な検索文字列が攻撃パターンに一致する場合があります。ログやサンプル要求から一致した条件を確認し、必要な範囲で調整します。誤遮断の対処として広く防御を無効にすると、攻撃を防いでいた条件も失われるため、影響を測って変更します。
5. コードの修正も進める WAFがSQLインジェクションの試みを止めても、アプリが危険なSQL文字列連結をしていれば修正対象です。同様に出力の扱いが不適切ならXSSへの対策を実装します。要求の検査と、アプリ内でデータを安全に扱う仕組みは補完する対策です。
6. 大量通信への備え DDoSでサービスが使えなくなるおそれがある場合、Shieldの保護と耐障害性のある構成を検討します。Standardの自動保護があっても、全状況で停止時間がゼロになる保証ではありません。より高度な保護や支援が必要ならAdvancedの対象と条件を確認します。
7. 契約と費用の条件 Advancedは追加料金があり、支援や補償機能には適用条件があります。Standardが使えることとAdvancedへ登録したことは別です。加入状況、保護資源、必要設定を確かめ、個別の料金や補償条件は最新公式資料で確認します。固定金額の暗記では判断しません。
8. 動作で確かめる ルール作成の完了報告だけでなく、対象への関連付けと実際の要求の扱いを確認します。許可したい要求、遮断したい要求、誤検出が疑われる要求を分けて試し、観測結果を残します。DDoS対応の通知と担当者の手順も定め、保護を業務運用へつなげます。
図解
重要ポイント
- 一致件数は遮断件数と同じではない。
- 作成・関連付け・実要求の動作を分けて見る。
- 追加保護と安全な実装を組み合わせる。
間違えやすい点
- Countの一致を防御成功の件数として報告する。
- 一経路の保護を全ての入口へ一般化する。
用語解説
- 誤遮断
- 本来許可すべき正当な要求を防御ルールが止めること。
- 関連付け
- 作成したWeb ACLを対応する保護対象へ適用する設定。
- 一致率
- 対象の要求数に対しルールに一致した要求数が占める割合。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。