一次情報

• DDoS に対する AWS のベストプラクティス – ホワイトペーパーが更新されました

この極めて重要なホワイトペーパーが「英語のみ」だったため、機械翻訳版をつくってみました。

Source

• AWS Best Practices for DDoS Resiliency
  • First Published June 2015
  • Updated September 21, 2021

Notices

お客様は、このドキュメントの情報を独自に評価する責任があります。 このドキュメント：（a）情報提供のみを目的としており、（b）通知なしに変更される可能性のある現在のAWS製品の提供と慣行を表しており、（c）AWSおよびその関連会社、サプライヤー、または ライセンサー。 AWSの製品またはサービスは、明示または黙示を問わず、いかなる種類の保証、表明、または条件もなしに「現状有姿」で提供されます。 AWSのお客様に対する責任と義務は、AWS契約によって管理されており、このドキュメントは、AWSとお客様の間の契約の一部ではなく、変更するものでもありません。

© 2021 Amazon Web Services, Inc. or its affiliates. All rights reserved.

目次

• 序章
  • サービス拒否攻撃
  • インフラストラクチャLayerAttacks
  • アプリケーションLayerAttacks
• 緩和テクニック
  • DDoS緩和のためのベストプラクティス
• 攻撃対象領域の削減
• AWSリソースの難読化（BP1、BP4、BP5
• 運用テクニック
• 可視性
• サポート
• 結論
• 寄稿者
• 参考文献
• ドキュメントの改訂

概要

分散型サービス拒否（DDoS）攻撃やその他のサイバー攻撃の影響から、ビジネスを保護することが重要です。アプリケーションの可用性と応答性を維持することにより、サービスに対する顧客の信頼を維持することは最優先事項です。また、攻撃に応じてインフラストラクチャを拡張する必要がある場合は、不要な直接コストを回避する必要があります。アマゾンウェブサービス（AWS）は、インターネット上の悪意のある人物から身を守るためのツール、ベストプラクティス、およびサービスを提供することをお約束します。 AWSの適切なサービスを使用すると、高可用性、セキュリティ、および復元力を確保できます。

このホワイトペーパーでは、AWSは、AWSで実行されているアプリケーションの復元力を向上させるための規範的なDDoSガイダンスを提供します。これには、アプリケーションの可用性を保護するためのガイドとして使用できるDDoS耐性のあるリファレンスアーキテクチャが含まれます。このホワイトペーパーでは、インフラストラクチャ層の攻撃やアプリケーション層の攻撃など、さまざまな攻撃の種類についても説明します。 AWSは、各攻撃タイプを管理するのに最も効果的なベストプラクティスを説明しています。さらに、DDoS緩和戦略に適合するサービスと機能の概要を説明し、それぞれを使用してアプリケーションを保護する方法について説明します。

このホワイトペーパーは、ネットワーキング、セキュリティ、およびAWSの基本概念に精通しているIT意思決定者およびセキュリティエンジニアを対象としています。各セクションには、ベストプラクティスまたは機能の詳細を提供するAWSドキュメントへのリンクがあります。

序章

サービス拒否攻撃

サービス拒否（DoS）攻撃は、Webサイトまたはアプリケーションをネットワークトラフィックで溢れさせるなど、ユーザーが利用できないようにする意図的な試みです。 攻撃者は、大量のネットワーク帯域幅を消費したり、他のシステムリソースを拘束したりするさまざまな手法を使用して、正当なユーザーのアクセスを妨害します。 最も単純な形式では、次の図に示すように、1人の攻撃者が単一のソースを使用してターゲットに対してDoS攻撃を実行します。

(図はオリジナルソースの１ページ Diagram of a DoS Attack を参照)

DDoS攻撃では、攻撃者は複数のソースを使用して、ターゲットに対する攻撃を調整します。 これらのソースには、マルウェアに感染したコンピューター、ルーター、IoTデバイス、およびその他のエンドポイントの分散グループが含まれる場合があります。 次の図は、侵害されたホストのネットワークが攻撃に参加し、ターゲットを圧倒する膨大なパケットまたはリクエストを生成していることを示しています。

(図はオリジナルソースの２ページ Diagram of a DDoS Attack を参照)

オープンシステム相互接続（OSI）モデルには7つの層があり、それらはオープンシステム相互接続（OSI）モデルの表で説明されています。 DDoS攻撃は、レイヤー3、4、6、および7で最も一般的です。 レイヤー3および4の攻撃は、OSIモデルのネットワークレイヤーとトランスポートレイヤーに対応します。 このホワイトペーパーでは、AWSはこれらをまとめてインフラストラクチャレイヤー攻撃と呼びます。 レイヤー6および7の攻撃は、OSIモデルのプレゼンテーションレイヤーおよびアプリケーションレイヤーに対応します。 AWSは、これらをアプリケーション層の攻撃として一緒に対処します。 これらの攻撃タイプの例については、次のセクションで説明します。

(表はオリジナルソースの２ページ Open Systems Interconnection (OSI) Model を参照)

インフラストラクチャ Layer Attacks

最も一般的なDDoS攻撃である、ユーザーデータグラムプロトコル（UDP）リフレクション攻撃と同期（SYN）フラッドは、インフラストラクチャレイヤー攻撃です。 攻撃者は、これらの方法のいずれかを使用して、ネットワークの容量を氾濫させたり、サーバー、ファイアウォール、侵入防止システム（IPS）、ロードバランサーなどのシステムのリソースを占有したりする可能性のある大量のトラフィックを生成できます。 これらの攻撃は簡単に特定できますが、効果的に軽減するには、インバウンドトラフィックフラッドよりも迅速に容量をスケールアップするネットワークまたはシステムが必要です。 この追加の容量は、攻撃トラフィックを除外または吸収して、システムとアプリケーションを解放し、正当な顧客トラフィックに対応するために必要です。

UDP Reflection Attacks

ユーザーデータグラムプロトコル（UDP）リフレクション攻撃は、UDPがステートレスプロトコルであるという事実を悪用します。 攻撃者は、攻撃対象のIPアドレスをUDP送信元IPアドレスとしてリストする有効なUDP要求パケットを作成できます。 攻撃者は、UDP要求パケットの送信元IPを偽造（なりすまし）しました。 UDPパケットには、なりすましの送信元IPが含まれており、攻撃者によって中間サーバーに送信されます。 サーバーはだまされて、UDP応答パケットを攻撃者のIPアドレスに返送するのではなく、標的の被害者のIPに送信します。 中間サーバーは、要求パケットの数倍の応答を生成し、ターゲットIPアドレスに送信される攻撃トラフィックの量を効果的に増幅するために使用されます。

増幅率は、応答サイズと要求サイズの比率であり、攻撃者が使用するプロトコル（DNS、NTP、SSDP、CLDAP、Memcached、CharGen、またはQOTD）によって異なります。 たとえば、DNSの増幅率は、元のバイト数の28〜54倍にすることができます。 したがって、攻撃者が64バイトの要求ペイロードをDNSサーバーに送信すると、攻撃対象に3400バイトを超える不要なトラフィックが生成される可能性があります。 UDPリフレクション攻撃は、他の攻撃と比較して大量のトラフィックの原因となります。 UDPリフレクション攻撃の図は、リフレクション戦術と増幅効果を示しています。

(図はオリジナルソースの４ページ UDP Reflection Attack を参照)

SYN Flood Attacks

ユーザーがWebサーバーなどの伝送制御プロトコル（TCP）サービスに接続すると、クライアントはSYN同期パケットを送信します。 サーバーは確認応答でSYN-ACKパケットを返し、最後にクライアントは確認応答（ACK）パケットで応答します。これにより、予想される3ウェイハンドシェイクが完了します。 次の画像は、この典型的なハンドシェイクを示しています。

(図はオリジナルソースの５ページ SYN 3-way Handshake を参照)

SYNフラッド攻撃では、悪意のあるクライアントが多数のSYNパケットを送信しますが、ハンドシェイクを完了するために最後のACKパケットを送信することはありません。 サーバーは、ハーフオープンTCP接続への応答を待機したままになり、最終的には新しいTCP接続を受け入れるための容量を使い果たします。 これにより、新しいユーザーがサーバーに接続できなくなる可能性があります。 攻撃は、リソースが正当な接続に利用できないように、利用可能なサーバー接続を拘束しようとしています。 SYNフラッドは最大数百Gbpsに達する可能性がありますが、攻撃の目的はSYNトラフィック量を増やすことではありません。

アプリケーション Layer Attacks

攻撃者は、レイヤー7またはアプリケーションレイヤー攻撃を使用して、アプリケーション自体を標的にする可能性があります。 これらの攻撃では、SYNフラッドインフラストラクチャ攻撃と同様に、攻撃者はアプリケーションの特定の機能を過負荷にして、アプリケーションを使用不可にするか、正当なユーザーに応答しないようにします。 これは、ごく少量のネットワークトラフィックしか生成しない非常に少ないリクエスト量で達成できる場合があります。 これにより、攻撃の検出と軽減が困難になる可能性があります。 アプリケーション層の攻撃の例には、HTTPフラッド、キャッシュ破壊攻撃、WordPressXML-RPCフラッドが含まれます。

HTTPフラッド攻撃では、攻撃者はWebアプリケーションの有効なユーザーからのものと思われるHTTP要求を送信します。 一部のHTTPフラッドは特定のリソースを対象としていますが、より複雑なHTTPフラッドは、アプリケーションとの人間の相互作用をエミュレートしようとします。これにより、リクエストレート制限などの一般的な緩和手法を使用することが難しくなる可能性があります。

キャッシュ破壊攻撃は、クエリ文字列のバリエーションを使用してコンテンツ配信ネットワーク（CDN）のキャッシュを回避する一種のHTTPフラッドです。 CDNは、キャッシュされた結果を返すことができる代わりに、ページ要求ごとにオリジンサーバーに接続する必要があり、これらのオリジンフェッチにより、アプリケーションWebサーバーに追加の負荷がかかります。

攻撃者は、WordPress pingbackフラッドとも呼ばれるWordPressXML-RPCフラッド攻撃を使用して、WordPressコンテンツ管理ソフトウェアでホストされているWebサイトを標的にします。 攻撃者はXML-RPCAPI関数を悪用して、大量のHTTPリクエストを生成します。 ピングバック機能により、WordPress（サイトA）でホストされているWebサイトは、サイトAがサイトBに作成したリンクを介して別のWordPressサイト（サイトB）に通知できます。サイトBは、サイトAを取得してリンクの存在を確認しようとします。 。 ピングバックフラッドでは、攻撃者はこの機能を悪用してサイトBにサイトAを攻撃させます。このタイプの攻撃には明確な署名があります。WordPressは通常、HTTPリクエストヘッダーのユーザーエージェントに存在します。

アプリケーションの可用性に影響を与える可能性のある悪意のあるトラフィックの他の形式があります。 スクレイパーボットは、コンテンツを盗んだり、価格設定などの競争力のある情報を記録したりするために、Webアプリケーションにアクセスする試みを自動化します。 ブルートフォース攻撃とクレデンシャルスタッフィング攻撃は、アプリケーションの安全な領域への不正アクセスを取得するためのプログラムされた取り組みです。 これらは厳密にはDDoS攻撃ではありません。 ただし、それらの自動化された性質はDDoS攻撃に似ている可能性があり、このホワイトペーパーで説明されているのと同じベストプラクティスのいくつかを実装することで軽減できます。

アプリケーション層の攻撃は、ドメインネームシステム（DNS）サービスを標的にすることもできます。 これらの攻撃の最も一般的なものは、攻撃者が多くの整形式のDNSクエリを使用してDNSサーバーのリソースを使い果たすDNSクエリフラッドです。 これらの攻撃には、攻撃者がサブドメイン文字列をランダム化して、特定のリゾルバーのローカルDNSキャッシュをバイパスするキャッシュバスティングコンポーネントも含まれる可能性があります。 その結果、リゾルバーはキャッシュされたドメインクエリを利用できず、代わりに権限のあるDNSサーバーに繰り返し接続する必要があります。これにより攻撃が増幅されます。

Webアプリケーションがトランスポート層セキュリティ（TLS）を介して配信される場合、攻撃者はTLSネゴシエーションプロセスを攻撃することも選択できます。 TLSは計算コストが高いため、攻撃者はサーバー上に余分なワークロードを生成して読み取り不可能なデータを処理します
（または理解できない（暗号文））正当なハンドシェイクとして、サーバーの可用性を低下させる可能性があります。 この攻撃のバリエーションでは、攻撃者はTLSハンドシェイクを完了しますが、暗号化方式を永続的に再ネゴシエートします。 あるいは、攻撃者は多くのTLSセッションを開いたり閉じたりして、サーバーリソースを使い果たしようとする可能性があります。

緩和テクニック

一部の形式のDDoS緩和策は、AWSサービスに自動的に含まれます。 DDoSの回復力は、次のセクションで説明する特定のサービスを備えたAWSアーキテクチャを使用し、ユーザーとアプリケーション間のネットワークフローの各部分に追加のベストプラクティスを実装することでさらに改善できます。

AWSのすべてのお客様は、追加料金なしでAWS ShieldStandardの自動保護の恩恵を受けることができます。 AWS Shield Standardは、Webサイトまたはアプリケーションを標的とする最も一般的で頻繁に発生するネットワークおよびトランスポート層のDDoS攻撃から防御します。 この保護は常にオンで、事前構成され、静的であり、レポートや分析を提供しません。 すべてのAWSサービスとすべてのAWSリージョンで提供されます。 AWSリージョンでは、DDoS攻撃が検出され、Shield Standardシステムがトラフィックのベースラインを自動的に設定し、異常を識別し、必要に応じて軽減策を作成します。 AWS Shield StandardをDDoS耐性アーキテクチャの一部として使用して、Webアプリケーションと非Webアプリケーションの両方を保護できます。

また、Amazon CloudFront、AWS Global Accelerator、Amazon Route 53などのエッジロケーションから動作するAWSサービスを利用して、すべての既知のインフラストラクチャレイヤー攻撃に対する包括的な可用性保護を構築することもできます。 これらのサービスはAWSグローバルエッジネットワークの一部であり、世界中に分散しているエッジロケーションからのあらゆるタイプのアプリケーショントラフィックを処理するときに、アプリケーションのDDoS復元力を向上させることができます。 アプリケーションは任意のAWSリージョンで実行でき、これらのサービスを使用してアプリケーションの可用性を保護し、正当なエンドユーザー向けにアプリケーションのパフォーマンスを最適化できます。

CloudFront、AWS Global Accelerator、Amazon Route53を使用するメリットは次のとおりです。

• AWS グローバルエッジネットワーク全体でのインターネットおよび DDoS 緩和能力へのアクセス。 これは、テラビット規模に達する可能性のある大規模なボリューム攻撃を軽減するのに役立ちます。
• AWS Shield DDoS 緩和システムは AWS エッジサービスと統合されており、緩和までの時間を数分から1秒未満に短縮します。
• ステートレスSYNフラッド軽減技術は、保護されたサービスに渡す前に、着信接続をプロキシして検証します。 これにより、正当なエンドユーザーを誤検知のドロップから保護しながら、有効な接続のみがアプリケーションに到達することが保証されます。
• 大規模なボリュームDDoS攻撃の影響を分散または分離する自動トラフィックエンジニアリングシステム。 これらのサービスはすべて、発信元に到達する前に発信元での攻撃を分離します。つまり、これらのサービスによって保護されているシステムへの影響が少なくなります。
• 現在のアプリケーションアーキテクチャを変更する必要のないAWSWAFと組み合わせた場合のアプリケーションレイヤーの防御（たとえば、AWSリージョンまたはオンプレミスデータセンター）。
  AWSでのインバウンドデータ転送は無料で、AWSShieldによって軽減されるDDoS攻撃トラフィックの料金はかかりません。 次のアーキテクチャ図には、AWSグローバルエッジネットワークサービスが含まれています。

(図はオリジナルソースの８ページ DDoS-resilient reference architecture を参照)

このアーキテクチャには、DDoS攻撃に対するWebアプリケーションの復元力を向上させるのに役立ついくつかのAWSサービスが含まれています。 「ベストプラクティスの概要」の表には、これらのサービスとそれらが提供できる機能の概要が記載されています。 AWSは、このドキュメント内で簡単に参照できるように、各サービスにベストプラクティスインジケーター（BP1、BP2）のタグを付けています。 たとえば、次のセクションでは、CloudFrontとGlobal Acceleratorによって提供される、ベストプラクティスインジケーターBP1を含む機能について説明します。

(表はオリジナルソースの９ページ Summary of Best Practices を参照)

DDoS攻撃に対応して軽減する準備を改善する別の方法は、AWS ShieldAdvancedにサブスクライブすることです。

顧客は、以下に基づいて調整された検出を受け取ります。

• アプリケーションの特定のトラフィックパターン。
• 追加費用なしで、AWS WAF を含むレイヤー7 DDoS 攻撃に対する保護。
• •AWS SRT からの24時間年中無休の専門サポートへのアクセス。
• AWS ファイアウォールマネージャーによるセキュリティポリシーの集中管理。
• DDoS関連の使用量の急増に起因するスケーリング料金から保護するためのコスト保護。

このオプションのDDoS緩和サービスは、AWSリージョンでホストされているアプリケーションを保護するのに役立ちます。 このサービスは、CloudFront、Amazon Route 53、および Global Accelerator でグローバルに利用できます。 AWS ShieldAdvanced を ElasticIP アドレスで使用すると、Network Load Balancer（NLB）または AmazonEC2 インスタンスを保護できます。

AWS Shield Advanced を使用する利点は次のとおりです。

• アプリケーションの可用性に影響を与えるDDoS攻撃の軽減を支援するためのAWSSRTへのアクセス。
• AWSマネジメントコンソール、API、AmazonCloudWatchのメトリクスとアラームを使用したDDoS攻撃の可視性。
• 過去13か月間のすべてのDDoSイベントの履歴へのアクセス。
• アプリケーション層のDDoS攻撃を軽減するための追加コストなしでAWSWebアプリケーションファイアウォール（WAF）にアクセスします（CloudFrontまたはApplication Load Balancerで使用する場合）。
• AWSWAFで使用する場合のWebトラフィック属性の自動ベースライン。
• 自動化されたポリシー施行のための、追加費用なしのAWSFirewallManagerへのアクセス。
• トラフィックをDDoS緩和システムに早期にルーティングし、Elastic IPアドレスとともに使用すると、AmazonEC2またはNetworkLoadBalancerに対する攻撃を緩和するまでの時間を短縮できる高感度の検出しきい値。
• DDoS攻撃に起因するスケーリング関連のコストの限定的な払い戻しを要求できるようにするコスト保護。
• AWSShieldAdvancedのお客様に固有の拡張サービスレベル契約。
• シールドイベントが検出された場合のAWSSRTからのプロアクティブなエンゲージメント。
• リソースをバンドルできるようにする protection groups。複数のリソースを単一のユニットとして扱うことで、アプリケーションの検出と軽減の範囲をカスタマイズするセルフサービスの方法を提供します。 リソースのグループ化により、検出の精度が向上し、誤検知が最小限に抑えられ、新しく作成されたリソースの自動保護が容易になり、単一のアプリケーションを構成する多くのリソースに対する攻撃を軽減する時間が短縮されます。 protection groups の詳細については、Shield Advanced protection groups を参照してください。

AWS Shieldの高度な機能の完全なリスト、およびAWS Shieldの詳細については、「How AWS Shield works」 を参照してください。

DDoS 緩和のためのベストプラクティス

次のセクションでは、DDoS緩和のために推奨される各ベストプラクティスについて詳しく説明します。 静的または動的Webアプリケーション用のDDoS緩和レイヤーを構築するための迅速で簡単なガイドについては、「動的WebアプリケーションをDDoS攻撃から保護する方法」を参照してください。

Infrastructure Layer Defense (BP1, BP3, BP6, BP7)

従来のデータセンター環境では、容量のオーバープロビジョニング、DDoS緩和システムの導入、DDoS緩和サービスを利用したトラフィックのスクラビングなどの手法を使用して、インフラストラクチャ層のDDoS攻撃を緩和できます。 AWSでは、DDoS緩和機能が自動的に提供されます。 ただし、これらの機能を最大限に活用し、過剰なトラフィックに合わせて拡張できるアーキテクチャを選択することで、アプリケーションのDDoS回復力を最適化できます。

ボリュームDDoS攻撃を軽減するための重要な考慮事項には、十分なトランジット容量と多様性が利用可能であることを確認し、AmazonEC2インスタンスなどのAWSリソースを攻撃トラフィックから保護することが含まれます。

一部のAmazonEC2インスタンスタイプは、最大100 Gbpsのネットワーク帯域幅インターフェイスや拡張ネットワークなど、大量のトラフィックをより簡単に処理できる機能をサポートしています。 これにより、AmazonEC2インスタンスに到達したトラフィックのインターフェースの輻輳を防ぐことができます。 拡張ネットワーキングをサポートするインスタンスは、従来の実装と比較して、より高いI / Oパフォーマンス、より高い帯域幅、およびより低いCPU使用率を提供します。 これにより、インスタンスが大量のトラフィックを処理する能力が向上し、最終的には1秒あたりのパケット数（pps）の負荷に対して高い回復力が得られます。

この高レベルの復元力を実現するために、AWSでは、Amazon EC2専用インスタンスまたはネットワークスループットが高く、Nサフィックスがあり、最大100 Gbpsのネットワーク帯域幅（c6gn.16xlargeやc5nなど）の拡張ネットワークをサポートするEC2インスタンスを使用することをお勧めします。 18xlargeまたはメタルインスタンス（c5n.metalなど）。

100ギガビットネットワークインターフェイスと拡張ネットワークをサポートするAmazonEC2インスタンスの詳細については、「AmazonEC2インスタンスタイプ」を参照してください。

拡張ネットワーキングに必要なモジュールと必要なenaSupport属性セットは、Amazon Linux2と最新バージョンのAmazonLinuxAMIに含まれています。 したがって、サポートされているインスタンスタイプでHVMバージョンのAmazon Linuxを使用してインスタンスを起動すると、インスタンスに対して拡張ネットワークがすでに有効になっています。 詳細については、拡張ネットワークが有効になっているかどうかをテストするを参照してください。 拡張ネットワークを有効にする方法の詳細については、「Linuxでの拡張ネットワーク」を参照してください。

Amazon EC2 with Auto Scaling (BP7)

インフラストラクチャとアプリケーション層の両方の攻撃を軽減する別の方法は、大規模に運用することです。 Webアプリケーションがある場合は、ロードバランサーを使用して、オーバープロビジョニングされているか、自動的にスケーリングするように設定されている多数のAmazonEC2インスタンスにトラフィックを分散できます。これらのインスタンスは、フラッシュクラウドやアプリケーション層のDDoS攻撃など、何らかの理由で発生する突然のトラフィックサージを処理できます。 Amazon CloudWatchアラームを設定して、Auto Scalingを開始し、CPU、RAM、ネットワークI / O、さらにはカスタムメトリクスなど、定義したイベントに応じてAmazonEC2フリートのサイズを自動的にスケーリングできます。このアプローチは、リクエスト量が予期せず増加した場合にアプリケーションの可用性を保護します。 CloudFront、Application Load Balancer、Classic Load Balancer、またはNetwork Load Balancerをアプリケーションで使用する場合、TLSネゴシエーションはディストリビューション（CloudFront）またはロードバランサーによって処理されます。これらの機能は、正当なリクエストとTLS不正使用攻撃を処理するようにスケーリングすることにより、TLSベースの攻撃による影響からインスタンスを保護するのに役立ちます。

AmazonCloudWatchを使用してAutoScalingを呼び出す方法の詳細については、AutoScalingグループおよびインスタンスのCloudWatchメトリクスのモニタリングを参照してください。

Amazon EC2はサイズ変更可能なコンピューティング容量を提供するため、要件の変化に応じてすばやくスケールアップまたはスケールダウンできます。 Auto Scalingグループのサイズをスケーリングすることでアプリケーションにインスタンスを自動的に追加することで水平方向にスケーリングでき、より大きなEC2インスタンスタイプを使用して垂直方向にスケーリングできます。

Elastic Load Balancing (BP6)

大規模なDDoS攻撃は、単一のAmazonEC2インスタンスの容量を圧倒する可能性があります。 Elastic Load Balancing（ELB）を使用すると、多くのバックエンドインスタンスにトラフィックを分散することで、アプリケーションが過負荷になるリスクを減らすことができます。 Elastic Load Balancingは自動的にスケーリングできるため、フラッシュクラウドやDDoS攻撃などにより、予期しない余分なトラフィックが発生した場合に、より多くのボリュームを管理できます。 Amazon VPC内で構築されたアプリケーションの場合、アプリケーションのタイプに応じて、アプリケーションロードバランサー（ALB）、クラシックロードバランサー（CLB）、ネットワークロードバランサーの3種類のElastic LoadBalancingを検討する必要があります。

Webアプリケーションの場合、Application Load Balancerを使用して、コンテンツに基づいてトラフィックをルーティングし、整形式のWeb要求のみを受け入れることができます。 Application Load Balancerは、SYNフラッドやUDPリフレクション攻撃など、多くの一般的なDDoS攻撃をブロックし、アプリケーションを攻撃から保護します。 これらのタイプの攻撃が検出されると、Application LoadBalancerは自動的にスケーリングして追加のトラフィックを吸収します。 インフラストラクチャレイヤー攻撃によるスケーリングアクティビティは、AWSのお客様には透過的であり、請求には影響しません。

Application Load Balancerを使用したWebアプリケーションの保護の詳細については、「Application LoadBalancer の使用を開始する」を参照してください。

TCPベースのアプリケーションの場合、Network Load Balancerを使用して、トラフィックをターゲット（Amazon EC2インスタンスなど）に超低レイテンシでルーティングできます。 ネットワークロードバランサーに関する重要な考慮事項の1つは、有効なリスナーでロードバランサーに到達するトラフィックはすべて、吸収されずにターゲットにルーティングされることです。 AWS Shield Advancedを使用して、ElasticIPアドレスのDDoS保護を構成できます。 アベイラビリティーゾーンごとにElasticIPアドレスがネットワークロードバランサーに割り当てられると、AWS ShieldAdvancedはネットワークロードバランサートラフィックに関連するDDoS保護を適用します。

ネットワークロードバランサーを使用してTCPアプリケーションを保護する方法の詳細については、「ネットワークロードバランサーの使用を開始する」を参照してください。

Leverage AWS Edge Locations for Scale (BP1, BP3)

高度に拡張された多様なインターネット接続にアクセスすることで、ユーザーへの遅延とスループットを最適化し、DDoS攻撃を吸収し、アプリケーションの可用性への影響を最小限に抑えながら障害を切り分ける能力を大幅に向上させることができます。 AWSエッジロケーションは、CloudFront、Global Accelerator、Amazon Route 53を使用するすべてのアプリケーションにこれらのメリットを提供するネットワークインフラストラクチャの追加レイヤーを提供します。これらのサービスを使用すると、AWSリージョンから実行されているアプリケーションをエッジで包括的に保護できます。

Web Application Delivery at the Edge (BP1)

CloudFrontは、静的、動的、ストリーミング、インタラクティブコンテンツを含むWebサイト全体を配信するために使用できるサービスです。 キャッシュ可能なコンテンツを提供していない場合でも、永続的な接続と可変の存続可能時間（TTL）設定を使用して、発信元からトラフィックをオフロードできます。 これらのCloudFront機能を使用すると、オリジンに戻るリクエストとTCP接続の数が減り、HTTPフラッドからWebアプリケーションを保護するのに役立ちます。 CloudFrontは整形式の接続のみを受け入れます。これにより、SYNフラッドやUDPリフレクション攻撃などの多くの一般的なDDoS攻撃がオリジンに到達するのを防ぐことができます。 DDoS攻撃は、ソースの近くでも地理的に隔離されているため、トラフィックが他の場所に影響を与えることはありません。 これらの機能は、大規模なDDoS攻撃中にユーザーにトラフィックを提供し続ける能力を大幅に向上させることができます。 CloudFrontを使用して、AWSまたはインターネット上の他の場所のオリジンを保護できます。

Amazon S3を使用してインターネット上で静的コンテンツを提供している場合、AWSではCloudFrontを使用してバケットを保護することをお勧めします。 オリジンアクセスID（OAI）を使用して、ユーザーがCloudFrontURLを使用してのみオブジェクトにアクセスできるようにすることができます。

OAIの詳細については、オリジンアクセスID（OAI）を使用したAmazonS3コンテンツへのアクセスの制限を参照してください。

CloudFrontを使用したWebアプリケーションのパフォーマンスの保護と最適化の詳細については、「AmazonCloudFront入門」を参照してください。

Protect network traffic further from your origin using AWS Global Accelerator (BP1)

Global Acceleratorは、ユーザーのトラフィックの可用性とパフォーマンスを最大60％向上させるネットワークサービスです。 これは、ユーザーに最も近いエッジロケーションでトラフィックを入力し、単一または複数のAWSリージョンで実行されているかどうかに関係なく、AWSグローバルネットワークインフラストラクチャを介してアプリケーションにルーティングすることで実現されます。

Global Acceleratorは、ユーザーに最も近いAWSリージョンのパフォーマンスに基づいて、TCPおよびUDPトラフィックを最適なエンドポイントにルーティングします。 アプリケーションに障害が発生した場合、GlobalAcceleratorは30秒以内に次善のエンドポイントへのフェイルオーバーを提供します。 Global Acceleratorは、AWSグローバルネットワークの膨大な容量とAWS Shieldとの統合を使用して、アプリケーションを保護するために、新しい接続の試行に挑戦し、正当なエンドユーザーにのみサービスを提供するステートレスSYNプロキシ機能などを使用します。

アプリケーションがCloudFrontでサポートされていないプロトコルを使用している場合や、グローバル静的IPアドレスを必要とするWebアプリケーションを運用している場合でも、エッジでのWebアプリケーション配信のベストプラクティスと同じ利点の多くを提供するDDoS復元力のあるアーキテクチャを実装できます。 たとえば、エンドユーザーがファイアウォールの許可リストに追加でき、他のAWSカスタマーによって使用されないIPアドレスが必要になる場合があります。 これらのシナリオでは、Global Acceleratorを使用して、Application Load Balancerで実行されているWebアプリケーションを保護し、AWS WAFと組み合わせて、Webアプリケーションレイヤーのリクエストフラッドを検出して軽減することもできます。

Global Acceleratorを使用したネットワークトラフィックの保護と最適化の詳細については、「AWS GlobalAccelerator入門」を参照してください。

Domain Name Resolution at the Edge (BP3)

Amazon Route 53は、トラフィックをWebアプリケーションに転送するために使用できる、可用性が高くスケーラブルなドメインネームシステム（DNS）サービスです。これには、トラフィックフロー、ヘルスチェックとモニタリング、遅延ベースのルーティング、GeoDNSなどの高度な機能が含まれています。これらの高度な機能を使用すると、サービスがDNS要求に応答する方法を制御して、Webアプリケーションのパフォーマンスを向上させ、サイトの停止を回避できます。

Amazon Route 53は、シャッフルシャーディングやエニーキャストストライピングなどの手法を使用しており、DNSサービスがDDoS攻撃の標的になっている場合でも、ユーザーがアプリケーションにアクセスするのに役立ちます。

シャッフルシャーディングを使用すると、委任セット内の各ネームサーバーは、エッジの場所とインターネットパスの一意のセットに対応します。これにより、フォールトトレランスが向上し、顧客間の重複が最小限に抑えられます。委任セット内の1つのネームサーバーが使用できない場合、ユーザーは再試行して、別のエッジロケーションにある別のネームサーバーから応答を受信できます。

エニーキャストストライピングを使用すると、各DNS要求を最適な場所で処理できるため、ネットワークの負荷が分散され、DNSの遅延が減少します。これにより、ユーザーの応答が速くなります。さらに、Amazon Route 53は、DNSクエリのソースとボリュームの異常を検出し、信頼できることがわかっているユーザーからのリクエストに優先順位を付けることができます。

Amazon Route 53を使用してユーザーをアプリケーションにルーティングする方法の詳細については、「Amazon Route53入門」を参照してください。

Application Layer Defense (BP1, BP2)

このホワイトペーパーでこれまでに説明した手法の多くは、インフラストラクチャ層のDDoS攻撃がアプリケーションの可用性に与える影響を軽減するのに効果的です。 また、アプリケーション層の攻撃から防御するには、悪意のある要求を具体的に検出、拡張して吸収、およびブロックできるアーキテクチャを実装する必要があります。 ネットワークベースのDDoS緩和システムは、一般に複雑なアプリケーション層の攻撃を緩和するには効果がないため、これは重要な考慮事項です。

悪意のあるWebリクエストの検出とフィルタリング（BP1、BP2）

アプリケーションがAWSで実行されている場合、CloudFrontとAWS WAFの両方を活用して、アプリケーション層のDDoS攻撃からの防御に役立てることができます。

CloudFrontを使用すると、静的コンテンツをキャッシュしてAWSエッジロケーションから提供できるため、オリジンの負荷を軽減できます。また、Web以外のトラフィックが発信元に到達するのを防ぐことで、サーバーの負荷を軽減するのにも役立ちます。

さらに、CloudFrontは、読み取りが遅い、または書き込みが遅い攻撃者（Slowlorisなど）からの接続を自動的に閉じることができます。

AWS WAFを使用すると、CloudFrontディストリビューションまたはアプリケーションロードバランサーでWebアクセスコントロールリスト（Web ACL）を設定して、リクエストシグネチャに基づいてリクエストをフィルタリングおよびブロックできます。各WebACLは、Uniform Resource Identifier（URI）、クエリ文字列、HTTPメソッド、ヘッダーキーなど、1つ以上の要求属性を文字列一致または正規表現一致するように設定できるルールで構成されています。さらに、AWS WAFのレートベースのルールを使用することで、ルールに一致するリクエストが定義したしきい値を超えたときに、悪意のあるユーザーのIPアドレスを自動的にブロックできます。

問題のあるクライアントIPアドレスからのリクエストは、403 Forbiddenエラー応答を受け取り、リクエストレートがしきい値を下回るまでブロックされたままになります。これは、通常のWebトラフィックを装ったHTTPフラッド攻撃を軽減するのに役立ちます。 IPアドレスのレピュテーションに基づいて攻撃をブロックするには、IP一致条件を使用してルールを作成するか、AWSMarketplaceのセラーが提供するAWSWAFのマネージドルールを使用します。 AWS WAFは、IPレピュテーションルールグループを選択できるマネージドサービスとしてAWSマネージドルールを直接提供します。 Amazon IPレピュテーションリストルールグループには、Amazon内部脅威インテリジェンスに基づくルールが含まれています。これは、ボットやその他の脅威に通常関連付けられているIPアドレスをブロックする場合に役立ちます。匿名IPリストルールグループには、ビューアIDの難読化を許可するサービスからの要求をブロックするルールが含まれています。これには、VPN、プロキシ、Torノード、クラウドプラットフォーム（AWSを含む）からのリクエストが含まれます。 AWS WAFとCloudFrontはどちらも、選択した国からのリクエストをブロックまたは許可するように地理的制限を設定することもできます。これは、ユーザーにサービスを提供することを期待していない地理的な場所から発生する攻撃をブロックするのに役立ちます。

悪意のあるリクエストを特定するには、ウェブサーバーのログを確認するか、AWS WAF のログ機能とサンプルリクエスト機能を使用してください。 AWS WAFロギングを有効にすることで、WebACL によって分析されたトラフィックに関する詳細情報を取得できます。 AWS WAF はログフィルタリングをサポートしており、どの Webリクエストをログに記録し、どのリクエストをインスペクション後にログから破棄するかを指定できます。

ログに記録される情報には、AWS WAFがAWSリソースからリクエストを受信した時刻、リクエストに関する詳細情報、およびリクエストされた各ルールのマッチングアクションが含まれます。 サンプルリクエストは、AWSWAFルールの1つに一致した過去3時間以内のリクエストに関する詳細を提供します。 この情報を使用して、潜在的に悪意のあるトラフィックシグネチャを識別し、それらの要求を拒否する新しいルールを作成できます。 ランダムなクエリ文字列を含む多数のリクエストが表示される場合は、アプリケーションのキャッシュに関連するクエリ文字列パラメータのみを許可するようにしてください。 この手法は、オリジンに対するキャッシュバスティング攻撃を軽減するのに役立ちます。

AWS Shield Advancedにサブスクライブしている場合は、AWS Shield Response Team（SRT）を利用して、アプリケーションの可用性を損なう攻撃を軽減するためのルールを作成できます。 アカウントのAWSShieldAdvancedおよびAWSWAFAPIへのAWSSRT制限付きアクセスを許可できます。 AWS SRTはこれらのAPIにアクセスして、明示的な承認がある場合にのみアカウントに緩和策を適用します。 詳細については、このドキュメントの「サポート」セクションを参照してください。

AWS Firewall Managerを使用して、組織全体でAWS ShieldAdvanced保護やAWSWAFルールなどのセキュリティルールを一元的に設定および管理できます。 AWS Organizations管理アカウントは、FirewallManagerポリシーの作成を許可されている管理者アカウントを指定できます。 これらのポリシーを使用すると、ルールが適用される場所を決定するリソースタイプやタグなどの基準を定義できます。 これは、複数のアカウントがあり、保護を標準化する場合に役立ちます。

詳細については、以下をご覧ください。

• Getting started with AWS WAF
• Logging web ACL traffic information
• Viewing a sample of web requests

レートベースのルールの設定については、「AWSWAFのレートベースのルールを使用したWebサイトとサービスの保護」を参照してください。
AWS FirewallManagerを使用してAWSリソース全体にAWSWAFルールのデプロイを管理する方法については、以下を参照してください。

• Getting started with AWS Firewall Manager AWS WAF policies
• Getting started with AWS Firewall Manager AWS Shield Advanced policies

攻撃対象領域の削減

AWSソリューションを設計する際のもう1つの重要な考慮事項は、攻撃者がアプリケーションを標的にする機会を制限することです。 この概念は、攻撃対象領域の削減として知られています。 インターネットに公開されていないリソースは攻撃がより困難であるため、攻撃者がアプリケーションの可用性を標的にするために必要なオプションが制限されます。

たとえば、ユーザーが特定のリソースと直接対話することを期待しない場合は、それらのリソースにインターネットからアクセスできないようにしてください。 同様に、通信に必要のないポートまたはプロトコルでユーザーまたは外部アプリケーションからのトラフィックを受け入れないでください。

次のセクションでは、AWSは、攻撃対象領域を減らし、アプリケーションのインターネットへの露出を制限するためのベストプラクティスを提供します。

AWSリソースの難読化（BP1、BP4、BP5）

通常、ユーザーはAWSリソースをインターネットに完全に公開しなくても、アプリケーションをすばやく簡単に使用できます。 たとえば、Elastic LoadBalancingの背後にAmazonEC2インスタンスがある場合、インスタンス自体がパブリックにアクセス可能である必要はない場合があります。

代わりに、特定のTCPポートでElastic Load Balancingへのアクセスをユーザーに提供し、Elastic LoadBalancingのみがインスタンスと通信できるようにすることができます。 これを設定するには、Amazon Virtual Private Cloud（Amazon VPC）内でセキュリティグループとネットワークアクセスコントロールリスト（ネットワークACL）を設定します。

Amazon VPCを使用すると、AWSクラウドの論理的に分離されたセクションをプロビジョニングして、定義した仮想ネットワークでAWSリソースを起動できます。

セキュリティグループとネットワークACLは、VPC内のAWSリソースへのアクセスを制御できるという点で類似しています。 ただし、セキュリティグループを使用すると、インスタンスレベルでインバウンドトラフィックとアウトバウンドトラフィックを制御できますが、ネットワークACLはVPCサブネットレベルで同様の機能を提供します。 セキュリティグループまたはネットワークACLの使用に追加料金はかかりません。

Security Groups and Network Access Control Lists (Network ACLs) (BP5)

インスタンスを起動するときにセキュリティグループを指定するか、後でインスタンスをセキュリティグループに関連付けるかを選択できます。トラフィックを許可する許可ルールを作成しない限り、セキュリティグループへのすべてのインターネットトラフィックは暗黙的に拒否されます。たとえば、Elastic LoadBalancingと複数のAmazonEC2インスタンスを使用するWebアプリケーションがある場合、Elastic Load Balancing用に1つのセキュリティグループ（Elastic Load Balancingセキュリティグループ）を作成し、インスタンス用に1つ（Webアプリケーションサーバー）を作成することができます。セキュリティグループ）。次に、Elastic Load Balancingセキュリティグループへのインターネットトラフィックを許可する許可ルールと、Elastic LoadBalancingセキュリティグループからWebアプリケーションサーバーセキュリティグループへのトラフィックを許可する別のルールを作成できます。これにより、インターネットトラフィックがAmazon EC2インスタンスと直接通信できなくなり、攻撃者がアプリケーションについて学習して影響を与えることがより困難になります。

ネットワークACLを作成するときに、許可ルールと拒否ルールの両方を指定できます。これは、アプリケーションへの特定のタイプのトラフィックを明示的に拒否する場合に役立ちます。たとえば、サブネット全体へのアクセスを拒否されるIPアドレス（CIDR範囲として）、プロトコル、および宛先ポートを定義できます。アプリケーションがTCPトラフィックにのみ使用される場合は、すべてのUDPトラフィックを拒否するルールを作成できます。その逆も可能です。このオプションは、ソースIPまたはその他のシグニチャがわかっている場合に攻撃を軽減する独自のルールを作成できるため、DDoS攻撃に対応する場合に役立ちます。

AWS Shield Advancedにサブスクライブしている場合は、ElasticIPアドレスを保護されたリソースとして登録できます。保護されたリソースとして登録されているElasticIPアドレスに対するDDoS攻撃は、より迅速に検出されるため、軽減にかかる時間が短縮されます。攻撃が検出されると、DDoS緩和システムはターゲットのElastic IPアドレスに対応するネットワークACLを読み取り、AWSネットワークの境界でそれを適用します。これにより、多くのインフラストラクチャ層のDDoS攻撃による影響のリスクが大幅に軽減されます。

DDoSの回復力を最適化するためのセキュリティグループとネットワークACLの構成の詳細については、攻撃対象領域を減らしてDDoS攻撃に備える方法を参照してください。

保護されたリソースとしてElasticIPアドレスを使用してAWSShieldAdvancedを使用する方法の詳細については、AWSShieldAdvancedをサブスクライブする手順を参照してください。

Protecting Your Origin (BP1, BP5)

VPC内にあるオリジンでCloudFrontを使用している場合は、CloudFrontディストリビューションのみがリクエストをオリジンに転送できるようにすることができます。 Edge-to-Originリクエストヘッダーを使用すると、CloudFrontがリクエストをオリジンに転送するときに、既存のリクエストヘッダーの値を追加またはオーバーライドできます。 X-Shared-Secretヘッダーなどのオリジンカスタムヘッダーを使用して、オリジンに対して行われたリクエストがCloudFrontから送信されたことを検証できます。

オリジンカスタムヘッダーを使用してオリジンを保護する方法の詳細については、オリジンリクエストへのカスタムヘッダーの追加およびアプリケーションロードバランサーへのアクセスの制限を参照してください。

オリジンアクセス制限のオリジンカスタムヘッダーの値を自動的にローテーションするサンプルソリューションの実装に関するガイドについては、「AWSWAFおよびAWSSecretsManagerを使用してAmazonCloudFrontオリジンセキュリティを強化する方法」を参照してください。

または、AWS Lambda関数を使用して、セキュリティグループルールを自動的に更新し、CloudFrontトラフィックのみを許可することもできます。これにより、悪意のあるユーザーがWebアプリケーションにアクセスするときにCloudFrontとAWS WAFをバイパスできないようにすることで、オリジンのセキュリティが向上します。

セキュリティグループを自動的に更新してオリジンを保護する方法の詳細については、「AWSLambdaを使用してAmazonCloudFrontとAWSWAFのセキュリティグループを自動的に更新する方法」を参照してください。

Protecting API Endpoints (BP4)

通常、APIを公開する必要がある場合、APIフロントエンドがDDoS攻撃の標的になる可能性があるというリスクがあります。リスクを軽減するために、Amazon EC2、AWS Lambda、またはその他の場所で実行されているアプリケーションへの入り口としてAmazonAPIGatewayを使用できます。 Amazon API Gatewayを使用することで、APIフロントエンドに独自のサーバーを必要とせず、アプリケーションの他のコンポーネントを難読化できます。アプリケーションのコンポーネントの検出を困難にすることで、これらのAWSリソースがDDoS攻撃の標的になるのを防ぐことができます。

Amazon API Gatewayを使用する場合、2種類のAPIエンドポイントから選択できます。 1つ目はデフォルトオプションです。CloudFrontディストリビューションを介してアクセスされるエッジ最適化APIエンドポイントです。ただし、ディストリビューションはAPI Gatewayによって作成および管理されるため、管理することはできません。 2番目のオプションは、RESTAPIがデプロイされているのと同じAWSリージョンからアクセスされるリージョンAPIエンドポイントを使用することです。 AWSでは、2番目のタイプのエンドポイントを使用し、それを独自のCloudFrontディストリビューションに関連付けることをお勧めします。これにより、CloudFrontディストリビューションを制御し、アプリケーションレイヤーの保護にAWSWAFを使用できるようになります。このモードでは、AWSグローバルエッジネットワーク全体でスケーリングされたDDoS緩和能力にアクセスできます。

CloudFrontとAWSWAFをAmazonAPIGatewayで使用する場合は、次のオプションを設定します。

• すべてのヘッダーをAPIGatewayリージョナルエンドポイントに転送するように、ディストリビューションのキャッシュ動作を構成します。 これにより、CloudFrontはコンテンツを動的として扱い、コンテンツのキャッシュをスキップします。
• API GatewayでAPIキー値を設定することにより、オリジンカスタムヘッダーを含むようにディストリビューションを構成することにより、APIGatewayを直接アクセスから保護します。
• REST APIの各メソッドに標準またはバーストレートの制限を設定することにより、バックエンドを過剰なトラフィックから保護します。

Amazon API Gatewayを使用したAPIの作成の詳細については、「AmazonAPIGateway入門」を参照してください。

運用テクニック

このホワイトペーパーの緩和手法は、DDoS攻撃に対して本質的に回復力のあるアプリケーションを設計するのに役立ちます。 多くの場合、DDoS攻撃がアプリケーションを標的にしていることを知っておくと、軽減策を講じることができます。 このセクションでは、異常な動作の可視化、アラートと自動化、大規模な保護の管理、および追加サポートのためのAWSの利用に関するベストプラクティスについて説明します。

可視性

主要な運用指標が期待値から大幅に逸脱している場合、攻撃者はアプリケーションの可用性を標的にしようとしている可能性があります。アプリケーションの通常の動作に精通しているということは、異常を検出したときに、より迅速にアクションを実行できることを意味します。 Amazon CloudWatchは、AWSで実行するアプリケーションをモニタリングすることで役立ちます。たとえば、メトリクスの収集と追跡、ログファイルの収集と監視、アラームの設定、AWSリソースの変更への自動応答を行うことができます。

アプリケーションを設計するときにDDoS耐性のある参照アーキテクチャに従うと、アプリケーションに到達する前に、一般的なインフラストラクチャ層の攻撃がブロックされます。 AWS Shield Advancedにサブスクライブしている場合は、アプリケーションがターゲットになっていることを示すことができるいくつかのCloudWatchメトリクスにアクセスできます。たとえば、進行中のDDoS攻撃があったときに通知するようにアラームを設定できるため、アプリケーションの正常性を確認し、AWSSRTを利用するかどうかを決定できます。攻撃が検出されたかどうかを通知するようにメトリックを構成できます。攻撃量に基づいてアラートを受け取りたい場合は、(この部分のテキストがオリジナルソース上で欠損している) またはメトリックを使用することもできます。これらのメトリクスは、Amazon CloudWatch を独自のツールと統合するか、Slack や PagerDuty などのサードパーティが提供するツールを使用して監視できます。

アプリケーション層の攻撃は、多くの Amazon CloudWatch メトリクスを上昇させる可能性があります。 AWS WAFを使用している場合は、CloudWatch を使用して、AWS WAFで許可、カウント、またはブロックするように設定したリクエストの増加に対するアラームを監視およびアクティブ化できます。 これにより、トラフィックのレベルがアプリケーションで処理できるレベルを超えた場合に通知を受け取ることができます。 CloudWatchで追跡される CloudFront、Amazon Route 53、Application Load Balancer、Network Load Balancer、Amazon EC2、および Auto Scaling メトリックを使用して、DDoS攻撃を示す可能性のある変更を検出することもできます。

推奨される AmazonCloudWatch メトリクスの表に、DDoS攻撃の検出と対応に一般的に使用される AmazonCloudWatch メトリクスの説明を示します。

(表はオリジナルソースの22ページ Recommended Amazon CloudWatch Metrics を参照)

• サポート
• 結論
• 寄稿者
• 参考文献
• ドキュメントの改訂

（この続きは明日追記します）