re:Invent 2024: AWSがDNS FirewallとNetwork Firewallで実現するEgress制御
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Reduce your risk exposure with least privilege egress controls (SEC322)
この動画では、AWS Security GTM SpecialistのSofia AlumaとSenior Security Specialist SAのMichael Leightyが、Zero TrustとLeast Privilegeの観点からEgressコントロールのベストプラクティスを解説しています。DNSを悪用するマルウェアが80-85%に上るというPalo Altoの研究データや、Log4j脆弱性の事例を交えながら、DNS FirewallとNetwork Firewallを組み合わせたEgress制御の重要性を説明しています。特に、DNS Firewall AdvancedによるDNSトンネリングのブロックや、Network FirewallのGeographic IP Filtering機能など、最新の対策手法にも触れながら、信頼できるドメインのみにEgressを許可する具体的なアプローチ方法を紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Inventセッションの概要と本日のテーマ
re:Inventの一日が始まりました。ついに来ましたね。皆様には一週間お付き合いいただき、本当にありがとうございます。楽しんでいただけていることを願っています。会場にいらっしゃる方も、オンラインでご視聴の方も、セキュリティサービスやネットワークセキュリティの原則についてある程度ご理解があることを前提にお話を進めさせていただきます。本日は、Zero TrustとLeast Privilegeの観点から、Egressコントロールに関するベストプラクティスと重要なポイントをご紹介させていただきます。私はAWSのSecurity GTM Specialistを務めているSofia Alumaです。本日は同僚のMichael Leightyと一緒に登壇させていただきます。彼はSenior Security Specialist SAとして活躍しており、後半の担当パートで詳しく自己紹介させていただきます。
本日は盛りだくさんの内容をご用意しています。まず、業界から寄せられている声や課題、私たちの観察などについて、お客様の実際の経験をもとにお話しします。これは300レベルのセッションですが、用語の定義から始めて、全員が同じ理解で進められるようにしたいと思います。また、Egressコントロールとネットワークセキュリティに関連するAWSのセキュリティサービスについても触れていきます。その後、Michaelに引き継ぎ、今回の本題に入ります。彼がEgressの観点からランサムウェアのパターンを詳しく解説し、これらのサービスがどのように連携して包括的なEgressコントロール戦略を実現するのかをご説明します。さらに、ベストプラクティスや重要なポイント、新機能についてもご紹介し、最後にまとめで締めくくります。
ネットワークセキュリティの課題とAWSのソリューション
お客様からどのような声が寄せられているのでしょうか？ネットワークセキュリティとクラウドセキュリティのチームは、ネットワークセキュリティ戦略を立てる際に、様々な優先事項のバランスを取る必要があります。特にネットワークセキュリティの観点から、常に進化する脅威の状況に対応し、データ流出のリスクを防ぐためのEgressコントロールの管理が求められています。コンプライアンスも重要な要素です。顧客データやIP関連データなどの機密データを扱う場合、最新のフレームワーク、規制、Data Sovereignty、Geofencingなどに常に対応する必要があります。コンプライアンスを維持するだけでなく、定期的にそれを報告し証明することも求められます。
また、チームは様々な複雑さを持つ環境を管理する必要があります。企業の合併買収、子会社、フランチャイズ、社内ソリューションの維持、サードパーティアプリケーション、マルチハイブリッドクラウド環境など、多岐にわたります。そのため、高いスケーラビリティと信頼性を備え、使いやすいソリューションへの依存度と必要性が非常に高まっています。
基本的な用語の確認として、もしEgressという言葉に馴染みがない場合は、VPCレベルでネットワーク内部から開始され、ネットワークの外部に向かって出ていくトラフィックだと考えてください。これについては後ほど詳しく説明します。また、インターネットへの経路には2つあることを覚えておくことが重要です。従来のネットワークIPパスと、DNSパスです。調査によると、DNSは実は非常に見落とされがちな攻撃対象領域となっています。
Palo Altoの研究によると、マルウェアの80-85%がその悪意のある活動においてDNSを悪用していることが分かっています。また、IDCの調査では、調査対象となった組織の88%が過去1年間にDNS攻撃を経験したと報告しています。これらの脆弱性とリスクに関して、DNS視点からAmazon Route 53 Resolver DNS Firewallについて見ていきましょう。基本的には、DNSトラフィックのためのファイアウォールとして考えてください。これは、非常に堅牢で導入が容易なマネージドサービスで、いくつかの新機能も備えています。
新機能には、プロファイルの一元設定とドメインリダイレクションのためのRoute 53プロファイルのサポートが含まれています。数週間前にリリースしたばかりの機能では、DNSトンネリングなどの高度なDNSの脅威に対するブロックとモニタリングが可能になりました。また、本日の範囲にはAWS Network Firewallも含まれています。これにより、VPCに不可欠なネットワーク保護を展開できます。非常に堅牢で、高度な設定やカスタマイズが可能で、ディープパケットインスペクションやTLSインスペクションなどの高度な検査機能をサポートしています。DNS Firewallと組み合わせることで、エグレスの脆弱性に対する非常に強力な戦略を提供します。
なぜエグレスが重要なのか、と疑問に思われるかもしれません。セキュリティ分野やセキュリティ関連の仕事に携わっている方なら、このワードを耳にしたことがあるでしょう。しかし、2021年12月に遡って、これがまだ未知のゼロデイ脆弱性だった時のことを考えてみましょう。クラウドセキュリティチームの立場で考えてみましょう。インバウンドパスでのNode Webアプリケーションの脆弱性対策を無事に完了し、素晴らしい1年を締めくくったところです。気分は最高です。インターネットへのアウトバウンド通信もそれほど多くないので、エグレス対策の優先順位はまだ低いままでした。そんな中、突然スマートフォンの通知が鳴り始めます。世界が大変なことになりそうです。ApacheのオープンソースロギングフレームワークであるLog4jを利用した脆弱性が発見されたというニュースが入ってきました。
この脆弱性が自分たちに関係があるのか、影響があるのかを確認しなければなりません。Log4j脆弱性の重要なポイントは、悪意のある攻撃コードをダウンロードするために別のサーバーに接続する必要があったということです。これがエグレス制御が重要となるところです。エグレス制御が適切に設定されていれば、この段階で保護されていたはずです。「それは分かりますが、もう何年も前にパッチが当てられたじゃないですか」と言われるかもしれません。しかし、なぜまだ関連性があるのでしょうか？パッチが適用されていない古いバージョンのLog4jの日次ダウンロード数が、今でも30%にも達することがあるのです。
そして、これはLog4jだけの問題ではありません。これはソフトウェアサプライチェーンセキュリティリスクとして知られる概念で、アプリケーション開発の観点から見ると、私たちはオープンソースツールを基盤として使用し、XZ Utilsのバックドアのように、知らない、あるいは管理できないメンテナーチームに依存しているのです。これは、メンテナーがチームの信頼を獲得し、その後悪意のあるコードを挿入するという、非常に巧妙な社会工学的手法でした。クラウドセキュリティチームとして、私たちはこれらすべての脅威や脆弱性に常に注意を払っていく必要があります。
Egressコントロールの重要性とマルウェアの脅威
でも、リスクを軽減するための戦略を立てるもっと簡単な方法があったらどうでしょう？ 今日は特にこの点に焦点を当てて、より Zero Trust で Least Privilege な戦略、つまり明示的な許可と暗黙的な拒否の戦略を構築する方法についてお話ししたいと思います。それでは、同僚の Michael に引き継ぎたいと思います。ありがとうございます。Sophia が申し上げた通り、私は AWS の Senior Security SA として3年以上勤務しています。私はネットワークセキュリティの分野で10年以上の経験があり、InfoBlocks や Palo Alto Networks といったセキュリティ企業で働いてきました。AWS では、今日お話しするサービスの導入を大手のお客様にサポートすることに注力しており、そこで得た知見をサービスチームにフィードバックして、サービスの改善に活かすよう心がけています。
本題に入る前に、ネットワークセキュリティに関する考え方のモデルについてお話ししたいと思います。日々のセキュリティ業務ではあまり触れることのないトピックですが、このようなイベントは、脅威を認識し対応するために使用しているメタファーについて立ち止まって考える絶好の機会です。
ここで、このお城があなたのクラウド環境だと想像してみてください。堅固な要塞で、警備が厳重で、多層的な防御システムを備えています。インターネット上の悪意ある攻撃者を防ぐための、最も洗練された入口制御を持っているわけです。これは、多くの方々が持っている一般的な考え方のモデルです。インターネットには常に新しい脅威が出現する危険な場所であることを考えれば、当然の発想といえます。ただし、このような考え方は、私たちを「侵すことのできない要塞」を作ることに過度に注力させ、入口の制御に過剰に重点を置かせてしまう傾向があります。
このメンタルモデルで見落としがちな重要な点は、クラウド上のデジタルリソースは、金庫に保管された静的な財宝ではないということです。これらのワークロードやアプリケーションは、動的なエコシステムの中で活発に活動する参加者であり、その根底にある動作を支配しているのはコードなのです。このコードの一部は開発者が書いたものですが、氷山の水面下に例えられる大部分は、他の人々が書いたコードです。これには、オペレーティングシステム、サードパーティのライブラリ、そして開発者がアプリケーションやサービスを構築する際に使用するあらゆる種類のパッケージが含まれます。
この例えで言えば、脆弱性は方程式の一部であり、完全に侵されない要塞モデルというのは存在し得ないことがわかります。Sofiaが言及した Log4j の脆弱性は、私たちが認識していて修正できる例です。しかし、まだ発見されていない脆弱性、つまり将来の Log4j のような問題も存在します。また、Sofiaが示唆したように、脅威アクターがオープンソースのエコシステムに侵入して、一般的な依存関係に悪意のあるコードを仕込むという懸念すべきトレンドも出てきています。もし入口側の対策にばかりすべての時間とエネルギーを費やしていた場合、侵害されたワークロードがインターネットに接続し、悪意のある送信先にアクセスしてデータを外部に送信しても、それを検査する手段がないことになります。したがって、インターネットが危険な場所である以上、入口の対策を優先することは重要ですが、出口の制御にも時間とエンジニアリングの努力を割くことを忘れないでください。
Amazon VPCのネットワーキングの仕組みを説明するために、まずインバウンド側について見ていき、その後、同じWebアプリケーションアーキテクチャを使ってアウトバウンド側の話に移りたいと思います。これは非常にシンプルなWebアプリケーションアーキテクチャです。Application Load Balancerが配置されているパブリックサブネットがあり、プライベートサブネットにワークロードがあります。インターネット上のエンドユーザーからのトラフィックはApplication Load Balancerに転送され、そこからバックエンドのワークロードに転送されます。これらのワークロードはEC2インスタンス、ECSコンテナ、あるいはサービスアーキテクチャかもしれませんが、この説明の目的においては実際どれでも構いません。
ネットワークセキュリティの観点から、まず最初に話したいのはSecurity Groupsです。これはVPCの基盤に組み込まれた優れた仮想ファイアウォールです。Application Load Balancerに入ってくる特定のプロトコルを制限します。この場合、暗号化されたHTTP通信を許可するため、TCP 443ポートのみを許可し、それ以外は許可しません。これによってアクセスが制限されます。 さらに、これがWebアプリケーションであることを考えると、Webアプリケーショントラフィックを実際に検査する何かが必要になります。それがWeb Application Firewallです。AWS WAFやパートナーのWAFなどが該当します。これによって、SQLインジェクションやクロスサイトスクリプティングなどのWeb特有の脅威をより深く調査することができます。
これらやその他のWeb特有の脅威（DDoS攻撃を含む）は重要な考慮事項です。これらの脅威について触れる理由は、現在の環境でこのようなインバウンド制御がある場所は、アウトバウンドの取り組みを始めるのに適した場所だからです。これらのワークロードは、機密性の高い顧客データや社内の知的財産にアクセスできる可能性が高いため、それらのワークロードがインターネット上で何にアクセスできるかを優先的に考える必要があります。
では、もう一方の側面であるアウトバウンド側について話しましょう。 すべてはDNSから始まります。ネットワーキングに長く携わっている方なら、「問題の原因は常にDNS」というフレーズを聞いたことがあるでしょう。これは、DNSがインターネットを動かす基本的で重要なプロトコルであることを表しています。重要なネットワークフローの99.999%は、DNSルックアップから始まります。DNSがダウンすると、実質的にネットワークがダウンしたも同然です。これに対処するため、Amazon VPCにはRoute 53 Resolverという非常に優れた機能があります。0.2アドレスにちなんで「0.2リスナー」と呼ぶ人もいますが、これは常時稼働の信頼性の高いDNS解決サービスを提供します。
例えば、私のワークロードが何らかのS3エンドポイントと通信する必要がある場合、 エンドポイントを検索するためにRoute 53 Resolverと通信します。そこからサービス管理プレーンを経由してインターネットに接続し、 そのドメインのIPアドレスを保持する権威DNSサーバーと通信します。ここで注目すべき点の一つは、DNSは本質的にインターネットとの双方向通信チャネルだということです。問い合わせとそれに対する応答があり、このプロセス全体が実質的に双方向通信となります。これには後ほど詳しく説明するセキュリティ上の影響があります。
この例では、バケット用のS3エンドポイントのIPを解決し、これから通信を外部に向けて行おうとしています。これらはプライベートサブネットなので、そのワークロードは公共インターネット上に独自のIPアドレスを持っていません。NAT Gatewayやその他のNATデバイスと呼ばれるものがIPアドレスを共有し、インターネットへの通信を可能にします。結局のところ、インターネットへの2つの経路があります：NAT Gatewayを経由する従来のIP経路とDNS経路です。これらは両方とも、Egress制御を考える際に考慮すべきインターネットへのチャネルとなります。
ここで視点を変えて、脅威アクターがこれらの同じEgress接続をどのように利用するかを見ていきましょう。この話をする際に、「悪い人たちが何をするか見てください」とか「彼らはなんて革新的なんでしょう」といった考え方はしないでください。重要なのは、脅威アクターが目的を達成するために常に様々なステップを踏まなければならないということです。これらの異なるステップを見ていく中で、後ほど説明するツールを使ってどのようにブロックできるかを考えてみましょう。
これを説明するために、Millyと呼ばれる実際のマルウェアの例を紹介します。これはLinuxサーバーを標的とするマルウェアで、そのライフサイクルはWGETリクエスト、より正確には一連のIPへの直接リクエストから始まります。DNSは一切使用せず、ハードコードされたIPアドレスに直接アクセスします。通信は、HTTPには少し unusual なポート、つまり暗号化されていないHTTPをポート8765で行います。マルウェアのホスティングに関して、このような unusual なポートの使用をよく目にします。脅威アクターは多くの場合、侵害されたシステム上にマルウェアやその他のツールをホストしており、そのシステム上でRoot権限を持っていない場合、低いポート番号にアクセスできない可能性があります。また、すでにそれらのポートを使用しているWebサーバー上でホストしようとしている可能性もあるため、unusual なポートが使用されることが多いのです。
この例では、2つのWGETリクエストが行われ、ワークロード上にRootkitとImplantの両方をダウンロードします。Implantは、RC Localスクリプトに自身を挿入することで持続性を維持し、Rootkitは、RC Modulesに自身を挿入するカーネルモジュールです。Implantが実行されると、C2インフラストラクチャーとの通信を試みます。そのために、C2ドメインに関連付けられたIPアドレスを解決します。攻撃者がC2インフラストラクチャーにDNSを使用するのはほぼ間違いありません。その理由は、サービスの柔軟性と可用性を高めるためです。私たちのアプリケーションでハードコードされたIPアドレスを使用しない理由と同じで、彼らもDNSを使用するのです。マルウェアのC2ドメインに関連付けられたIPアドレスを解決すると、通信が可能になります。
このアプローチにより、C2インフラストラクチャーの可用性と信頼性が向上し、攻撃者により多くの選択肢が与えられます。脅威アクターのC2インフラストラクチャーに到達すると、これが完全な侵害のポイントとなり、インフラストラクチャーを制御している者が、侵害されたワークロード上のRootkitとImplantを通じて何ができるかをコントロールできるようになります。
その後に起こることは、状況によってかなり異なります。 攻撃者の目的は環境内での横展開を含む可能性があり、長期的な持続性を維持するために追加のツールをインストールするかもしれません。ランサムウェアの場合のように機密データの窃取や暗号化を行う可能性もあります。これはニュースでよく取り上げられる大きな事件になりがちです。また、さらなるアクセス権を維持・付与するために、追加のAWS認証情報やSSHキーを探そうとするでしょう。
重要なポイントは、これらのステップがどのように機能するかを確認できたことです。これらはすべて、DNS FirewallやNetwork Firewall、あるいはその両方を組み合わせることで潜在的にブロックできる要素でした。すべてのステップをブロックする必要はありません - 1つのステップを効果的にブロックするだけで、脅威アクターは完全な侵害に至ることができません。では次に、最小権限への私たちの取り組みについてお話ししましょう。 ここまでの説明をよく聞いていただいていれば、それほど驚くような内容ではないはずです。
最小権限アプローチと最新のAWSセキュリティ機能
最低限必要なのは、既知の不正なトラフィックをブロックすることです。これを実現する簡単で直接的な方法の1つは、先ほど説明したサービスに組み込まれているAWS管理の脅威ルールを活用することです。これらの脅威ルールにより、インターネット上の既知の不正な送信先をブロックする機能が提供されます。両サービスとも、最初にアラートモードで、その後ブロックモードで設定できるルールをサポートしています。この脅威インテリジェンスは、AWSの内部ソースと外部パートナーのデータの両方から提供されています。Network Firewallの場合、悪意のあるドメイン名だけでなく、仮想通貨マイニングやマルウェアのC2トラフィックに関連する脅威シグネチャなど、ネットワークトラフィックの幅広い特性も考慮されます。
既知の不正なトラフィックをブロックした後、次に可能な限りリスクの高い場所をブロックしたいと考えます。 環境によっては、通信する必要のないインターネットの特定の部分があることがわかっているので、それらをブロックして対象から外すことができます。その方法の1つは、悪用されやすいトップレベルドメイン（TLD）- .comや.eduなどのサフィックス - をブロックすることです。毎日新しいマルウェアドメインが出現する、管理が非常に緩いTLDが多数存在します。この詳細を知りたい場合は、どのTLDが最も問題があるかについての統計分析が豊富にあります。ほとんどのお客様は、これらのドメインとワークロードが通信する正当な理由を持っていません。
Network Firewallには新しい地理的なIPフィルタリング機能があり、トラフィックを送信したくない国を指定できます。顧客やコミュニケーションパートナーの所在地を特定し、それに基づいてフィルタリングを行うことができます。 次に、インターネットに許可するプロトコルを検証する必要があります。Network Firewallには非常に高度なパケット検査機能があり、標準で20以上の異なるプロトコルをネイティブに識別できます。これにより、それらのプロトコルの重要なメタデータに対するロギングとフィルタリング機能が可能になります。例えば、先ほど示した例のような、通常とは異なるポートでのHTTP通信や、WGETリクエストの直接IPコンポーネントなどを簡単に検出してブロックすることができます。
先ほど申し上げた通り、Network Firewallはすでに20種類のプロトコルをサポートしており、その数は常に増え続けています。最近では、HDB2 QuickとPostgreSQLが追加されました。これは常にお客様との対話の中で出てくる話題であり、現在リストにない中で最も重要なものは何かについて、常にフィードバックをお待ちしています。このことについて何かご意見がありましたら、ぜひお声がけください。
最後になりますが、信頼できるドメインに対してのみEgressを許可することについてお話しします。これは多くのお客様にとって課題となっていますが、それでも多くの方々がこの方向への取り組みを始めているのを目にします。考えてみれば、クラウド環境におけるワークロードの振る舞いは、日々様々な場所にアクセスする一般的なユーザートラフィックとは大きく異なるはずです。ワークロードが通信する必要のある接続先は、かなり限定的なものであるべきなのです。
通常、お客様はこの取り組みを始める際、信頼できると分かっている主要なドメインのリストを含むファイアウォールポリシーを作成することから始めます。そして、それらの信頼できるドメイン以外へのトラフィックについては、まずはアラートを設定します。その後、アラートされたトラフィックから検出されるドメインを調査し、ワークロードが本当に通信する必要のあるドメインを完全に把握できるまでこれを続けます。これが完了したら、最終的なアクションをブロックに変更し、許可リストに載っていないインターネットアクセスを全て遮断する状態に移行します。これにより、インターネット上の悪意のある活動に関する最新の脅威インテリジェンスリストを常に維持する必要がなくなり、大幅なリスク軽減が可能となります。なぜなら、そもそもほとんどのアクセスをブロックしているからです。このユースケースは非常に人気が高いため、サービスチームは現在、このプロセスの合理化と摩擦の軽減に積極的に投資しています。
Geographic IP Filtering は、PFR（プロダクト機能リクエスト）として最も要望の多かった機能の一つで、今年8月にローンチされました。簡単に言えば、Amazon VPCにおいて、どの国との通信を許可または制限するかをファイアウォール内で制御できる機能です。多くのお客様から、自社のワークロードは特定の国とのみ通信を行うことが分かっているため、それらの国に対する許可リストモデルを作成したり、特定の国へのアクセスをブロックしたりすることが非常に簡単になったという声を聞いています。特に米国のお客様からよく聞かれるリクエストは、ITAR（国際武器取引規制）の制裁リストに載っている国々をブロックしたいというものです。多くのお客様にとって、コンプライアンス上の理由でこのようなトラフィックをブロックする必要がありますが、同時に、脅威アクターが責任を問われにくい地域からのアクセスをブロックすることで、大幅なリスク軽減も実現できます。
約1週間半前にリリースされたDNS Firewall Advanced は、DNSトンネリングをブロックする機能を提供します。これは多くのC2ツール、特にランサムウェア攻撃でよく使用されるCobalt StrikeやSliverなどの悪名高いC2ツールが積極的に利用している手法です。これらのツールは従来の制御をバイパスすることができましたが、この新機能により、リアルタイムで検知してブロックすることが可能になりました。GuardDutyでもこの種の検知は可能ですが、それは遅延があり、インラインではないためブロックすることができません。DNS Firewall Advancedを使用すれば、このような活動を実際にブロックすることができます。
DNS Firewall Advancedは、Domain Generation Algorithm（DGA）もブロックすることができます。DGAはマルウェアに組み込まれており、本質的に多数のC2ドメインとの通信を可能にします。C2ドメインが特定されてブロックリストに登録されたり、当局によって停止されたりしても、マルウェアは何千、何十万というドメインを使い回して通信を継続できるという考えに基づいています。静的なブロック手法ではこれを検出してブロックすることは非常に困難ですが、DNS Firewall Advancedは機械学習機能を活用してこれらの脅威を特定します。最近、私はこの機能を探求し、DNS Tunnelingなどの同様のイベントの検出とブロックについて学ぶためのワークショップを作成しました。
Re:Inventの会場でワークショップを実施することはできませんが、この機能についてさらに詳しく知りたい方は、後ほど私にお声がけください。それでは、Sofiaにバトンを渡したいと思います。
ありがとう、Michael。これで私たちのプレゼンテーションは終わりです。最小権限に向けた取り組みを始めるための4つの重要な原則についてご説明させていただきました。これらの概念について掘り下げて始めたい方には、特に一番上にある Network Firewall のベストプラクティスなど、これらのリソースをブックマークすることをお勧めします。 これは、MichaelとJesse Leitchが作成した、例示やシナリオ、FAQ、トラブルシューティング情報を含む包括的なガイドです。
Michaelが言及したように、本日お話しした原則、特に新しいDNS Firewall Advancedの機能について実践的な経験を積みたい方は、このワークショップをご活用ください。アクセスをご希望の方は、お気軽にお申し付けください。お時間を頂き、ありがとうございました。ご質問がある方は、この後しばらく会場に残っております。それ以外の方は、今回のセッションについてのフィードバックをいただけますと幸いです。来年またお会いできることを楽しみにしています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion