re:Invent 2024: AWSのDDoS対策 - Shield、CloudFront、WAFの活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - You are under a DDOS attack! Are you ready to respond? (CDN306)
この動画では、DDoS攻撃への対応と防御について詳しく解説しています。AWS ShieldやCloudFront、AWS WAFなどを組み合わせた多層防御の実践的な方法を紹介し、特にCloudFrontが攻撃の90%以上を吸収できた実例も共有されています。AWS Shieldチームは1日約2,000件、年間約70万件のDDoS攻撃を確認しており、HTTP/2 Rapid Reset攻撃など新しい攻撃手法への対応も説明されています。また、Honeypotを活用した脅威インテリジェンスの収集方法や、Rate-basedルールの設定方法など、具体的な防御手法についても詳しく解説されています。DDoS攻撃発生時の初動対応から、インシデント後のレビューまでの一連のプロセスを包括的に網羅しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
DDoS攻撃対策セッションの概要と講演者紹介
みなさん、こんにちは。re:Inventの2日目です。みなさん、いかがお過ごしでしょうか？これまで楽しんでいただけていますか？素晴らしいですね。本日は皆様とご一緒できることを嬉しく思います。今日は重要なトピックについてお話しします。それは「DDoS攻撃を受けた時、あなたは対応できていますか？」というテーマです。このセッションはCDN 306です。まず自己紹介させていただきます。私はEtienneと申します。AWS WAF、CloudFront、Shield Advancedを使用して、お客様のワークロードをAWS上で保護するお手伝いをしています。本日は同僚のNitinと一緒に発表させていただきます。皆様、こんにちは。AWS WAFとShieldチームのNitin Saxenaです。私たちのチームは、ボットやDDoSがお客様のアプリケーションやインフラに影響を与えないようにすることをミッションとしています。本日はお越しいただき、ありがとうございます。
本日お話しする技術について、ある程度の理解をお持ちの方を想定しています。AWS WAF（Webアプリケーションファイアウォール）、CloudFront（コンテンツデリバリーネットワーク）、そして当社のマネージドDDoSサービスであるAWS Shield Advancedです。これは300レベルの講演ですが、これらの技術に不慣れな方にも分かりやすく説明させていただきます。 本日のアジェンダは、DDoS攻撃とは何か、攻撃にどのように対応できるのか、そしてAWSがバックグラウンドでどのようにサポートしているのかについて説明します。最後に、トラブルを避けるために活用できるベストプラクティスについてご紹介します。
DDoS攻撃の概要と対応シナリオ
少しの間、eコマースのWebサイトやAPIを管理するSREやチームメンバーの立場に立って考えてみてください。金曜の午後、プールでリラックスしようとしているところです。くつろごうとした矢先、運用チームから連絡が入ります。顧客がWebサービスにアクセスできない、注文が出来ない、問題の原因究明を始める必要があると。次のステップは何で、どのようなアクションを取るべきでしょうか？もしかしたら、このような事態に備えて計画を立て、手順を決めているかもしれません。あるいは、セキュリティ態勢をまだ発展させている途中かもしれません。セキュリティは常に進行中の作業であり、成熟には時間がかかることは周知の通りです。
それでは、この仮想のSREと共に、このリスクを軽減する方法を探る旅に出かけましょう。この旅に出る前に、分散型サービス妨害（DDoS）攻撃が環境に与える影響について少しお話ししたいと思います。最も単純な形式では、DDoS攻撃はボリューム攻撃です。パブリックエンドポイントに対して大量のリクエストやパケットが送られ、アプリケーションを圧倒する可能性があります。多くの場合、これらのリクエストやパケットは多数のIPソースから送られてきます。このような攻撃の目的は、サービスをオフラインにするか、そのパフォーマンスを低下させることです。DDoS攻撃は一般的にOSIスタックのネットワーク層やトランスポート層を標的にしますが、最近ではHTTPリクエストフラッドやボットによる高度な攻撃が可能なレイヤー7での攻撃がより一般的になってきています。
私たちのSREは、Webサービスに対する大量のリクエスト攻撃というまさにこの課題に直面しています。これから、どのような対策を講じるべきかを見ていきましょう。 攻撃は複数のIPアドレスから分散してこれらのエンドポイントを攻撃し、 最終的に正当なユーザーの商品購入体験に影響を与えることになります。AWSと私たちのお客様を日々保護しているShieldレスポンスチームから共有されたデータをご紹介して、状況を説明したいと思います。平均して1日約2,000件、年間で約70万件のDDoS攻撃を確認しています。攻撃は、大量のトラフィックを伴う短期的で急激なものから、複数の攻撃ベクトルを使用する長期的なものまでさまざまです。後者の場合、単に大量のリクエストを送信するだけでなく、ログインやAPIに対するブルートフォース攻撃などの形で潜んでいることもあります。
例えば昨年、AWSのプロアクティブな監視システムがCloudFrontに対する異常なHTTP/2トラフィックの急増を検知し、そのピーク時には1秒あたり1億5500万リクエストに達しました。CloudFrontは自動的にこのリクエストフラッドを緩和しましたが、これは現在ではHTTP rapid resetタイプの攻撃手法として知られています。では、SREのお客様にとって、これはどのような影響をもたらすのでしょうか？
「このサイトにアクセスできません」というエラーが表示されます。この場合、DNSが解決できない状態です。大量のリクエストによってDNSサービスが圧迫されているのです。また、DNSの解決に成功したお客様の場合でも、バックエンドサービスが十分な速さで応答できないため、5XXエラーを受け取ることになります。 つまり、SREとして直面する典型的なエラーには、さまざまな5XXエラー、DNSの解決エラー、あるいは単純なレイテンシーの増加などが含まれます。
この問題の解決に向けて、どのように取り組むべきか見ていきましょう。SREが待機し、ノートPCを開いて、 問題の対応を始めます。このSREが以前にDDoS攻撃に対応したことがなく、問題解決に奔走している状況を想定してみましょう。このSREはまず、どのシステムが影響を受けているのかを把握する必要があります。システムの全体像を理解し、それぞれの所有者を把握しておくことが重要です。問題を迅速に解決するためには、これら両方の情報が不可欠です。
トリアージを開始する最初のステップは、会議通話を始めるか、関係者を一室に集めることです。復旧プロセスの責任者や、部屋の外部のステークホルダーとのコミュニケーションを担当する人を明確にすることが重要です。ビジネスオーナーや状況を把握したい人々がいるためです。これらの組織的な役割と責任を割り当てることが重要です。この時点で、AWS Support、Enterprise Support、またはAWSアカウントチームに連絡することをお勧めします。AWSパートナーと協力している場合は、彼らにも連絡して会議通話に参加してもらい、協力して対応できるようにしましょう。
AWSによるDDoS攻撃対策の仕組み
これが私たちのSREのアーキテクチャです。 Load BalancerとAmazon API Gatewayを使用したシンプルなアーキテクチャで、ComputeとAWS Lambdaがあり、アプリケーションがダウンしている状態です。この攻撃に対処しながらレジリエンシーを構築していく上で重要なのは、まず問題の発生箇所を特定するためにメトリクスを有効にすることです。最初にAWS CloudTrailから始めることが重要です。最終的にインシデント後のレビューを作成する必要があるため、環境に加えられた変更を追跡することは重要なタスクとなります。
AWS CloudTrailのログ取得を有効にすることは重要です。次に、SREチームはElastic Load BalancingとAmazon API Gateway両方のAmazon CloudWatchメトリクスを有効にします。これらのメトリクスについては後ほど詳しく説明します。API GatewayとElastic Load Balancerのログ取得を有効にする必要があります。これにより、インシデント後のレビューを作成する際に、発生前と発生後の状況を把握することができます。次に、Amazon Route 53のヘルスチェックを構築します。これはアプリケーションがパブリックエンドポイントで稼働しているかを確認する単純なヘルスチェックです。APIとWebサイトの2つのヘルスチェックを設定することで、可用性の改善状況を追跡することができます。
これらのテクノロジーを導入したところで、監視すべきメトリクスを見ていきましょう。運用チームはこのようなデータにアクセスできる必要があります。これらは簡単にCloudWatchダッシュボードに組み込むことができますし、コンソールにアクセスするだけでも確認できます。EC2ワークロードには2つのアプローチがあります。スケールアウトであれスケールアップであれ、何らかのスケール機能を持つ必要があり、そのためのプレイブックが必要です。まだプレイブックがない場合は、Auto Scalingグループの最大サイズを増やすだけで済むスケールアウトの方が早い対応かもしれません。スケールアップは新しいインスタンスタイプでのテストが必要になる可能性があるため、インシデント発生時の最初の対応としては適していないかもしれませんが、障害対応時にはあらゆる選択肢を検討する必要があります。
EC2インスタンスのネットワークとCPU使用率を監視する必要があります。これらはインスタンスの負荷状況を示す指標となります。特にAmazon API Gatewayについては、処理可能なリクエスト数を超える負荷がかかっているかどうかを判断するため、エラー数を監視する必要があります。これらのエラーを確実に監視する必要があります。さて、ここからが本題です。実際の対策を開始していきます。APIとロードバランサーの両方で高いリクエスト率が発生していることが分かり、これは単純な量的攻撃とレイヤー7のリクエスト攻撃であることが判明しました。
DNSも影響を受けているため、まずはこれを修正する必要があります。そのため、最初にAmazon Route 53を追加します。Route 53は高可用性のDNSサービスで、大量のDNSトラフィックを処理することができます。クライアントがIPアドレスを解決できるようにするため、これが最初のステップとなります。
次のステップは、Amazon CloudFrontを導入することです。可能な限りキャッシュを活用してオリジンの負荷を軽減します。たとえ短時間であっても、キャッシュのTTLが短いほうが、まったくキャッシュがない状態よりも望ましいです。エラーも一定期間キャッシュする必要があります - デフォルトでは、CloudFrontは5秒間キャッシュします。攻撃を受けている間は、バックエンドの回復のチャンスを最大限に高めるため、この設定を調整することをお勧めします。このアプローチでAPIを保護することができ、APIにキャッシュ可能なレスポンスがある場合は、それらをキャッシュすることも選択できます。レスポンスが動的な性質を持つ場合は、次の一連の対策が役立ちます。
CloudFrontは、最初の段階で重要なメリットを提供します。CloudFrontを導入することで最初に得られる保護は、ロードバランサーに到達する前のプロトコルとパケットの検査です。接続はポート80とポート443のみを受け付け、CloudFrontダッシュボードから直接AWS WAFを簡単に統合できます。フロントエンドのリクエストパスを保護したので、次はバックエンドサービスを保護する必要があります。Application Load BalancerをCloudFrontのIPアドレスに制限することが重要です。これには2つの選択肢があります：VPCで使用できるVPCプレフィックスリストか、あるいは最近リリースされたVPC originsという機能で、これを使用すると、プライベートVPC内にプライベートな新しいロードバランサーを作成し、ロードバランサーに追加の制御を加えることなくCloudFrontと通信することができます。
プラットフォームと設定について詳しく見ていきましょう。SREが初めてCloudFrontを有効にする際に直面する課題があります。まず、できるだけ多くのキャッシュを試してください。すぐに使える組み込みのポリシーがありますし、より短いTTLのためにそれらのポリシーをカスタマイズすることもできます。 同様に、特定のエラーについては、4xxと 5xxエラーに対してエラーのキャッシュ時間を定義できます。これらのエラーレスポンスをカスタマイズすることもできますが、現時点ではそれが最優先事項ではないかもしれません。
直面しているDDoS攻撃のタイプに応じて、 次のステップではCloudFrontのネイティブ機能を有効にして、取引のない国からのアクセスをブロックするジオブロッキングを開始します。これはリクエスト量を抑制するための迅速な対策となります。後でAWS WAFでより細かく調整することもできるので、これは一時的な対応かもしれません。次のステップは、ロギングを有効にすることです。CloudFrontが提供しているリクエストのログを取得し始める必要があります。これにより、 CloudFrontダッシュボードでパフォーマンスの可視性も得られます。
CloudFrontでもう1つ追加のメトリクス、特にOrigin LatencyのCloudWatchメトリクスを有効にする必要があります。これにより、バックエンドの健全性と、CloudFrontへの応答の適時性についての感覚をつかむことができます。総リクエストの割合、エラー率、CloudFrontディストリビューションにリクエストを送信している世界各地の地域など、さらに確認できるメトリクスがあります。
ここで、CloudFront ダッシュボードから直接AWS WAFを有効にすることができます。コンソールから直接WAF Web ACLを有効にするだけです。これは数回クリックするだけで、実装にそれほど時間はかかりません。すぐに使える4つのルールカテゴリが追加され、最初はモニターモードで有効にできます。これは、リクエストをカウントモードにして開始することを意味します。すぐにブロックする必要はなく、これらのルールを確認してから後でブロッキングモードに切り替えることができます。OASトップ10などのOASの出版物に基づいた、ほとんどすべてのWebサイトが必要とするCore Rule Setで保護することをお勧めします。
OASの各種発行物（OAS Top 10、IPレピュテーションリスト、匿名IPレピュテーションリストなど）は、Amazonの脅威インテリジェンスから得られたものです。これらのルールセットは、既知の悪意のある攻撃者のIPからのリスクを防ぐのに役立ちます。また、既知のVPN、Torノード、匿名プロキシ、その他のホスティングプロバイダーからのリクエストアクセスを防ぐこともできます。これは、基本的な保護を即座に実装する効果的な方法です。最後のステップとして、基本的なIP集約キーのレート制限を追加します。これにより、正当な顧客からWebサービスが想定するリクエスト率を適切に設定できます。後で追加のレート制限を設定する予定なので、まずは一般的なレート制限として定義しておきましょう。
これをブロッキングモードに切り替え、 今後の状況を確認するためにロギングを有効にします。これは最終レポートにとって特に重要です。 ここで、レートベースのコントロールについてより深く掘り下げ、Webベースのコントロールの強力な機能をいくつかご紹介したいと思います。このシナリオでは、APIを持つSREの2つのユースケースを見ていきます。まず、そのエンドポイントを保護したいと考えています。このレートベースのコントロールのスコープを、フォワードスラッシュAPIパスに設定します。IPアドレスだけでAPI集約キーを使用することもできますが、認証ヘッダーを追加することで、非常にきめ細かなレート制限が可能になります。この例では、300秒あたり50リクエストを評価しています。次のユースケースで説明する他の利用可能なアクションではなく、通常はブロックモードにすることをお勧めしています。
これは、シンプルなIPレート制限をベースにした、アンチDDoSルールのさらなる発展形です。ここでは、このレート制限の評価基準として、ホストヘッダー、URIパス、IPを組み合わせています。これらの値のいずれかにユニークな部分があれば、新しいキーとなります。これは、DDoS保護のために非常に低い制限を設定する重要な方法です。ホストヘッダー、パスURI、IPなどの要素を組み合わせることができ、さらにきめ細かな制御が必要な場合は、検索クエリを保護するためにクエリ文字列を含めることもできます。APIエンドポイントではなくWebコンテンツを提供するWebサイトの場合、ブラウザの正当性を証明するためのJavaScriptチャレンジの使用を検討するとよいでしょう。1つのホスト名で混在環境を使用している場合は、API機能を壊さないようにブロックアプローチが推奨されます。
このプロセスは、ルールを修正しながら時間をかけて進化させていきます。WAFを構築する際のこのモデルは、ブロックしたい内容に基づいてコントロールを実装し、ダッシュボードで提供されるログを観察し、そのルールを調整して、最終的にブロックまたはチャレンジアクションに移行するという流れです。このワークフローにより、誤った判断や不適切なブロッキングの想定による影響を軽減できます。Defense in Depthを構築する一環として、レートベースのコントロールだけでなく、バックエンドサービスに送信されるペイロードのサイズを含むペイロードコントロールも考慮してください。許可または禁止する国のGEOコントロール、複数のレートベースのコントロール、SQLインジェクション攻撃、クロスサイトスクリプティング、既知の悪意のあるLFIやRFIに対するペイロード検査を実装できます。
SREがWAFダッシュボードにアクセスしてログをクエリする際、2つの重要なクエリを確認できます。これらのクエリは、受信リクエストの地理位置情報データとWAFルールの最終判断を示す終端ルールを分析します。結果として、許可、ブロック、カウントモード、チャレンジの各リクエスト数が表示され、そのトラフィックパターンの状況を把握するのに役立ちます。
これらのクエリは、CloudWatchダッシュボードで使用したり、お好みのシーンに合わせて調整したりすることができます。AWS WAFダッシュボードには、追加料金なしで使用できる事前設定されたダッシュボードがあり、同様の監視機能を提供します。
次のステップとして、Rate-basedルールが発動し、環境を保護し始め、レートチャレンジやリクエストレートが低下し、多くの不正なトラフィックをブロックしている中で、運用ダッシュボードにどのようなメトリクスを追加するかを検討します。運用チームが環境に精通していることを確認するため、ダッシュボードに適切なメトリクスを表示する必要があります。ここで重要なものをいくつか挙げてみましょう：Amazon CloudFrontを通過するリクエストと総エラーレートはアラートを設定する価値があります。CloudFrontを通過するリクエストの閾値が高い場合、問題が発生する可能性があるときに適切な担当者に通知するアラームを設定できます。ヘルスチェックのステータスはチームへの可視性を確保する上で重要です。また、AWS WAFのメトリクスも確認する必要があります。ブロック率が高い場合は、攻撃が進行中であることを示唆しています。
SREはプールに向かう準備ができていますが、まだその時ではありません。インシデント後のレビューを少し行う必要があります。まず、インシデントが終了したと判断する基準を決める必要があります。通常、これはヘルスチェックが正常である、アプリケーションが応答している、またはCloudWatchメトリクスが想定される負荷を示しているかどうかです。さらなる問題がないかログを調査し、必要に応じてルールを修正します。また、CloudWatchリクエストレートや高エラーレートなど、潜在的な活動を警告するアラームを追加します。最後に、インフラストラクチャに加えた変更と、将来の通常サイクルの一部として計画する必要がある追加の対策を文書化します。
re:Inventで開催されるARC 314セッションをお勧めします。このセッションでは、このような攻撃への対応方法とインシデント後のレビューから得られる教訓について、より詳しく説明しています。SREはプールサイドで満足し、注文も順調に処理されています。ここで、AWSがお客様を支援するために裏で行っていることについて、Nitinに説明を譲りたいと思います。
AWSの脅威インテリジェンス収集と活用
ありがとう、Etienne。WebアプリケーションがDDoS攻撃を受けた際に取れるアクションについて共有してくれました。DDoS攻撃の防止には、多層防御戦略が必要です。今日では、DDoS攻撃を仕掛けるのはそれほど難しいことではありません。保護すべきものがある限り、攻撃は続くでしょう。DDoS耐性のある優れたアーキテクチャは層状に構築されており、AWSはDDoS対策の最前線に立っています。このプレゼンテーションのこのパートでは、AWSがDDoS攻撃を防ぐために行っていることについてお話しします。セキュリティのすべてがそうであるように、DDoS防止も共有責任であり、今日は私たちが攻撃を防ぐために行っていることについてお話しし、後半では、クラウドにおけるセキュリティである、お客様の役割について説明します。
クラウドのセキュリティについて説明する前に、AWSへのトラフィックの流れを見てみましょう。左側にはPOPとTransit Centerがあります。中央には、Edge Serviceと呼ばれるAmazon CloudFront、AWS Global Accelerator、そしてロードバランシングのサービスがあります。これらが私たちのEdge Serviceです。トラフィックは、世界中の何百もの都市に配置されたPOPを通じて入ってきます。また、リージョナルなリソースに対しては、AWSが所有するTransit Centerを通じてトラフィックが入ってきます。
トラフィックはTransit Centerに入り、各サービスに配信され、そこからリージョナルなワークロードへと届けられます。AWS Shield Standardはトラフィックの流れの中に組み込まれた一連のサービスで、トラフィックのスクラビングと検査を行います。これは私たちのシステムにおけるDDoS防御の第一層を形成し、DDoS攻撃に対する最前線の防御として機能します。AWS Shield Standardは、すべてのAWSユーザーがデフォルトで利用できます - 常にオンで、常に実行され、トラフィックを検査し続けています。
まさにこの瞬間も、DDoS攻撃は発生しており、AWS ShieldはTransit CenterとPoint of Presenceの中で、トラフィックを検査しています。システムに入ってくるトラフィックを監視する際、まず最初にトップトーカーを特定し、インテリジェントなレート制限を適用します。このレート制限はリソースを認識しており、トップトーカーにレート制限を適用する前に、利用可能な計算能力とネットワークリソースを確認します。また、既知の脅威からも保護します。後ほど、これらの既知の脅威とは何か、どのように特定し、データを収集するのかについて詳しく説明します。さらに、不審なポートからのトラフィックなどの不審なトラフィックを特定し、プロトコルを考慮した緩和策を実施します。
これはAWS Shieldのインフラストラクチャがどこに配置されているかを示すアーキテクチャの図です。先ほど説明したように、AWS ShieldはEdge LocationとTransit Centerを持つリージョナルロケーションでトラフィックの流れに組み込まれています。インフラストラクチャがグローバルに分散しているため、この分散型の特性を活かして、非常に大規模なDDoS攻撃を吸収することができます。その役割は、出力を最大化し、悪意のあるトラフィックがネットワークに入ってくるのを最小限に抑えることです。Transit Centerとサービスでトラフィックをブロックすることで、お客様のワークロードへの到達を防ぎます。
AWS ShieldがPoint of Presenceインフラストラクチャをどのように保護しているかをより詳しく見てみましょう。例を挙げて説明します。SYNフラッドは、非常に一般的なネットワーク層のDDoS攻撃手法です。SYNフラッドでは、攻撃者がTCPの3ウェイハンドシェイクを悪用します。通常、クライアントがSYNを送信し、サーバーがACKを送信し、その後クライアントがハンドシェイクを完了します。SYNフラッドでは、攻撃者がこのTCPハンドシェイクを悪用し、リクエストを完了することなく複数のSYNリクエストを送信します。これにより、サーバー側でACKの完了を待つ間にポートが枯渇する可能性があります。AWS Shieldは、ネットワークの最前線にSYNプロキシを組み込んでおり、SYNフラッドを直接緩和します。また、UDPサポートなどの不審な特徴も監視しており、攻撃者が他所でリフレクション攻撃を行うために私たちのサービスを利用しようとする場合もあります。AWS Shieldはそれらの試みを監視し、エッジでそれらの攻撃を吸収します。
私たちのボーダーネットワークでは、AWS Shieldはネットワークレベルで見てきたすべての対策を行うだけでなく、リージョナルおよびボーダーネットワークでさらに多くの機能を提供します。SYN攻撃を吸収するためのSYNプロキシを適用し、トップトーカー検出や不審なトラフィックの監視を行い、さらにリソースを考慮した緩和策や設定を考慮した緩和策も実施します。
例えば、Geo BlockingやNetwork ACLを設定している場合、そのトラフィックはリージョンに到達する前にエッジで完全にフィルタリングされます。DDoS攻撃者は時として、オープンポートの脆弱性を探し、サービスが実際にリッスンしていないポートにトラフィックを送信してサーバーを過負荷にしようとします。AWS ShieldはAWS Global Acceleratorの設定を確認し、Global Acceleratorがどのポートでリッスンしているかを把握します。Global Acceleratorがリッスンしていないポートへのトラフィックを検知すると、そのトラフィックがオーバーヘッドサービスに到達することを防ぎます。このように、トップトーカー、プロトコルレベルの対策、リソースレベルの対策により、Shieldはネットワークに対する大規模なLayer 3およびLayer 4の攻撃を吸収することができます。
ここまで、Layer 3とLayer 4について説明してきました。 よく受ける質問の1つに、AWSのサービスの多く（データベースやAmazon CloudFront、ほとんどのアプリケーション）がマルチテナントであることから、「ある顧客がDDoS攻撃を受けた場合、私のアプリケーションに影響が及ぶことはありますか？」というものがあります。答えは「いいえ」です。なぜなら、これはAWS Shieldの核となる原則の1つだからです。 攻撃を隔離し、サービスを円滑に運用し続け、私たちが「Noisy Neighbor Protection」と呼ぶ保護を提供します。これは、特定のリソースが攻撃を受けた際に、他の顧客への影響を自動的に防止する機能です。
CloudFrontによるLayer 7 DDoS攻撃対策
では、Layer 7について少し話しましょう。先ほどEtienneが、SREチームがDDoS攻撃に対処する際にCloudFrontを導入して攻撃を吸収した例を挙げていましたが、CloudFrontはDDoS耐性のあるアーキテクチャにおいて非常に重要です。ここ数年、DDoS攻撃はLayer 3およびLayer 4の攻撃からLayer 7のリクエストフラッドへと顕著にシフトしており、Layer 7のリクエストフラッドの中でも、Etienneが言及したHTTP/2 Rapid Reset攻撃のような新しいタイプの攻撃が出現しています。Layer 7リクエストによる攻撃は非常に実行しやすく、暗号通貨による支払いを受け付けてDDoS攻撃を代行するウェブサイトも存在します。これらのリクエストは正常なトラフィックと非常によく似ているため、パケットレベルでの緩和が困難です。
私たちはCloudFrontサービスに直接DDoS検知および緩和機能を組み込みました。HTTP/2 Rapid Reset攻撃と同様に、CloudFrontはネットワークレベルとIPレベルの両方で来る攻撃から保護するために、さまざまな対策を講じています。 Shieldと同様に、CloudFrontもトップトーカーを監視し、既知の脅威から保護し、5〜10秒以内に攻撃を緩和・吸収します。 違いは、IPレベルとリクエストレベルの両方を見ているという点です。 リクエストエントロピーを分析します。これは、通常のWebトラフィックには特定のシグネチャがあるということです。リクエストヘッダー、リファラーヘッダー、TLSフィンガープリントなどが関連付けられています。DDoSトラフィックが入ってくると、HTTPリクエストの属性が変化します。
CloudFrontはレイヤー7のリクエストパスにあり、HTTPヘッダーやレイヤー7でのみ利用可能なその他の情報を確認できるため、ネットワークレベルでは検知できない異常や変動を監視することができます。これらの異常とトラフィックの挙動の変化を組み合わせてDDoS攻撃かどうかを判断し、IPパケットレベルとリクエストレベルの両方で対策を実施します。これはCloudFrontがDDoS攻撃に対して包括的な保護を提供している一例です。
もう一つの例をご紹介しましょう。数ヶ月前、CloudFrontは単独で攻撃の90%以上を吸収し、アプリケーションへの影響を完全に防ぎました。この攻撃は7分足らずの間に34億3000万件のリクエストを記録しましたが、CloudFrontはこれを吸収することができました。グラフには、ブロックされたパケットとリクエストの2つの線が示されています。
私たちのミッションは、最前線の防御としてインフラストラクチャとお客様のアプリケーションを保護することです。私たちは、インフラストラクチャに対して行われる大規模な攻撃を継続的に軽減しています。先ほどの説明で、CloudFrontとShieldが既知の脅威から保護すると言及しました。では、既知の脅威とは何でしょうか？それらが脅威だとどのように判断するのでしょうか？
時間の経過とともに、私たちの戦略は、自社で検証可能な脅威インテリジェンスを作成し、そのインテリジェンスを活用して悪意のあるリクエストがインフラストラクチャやお客様のアプリケーションに到達するのを防ぐように発展してきました。脅威インテリジェンスの収集がどのように機能するのか、基本的な原理を見てみましょう。脅威アクターがターゲットを攻撃する際には、必ず痕跡が残ります。これらの痕跡には、IPアドレス、リクエストの特徴、マルウェアのペイロードなどがあります。私たちはこれらの痕跡を分析し、脅威インテリジェンスに変換して、同じ脅威アクターや異なるアクターによる将来の同様の攻撃を軽減します。
では、どのようにして自社で検証可能な情報を作成しているのでしょうか？私たちの脅威インテリジェンス収集の仕組みの中核には、Honeypotと呼ばれるものがあります。これは、脆弱性のあるアプリケーション、オープンプロキシ、IoTデバイスを模倣するインスタンスのグローバルフリートです。オープンポートやソフトウェアをスキャンする攻撃者にとって、これらはお客様のアプリケーションと見分けがつきません。私たちは1日に数十億件のインタラクションを観察し、それらのリクエストペイロードと特徴を分析して、特定のIPアドレスが複数の顧客に対して悪意のある活動を試みていないかを判断します。
ハニーポットインフラストラクチャの目的は、データを生成し、そのデータを研究に活用できるようにすることです。データが収集されると、複数のターゲットを攻撃するIPアドレスや、頻繁に悪用されるオープンプロキシ、Command & Control（C&C）インフラ、特定のIPアドレスやプロキシに関連付けられたマルウェアペイロードなどの脅威指標によって、データの変換と整理を行います。これらの脅威に関する成果物や指標を使用して、Threat Intelligenceと呼ばれる統合された記録を生成します。
このThreat Intelligenceは、エッジで脅威を軽減するために、これらすべての製品で活用されています。このプレゼンテーションで紹介したサービスを含む多くのサービスが、AWSが収集した自社のThreat Intelligenceを使用して、悪意のある活動や攻撃者を軽減しています。私たちのThreat Intelligenceは、今年だけでも何十万件もの攻撃を防いできました。また、このアクショナブルなインテリジェンスをAWS内のチームや関連する外部機関に提供することで、攻撃者のボットネットを停止し、攻撃を阻止し、私たち全員にとってインターネットをより安全な場所にするために活用しています。
ここまで、クラウドを保護し、最前線の防御となる方法について説明してきました。CloudFrontが攻撃の90%を吸収したという例を挙げましたが、非常に大規模な攻撃の90%がアプリケーションに到達する前にエッジで吸収されたというのは素晴らしいニュースです。
しかし、攻撃の10%でもアプリケーションを混乱させる可能性があります。ここで重要なのが、誤検知（False Positive）という微妙なラインです。私たちはお客様のアプリケーションを知りませんが、お客様は自身のアプリケーションをよく知っています。そのため、私たちは大量アクセス元やレート制限について、そしてDDoSイベントとフラッシュクラウドを区別することについて、経験に基づいた推測を行っています。私たちが維持しなければならないトレードオフは、制御を厳しくしすぎると実際のワークロードに影響が出始め、逆に緩めすぎるとアプリケーションに影響が出始めるということです。私たちはその微妙なラインを慎重に歩んでいますが、DDoSに強いアーキテクチャを構築するための追加サービスとヒントを提供することで、最終的にアプリケーションを保護する多層防御戦略の構築にお客様も参加していただけるようにしています。
DDoSレジリエントアーキテクチャの構築
それでは、DDoSレジリエントアーキテクチャについて、さらに詳しくEtienneに説明してもらいましょう。ありがとうございました。Nitinさん、お客様の安全を守るためにチームが行っている努力に感謝します。今日お持ち帰りいただきたいQRコードが1つあるとすれば、これです。最後にもう一度表示しますが、これは必見です。これは私たちのDDoSレジリエンシーガイドで、レジリエントなアーキテクチャの構築方法について詳しく説明しています。このダイアグラムはそこからのものですが、ここではいくつかの重要なポイントについて説明します。ここで強調したいのは、Amazon CloudFrontを導入すると、Nitinとそのチームが構築したAWS Shield Standardにアクセスできるということです。Shield StandardはCloudFrontに組み込まれており、最初からそのメリットを得ることができます。これがアーキテクチャに組み込むことが重要な理由であり、Amazon API Gatewayの前に配置してAPIを保護することができます。
CloudFrontを使用することのもう1つのメリットは、コスト面でも自然なメリットがあることです。無料利用枠と無料のSSL証明書があります。そのため、ベストプラクティスとしてCloudFrontの活用を検討する価値は十分にあります。HTTPではないワークロードの場合は、CloudFrontの代わりにAWS Global Acceleratorを使用します。このテクノロジーを重ね合わせることで、多層防御の構築を支援します。CloudFrontでAWS WAFを使用することで、レートベースの制御を適用し、怪しい性質のIPアドレスをブロックしたり、チャレンジしたりすることができます。攻撃をリージョンに到達する前に、ネットワークのエッジで緩和することができます。
AWS Shield Advancedを利用することもできます。これはオプションのサービスで、困ったときに連絡できる24時間体制のレスポンスチームが背後にいます。彼らは緩和策の構築やWAFルールの作成を支援し、また彼らが確認している攻撃ベクトルの種類についての可視性も提供してくれます。DDoS対策が必要な場合は、確実に検討する価値があります。ただし、まずは基本を押さえることが重要です。最初にAWS WAFとCloudFrontを導入し、その後でShield Advancedを追加するというアプローチをお勧めします。多層防御について話す際には、AWS Firewall Manager、AWS Security Hub、Amazon GuardDutyも含まれます。Shield Advancedに加入すると、パッケージの一部としてFirewall Managerが提供されます。これにより保護を拡張することができ、AWS organizationをShield Advancedに登録し、WAFポリシーを大規模に展開し、セキュリティグループやネットワークACLを大規模に設定することができます。Firewall Managerは、時間を有効活用し、大規模な成果を達成するまでの時間を短縮するための重要な要素です。
AWS WAFルールについて説明しましょう。WAFの多層防御について話す際、いくつかのルールがあります。レートベースの制御について多く話してきましたが、他のものについても説明したいと思います。レートベースのルールは重要で、複数のIP評価リストを使用することは不可欠です。また、後のルール評価で何をしたいかを決定できるように、リクエストに適切にラベルを付けることができます。カスタマー管理ルールは、お客様が作成できるルールです。これらは、チームがすでにリスクを特定している簡単な対策であり、ブロックリストを作成して使用することができます。
私が「リビングルールセット」と呼ぶものがあります。これは定期的に更新されバージョン管理されるルールセットで、切り替えて有効にすることができます。これらは、使用しているワークロードに特化したもので、例えばAAALinuxのバックエンドサービスやWindowsのバックエンドサービスがある場合、そのワークロードに適したルールセットがあります。最後に、Shield Advanced自動ルールがあります。Shield Advancedの加入者の場合、これはルールセット内に配置され、Shield Advancedによって自動的に更新されます。フラッドを検出すると、自動的に更新されます。
そして、Bot ControlとFraud Controlがあります。これら2つのテクノロジースイートにより、直面する可能性のある特定のリスクに対処することができます。ボットアクティビティに対処する場合は、ボット対策ソリューションがあり、Fraud Controlは特にブルートフォースログイン試行や、何らかの利益を得るために大量のアカウントを作成する行為に対処するためのものです。では、これらのルールをどのように構築すればよいでしょうか？ できるだけコスト効率の良い方法で構築します。上位レベルで不正なIP評価、ユースケース固有の制御、レートベースの制御を重ね合わせます。これにより、Shield Advancedで対処する大量攻撃、そしてBot ControlとFraud Controlのルールに取り組む前に、すでに多くのリスクを排除することができます。このようにすることで、できるだけコスト効率を高めることができます。ユースケースによって多少の変更が必要かもしれませんが、これは良い考え方のモデルとなります。
DDoS対策におけるユーザーの役割とベストプラクティス
AWSでアプリケーションを構築する際のあなたの役割について少しお話ししましょう。 ルールセットは定期的にレビューすることをお勧めします。ルールセットを放置したままにするのではなく、デプロイメントサイクルの一環として、あるいはこれらの確認が必要なコンプライアンスサイクルの一環として、定期的に見直すことが大切です。 Rate-basedコントロールを使用し、時間の経過とともにこれらのコントロールを適応させていくことが重要です。 また、チームが認識しているリスクに基づいて適応させていきましょう。Route 53のヘルスチェックを活用してください。 これは、リスクの有無を確認し、何か異常がある場合にアラートを出す、シンプルながら効果的なコントロールです。
可用性の問題が発生した場合、CloudFrontとAWS WAFのダッシュボードには多くの詳細情報が表示されます。特にAWS WAFのダッシュボードは、リスクのフィルタリングを開始するのに最適な場所であり、デフォルトで多くの価値を提供します。追加の保護が必要な場合は、Shield Advancedの利用を検討してください。Shield AdvancedをRoute 53 ヘルスチェックと組み合わせて使用すると、レート制限やワークロードの保護に関するShield Advancedの緩和策がより迅速に機能します。
最後に、アカウントチームとWell-Architectedレビューのスケジュールを組むことをお勧めします。これは確実に実施する価値があります。なぜなら、インフラストラクチャの脆弱性や対処が必要な問題を発見するのに役立ち、最も可用性の高いアプリケーションを実現できるからです。 テストしていないコントロールに何の価値があるでしょうか？提案したこれらのコントロールが実際に期待通りに機能しているかを確認するため、DDoSテストやペネトレーションテストを実施することが重要です。インシデント対応プロセスを見直してください。 これは特に重要です。アプリケーションは時間とともに変化するため、アプリケーションが攻撃を受けた際に適切な人材が対応できる体制を整えることが重要です。
最後に、Shield Response Team（SRT）に相談することをお勧めします。このチームは、DDoS攻撃から環境を保護するための最適な結果を確保できるよう、環境のレビューをサポートしています。先ほどQRコードについて後ほど紹介すると申し上げましたが、さらに2つ追加でご紹介したいものがあります。 AWS Best Practices for DDoS ResiliencyとBot Controlのための規範的ガイダンスがあります。これには、AWS WAFルールの構築方法に関して私たちが話してきた内容の多くが含まれており、ログの調査に携わる運用担当者向けに、成果を上げるために活用できる様々な例も用意されています。ご清聴ありがとうございました。ご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion