翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 緩和手法 一部のDDoS緩和策は、 サービスに自動的に含まれます AWS 。DDoS レジリエンスは、以下のセクションで説明する特定の サービスで アーキテクチャを使用すること AWS 、およびユーザーとアプリケーション間のネットワークフローの各部分に追加のベストプラクティスを実装することで、さらに向上できます。 Amazon 、 CloudFront AWS Global Accelerator、Amazon Route 53 などのエッジロケーションから運用される AWS サービスを使用して、すべての既知のインフラストラクチャレイヤー攻撃に対する包括的な可用性保護を構築できます。これらのサービスは [AWS グローバルエッジネットワーク ](https://aws.amazon.com/products/networking/edge-networking/)の一部であり、世界中に分散されているエッジロケーションからあらゆるタイプのアプリケーショントラフィックを処理する際のアプリケーションのDDoS耐障害性を向上させることができます。任意の でアプリケーションを実行し AWS リージョン、これらのサービスを使用してアプリケーションの可用性を保護し、正当なエンドユーザー向けにアプリケーションのパフォーマンスを最適化できます。 Amazon CloudFront、Global Accelerator、および Amazon Route 53 を使用する利点は次のとおりです。 + グローバルエッジネットワーク全体のインターネットへのアクセスと容量のDDoS AWS 緩和。これは、テラビット規模に達する可能性のある大規模なボリューメトリック攻撃の軽減に役立ちます。 + AWS Shield DDoS 緩和システムは AWS エッジサービスと統合され、数分 time-to-mitigate から 1 秒未満に短縮されます。 + ステートレスSYNフラッド緩和は、保護されたサービスに渡す前に、SYNCookie を使用して受信接続を検証します。これにより、正当なエンドユーザーを誤検出ドロップから保護しながら、有効な接続のみがアプリケーションに到達できるようになります。 + 大規模なボリューメトリックDDoS攻撃の影響を分散または分離する自動トラフィックエンジニアリングシステム。これらのサービスはすべて、オリジンに到達する前にソースで攻撃を分離します。つまり、これらのサービスで保護されるシステムへの影響は少なくなります。 + 現在のアプリケーションアーキテクチャを変更する[AWS WAF](https://aws.amazon.com/waf/)必要がない (例えば、 AWS リージョン やオンプレミスのデータセンターなど) と組み合わせ CloudFront た場合のアプリケーションレイヤーの防御。 でのインバウンドデータ転送には料金はかかりません。 AWS また、 によって緩和されるDDoS攻撃トラフィックに対しては料金はかかりません AWS Shield。次のアーキテクチャ図には、 AWS グローバルエッジネットワークサービスが含まれています。 ![\[DDoSレジリエンスリファレンスアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-best-practices-ddos-resiliency/images/ddos-resilient-ref-arch.png) このアーキテクチャには、DDoS攻撃に対するウェブアプリケーションの耐障害性を向上させるのに役立ついくつかの AWS サービスが含まれています。次の表は、これらのサービスとそれらが提供できる機能の概要を示しています。 AWS は、このドキュメント内で簡単に参照できるように、各サービスにベストプラクティスインジケータ (BP1、BP2) をタグ付けしています。例えば、次のセクションでは、ベストプラクティスインジケータ を含む Amazon CloudFront と Global Accelerator が提供する機能について説明しますBP1。 *表 2 - ベストプラクティスの概要* | | AWS Edge | AWS リージョン | | --- | --- | --- | | | CloudFront （BP1) での Amazon AWS WAF （BP2) の使用 | Global Accelerator の使用 (BP1） | Amazon Route 53 の使用 (BP3） | （BP6) での Elastic Load Balancing AWS WAF （BP2) の使用 | Amazon ACLsでのセキュリティグループとネットワークの使用 VPC (BP5） | [Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling](https://aws.amazon.com/pm/ec2/) の使用 (BP7） | | レイヤー 3 (UDPリフレクションなど) 攻撃の軽減 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | レイヤー 4 (フラSYNッドなど) 攻撃の軽減 | ✔ | ✔ | ✔ | ✔ | | | | レイヤー 6 ( などTLS) 攻撃の軽減 | ✔ | ✔ | ✔ | ✔ | | | | アタックサーフェスを減らす | ✔ | ✔ | ✔ | ✔ | ✔ | | | アプリケーションレイヤートラフィックを吸収するためのスケーリング | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | | レイヤー 7 (アプリケーションレイヤー) 攻撃の軽減 | ✔ | ✔(\$1) | ✔ | ✔ | ✔(\$1) | ✔(\$1) | | 過剰なトラフィックや大規模なDDoS攻撃の地理的分離と利用 | ✔ | ✔ | ✔ | | | | ✔(\$1): [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) AWS WAF で と共に使用する場合 DDoS 攻撃に対応し、軽減する準備状況を向上させるもう 1 つの方法は、 にサブスクライブすることです AWS Shield Advanced。を使用する利点 AWS Shield Advanced は次のとおりです。 + オプションのプロアクティブエンゲージメント機能など、アプリケーションの可用性に影響を与えるDDoS攻撃の軽減を支援するために、[AWS Shield レスポンスチーム](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-srt-support.html) (AWS SRT) からの 24 時間 365 日の専門サポートへのアクセス + Elastic IP アドレスと併用すると、トラフィックをDDoS緩和システムに早期にルーティングし、Amazon EC2 (Elastic Load Balancer を含む) または Network Load Balancer に対する time-to-mitigate 攻撃を改善できる機密性の高い検出しきい値 + で使用する場合のアプリケーションのベースライントラフィックパターンに基づく、カスタマイズされたレイヤー 7 検出 AWS WAF + Shield Advanced がカスタム AWS WAF ルールを作成、評価、デプロイして検出されたDDoS攻撃に対応するアプリケーションレイヤーの自動DDoS緩和 + アプリケーションレイヤーDDoS攻撃の軽減のために追加料金 AWS WAF なしで にアクセスする (Amazon CloudFront または Application Load Balancer で使用する場合） + 追加コストなしで、 を通じてセキュリティポリシー[AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)を一元管理できます。 + DDoS 攻撃によるスケーリング関連のコストの限定的な返金をリクエストできるコスト保護。 + AWS Shield Advanced お客様固有のサービスレベルアグリーメントの強化。 + リソースをバンドルできる保護グループ。複数のリソースを 1 つのユニットとして扱うことで、アプリケーションの検出と緩和の範囲をセルフサービスでカスタマイズできます。保護グループの詳細については、[「Shield](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html#ddos-advanced-protection-groups) [Advanced 保護グループ」を参照してください。](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html#ddos-advanced-protection-groups) + DDoS 、[AWS マネジメントコンソール](https://aws.amazon.com/console/)、および Amazon CloudWatch [メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)と[アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) を使用してAPI、 が可視性を攻撃します。 このオプションDDoSの緩和サービスは、任意の でホストされているアプリケーションを保護するのに役立ちます AWS リージョン。このサービスは、、Route 53 CloudFront、および Global Accelerator でグローバルに利用できます。リージョンごとに、Application Load Balancer 、Classic Load Balancer、および Elastic IP アドレスを保護できます。これにより、[Network Load Balancer () または Amazon ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)インスタンスを保護できます。NLBs [ EC2](https://aws.amazon.com/ec2/) AWS Shield Advanced 機能の完全なリストと の詳細については AWS Shield、「 の仕組み[AWS Shield](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html)」を参照してください。 # DDoS 緩和のベストプラクティス 以下のセクションでは、DDoS緩和のために推奨される各ベストプラクティスについて詳しく説明します。静的または動的ウェブアプリケーションのDDoS緩和レイヤーの構築に関する簡単な easy-to-implement ガイドについては、[「Amazon と Amazon Route 53 を使用してDDoS攻撃から動的ウェブアプリケーションを保護する方法](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/)」を参照してください。 [ CloudFront ](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/) # インフラストラクチャレイヤーの防御 (BP1、BP3、BP6、BP7） 従来のデータセンター環境では、容量のオーバープロビジョニング、DDoS緩和システムのデプロイ、緩和サービスの活用によるトラフィックのスクラブなどの手法を使用して、インフラストラクチャレイヤーDDoS攻撃DDoSを軽減できます。では AWS、DDoS緩和機能が自動的に提供されますが、これらの機能を最大限に活用し、過剰なトラフィックに合わせてスケーリングできるアーキテクチャを選択することで、アプリケーションのDDoS耐障害性を最適化できます。 ボリューメトリックDDoS攻撃を軽減するための主な考慮事項には、十分なトランジットキャパシティと多様性を確保し、Amazon EC2インスタンスなどの AWS リソースを攻撃トラフィックから保護することが含まれます。 一部の Amazon EC2インスタンスタイプは、最大 100 Gbps のネットワーク帯域幅インターフェイスや拡張ネットワーキングなど、大量のトラフィックをより簡単に処理できる機能をサポートしています。これにより、Amazon EC2インスタンスに到達したトラフィックのインターフェイスの輻輳を防ぐことができます。拡張ネットワーキングをサポートするインスタンスは、従来の実装と比較して、高い入出力 (I/O) パフォーマンス、高い帯域幅、低いCPU使用率を提供します。これにより、大量のトラフィックを処理するインスタンスの能力が向上し、最終的には 1 秒あたりのパケット数 (pps) の負荷に対する回復力が高まります。 この高レベルの耐障害性を実現するには、[Amazon EC2 Dedicated Instances ](https://aws.amazon.com/ec2/pricing/dedicated-instances/)を使用する AWS か、`N`「」サフィックスを持つネットワークスループットが高い Amazon EC2インスタンスを使用し、最大 100 Gbps のネットワーク帯域幅で拡張ネットワーキングをサポートすることをお勧めします。例えば、 `c6gn.16xlarge` や `c5n.18xlarge` メタルインスタンス ( など`c5n.metal`）。 100 ギガビットのネットワークインターフェイスと拡張ネットワーキングをサポートする Amazon EC2インスタンスの詳細については、[「Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)」を参照してください。 拡張ネットワーキングに必要なモジュールと必要な`enaSupport`属性セットは、Amazon Linux 2 および最新バージョンの Amazon Linux に含まれていますAMI。したがって、サポートされているインスタンスタイプで Amazon Linux のハードウェア仮想マシン (HVM) バージョンを使用してインスタンスを起動すると、インスタンスの拡張ネットワーキングは既に有効になっています。詳細については、[「拡張ネットワーキングが有効になっているかどうかのテスト](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html#test-enhanced-networking-ena)」および[「Linux での拡張ネットワーキング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)」を参照してください。 # Amazon EC2と Auto Scaling (BP7） インフラストラクチャとアプリケーションレイヤーの両方の攻撃を軽減するもう 1 つの方法は、大規模に運用することです。ウェブアプリケーションがある場合は、ロードバランサーを使用して、オーバープロビジョニングまたは自動スケーリングが設定された多数の Amazon EC2インスタンスにトラフィックを分散できます。これらのインスタンスは、フラッシュ群やアプリケーションレイヤーDDoS攻撃など、何らかの理由で発生した突然のトラフィックの急増を処理できます。、、ネットワーク I/O、さらにはカスタムメトリクスなどCPU、定義したイベントに応じて Amazon EC2フリートのサイズを自動的にスケーリング Auto Scaling するように RAMAmazon [ CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を設定できます。 このアプローチは、リクエスト量が予期せず増加した場合にアプリケーションの可用性を保護します。アプリケーションで Amazon CloudFront、Application Load BalancerClassic Load Balancer、または Network Load Balancer TLS を使用する場合、ネゴシエーションはディストリビューション (Amazon CloudFront) またはロードバランサーによって処理されます。これらの機能は、正当なリクエストやTLS不正使用攻撃を処理するようにスケーリングすることで、 TLSベースの攻撃の影響を受けるインスタンスを保護するのに役立ちます。 Amazon を使用して Auto Scaling CloudWatch を呼び出す方法の詳細については、「Auto Scaling [グループとインスタンスの Amazon CloudWatch メトリクスのモニタリング Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)」を参照してください。 Auto Scaling Amazon EC2では、要件の変化に応じて迅速にスケールアップまたはスケールダウンできるように、サイズ変更可能なコンピューティング容量を提供しています。[Amazon EC2 Auto Scaling グループ のサイズ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/scaling_plan.html)をスケーリングすることで、アプリケーションにインスタンスを自動的に追加することで水平方向にスケーリングでき、より大きなEC2インスタンスタイプを使用して垂直方向にスケーリングできます。 [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) を使用すると、アプリケーションがデータベース接続をプールして共有し、データベーストラフィックの予期しない急増をスケーリングおよび処理する能力を向上させることができます。また、Amazon RDS データベースインスタンスのストレージの自動スケーリングを有効にすることもできます。詳細については、[「Amazon RDSストレージの自動スケーリングによる容量の自動管理](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.Autoscaling)」を参照してください。 # Elastic Load Balancing (BP6） 大規模なDDoS攻撃は、単一の Amazon EC2インスタンスの容量を圧倒する可能性があります。Elastic Load Balancing (ELB) を使用すると、多くのバックエンドインスタンスにトラフィックを分散することで、アプリケーションの過負荷のリスクを減らすことができます。Elastic Load Balancing は自動的にスケーリングできるため、フラッシュの群集やDDoS攻撃など、予期しない余分なトラフィックがある場合に、より大きなボリュームを管理できます。Amazon 内に構築されたアプリケーションの場合VPC、アプリケーションタイプに応じて、Application Load Balancer (ALB）、Network Load Balancer ()、Classic Load Balancer (NLB) の 3 つのタイプELBsを考慮する必要がありますCLB。 Load Balancer ウェブアプリケーションの場合、Application Load Balancer を使用してコンテンツに基づいてトラフィックをルーティングし、適切な形式のウェブリクエストのみを受け入れることができます。Application Load Balancer は、SYNフラッドDDoS攻撃やUDPリフレクション攻撃など、多くの一般的な攻撃をブロックし、攻撃からアプリケーションを保護します。Application Load Balancer は、これらのタイプの攻撃が検出されると、追加のトラフィックを吸収するように自動的にスケーリングします。インフラストラクチャレイヤー攻撃によるスケーリングアクティビティは、お客様にとって AWS 透過的であり、請求には影響しません。 Application Load Balancer によるウェブアプリケーションの保護の詳細については、[「Application Load Balancer の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)」を参照してください。 HTTP/HTTPS 以外のアプリケーションでは、Network Load Balancer を使用して、超低レイテンシーでトラフィックをターゲット (Amazon EC2インスタンスなど) にルーティングできます。Network Load Balancer の重要な考慮事項の 1 つは、有効なリスナーのロードバランサーに到達する TCPSYNまたは UDPトラフィックは、吸収されずにターゲットにルーティングされることです。ただし、TCP接続を終了する TLSリスナーには適用されません。TCP リスナーを備えた Network Load Balancer では、SYN洪水を防ぐために Global Accelerator をデプロイすることをお勧めします。 Shield Advanced を使用して、Elastic IP アドレスDDoSの保護を設定できます。Elastic IP アドレスがアベイラビリティーゾーンごとに Network Load Balancer に割り当てられると、Shield Advanced は Network Load Balancer トラフィックに関連するDDoS保護を適用します。 Network Load Balancer による TCPおよびUDPアプリケーションの保護の詳細については、[「Network Load Balancer の開始方法](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)」を参照してください。 Load Balancer **注記** セキュリティグループの設定によっては、セキュリティを使用して リソースをグループ化し、接続追跡を使用してトラフィックに関する情報を追跡する必要があります。これは、追跡される接続の数が制限されるため、ロードバランサーが新しい接続を処理する能力に影響を与える可能性があります。  任意の IP アドレス ( `0.0.0.0/0`や など`::/0`) からのトラフィックを受け入れるイングレスルールを含むが、応答トラフィックを許可する対応するルールがないセキュリティグループ設定では、セキュリティグループは接続追跡情報を使用して応答トラフィックの送信を許可します。攻撃が発生した場合DDoS、追跡される接続の最大数を使い果たす可能性があります。パブリック向け Application Load Balancer または Classic Load Balancer のDDoS耐障害性を向上させるには、ロードバランサーに関連付けられたセキュリティグループが接続追跡 (追跡されていない接続) を使用しないように設定されていることを確認し、トラフィックフローが接続追跡制限の対象にならないようにします。  そのためには、 インバウンドルールが任意の IP アドレス (`0.0.0.0/0` または `::/0`) からのTCPフローを受け入れることを許可するルールでセキュリティグループを設定します。 および は、このリソースがすべてのポート (0～65535`::/0`) の応答トラフィック (任意の IP アドレス`0.0.0.0/0`または のアウトバウンド範囲を許可) を送信できるようにするアウトバウンド方向に対応するルールを追加します。 セキュリティグループルールに基づいてレスポンストラフィックが許可されるようにします。 追跡情報ではなく 。この設定では、 Classic および Application Load Balancer は、ロードバランサーノードへの新しい接続の確立に影響を与える可能性のある、エグゼート接続の追跡制限の対象ではありません。 と では、DDoS攻撃発生時のトラフィックの増加に基づいてスケーリングできます。追跡されていない接続の詳細については、以下を参照してください。 [セキュリティグループ接続の追跡： 追跡されていない接続 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)。 セキュリティグループ接続の追跡を回避すると、DDoSトラフィックがセキュリティグループで許可されているソースから発信される場合にのみ役立ちます。DDoSセキュリティグループで許可されていないソースからのトラフィックは、接続の追跡には影響しません。このような場合、接続の追跡を避けるためにセキュリティグループを再設定する必要はありません。例えば、セキュリティグループの許可リストが、企業のファイアウォールや信頼できる送信や IPs など、高い信頼度を持つ IP VPN 範囲で構成されている場合などですCDNs。 # スケールに AWS エッジロケーションを使用する (BP1、BP3） 高度にスケールされた多様なインターネット接続にアクセスすると、ユーザーへのレイテンシーとスループットを最適化し、DDoS攻撃を吸収し、障害を分離しながら、アプリケーションの可用性への影響を最小限に抑える能力が大幅に向上します。 AWS エッジロケーションは、Amazon 、Global Accelerator CloudFront、Amazon Route 53 を使用するすべてのウェブアプリケーションにこれらの利点を提供するネットワークインフラストラクチャの追加レイヤーを提供します。これらのサービスを使用すると、 から実行されているアプリケーションをエッジで包括的に保護できます AWS リージョン。 # エッジでのウェブアプリケーション配信 (BP1） Amazon CloudFront は、静的コンテンツ、動的コンテンツ、ストリーミングコンテンツ、インタラクティブコンテンツなど、ウェブサイト全体を配信するために使用できるサービスです。キャッシュ可能なコンテンツを提供していなくても、永続的な接続と可変 time-to-live （TTL) 設定を使用して、オリジンからトラフィックをオフロードできます。これらの CloudFront 機能を使用すると、オリジンに戻るリクエストとTCP接続の数が減り、ウェブアプリケーションをHTTPフラッドから保護できます。 CloudFront は、適切な形式の接続のみを受け入れ、SYNフラッドやUDPリフレクションDDoS攻撃などの多くの一般的な攻撃がオリジンに到達するのを防ぐのに役立ちます。DDoS また、攻撃はソースの近くで地理的に分離されているため、トラフィックが他のロケーションに影響を与えるのを防ぐことができます。これらの機能により、大規模なDDoS攻撃中にユーザーにトラフィックを提供し続ける能力が大幅に向上します。 CloudFront を使用して、インターネット上の AWS または他の場所でオリジンを保護できます。 [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) を使用してインターネットで静的コンテンツを提供する場合は、 では、バケット CloudFront を保護するために Amazon を使用する AWS ことをお勧めします。これには以下の利点があります。 + Amazon S3 バケットへのアクセスを制限して、パブリックにアクセスできないようにします。 + ビューワー (ユーザー) が、指定された CloudFront ディストリビューションを介してのみバケット内のコンテンツにアクセスできるようにします。つまり、バケットから直接、または意図しない CloudFront ディストリビューションを介してコンテンツにアクセスできないようにします。 これを実現するには、認証されたリクエスト CloudFront を Amazon S3 に送信するように を設定し、 からの認証されたリクエストへのアクセスのみを許可するように Amazon S3 を設定します CloudFront。 CloudFront は、認証されたリクエストを Amazon S3 オリジンに送信する 2 つの方法として、オリジンアクセスコントロール (OAC) とオリジンアクセスアイデンティティ () を提供しますOAI。以下をサポートするOACため、 を使用することをお勧めします。 + 2022 年 12 月以降に開始されたオプトインリージョンを含む AWS リージョン、すべての のすべての Amazon S3 バケット + AWS KMS (-KMS) による Amazon S3 SSE [サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) + Amazon S3 に対する動的なリクエスト (`PUT` と `DELETE`) OAC および の詳細についてはOAI、[Amazon S3オリジンへのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)」を参照してください。 Amazon によるウェブアプリケーションのパフォーマンスの保護と最適化の詳細については CloudFront、[「Amazon の開始方法 CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html)」を参照してください。 # AWS Global Accelerator を使用してオリジンからネットワークトラフィックをさらに保護する (BP1） Global Accelerator は、ユーザーのトラフィックの可用性とパフォーマンスを最大 60% 向上させるネットワークサービスです。これは、トラフィックをユーザーに最も近いエッジロケーションに取り込み、単一または複数の で実行されているかどうかにかかわらず、 AWS グローバルネットワークインフラストラクチャ経由でアプリケーションにルーティングすることで実現されます AWS リージョン。 Global Accelerator は、ユーザーに最も近い のパフォーマンスに基づいて、最適なエンドポイント AWS リージョン に TCPとUDPトラフィックをルーティングします。アプリケーションに障害が発生した場合、Global Accelerator は 30 秒以内に次善のエンドポイントへのフェイルオーバーを提供します。Global Accelerator は、新しい接続試行にチャレンジし、正当なエンドユーザーのみにサービスを提供するステートレスSYNプロキシ機能など、 AWS グローバルネットワークと Shield との統合の膨大な容量を使用してアプリケーションを保護します。 アプリケーションが でサポートされていないプロトコルを使用しているか、グローバル静的 IP アドレスを必要とするウェブアプリケーションを CloudFront 運用している場合でも、エッジのベストプラクティスでウェブアプリケーション配信と同じ利点の多くを提供するDDoS回復力のあるアーキテクチャを実装できます。 例えば、エンドユーザーがファイアウォールの許可リストに追加でき、他の AWS 顧客では使用されない IP アドレスが必要になる場合があります。これらのシナリオでは、Global Accelerator を使用して、Application Load Balancer で実行されているウェブアプリケーションを保護し、 と組み合わせて、ウェブアプリケーションレイヤーリクエストのフラッドを検出して軽減 AWS WAF することもできます。 Global Accelerator を使用したネットワークトラフィックのパフォーマンスの保護と最適化の詳細については、「Global Accelerator [の開始方法」を参照してください。](https://docs.aws.amazon.com/global-accelerator/latest/dg/getting-started.html) # エッジでのドメイン名解決 (BP3） **Topics** + [DNS 可用性のための Route 53 の使用](using-route53-for-dns-availability.md) + [`NXDOMAIN` 攻撃からのコスト保護のための Route 53 の設定](configuring-route53-for-cost-protection-from-nxdomain-attacks.md) # DNS 可用性のための Route 53 の使用 Amazon Route 53 は、トラフィックをウェブアプリケーションに転送するために使用できる、可用性が高くスケーラブルなドメインネームシステム (DNS) サービスです。これには、トラフィックフロー、ヘルスチェックとモニタリング、レイテンシーベースのルーティング、Geo などの高度な機能が含まれていますDNS。これらの高度な機能により、ウェブアプリケーションのパフォーマンスを向上させ、サイトの停止を回避するために、サービスがDNSリクエストにどのように応答するかを制御できます。これは、データプレーンの可用性が 100% である唯一の AWS サービスですSLA。 Amazon Route 53 は[、シャッフルシャーディング](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)や[エニーキャストストライピング](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/)などの手法を使用します。これは、DNSサービスがDDoS攻撃のターゲットであっても、ユーザーがアプリケーションにアクセスするのに役立ちます。 シャッフルシャーディングでは、委任セット内の各ネームサーバーは、エッジロケーションとインターネットパスの一意のセットに対応します。これにより、耐障害性が向上し、顧客間の重複が最小限に抑えられます。委任セット内の 1 つのネームサーバーが使用できない場合、ユーザーは別のエッジロケーションにある別のネームサーバーからレスポンスを再試行して受信できます。 エニーキャストストライピングにより、各DNSリクエストを最適なロケーションで処理できるため、ネットワーク負荷が分散され、DNSレイテンシーが短縮されます。これにより、ユーザーの応答が速くなります。さらに、Amazon Route 53 はDNSクエリのソースとボリュームの異常を検出し、信頼性が高いことがわかっているユーザーからのリクエストに優先順位を付けることができます。 Amazon Route 53 を使用してユーザーをアプリケーションにルーティングする方法の詳細については、[「Amazon Route 53 の開始方法](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-started.html)」を参照してください。 # `NXDOMAIN` 攻撃からのコスト保護のための Route 53 の設定 `NXDOMAIN` 攻撃は、攻撃者が、多くの場合既知の「良い」リゾルバーを介して、存在しないサブドメインのホストゾーンに大量のリクエストを送信したときに発生します。これらの攻撃の目的は、再帰リゾルバーのキャッシュや信頼できるリゾルバーの可用性に影響を与えることや、ホストゾーンレコードを検出しようとするDNS偵察の一形態である可能性があります。信頼できるリゾルバーに Route 53 を使用すると、可用性/パフォーマンスへの影響のリスクを軽減できますが、その結果、Route 53 の月額コストが大幅に増加する可能性があります。コストの増加を防ぐには、[Route 53 の料金](https://aws.amazon.com/route53/pricing/)を利用して、次の条件の両方に当てはまる場合にDNSクエリが無料になります。 + クエリ内のドメインまたはサブドメイン名 (`example.com` または `store.example.com`) とレコードタイプ (`A`) がエイリアスレコードと一致します。 + エイリアスターゲットは、別の Route 53 レコード以外の AWS リソースです。 例えば、EC2インスタンス、Elastic Load Balancer、 CloudFront ディストリビューションなどの AWS リソースを指すタイプ `A` (エイリアス) `*.example.com`を使用してワイルドカードレコードを作成します。これにより、 のクエリが行われると、リソースの IP `qwerty12345.example.com` が返され、クエリに対して課金されません。 # アプリケーションレイヤーの防御 (BP1、BP2） このホワイトペーパーでこれまでに説明した手法の多くは、インフラストラクチャレイヤーDDoS攻撃がアプリケーションの可用性に与える影響を軽減するのに役立ちます。また、アプリケーションレイヤー攻撃から保護するには、悪意のあるリクエストを具体的に検出、スケールして吸収、ブロックできるアーキテクチャを実装する必要があります。ネットワークベースのDDoS緩和システムは、複雑なアプリケーションレイヤー攻撃の軽減に一般的に効果がないため、これは重要な考慮事項です。 # 悪意のあるウェブリクエストを検出してフィルタリングする (BP1、BP2） アプリケーションで を実行すると AWS、Amazon CloudFront （およびそのキャッシュ機能) HTTP と Shield Advanced 自動アプリケーションレイヤー保護を活用して AWS WAF、アプリケーションレイヤーDDoS攻撃中に不要なリクエストがオリジンに到達するのを防ぐことができます。 # Amazon CloudFront Amazon CloudFront は、ウェブ以外のトラフィックがオリジンに到達するのを防ぐことで、サーバーの負荷を軽減できます。 CloudFront アプリケーションにリクエストを送信するには、完了したTCPハンドシェイクを通じて有効な IP アドレスで接続を確立する必要があります。これは偽装できません。さらに、 CloudFront は、読み取りが遅い攻撃者や書き込みが遅い攻撃者 ([Slowloris](https://en.wikipedia.org/wiki/Slowloris_(computer_security)) など) から自動的に接続を閉じることができます。 ## CDN キャッシュ CloudFront では、 AWS エッジロケーションから動的コンテンツと静的コンテンツの両方を提供できます。CDN キャッシュからプロキシキャッシュ可能なコンテンツを提供することで、キャッシュ の期間中、特定のエッジキャッシュノードからのリクエストがオリジンに到達するのを防ぐことができますTTL。有効期限が切れているがキャッシュ可能なコンテンツの[リクエストが折りたたまれ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-traffic-spikes)ると、非常に短い場合でも、そのコンテンツのリクエストフラッド中にごくわずかな数のリクエストがオリジンに到達するTTLことを意味します。さらに、[CloudFront Origin Shield ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)などの機能を有効にすると、オリジンの負荷をさらに軽減できます。[キャッシュヒット率を向上させる](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)ためにできることは、影響のあるリクエストフラッド攻撃と影響のないリクエストフラッド攻撃の違いを意味します。 # AWS WAF を使用すると AWS WAF、グローバル CloudFront ディストリビューションまたはリージョンリソースでウェブアクセスコントロールリスト (Web ACLs) を設定して、リクエスト署名に基づいてリクエストをフィルタリング、モニタリング、ブロックできます。リクエストを許可またはブロックするかどうかを決定するには、IP アドレスまたは発信国、リクエスト内の特定の文字列またはパターン、リクエストの特定部分のサイズ、悪意のあるSQLコードまたはスクリプティングの存在などの要因を考慮できます。リクエストに対してCAPTCHAパズルやサイレントクライアントセッションチャレンジを実行することもできます。 また CloudFront 、 AWS WAF と の両方で、地理的制限を設定して、選択した国からのリクエストをブロックまたは許可することもできます。これにより、ユーザーにサービスを提供しないことが予想される地理的場所からの攻撃をブロックまたはレート制限することができます。の詳細な地理的一致ルールステートメントを使用すると AWS WAF、リージョンレベルまでアクセスを制御できます。 [スコープダウンステートメント](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-scope-down-statements.html)を使用して、ルールが評価するリクエストの範囲を絞り込み、[ウェブリクエストのコストを節約し](https://docs.aws.amazon.com/waf/latest/developerguide/waf-labels.html)、リクエストに一致するルールが一致結果を同じウェブ で後で評価されるルールに伝達できるようにしますACL。複数のルールで同じロジックを再利用するには、このオプションを選択します。 レスポンスコード、ヘッダー、本文を使用して、完全なカスタムレスポンスを定義することもできます。 悪意のあるリクエストを特定するには、ウェブサーバーログを確認するか、 AWS WAFのログ記録と sampling.By リクエストを使用して AWS WAF ログ記録を有効にすると、ウェブ によって分析されたトラフィックに関する詳細情報が得られますACL。 はログフィルタリング AWS WAF をサポートしているため、検査後にログに記録するウェブリクエストとログから破棄されるリクエストを指定できます。 ログに記録される情報には、 が AWS リソースからリクエストを AWS WAF 受信した時間、リクエストに関する詳細情報、およびリクエストされた各ルールの一致するアクションが含まれます。 サンプルリクエストは、過去 3 時間以内にいずれかの AWS WAF ルールに一致したリクエストに関する詳細を提供します。この情報を使用して、潜在的に悪意のあるトラフィック署名を特定し、それらのリクエストを拒否する新しいルールを作成できます。ランダムなクエリ文字列を持つ多数のリクエストが表示される場合は、アプリケーションのキャッシュに関連するクエリ文字列パラメータのみを許可してください。この手法は、オリジンに対するキャッシュの破壊攻撃を軽減するのに役立ちます。 # AWS WAF – レートベースのルール AWS では、5 分間のスライディングウィンドウで受信したHTTPリクエストの数が定義したしきい値を超えた場合に、不正なアクターの IP アドレスを自動的にブロック AWS WAF するために、レートベースのルールを使用してリクエストフラッドから保護することを強くお勧めします。問題のあるクライアント IP アドレスは、403 の禁止レスポンス (または設定されたブロックエラーレスポンス) を受け取り、リクエスト率がしきい値を下回るまでブロックされたままになります。 レートベースのルールをレイヤー化して保護を強化し、以下を行うことをお勧めします。 + 大規模なHTTPフラッドからアプリケーションを保護するための一括レートベースのルール。 + 一括レートベースのルールよりも制限の厳しいレートURIsで特定の を保護する 1 つ以上のレートベースのルール。 例えば、5 分間に 500 リクエストの制限がある一括レートベースのルール (スコープダウンステートメントなし) を選択し、スコープダウンステートメントを使用して、500 (5 分間に 100 リクエストまで) より低い制限の次のレートベースのルールを 1 つ以上作成できます。 + ファイル拡張子のないリソースのリクエストがさらに保護`if NOT uri_path contains '.'`されるように、「」のようなスコープダウンステートメントで**ウェブページ**を保護します。これにより、頻繁にターゲットにされるURIパスであるホームページ (`/`) も保護されます。 + 「」のようなスコープダウンステートメントで**動的エンドポイント**を保護する`if method exactly matches 'post' (convert lowercase)` + データベースに到達する、または「」のようなスコープダウンでワンタイムパスワード (OTP) を呼び出す**大量のリクエスト**を保護する`if uri_path starts_with '/login' OR uri_path starts_with '/signup' OR uri_path starts_with '/forgotpassword'` 「ブロック」モードのレートベースは、リクエストの defense-in-depth WAFフラッドから保護するための設定の基礎であり、コスト保護リクエストを承認するための要件 AWS Shield Advanced です。以下のセクションでは、追加の defense-in-depth WAF設定について説明します。 # AWS WAF – IP の評価 IP アドレスの評価に基づく攻撃を防ぐには、IP マッチングを使用してルールを作成するか、 の [マネージドルール](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html)を使用します AWS WAF。 [Amazon の IP 評価リストルールグループ](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon)には、Amazon の内部脅威インテリジェンスに基づくルールが含まれます。これらのルールは、ボット、 AWS リソースに対する偵察の実行、またはDDoSアクティビティへの積極的な関与である IP アドレスを探します。この`AWSManagedIPDDoSList`ルールは、悪意のあるリクエストのフラッドの 90% 以上をブロックしていることが確認されています。 [匿名 IP リストルールグループ](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-anonymous)には、ビューワー ID の難読化を許可する サービスからのリクエストをブロックするルールが含まれています。これには、VPNs、プロキシ、Tor ノード、クラウドプラットフォーム ( を除く AWS) からのリクエストが含まれます。 さらに、Security [Automations for AWS WAF](https://docs.aws.amazon.com/solutions/latest/security-automations-for-aws-waf/component-details.html) solution の IP [Lists パーサーコンポーネントを使用して、サードパーティーの IP](https://docs.aws.amazon.com/solutions/latest/security-automations-for-aws-waf/component-details.html#ip-lists-parser) 評価リストを使用することもできます。 # AWS WAF - インテリジェントな脅威の軽減 ボットネットは重大なセキュリティ上の脅威であり、スパムの送信、機密データの盗難、ランサムウェア攻撃の開始、不正クリックによる広告詐欺のコミット、分散 denial-of-service （DDoS) 攻撃の開始などの違法または有害な活動を実行するために一般的に使用されます。ボット攻撃を防ぐには、[AWS WAF Bot Control](https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control.html) マネージドルールグループを使用します。このルールグループは、自己識別ボットにラベルを追加し、一般的に望ましいボットを検証し、高い信頼性のボット署名を検出し、自己識別しない高度なボットの検出を追加する「ターゲット」保護レベルを提供する基本的な「共通」保護レベルを提供します。 ターゲットを絞った保護では、ブラウザ調査、フィンガープリント、動作ヒューリスティックなどの高度な検出手法を使用して不正なボットトラフィックを特定し、レート制限やチャレンジルールアクションなどの緩和コントロールを適用CAPTCHAします。Targeted には、人間のようなアクセスパターンを適用し、リクエストトークンを使用して動的レート制限を適用するためのレート制限オプションも用意されています。詳細については、[AWS WAF 「Bot Control ルールグループ」を参照してください。 ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control.html)アプリケーションのログインページで悪意のある乗っ取りの試みを検出および管理するには、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループを使用できます。ルールグループは、クライアントがアプリケーションのログインエンドポイントに送信するログイン試行を検査し、ログイン試行に対するアプリケーションの応答も検査して、成功率と失敗率を追跡します。 アカウント作成の不正行為は、攻撃者が 1 つ以上の偽のアカウントの作成を試みるオンライン上の違法行為です。攻撃者は、プロモーションやサインアップボーナスの濫用、なりすまし、フィッシングなどのサイバー攻撃などの不正行為のために偽のアカウントを使用します。偽のアカウントの存在は、顧客からの評判に傷をつけたり、金銭的な被害を伴う不正行為のリスクを生じさせたりするものであり、ビジネスに悪影響を及ぼす可能性があります。 Fraud Control アカウント作成の不正防止 (ACFP) AWS WAF 機能を実装することで、アカウント作成の不正試行をモニタリングおよび制御できます。 AWS WAF は、コンパニオンアプリケーション統合 `AWS ManagedRulesACFPRuleSet` を使用して AWS マネージドルール ルールグループでこの機能を提供しますSDKs。 これらの保護の詳細については、[*AWS WAF インテリジェントな脅威の軽減 *を参照してください。](https://docs.aws.amazon.com/waf/latest/developerguide/waf-managed-protections.html) # アプリケーションレイヤーDDoSイベントを自動的に緩和する (BP1、BP2、BP6） にサブスクライブしている場合は AWS Shield Advanced、[Shield Advanced 自動アプリケーション](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)[レイヤーDDoS緩和 ](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)を有効にできます。この機能は、ユーザーに代わってレイヤー 7 DDoSイベントを軽減するためのルールを自動的に作成、評価、デプロイ AWS WAF します。 AWS Shield Advanced は、WAFウェブ に関連付けられた保護されたリソースごとにトラフィックベースラインを確立しますACL。確立されたベースラインから大幅に逸脱したトラフィックは、潜在的なDDoSイベントとしてフラグが付けられます。イベントが検出されると、イベントを構成するウェブリクエストの署名を識別 AWS Shield Advanced しようとし、署名が特定されると、その署名でトラフィックを軽減するための AWS WAF ルールが作成されます。 ルールが履歴ベースラインに対して評価され、安全であると判断された場合、ルールは Shield マネージドルールグループに追加され、ルールがカウントモードまたはブロックモードでデプロイされるかどうかを選択できます。Shield Advanced は、イベントが完全に沈静化されたと判断すると、 AWS WAF ルールを自動的に削除します。 # Engage SRT (Shield Advanced サブスクライバーのみ） さらに、Shield Advanced にサブスクライブすると、 をエンゲージ AWS SRTして、アプリケーションの可用性を損なう攻撃を軽減するためのルールを作成できます。アカウントの AWS Shield Advanced と への制限付きアクセスを許可 AWS SRTできます AWS WAF APIs。 AWS SRT はこれらにアクセスしてAPIs、明示的な認可がある場合にのみアカウントに緩和策を配置します。詳細については、このドキュメントの[サポート](support.md)「」セクションを参照してください。 AWS Firewall Manager を使用して、組織全体で AWS Shield Advanced 保護やルールなどのセキュリティ AWS WAF ルールを一元的に設定および管理できます。 AWS Organizations 管理アカウントは、Firewall Manager ポリシーの作成が許可されている管理者アカウントを指定できます。これらのポリシーでは、リソースタイプやタグなどの条件を定義して、ルールが適用される場所を決定できます。これは、複数のアカウントがあり、保護を標準化する場合に便利です。 以下についての詳細: + AWS マネージドルール については AWS WAF、「」の[AWS マネージドルールAWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html)「」を参照してください。 + 地理的制限を使用して CloudFront ディストリビューションへのアクセスを制限するには、[「コンテンツの地理的ディストリビューションの制限](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html)」を参照してください。 + を使用して AWS WAF、以下を参照してください。 + [の開始方法 AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html) + [ウェブACLトラフィック情報のログ記録](https://docs.aws.amazon.com/waf/latest/developerguide/logging.html) + [ウェブリクエストのサンプルの表示](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html#web-acl-testing-view-sample) + レートベースのルールの設定については、「 の[レートベースのルールを使用してウェブサイトとサービスを保護する AWS WAF](https://aws.amazon.com/blogs/aws/protect-web-sites-services-using-rate-based-rules-for-aws-waf/)」を参照してください。 + Firewall Manager を使用して AWS リソース全体のルールのデプロイを管理する方法については、以下を参照してください。 + [Firewall Manager AWS WAF ポリシー の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html)。 + [Firewall Manager Shield Advanced ポリシー の開始](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-shield.html)方法。