大規模Web ApplicationのAttack Mitigation

1. 攻撃を同じ種類として扱わない

大規模ウェブアプリケーションへの攻撃は、どのレイヤーで発生するかによって必要な制御が異なります。

DDoSならAWS Shieldだけ、ウェブ攻撃ならAWS WAFだけという単純な対応ではなく、攻撃レイヤーと経路を分けて考えます。

2. 最初に実際の公開入口を特定する

インターネット
      │
      ▼
Amazon CloudFront
      │
      ▼
Application Load Balancer
      │
      ▼
アプリケーション

この構成で利用者がCloudFront経由だけでアクセスするなら、最初の公開入口はCloudFrontです。CloudFrontを使わずALBを直接公開する構成ならALBが入口です。

攻撃対策では「どのAWSサービスを使っているか」より先に、攻撃者が最初に到達できる場所はどこかを確認します。

3. AWS WAFはHTTP(S)リクエストの内容を評価する

AWS WAFは、ウェブリクエストの内容や送信元などを条件に制御します。SQLインジェクション、XSS、特定URI、HTTPヘッダー、送信元IP、リクエスト量など、HTTP(S)として判断できる攻撃が対象です。

悪意のあるウェブリクエスト
↓
アプリケーションへ到達させたくない
↓
AWS WAFを候補

ウェブACLはAmazon CloudFrontやApplication Load Balancerなど、対応するリソースへ関連付けて使用します。

4. 一般的なウェブ攻撃にはマネージドルールを基礎にする

一般的なウェブ攻撃をすべて独自ルールで再実装するのではなく、要件に合うAWS マネージドルールなどを基礎にし、アプリケーション固有条件を独自ルールで補います。

一般的なウェブ攻撃
→ マネージドルールアプリケーション固有条件
→ 独自ルール大量リクエスト
→ レートベースルール / DDoS対策機能

新しいルールは、正常通信への影響を確認するため、必要に応じてCountで観測してからブロックへ移行します。

5. レート制御では「対象」と「集約単位」を分ける

例えば/loginだけが攻撃されている場合、サイト全体を一律に制限する必要はありません。

どのリクエストを数える？
→ スコープダウンステートメント何を単位として数える？
→ 送信元IP / 転送元IP / 独自集約キーなど

スコープダウンステートメントは評価対象を絞り、集約方法はレートをどの単位で数えるかを決めます。例えば/loginを対象にし、送信元IPごとに集約する設計なら、一部の過剰な送信元だけを制限しやすくなります。

一方、対象となる全/loginリクエストを1つに集約すると、攻撃者のトラフィックによって正常利用者も同じ制御対象になり得ます。

6. AWS Shield StandardはDDoS保護の基礎になる

AWS Shield StandardはAWS利用者へ自動的に提供されるDDoS保護です。特にAmazon CloudFront、Amazon Route 53、AWS Global AcceleratorなどのAWSエッジを利用する構成では、ネットワーク / トランスポート層攻撃に対するAWSの大規模な緩和能力を利用できます。

そのため、DDoS対策だから必ずShield Advancedを選ぶのではなく、標準保護とアーキテクチャで必要な可用性を満たせるかを先に確認します。

7. HTTPリクエストフラッドでは現行のAWS WAF DDoS機能を評価する

AWS WAFでは、通常のレートベースルールに加えてAWSManagedRulesAntiDDoSRuleSetを利用できます。このAnti-DDoS マネージドルールグループはShield Advanced専用機能ではなく、AWS WAFで利用できる高度なDDoS対策です。

2026年3月26日以降、HTTPリクエストフラッド対策ではAnti-DDoS マネージドルールグループが現行の主要な選択肢となっており、Shield Advancedの従来のレイヤー 7 自動緩和だけを新規設計の固定解にはしません。

HTTPリクエストフラッド
↓
要件を確認
├─ レートベースルール
├─ Anti-DDoS マネージドルールグループ
└─ さらに高度な対応水準が必要
   → AWS Shield Advancedも評価

8. Shield Advancedは追加のDDoS対応水準が必要な場合に評価する

高度なDDoS可視性、Shield Response Team（SRT）、プロアクティブな関与、対象となるDDoSコスト保護などが必要な場合、AWS Shield Advancedを評価します。

ただし、契約だけで全リソースが自動的にShield Advanced保護対象になるわけではありません。保護するリソースを指定し、利用する機能の前提条件も確認します。

9. Amazon CloudFrontは攻撃をオリジンから遠ざける

利用者 / 攻撃者
      │
      ▼
AWSエッジ
      │
      ▼
Amazon CloudFront
      │
      ▼
オリジン

CloudFrontを公開入口にすると、AWSエッジ側でトラフィックを受けられます。キャッシュ可能なコンテンツならエッジで応答することで、オリジンが処理するリクエスト量も減らせます。

ただし、CloudFrontの配置だけでウェブ攻撃対策が完成するわけではありません。HTTP(S)リクエストの検査やオリジン迂回防止は別の責任です。

10. CloudFrontとAWS WAFは異なる責任を持つ

インターネット
   │
   ▼
Amazon CloudFront
   │  エッジで受ける
   ▼
AWS WAF
   │  ウェブリクエストを評価
   ▼
オリジン

CloudFrontはエッジを入口にし、AWS WAFはウェブリクエスト内容を評価します。一般的なウェブ脆弱性悪用、特定URIへの大量アクセス、アプリケーション固有の不正リクエストなどを役割ごとに制御します。

11. オリジンへ直接到達できれば防御層を迂回される

             ┌→ CloudFront + AWS WAF
インターネット ┤        │
             │        ▼
             └────→ 公開ALB
                       │
                       ▼
                 アプリケーション

CloudFrontへ強いWAFルールを設定しても、ALBのDNS名へ直接到達できれば、攻撃者はCloudFront / WAFを迂回できる可能性があります。

そのため、CloudFrontを入口にする設計ではオリジンへの直接経路が残っていないかまで確認します。

12. CloudFrontを単一の公開入口にする

CloudFront VPCオリジンでは、プライベートサブネット内のApplication Load Balancer、Network Load Balancer、EC2インスタンスをオリジンとして利用できます。

インターネット
↓
Amazon CloudFront
↓
VPCオリジン
↓
内部ALB
↓
アプリケーション

インターネット向けALBを維持する場合でも、CloudFrontが付与するカスタムHTTPヘッダーをALB側で確認するなど、CloudFront経由のリクエストだけを許可する構成を評価できます。

13. 多層防御では各制御へ別の責任を持たせる

1つのサービスですべてを処理するのではなく、攻撃レイヤーごとに責任を分けて組み合わせます。

14. Auto Scalingと攻撃緩和を混同しない

Auto Scalingは正規トラフィック増加へ対応するために重要ですが、悪意のあるリクエスト自体を減らす制御ではありません。

入口側
AWS WAF / DDoS緩和
↓
不要な攻撃トラフィックを減らす
        +
バックエンド
Auto Scaling
↓
必要な正規トラフィックを処理する

攻撃トラフィックを無条件にバックエンドまで通すと、アプリケーション、データベース、外部API、コストへの負荷が増える可能性があります。

15. 判断フロー

ウェブアプリケーション攻撃対策の要件
        ↓
実際の公開入口はどこ？
        ↓
攻撃レイヤーは？
├─ ウェブ攻撃
│   → AWS WAF
├─ HTTPリクエストフラッド
│   → レート制御 / DDoS対策機能
└─ ネットワーク/ トランスポート DDoS
    → AWS Shield / エッジ構成
        ↓
CloudFrontを入口にできる？
        ↓
オリジンへ直接迂回できる？
├─ はい → 直接経路を制限
└─ いいえ
        ↓
標準保護で対応水準を満たす？
├─ はい → Shield Standardを基礎にする
└─ いいえ → Shield Advancedを評価
        ↓
正常トラフィックへの影響を確認
        ↓
多層防御成立

16. 混同ポイント

まとめ

攻撃を分類
↓
公開入口を特定
↓
AWS WAF / AWS Shield / Amazon CloudFrontを攻撃レイヤー別に配置
↓
オリジン迂回を防ぐ
↓
必要ならShield Advancedを追加
↓
正常利用者への影響を確認
↓
多層防御完成

サービス名の暗記ではなく、攻撃レイヤー・公開入口・迂回経路・必要な対応水準から制御を選択します。

主要AWS公式資料

• AWS WAF — マネージドルールグループ / レートベースルール
• AWS WAF — Anti-DDoS マネージドルールグループ
• AWS Shield Standard / AWS Shield Advanced
• AWS Shield Advanced — アプリケーションレイヤーDDoS対策
• Amazon CloudFront — VPCオリジン
• Amazon CloudFront — Application Load Balancerへの直接アクセス制限