re:Invent 2024: AWSセキュリティチームによるActive Defense戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How AWS scales active defense (SEC361)
この動画では、AWSのセキュリティチームがActive Defenseと呼ばれる防御システムについて解説しています。VPCやBlackfootなどのインフラ基盤を活用し、MadPotと呼ばれるハニーポットシステムで悪意のある通信を検知・分類し、インターネットからの攻撃を効果的にブロックする仕組みを説明しています。1時間あたり12兆のイベントを処理し、悪意のある攻撃の89%を防止するなど、具体的な成果も示されています。さらに、N-tuple Blocking、アウトバウンドブロッキング、S3ブロッキングなど、様々な防御手法についても詳しく解説されており、AWSの大規模インフラを保護するための包括的なセキュリティ戦略が明らかにされています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのActive Defense：インターネット上の脅威への対応
みなさん、こんにちは。私はEric Brandwineです。同僚のStephen Goodmanと一緒に、私たちが取り組んでいることについてお話しできることを大変嬉しく思います。このような講演でよくあることですが、実際の作業は複数のオフィスに散らばる大きなチームによって行われています。私たちは単に壇上に上がってその功績を受けるだけの存在です。さて、タイトルに「terminate active defense」とありますが、これは何を意味するのでしょうか。
みなさんご存知の通り、インターネット上には親切な人ばかりではありません。悪意のある人々が存在し、私たちは顧客を大切にしています。私たちは顧客に対して徹底的にこだわりを持っていますが、時としてインターネット上の悪意のある人々が私たちの顧客に対して悪意のある行動を取ることがあります。私たちはこれを決して許容しません。AWSはすでに世界クラスのセキュリティサービスと機能を提供しています。私たちのサービスはデフォルトで、また設計の段階からセキュアですが、顧客は複雑で重要なアプリケーションを構築する必要があります。多くの顧客がインターネットとの相互通信を必要とし、インターネットからのトラフィックをある程度受け入れる必要があります。そしてそれは、悪意のある人々が悪事を働く機会を与えることにもなります。そこで私たちはリーダーシップから課題を与えられました：ここで私たちに何ができるのか？顧客の防衛に積極的に参加し、インターネット上でより良い体験を提供するために、私たちに何ができるのでしょうか？
AWSネットワークの仕組みとFlow Logsの重要性
顧客のネットワークを保護する方法について話す前に、そのネットワークを理解する必要があります。私たちは3つの視点からこれを見ていきます。AWSでは、顧客に提供するネットワークをVPC（Virtual Private Cloud）と呼んでいます。この旅の最初のステップは、VPCを作成することです。これはクラウド上のプライベートネットワークです。サイトレンジを持ち、ここにリソースを配置します。 次に、インスタンスを起動します。このインスタンスにはIPアドレスがありますが、これはプライベートIPアドレスです。このIPアドレスはインターネット上では機能せず、ルーティング不可能です。 そして、もう1つのインスタンスを起動するかもしれませんし、多数のインスタンスを持つかもしれませんが、これらのマシンの少なくとも1つはインターネットと通信する必要があります。
そこで、IGW（Internet Gateway）と呼ばれるものを接続します。 これは実質的にエッジルーターです。ネットワークのエッジに位置し、あなたのネットワークとインターネットの間を橋渡しするデバイスです。そして、あなたのIPアドレスはルーティング不可能なため、EIP（ Elastic IP address）を割り当てることになります。これはインターネット上でルーティング可能なパブリックIPアドレスです。この特定のIPアドレスはRFC 1918に該当し、実際にはルーティング不可能ですが、この講演の目的上、インターネットでルーティング可能なIPアドレスだと仮定しましょう。
このホストが、例えば私たちのマーケティングウェブサイトであるaws.amazon.comと通信したい場合、パケットを送信します。 そのパケットには、このルーティング不可能なIPアドレスが送信元として含まれています。このパケットをそのままインターネットに出すと、戻りトラフィックが流れません。そのため、ネットワークを出る際に、 送信元IPアドレスをそのパブリックアドレスに書き換えます。つまり、外に出る際は送信元IPアドレスを書き換え、内に入る際は宛先IPアドレスを書き換えます。これはNAT（Network Address Translation）と呼ばれ、長年使われているネットワーキング技術です。私たちが発明したわけではありませんが、ここでそれを使用しています。
インターネットにトラフィックを送信すると、それは課金対象のトラフィックとなり、コストが発生します。AWSには、Availability Zone内、他のAvailability Zoneへ、そしてインターネットへと、様々な種類のトラフィックが存在します。私たちはこれを正確に把握し、お客様に請求する必要があります。経験を通じて、これを実現する最善の方法は、単純に事実を記録することだと分かりました。フリートで判断を下そうとするのではなく、ただ起きたことを記録するだけです。そこで私たちは、ネットワーク上を流れる全てのバイトの記録を保持しています。ここで、InstanceとWebサイト間のやり取りを見ることができます。
実は2つの記録があります。なぜなら、これらの記録は一方向性だからです。アウトバウンドトラフィックを記録し、戻りトラフィックを記録します。そして、例えば10.0.0.3 と10.0.0.4という2つのInstanceが通信を行った場合、それも記録します。単純に事実を記録するだけです。これらの記録は完全に内部用で、お客様には公開していませんが、ネットワーク上を流れる全てのバイト、全てのパケットを正確に記録しています。
セキュリティの分野で働いている方なら、これがFlow Logsにとても似ていると気づくでしょう。先ほど説明したネットワークメータリングの記録は、ほぼ完璧なものでした。 ここにポート番号とプロトコル番号を追加するだけで、非常に価値のある情報になります。 最初の接続がWebサーバーへのアウトバウンド通信であることが分かります。ポート443はHTTPSです。2番目の接続はほぼ間違いなくMySQLで、ポート33306です。お気づきかもしれませんが、最初の接続の数値が少し減少しています。実際にはそこに2つの接続があったのです。Flow Logsではソースポートを記録しているため、この2つを区別することができます。
従来のネットワーク機器では、Flow Logsは高度にサンプリングされる傾向がありますが、AWSのFlow Logsはバイトとパケットの両方で正確です - ネットワーク上を流れるものは全てFlow Logsに記録されます。フローのカーディナリティは、ネットワークメータリング記録のカーディナリティよりもはるかに高くなる可能性があります。テーブルスペースには制限があり、Instanceがそのスペースを超過する可能性もありますが、その場合、その時間枠のFlow Recordの記録を停止したことを示すフローレコードを出力します。
これはセキュリティの専門家にとって非常に価値のある情報です。また、これらの接続は逆方向にも発生します。インターネット上の、悪意を持っているに違いないホストが接続を試みた場合、私たちはそのパケットの配信を試みます。Network Address Translationを行い、パケットの配信を試みます。このパケットは配信されるべきでしょうか？お客様はこのパケットを望んでいるでしょうか？私たちにはSecurity Groupsと呼ばれる、基本的に分散型のネットワークファイアウォールがあります。これはVPCの概念ではありません - VPCより前からあるもので、EC2 Classicの時代から存在していました。
AWSの中だけで運用している場合は、「WebサーバーはポートXXXXXでデータベースサーバーにアクセスできる」というような指定の仕方ができます。しかしAWS以外では、ネットワークブロックやIPアドレスを列挙する必要があります。これは長年使われてきた仕組みです。トラフィックが流れると、Flow Logsが生成されます。トラフィックが流れない場合は、Security Groupがトラフィックを拒否したという事実がFlow Logsに記録されます。このように、Security Groupによる拒否をFlow Logsで確認することができます。
AWSインフラストラクチャの内部構造：VPCからBlackfootまで
これがVPCについての第一の視点です。 これはAmazonの仮想ネットワークをお客様がどのように体験するかということです。クラウドは存在せず、ただあなたのネットワーク、インスタンス、サブネットがそこにあるだけです。このネットワークでは、何が流れているか、何が流れるべきかについて完全な可視性があり、それをコントロールすることができます。しかし、クラウドに魔法はありません。 結局のところ、これらのリソースはすべてコンピューターであり、どこかの物理サーバー上で動作している必要があります。それは私たちの物理サーバーです。
すべてのインスタンスの下には物理ホストがあります - 私たちはこれをDropletと呼んでいます。クラウドの最小単位だからです。Dropletの目的は、お客様のインスタンスを実行することです。Security Groupを適用し、ネットワークの計測記録やFlow Logsを書き出します。一般的に、これらはマルチテナントです。もちろん、パケットの変換はどこかで行われる必要があります。パケットを受け取り、プロセッサーで処理し、書き換えて再注入する何かが必要です。そのため、ネットワークのエッジにもボックスが存在します。
しかし実際には、あなたのVPCはクラウドのごく一部です。他にもVPCがあり、これらのVPCの中にはより多くのElastic IPアドレスを持つものもあれば、まったく持たないものもあります。 インスタンスの数が多いものや少ないものもありますが、色で示される異なる顧客が所有する多くの異なるVPCが存在することになります。Dropletは非常にステートフルです - それはあなたのインスタンス、ワークロード、ロードされたすべてのメモリ、オペレーティングシステムを実行しているホストです。
アプリケーションはそのホスト上にあるため、そのホストはあなたのインスタンスにとって非常に重要ですが、ネットワーク変換はそうではありません。私たちのレベルでは、VPCは存在せず、物理ボックスだけが存在します。ネットワーク変換はステートレスなので、マッピングを持つパケットを受信したボックスであれば、どのボックスでも変換を行い、転送することができます。実際には、VPCごとのInternet Gatewayは存在しません。ネットワークのエッジには、リージョン内のすべてのElastic IPアドレスのすべての変換を処理する単一のボックスフリートがあります。
これらのIPアドレスには意味的な内容は含まれていません。2つのElastic IPアドレスが隣り合っていて、1つだけ異なる場合でも、それらが同じカスタマーに割り当てられているということを意味するわけではありません。それらは単にAmazonのブロックの中にあるIPアドレスにすぎません。これが2つ目の視点です - AWSがあなたのVPCや他のすべてのVPCをどのように見ているかということです。
ここには面白い話があります。ネットワークの端にあるこのボックスはBlackfootと呼ばれています。初期の頃、EC2は主に南アフリカのケープタウンで開発されていました。私がVPCの開発に携わっていた時、そこに行く機会がありました。私はお調子者のアメリカ人なので、空港でキリンが歩き回っているのを見たい、ターミナルで象を見たいと思って、飛行機の窓に顔をくっつけていました。もちろん、空港には珍しい動物はいませんでしたし、滞在先やオフィスまでの道のりでも珍しい動物は一匹も見ませんでした。その週末にケープポイントに行くまでは。アフリカで最初に見た珍しい動物はペンギンでした - これは予想外でした。これらはマゼランペンギンで、Tuxというペンギンはご存知の通りLinuxのマスコットです。そこで、EC2がLinuxベースのネットワークアプライアンスを構築する必要があった時、EC2がケープタウン発祥で、ケープタウンにはBlackfootペンギンがいることから、そのネットワークボックスの名前としてBlackfootを選んだのです。
実際、彼らは黒い足を持っています。
3つ目の視点は、外部から覗き込む人の視点です。インターネット上には悪意のある人々がいますが、彼らは外部にいます。彼らに見えるのは、そのエッジデバイス、つまりElastic IPアドレスとBlackfootだけです。どのVPCに関連付けられているかさえわかりません - 単にIPアドレスが見えるだけです。これは巨大な配列、膨大なIPブロックです。この部外者は、この巨大なIPアドレスの配列を見つめているだけで、それが得られる情報のすべてです。これがAWSに対する部外者の視点です。
機会主義的な攻撃への対策：MadPotとActive Defenseの実装
ここで、これから説明することについて注意点があります：私たちが取り組んでいるのは、機会主義的なスキャンや探索に対する保護です。もし、偵察を行い、ターゲットのネットワークインフラを詳細に把握している攻撃者がいる場合、これから説明することは当てはまりません。共有責任モデルを忘れないことが非常に重要です - お客様は依然として自身のデプロイメントのセキュリティに責任を持ち、AWSのセキュリティサービスや機能を活用する必要があります。
外部からの攻撃者が脆弱性を探そうとしているとき、彼らはスキャンを開始します。それは順番に行うかもしれませんし、ランダムに行うかもしれません。また、素早くスキャンするかもしれませんし、センサーを回避するためにゆっくりとスキャンするかもしれません。しかし、彼らが直接アクセスできるのはBlackfootだけで、それより先には進めません。 お客様がこのインバウンドパケットを受信する場合、私たちはそれを書き換えます。お客様がhttp://customer.comのようなインターネット向けのWebサーバーを運用している場合、インターネットからのトラフィックを受け入れたいはずですので、このパケットをインスタンスに配信します。インスタンスはそれをWebサーバーに届けます。
このトラフィックは望ましいものでしょうか？それが良いものか悪いものかをどうやって判断できるでしょうか？1つの接続だけを見ても、それが正当な接続なのか不正な接続なのかを判断するのは困難です。これは、ビジネスを支える重要な購入をしようとしているお客様かもしれませんし、インターネット上の悪意のある人物かもしれません。多数のIPアドレスがあったとしても、お客様にとってシグナルとノイズを区別することは非常に困難です。
しかし、私たちにはこれらのElastic IPがどのお客様に関連付けられているかがわかります。スキャンが続くにつれて、より多くの異なるお客様に接続しようとするのが見えてきます。これらのIPアドレスの一部がまだ白く、マッピングされていないのは、お客様がインスタンスを起動してElastic IPアドレスをリクエストする際に、フリープールを用意しておく必要があるからです。これらのスキャナーは私たちのフリープールにヒットしており、それらのIPアドレスがマッピングされていないことを私たちは把握しています。一部のアドレスはマッピングされていてドロップレットに流れますが、 Security GroupやNetwork ACL、あるいはVPCの他のメカニズムによってトラフィックがドロップされます。私たちはこれを知っていますが、外部の攻撃者にはわかりません。
私たちのクラウドでは、魔法の杖を振るだけで仮想マシンが出現し、そこにIPアドレスをマッピングすることができます。不要になったら、もう一度杖を振れば全てが消えてしまいます。この機能を使って、MadPotというサービスを構築しました。MadPotは、Elastic IPアドレスがマッピングされたEC2インスタンスの集まりに過ぎません。 MadPot上では、高度なインタラクションが可能なHoneypotが動作しており、様々なサービスを公開し、それらの脆弱性のあるバージョンを装っています。私たちは、単にポートが開いているかどうかをチェックするだけでなく、サービスのバナーを調べ、ペイロードをテストする攻撃者を誘い込もうとしています。これらのインタラクションを常に深化させ、新しいインタラクションを追加することで、インターネット上の人々からより多くのペイロードを収集しています。
MadPotにヒットしてそれを攻撃しようとすれば、その人がインターネット上の悪意のある人物であることが確実にわかります。また、もしMadPotセンサーを見つけたり、あるIPアドレスがMadPotセンサーだと何らかの方法で特定したとしても、数分後にはそれは消えています。私たちは単にElastic IPを解放し、別の場所でMadPotセンサーを起動します。常時、私たちのグローバルネットワークでは数万個のセンサーが稼働しており、IPスペース全体を移動し続けることで、これらのIPアドレスを発見することができます。
この方法を使うことで、これらのIPアドレスを特定することができます。これは単にAmazonの多くのIPアドレスにアクセスしている送信元IPアドレスというわけではありません。 これはAmazonの多くの異なる顧客にアクセスを試みている送信元IPアドレスであり、そのトラフィックが通過するかどうかを把握できます。 正当な顧客は、リッスンしているサービスやマッピングされているIPアドレスにアクセスする傾向があります。一方、スキャナーはより高い割合で接続を拒否されることになります。 そして、MadPotによって、誰が何を悪用しようとしているのかを正確に把握することができます。
ネットワークのエッジにはBlackfootを配置しています。 プライベートIPアドレスとパブリックIPアドレスの間で変換を行うためには、設定テーブルが必要で、そのテーブルには緑色で示されているマッピングが含まれています。 パケットが入ってくると、インバウンドなので、外部IPアドレス、つまり宛先IPアドレスを書き換える必要があります。テーブルでそれを検索し、見つかったら内部IPアドレスを参照してパケットを書き換え、配信します。これは全てのVPCの全てのトラフィックに対して、毎日24時間行われています。これがネットワークの仕組みです。
これはマルチテナントのエッジデバイスなので、全てのVPCのマッピングがここに含まれています。私たちが行ったことは、高いレベルで見ると非常にシンプルです - これらのデバイスにもう1つの設定テーブルを追加し、顧客との通信を望まない全てのIPアドレスをリストアップしただけです。パケットが入ってきたとき、宛先IPアドレスを書き換えるための検索を行う前に、まず送信元IPアドレスを検索し、それがドロップテーブルにあることを確認して、そのトラフィックを単にドロップします。このように説明すると、顧客との通信を望まないIPアドレスを見つけて、それらからの通信を遮断するというのは、とても単純なことのように聞こえます。
これは一見明らかな発想から、大規模な分散システムの課題へと変わりますが、大規模なビッグデータセキュリティの問題こそが、私たちのやりがいなのです。これこそが私がAmazonで働き続ける理由です。BGPテーブルを確認すれば分かりますが、私たちは6,600万のパブリックIPアドレスを持っています。Blackfootは毎時125,000億のフローを24時間365日変換しています。MadPotセンサーは毎日25億のIPアドレスからの接続を検知しています。これは事実上、ルーティング可能なIPv4アドレス空間全体に相当します。
Amazon Active Defenseの導入を発表できることを大変嬉しく思います。 私たちはこれを3年間実施してきました。これは無料で、 インターネットに接続された全てのリージョンで利用可能です。これが経営陣からの課題に対する私たちの回答です。これはアクティブな防御ですが、ハックバックではありません。私たちは望むトラフィックだけが顧客に届くようにしているのです。インターネット上の誰かに対して攻撃的なハックバックを行っているわけではありません。私たちはここで、自社のネットワークを守り、サービスを守り、そして特に顧客を守るために働いているのです。
Active Defenseの科学的アプローチと多層防御戦略
これが私たちの成果です。MadPotセンサーを2つ稼働させています - 1つはActive Defenseの背後に、もう1つは生のインターネット上に設置し、それらの間で何が起きているかを比較しています。インバウンドのプローブの約83%を阻止していますが、すべてのインバウンドプローブが悪意のある攻撃につながるわけではありません。Active Defenseによって、悪意のある攻撃の89%が防止されています。99.998%という数字は、この3年間で不適切にミティゲーションされたIPアドレスに関するカスタマーサポートケースがわずか12件だったことを示しています。チームは安全性を非常に重視しており、正当な顧客トラフィックが確実に流れ続けるようにしています。
このスライドには載っていない事実をひとつ：私たちは3分ごとにミティゲーションされているIPアドレスのリストを測定していますが、各3分間の間隔で平均23%のIPアドレスが入れ替わっています。脅威インテリジェンスの有効期間は信じられないほど短いので、リアルタイムのフィードがない場合 - つまり日次や時間単位のフィードしかない場合 - 同じネットワーク上のセンサーからのリアルタイムフィードがない限り、はるかに効果が低くなってしまいます。
ここで、この仕組みについて詳しく説明してもらうために、Steveにバトンを渡したいと思います。ありがとう、Eric。私はAmazonのSenior Managerを務めるSteve Goodmanです。Ericと一緒に働いており、この正確な検知と保護の実装方法について、より詳しい内容をご説明できることを嬉しく思います。
まず第一に、これらの成果を出すための鍵となるのは、強力な実験的アプローチです。 この写真が大好きなんです。科学が素晴らしいのは、重要なものを測定し、変化を監視し、制御を適用するのに役立つからです。ちなみに、私がずっと憧れていたこの写真について、たった1週間前に知ったことがあります。この巨大なアークが数メガワットの電力で発生している実験の際、Teslaは実際にその場所にいなかったんです。安全ではないと判断し、装置をオフにした状態で別の写真を撮り、当時の技術でそれらを合成したものなんです。これは、私たちがActive Defenseで採用しているアプローチを見事に表現していると思います。
では、私たちの日々の科学的オペレーションは実際どのようなものでしょうか？測定に立ち返ると、非常に迅速な実験、低コスト、数分以内に仮説を検証できることが重要です。 私たちは階層化された検知を使用しており、これについて詳しく説明していきますが、セキュリティのスイスチーズモデルのように考えています。つまり、各セキュリティ層の強みが、他の層のギャップを補完し合うようにしているのです。 そして安全性です。Ericが話したように、私たちは毎分インターネットの膨大な部分と通信しているので、取る行動のすべてが顧客にとって安全である必要があります。IPルーティングを扱っているので、顧客とインターネット全体の両方にとって安全でなければなりません。
インターネットと言えば、ご存知かもしれませんが、急速に成長を続けており、皆さんもその成長の一部かもしれません。脆弱性の研究もそれに追随しており、これがその様子です。脆弱性の公開件数は10年間で年21%増加しています。今年だけでも35,000件以上のCVEが報告されており、これは数週間前の数字です。Active Defenseでは、これらの脆弱性を悪用する脅威アクターを上回るペースで対応することを目指しています。
このような脅威アクターを上回るために、地域全体のインフラストラクチャにわたって、私たちの防御がどのように機能しているかを迅速に把握する必要があります。Active Defenseの核心は、トラフィックの分類を継続的に改善することです。この接続を許可すべきか否か。そして、AWSの観点から見ると、顧客のワークロードが非常に多様な中で、どのように判断すればよいのでしょうか。その答えがMadPotです。MadPotでは、複数のフリートを持ち、それらを比較テスト用にグループ化することで、非常に細かい粒度の迅速な判断が可能になります。
実験グループはActive Defenseによって保護され、対照グループは保護されていない状態でインターネット上のIPスペースに公開されています。脅威アクターは、保護されたホストと保護されていないホストのどちらと通信しているのかを知らず、通常はMadPotと通信しているかどうかさえ分かりません。これらのフリートは同じ脅威活動にさらされることになります。非常に近い比較グループとなっているのです。MadPotの内部の実際の様子を簡単に見てみましょう。そこでは、受信した通信のIPアドレス、ポート、プロトコル、そしてその特定のリクエストに含まれるBase64エンコードされたペイロードを取得します。MadPotは、様々な分類技術を使用して過去の通信と比較し、リクエストの特徴に基づいて類似の通信をグループ化することで分類を行います。それは探索行為かもしれませんし、エクスプロイトかもしれませんし、ボットネットのコマンドかもしれません。この例では、探索行為であることが分かります。
MadPotは、その通信にラベルを付けます。MadPotには1日に7億5000万件以上のリクエストが届いています。非常に魅力的なハニーポットですね。個々の通信をそのレベルの粒度で見ることはできません。そこで、異なるタイプのエクスプロイトに関する傾向を見ていきます。各色の線は、異なる種類のエクスプロイト通信ファミリー、つまり先ほどのクラスターを表しています。注目すべき点として、ここで見ているのはエクスプロイトの悪意のあるものだけです。探索行為や中立的なもの、分類できなかったものは含まれていません。
右側では、保護されていないMadPotフリートに対する多くのエクスプロイト通信が見られます。これはプレゼンテーション用に抽出した1週間の期間のものです。左側では、保護されたMadPotフリートに対するエクスプロイト通信がほとんど見られません。異なる線は、異なる種類のシークレットソースを表しています。後ほど、層状の保護について説明します。右側では11月7日の特定の時間に大きなスパイクが発生しており、保護されたグループの同じ時間帯を見ると、11月7日にわずかな上昇が見られます。これらのエクスプロイトリクエストのごくわずかしか、保護されたMadPotフリートには到達していません。
このような比較フレームワークを使用することで、保護された環境と保護されていない環境の間で、文字通り数分で異なる保護手法をテストできます。これにより、攻撃の試みを阻止する効果について、迅速かつ統計的に厳密なフィードバックを得ることができます。私たちは、この迅速な実験のための環境を手に入れました。 これにより、素早く進めることができます。では、悪意のある攻撃者をインフラストラクチャから排除するための検知システムをどのように構築するのか、詳しく見ていきましょう。
脅威検知の精度向上：クラスタリングと多次元分析の活用
先ほど、MadPotのクラスタリングの例を見ました。クラスタリングについて概要を説明しましょう。この画像を見て、貝殻だと思うかもしれませんが、よく見ると、放射状のものもあれば、螺旋状のものもあり、さらによく見ると、実は螺旋状の化石が入った岩もあります。このように、私たちはこれらを適切にクラスタリングすることができます。 下の方に紫色のちょっと厄介なものがありますが、放射状に見えて実は螺旋状なんです。
このようなクラスタリングをAWSでのインタラクションに適用する場合、正常なものと悪意のあるものを区別するのは難しい場合があります。しかし、脅威は定義上、通常のユーザーとは異なる何かを行っています。Ericが話していたBlackfootの技術に戻りましょう。 Blackfootでの実際のフローを見てみましょう。リモートIPアドレス、サービスポート、EC2インスタンスの接続バイト数などの特徴を選択します。 そして、そのデータをプロットしてみましょう。X軸とY軸にフローの受信バイト数と送信バイト数を取ります。左下の、受信も送信も少ない領域を見ると、そこに多くの接続試行が集中していることがわかります。
興味深い領域にズームインしてみましょう。 すべてのワークロードについて、Blackfootのフローを見てみると、特に目立つものはなく、少し退屈な感じです。しかし、MadPotとのインタラクションだけでクラスタリングを実行すると、 3つの非常にタイトなビヘイビアクラスタが現れます。これは素晴らしい発見です。なぜなら、これはMadPotで見つかったものであり、通常のユーザーの行動ではないからです。これらのフローが発生する正当な理由はありません。これらのクラスタを実際のBlackfoot フロー、つまり通常のAWSワークロードに適用すると、そのクラス分類器を使って、実際のAWSサービスと相互作用しているMadPotのような接続を特定できます。これらの接続はすべて、Active Defenseの有力な候補となります。では、それを証明しましょう。 この機能をBlackfootの保護機能に実装し、比較テストグループを使用します。
これは、先ほどのスライドと同様に、右側が保護されていないグループ、左側が保護されたグループです。この特定の検知について、保護されていないグループでは大量のアクティビティが発生していますが、保護されたグループではほとんど何も起きていません。 この捕捉で特に興味深いのは、保護されていないグループの右側で、リクエスト試行の頻度が傾斜を描いて減少していることです。これを見ると、攻撃者が何も見つけられずに攻撃インフラをシャットダウンし、別の場所に移動していることがわかります。 これは素晴らしいことです。脅威アクティビティがAWSから離れ、成功することなく立ち去っていく様子を見ると、それは勝利です。これこそがActive Defenseの本質なのです。
私たちがここでこれほど詳細な情報を共有することについて、脅威アクターがこれらの対策を回避しようとするのではないかと考える方もいるでしょう。しかし、これこそが私たちの多層的な検知戦略が真価を発揮するところなのです。脅威アクターは時として（必ずしもいつもではありませんが）検知を回避しようとします。例えば、脅威アクターが後でYouTubeでこの講演を見て、私たちのClusteringの特徴について学んだとしましょう。おそらく彼らは、その特定の検知を避けるためにバイト数を増減させたり、リクエストレートを遅くしたり、あるいは私たちが想像もしていないような何かを試みるかもしれません。そうなると彼らは余計な作業が必要になるわけで、私としては仕事を果たせたと感じています。このような追加の負荷があることで、脅威アクターはより多くの労力を強いられ、その事実だけでも機会主義的な脅威の大部分を防ぐことができます。
脅威アクターは、私たちが持っているような防御的な視点を持っていません。彼らが持っている情報だけでは、実際に何が起きているのかを把握するのは簡単ではありません。私個人としては、マルウェア開発者たちがフォーラムに「誰か同じような現象に遭遇していませんか？自分のExploitが動かなくなったんですが」といった投稿をしている様子を想像するのが好きです。実際にそのようなチャットを見ることができます - 2022年に流出した興味深いマルウェアグループの開発者チャットがGoogleで検索できます。しかし、一部の脅威アクターは適応して革新的な方法を見つけ出すでしょう。そこで、回避の試みを積極的に探し、それを検知できるように層を設計していきましょう。
先ほどの例で使用したBlackfootのテレメトリーに戻りましょう。ここで示しているのは、非常にシンプルな行動チェックです。数学的手法を使って回避行動を記述することで、より適切なしきい値を特定することができます。この回避範囲関数について詳しく見ていきましょう。私たちは特定の防御層として、カーネル密度推定と呼ばれる統計関数を使用しています。これは自動化された脅威がAWSと相互作用する確率を実際に計算します。BlackfootとMadPotの両方で観察される悪意のあるスキャンの持続時間と再発を見て、継続的に再計算を行っています。左側の時間T1と右側の時間T2を見ると、プロットが微妙に次元を変えていることがわかります。脅威アクターがClusteringや以前の層を回避するために行動を変更すると、それに応じて他の層が彼らの行動に対してより敏感になるように調整されます。この関数から得られる確率行列に適合する接続は、アクティブな対応の候補となります。
回避と対応について見てみましょう。これらは実際の運用ダッシュボードです。左側では、新しいIPアドレスからの悪意のあるリクエストが大幅に増加しているのが分かります。これは9月の例で、あるBotnetがマルウェア感染の試みを広めるためにProxyネットワークを通じて活動を分散させたものです。脅威アクターはこれを、更新頻度の低いブロックリストを回避するために行います。私たちの回避検知層は自動的に変化を察知しました。面白いのは、これがネットワークレベル - つまりFlow Logsだけで行われているということです。これはWAFではなく、個々のリクエストを検査するのではなく、ネットワークの行動に焦点を当てています。
オレンジ色と緑色の線が交差するこのチャートでは、悪意のあるリクエストの全体的な量は一定のままであることがわかります。特に興味深いのは、これらの新しく攻撃してくるIPが実際のBotnetノードの一部ではなく、単なるProxyであることを示していることで、これは貴重な脅威インテリジェンスを提供します。攻撃の拡散における大きなスパイクが著しく減少しているのが観察できます。彼らは1日の攻撃が失敗に終わり、このProxyネットワークへの支払いを止めることにしたのです。AWSのオペレーターとして、私たちは今や、どこかで侵害されたワークロードを実行している可能性が高い何千もの追加のIPについて知ることができ、その情報を層化された検知にフィードバックしてモデルを改善しています。
カスタマーのワークロードへの接続は非常に多様であるため、通常とは異なる正常なトラフィックへの対応を考える際には、この点を考慮する必要があります。極端な外れ値であっても、1日に何百万回も発生する可能性があります。私たちは1時間あたり約12兆のイベントを処理していますが、1時間に100万回というのは比較的少ないように見えるかもしれません。しかし、判断を誤ると影響を受けるカスタマーにとっては重大な問題となります。そのため、低確率のイベントを正しく分類するために、これらの特徴を組み合わせ続ける必要があります。私たちはこれをCompoundingと呼んでいます。Blackfoot、MadPot、そしてClusteringやKDE Novelty Churnなどの派生分析を追加すればするほど、分類の精度は向上します。
私たちは、複数のデータソースと分析を組み合わせたHTTPリクエストの64次元のEmbeddingを使用しています。25万件のランダムにサンプリングされたリクエストに対してUAデータの削減を実行します。一見すると、いくつかの明確なクラスターが見えます。 MadPotのインタラクションラベルを適用すると、青色が正常なリクエストを表し、他の色はCVEやアプリケーション攻撃を示しており、悪意のあるリクエストの明確なクラスターが見えます。単一のインスタンスを調べると、それがBashコマンドインジェクション攻撃であることが明確に分かります。 より密度の高いエリアにズームインすると、検知レイヤーは明確なクラスター境界がない場合でも、非常に似通った正常なリクエストから悪意のあるリクエストを区別することができます。
これらのサンプリングされたリクエストの実際の詳細を調べると、人間のアナリストが何かが悪意のあるものか正常なものかを正確に判断するには、複数の要因と追加データを分析する時間が必要であることが分かります。しかし、私たちは多次元レイヤーを通じてこのデータを組み合わせる多くの方法にアクセスできるため、静的な正規表現や静的なIPブロックリストのような脆弱な手法を避けながら、1時間あたり数億の悪意のあるリクエストを処理することができます。より多くのコンピューティングリソースを活用することで、True Positive Rate、False Positive Rate、False Negative Rateを改善することができます。
カスタマーを保護する上で、安全性は最も重要です。誰もが信頼性を期待しており、私たちはその期待に応えています。インターネットのエンドポイントをブロックする際には、インターネット上に存在する住宅ネットワーク、モバイルホットスポット、大学、DNSルートサーバー、企業のVPNなどを考慮して、慎重にリスクを判断する必要があります。 私たちは分類の精度に徹底的にこだわり、False Positiveよりもむしろ、False Negativeを選択する方針を取っています。これを実現するために、アクションを取ることが安全かどうかを判断することに特化した、完全に独立した一連の階層型分類器を構築・運用しています。先ほど説明した脅威検知スタックと同じように頻繁に、Safety Stackの調整と適応を行っています。 実験、検知、レイヤー、ガードレールなど、これらすべてがどのように組み合わさっているのでしょうか？
非常にうまく機能しています。Ericが言及したように、MadPotでの攻撃の80%以上がEC2インスタンスに到達することはありません。これらのワークロードは私たちのカスタマーベース全体で非常に多様であるため、このアクティブディフェンスによる保護が、お客様独自のセキュリティコントロールを補完するものとなるよう、私たちは懸命に取り組んでいます。非標的型の脅威を排除し、すべてのカスタマーとそのセキュリティチームが、自社固有のセキュリティポスチャーとペリメータに集中できるよう、常に実験と改善を重ねています。
Active Defenseの応用：N-tuple BlockingからS3保護まで
まだ終わっていません。このプレゼンテーションもまだ終わっていません。結局のところ、まだDay Oneなのですから。ここでEricに戻して、さらなるActive Defenseについて説明してもらいましょう。こんにちは。私たちには素晴らしいフィードバックループがあります。ネットワークを計測し、MadPotを構築し、正当なトラフィックから悪意のあるトラフィックを選別できます。1時間に数兆のフローを処理し、1時間に数千のコントロールプレーン更新を行い、それがグローバルに展開されているコントロールプレーンを持っています。これらすべてのツールを手に入れた今、他に何ができるでしょうか？
Steveが言及したように、インターネット上には複数の用途で使用されるIPアドレスが存在します。典型的な例として、大学の出口エンドポイントがあります。そこには重要な研究を行っている研究室があり、もし中断してしまうと大変不機嫌になるでしょう。しかし同時に、完全に乗っ取られてインターネット上で悪質な行為を行っている寮のラップトップもあるかもしれません。私たちは悪意のあるトラフィックをブロックしたいのですが、すべてが1つのIPアドレスから出てきています。チームはN-tuple Blockingと呼ばれるものを構築し、パケットのヘッダーをさらに活用してブロックできるようにしました。このIPアドレスはポート443でAWSと通信できるが、ポート3306では通信できないというように、トラフィックのより多くの要素や特徴をブロックに適用し、安全性を維持しながらブロック率を向上させることができます。
もう1つ私たちが行っているのは、単純にマシンを反対方向に向けることです。AWSリソースにアクセスできる人々が全て善意の人々とは限りません。時には悪意のある人々がAWSリソースにアクセスを得ることがあり、私たちは自社のネットワークを保護し、インターネット上での評判を維持し、お客様を保護する必要があります。私たちは全く同じ手法を使用しますが、アウトバウンドトラフィックに対して適用します。Command & Controlサーバーとの通信を検知し、インスタンスがそのIPアドレスと通信を続けることを禁止できます。なぜなら、通信を続けると命令を受けて他者への攻撃を開始する可能性があるからです。私たちはそれを止めることができ、万が一攻撃が開始された場合でも、発生源でスロットリングを行い、インターネット上の他者に影響が及ばないようにできます。
最後にもう1つのユースケースとして、Amazon S3についてお話しします。S3は私たちのオブジェクトストアで、オブジェクトのPutとGetを行うバケットがあり、すべてがAPI駆動です。VPC、Blackfoot、Elastic IPアドレスといった概念はありません。S3を見てみましょう。バケットを作成して名前を付けますが、S3の仕組みでは、これらのバケット名はDNSに反映されます。グローバルで単一のバケット名前空間があるため、私のバケットとあなたのバケットは同じ名前を持つことができません。同じ名前のバケットが1つしか存在しないようにする必要があります。
もちろん、これはAWSですから、たくさんのバケットとたくさんのお客様がいて、それぞれにバケット名があります。これらの名前はお客様が選択するものですが、参考までに、このプレゼンテーションで示したバケット名は全て悪い例です - これらのバケット名は使用しないでください。これは4つのバケットをはるかに超える巨大なシステムです。長年、1アカウントあたり100バケットという制限がありましたが、多くのお客様がその制限に達していました。私たちはその制限を撤廃し、現在では100を大きく超えるバケットを持つ個別アカウントも存在します。膨大な数のバケットが膨大な数の異なるお客様によって所有されていますが、外部からはそれらのバケットの所有者を知ることはできません。完全なマッピングを持っているのは私たちだけです。
有効な顧客がいて、その顧客がバケットにアクセスしようとしています。そのバケットは存在することがわかっているのですが、実際には存在しません - 名前を間違えてしまったのです。そこで別のバケットにアクセスしようとします。このバケットは存在するかもしれませんし、存在しないかもしれません。最終的に、バケット名を修正して、source-codeというバケットは存在するのですが、source codeというバケットは存在しません。
存在しないバケットに何度もアクセスを試みていますが、アクセスしようとしているバケットの数は少数です。タイプミスをしたり、スクリプトに問題があったりするのです。多数の異なる存在しないバケットにアクセスしているわけではありません。一般的な顧客は、自分のアカウントにあるバケットや、パートナーなど他者から教えられたバケットしか知りません。これは日常的によく見られる、正当な行動パターンです。
外部からの攻撃者は、バケットのリストを知りません。バケットの名前空間を持っていないため、通常は辞書攻撃を使ってバケット名を推測しようとします。この時点で有効なバケットにアクセスする可能性もあります。これが正当なトラフィックなのか悪意のあるトラフィックなのかはわかりませんが、ここで存在しないバケットを探し始めます。これは異常な動作です。有効な顧客と同じ数のAPIコールかもしれませんが、多数のユニークな顧客にアクセスを試み、存在しないバケットに高い頻度でアクセスしていることがわかります。このようなトラフィックを特定できれば、それに対して任意の対策を取ることができます。このトラフィックを顧客のバケットに到達させる必要はありません。
私が説明したこれら3つのユースケース - N-tuple blocking、アウトバウンドブロッキング、S3ブロッキング - はすべて本番環境で稼働しています。S3のユースケースは、Active Defenseで最初に実装したものです。ネットワーク関連の機能は後から追加されました。これは何年も前から私たちのネットワーク全体で広く実施されており、顧客にとって有益なものとなっています。
AWSのセキュリティ哲学：規模がもたらす機会と課題
以前、私はいくつかのデータセンターを所有していました。規模は限られていて、すべてのシステムを把握していました。ファイアウォールを自分で選び、その設定を確認することができました。今は、AWSを保護し、AWSによるAWSの利用も含めて、すべてのAWSの利用を保護しています。これは、以前所有していた数個のデータセンターを保護するよりもはるかに難しい仕事です。規模が大きくなれば仕事は難しくなり、それは避けられません。
以前、私がデータセンターを数か所所有していた頃は、市販のFirewallやRouterを購入していました。当時は、AWSのような規模がなく、独自のネットワークデバイスを構築し、完全に所有するためのリソースもありませんでした。しかし、現在のような規模があり、多額の投資が可能になったことで、より多くの選択肢が生まれました。規模が大きくなれば、それだけチャンスも広がります。実際、機会の曲線は課題の曲線よりも急勾配なのです。規模が大きくなり、投資できる金額が増えると、機会に注意を払い探求していれば、決してゼロサムゲームではありません。より多くのことを実現し、小規模で運営していた時よりもはるかに多くのことができるようになるのです。
私が以前データセンターを所有していた時には、Active Defenseのようなものを構築することは到底できませんでした。Active Defenseを構築できたのは、すでに存在していた基盤があったからこそです。EC2があり、VPCがあり、Blackfootがありました。ある日突然思いついたわけではありません。長年にわたる深い技術投資と、その技術に対する深い所有権があったからこそです。私たちはBlackfootチームに「こんなクレイジーなアイデアがある」と持ちかけることができました。確かに彼らもクレイジーだと思ったようですが、それは刺激的なアイデアで、最終的に実現方法を見出し、成功させることができました。
これが可能だったのは、ソースコードとエンジニアが社内にいたからです。素早く改善できるクローズドループがあったのです。この深い所有権が、さらなる深い所有権を可能にし、その基盤の上に革新的なことを実現することができます。Stephenが言ったように、セキュリティの問題は根本的にすべて人の問題です。パケットロスやクラッシュなどはランダムな出来事ですが、それらはセキュリティイベントではありません。すべてのセキュリティイベントの向こう側には、動機を持った人間がいるのです。それは何層も離れているかもしれません。
セキュリティエンジニアとして、私たちはパケットやコアダンプなどに執着しがちです。しかし実際には、向こう側には人間がいて、私たちのテレメトリーでは、アクターグループがAWSに対して何かを仕掛け、ある程度の成功を収め、それが封じ込められ、そして彼らが去っていくのを見ることができます。彼らは立ち去り、インフラを停止します。私たちは決してこれをやめることはできません。なぜなら、彼らが戻ってきて、まだそこにいるか、これが機能するか、あれが機能するかをチェックするのを見るからです。これは永遠の仕事です。Active Defenseは常に必要ですが、これらのアクターがAWSを諦めて他へ移っていくのを見るのは非常に満足感があります。Andyが常々言っているように、クラウドプロバイダーを選ぶとき、インフラストラクチャーサービスプロバイダーを選ぶときは、大きな決断です。長期的な関係にコミットすることになります。私たちは、この深い所有権があったからこそ実現できたことを非常に誇りに思っています。re:Inventにご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion