データ流出の防止: AWS で実現するクラウドワークロードのエグレス制御

本ブログは 2026 年 6 月 22 日に公開された AWS Blog “Prevent data exfiltration: AWS egress controls for cloud workloads” を翻訳したものです。

2026 年 8 月 4 日: 「データ境界」セクションを更新しました。

Amazon Web Services (AWS) 環境のセキュリティを確保する際、チームが当然のように優先するのは、インバウンド制御、ファイアウォール、ウェブアプリケーションファイアウォール (WAF)、アクセスポリシーです。最も目につきやすい脅威がそこから発生するためです。一方、アウトバウンドトラフィックは注目されにくい傾向があります。アプリケーションの依存関係に支障をきたさないよう、またリスクがそれほど差し迫っていないように感じられることから、デフォルトで開放されたままになっているケースも少なくありません。しかし、エグレス (アウトバウンド方向の通信) を見落とすと、重要な防御レイヤーが欠けることになります。ネットワークから何が出ていくのかを把握できなければ、設定ミスのあるサービス、過度に広範な権限、不正アクセスを受けたワークロードなど、原因が何であれ、意図しないデータフローを検出するのは難しくなります。

実際のインシデントを見ると、従来のクラウドワークロードと新たな AI 駆動型アーキテクチャの両方で、エグレス制御に注意を払うべき理由がよくわかります。

従来のクラウド環境では、アプリケーションレベルのセキュリティ問題が依然として根強い脅威となっています。例えば、CVE-2025-55182 (React2Shell) が 2025 年 12 月に公開された際には、複数の組織的なグループが数時間以内に悪用を試み始め、パッチ未適用の React Server Components を標的としてリモートコード実行を狙いました。権限のない第三者はワークロードにアクセスすると、通常、アウトバウンドのコマンドアンドコントロールチャネルを確立し、データを外部に持ち出し始めます。エグレス制御が導入されていなければ、こうしたアウトバウンドトラフィックは制限なく流れ、コンプライアンス監査や顧客からの苦情、インシデント通知をきっかけに発覚するまで、不正アクセスに気付かない可能性があります。

エージェンティック AI システムは、このリスクに新たな側面をもたらします。OWASP Top 10 for Agentic Applications では、Agent Goal Hijack (エージェントの目標の乗っ取り、ASI01) や Unexpected Code Execution (想定外のコード実行、ASI05) などの脅威が挙げられています。前者は、権限のない第三者が自律型エージェントの目的を操作し、密かにデータを流出させる脅威です。後者は、不正アクセスを受けたエージェントが潜在的に有害なコードを生成、実行し、リバースシェルを確立したり、機密データを外部のエンドポイントに転送したりする脅威です。組織がツール、API、コードインタープリターにアクセスできる AI エージェントをデプロイするようになるにつれ、こうしたエージェントは価値の高い標的になります。そのため、エージェントのアウトバウンドのネットワークアクティビティも、他のワークロードと同等の厳格さで制限する必要があります。

どちらのシナリオにも共通するのは、不正なアウトバウンドトラフィックです。この記事では、送信元が不正アクセスを受けたアプリケーションでも、操作された AI エージェントでも、不正なデータ転送のリスクを低減できるよう、複数の AWS のサービスを連携させて、エグレスの検出と保護を多層的に実装する方法を紹介します。

アーキテクチャの概要

Figure 1: Hub-and-spoke egress control architecture

図 1: ハブアンドスポーク型のエグレス制御アーキテクチャ

図 1 に示すアーキテクチャは、マルチアカウントの AWS 環境でハブアンドスポーク型のネットワークパターンを実装するアプローチの一例です。組織の要件や制約によっては、別の設計が適している場合もある点に注意してください。

アプリケーションワークロードはスポーク VPC (Virtual Private Cloud) に配置され、これらの VPC は AWS Transit Gateway に接続されます。Transit Gateway は、VPC 間のトラフィックとインターネット向けトラフィックをルーティングする中央ハブとして機能し、慎重に設計されたルートテーブルによってネットワークのセグメンテーションを適用します。スポーク VPC は、AWS のサービスへの安全なアクセスに VPC エンドポイントを使用し、可能な限りトラフィックを AWS ネットワーク内にとどめます。VPC エンドポイントポリシーは主要なデータ境界の制御として適用され、AWS のサービスにアクセスできるプリンシパルと、これらのエンドポイント経由でアクセスできるリソースを制限します。

インターネット向けトラフィックは、Transit Gateway にアタッチされた AWS Network Firewall を経由してルーティングされます。Network Firewall は、アウトバウンドのフローがインターネットに到達する前に検査し、フィルタリングします。この一元的なルーティングモデルは、検査インフラストラクチャを変更せずにスポーク VPC を追加するだけで水平方向にスケールできるため、複数の AWS アカウントを持つ組織に適しています。

重要な点として、Route 53 VPC Resolver を通じて名前解決される DNS クエリをフィルタリングするには、Amazon Route 53 Resolver DNS Firewall を各 VPC にデプロイする必要があります。なお、他の DNS リゾルバーに直接送信される DNS クエリは DNS Firewall を経由しませんが、AWS Network Firewall でフィルタリングできます。DNS Firewall は、マネージドドメインリストとカスタムドメインリストの両方を使用して DNS クエリをフィルタリングし、ネットワーク接続が確立される前に、既知の不正なドメインの名前解決をブロックします。

データ境界の制御は複数のレイヤーで適用されます。具体的には、サービスコントロールポリシー (SCP) とリソースコントロールポリシー (RCP) を AWS Organizations レベルで、VPC エンドポイントポリシーをネットワークレベルで、リソースポリシーを個々のサービスで使用します。AWS IAM Access Analyzer は組織レベルでデプロイされ、パブリックにアクセス可能なリソースや外部と共有されているリソースを継続的に検出します。

検出レイヤーは Amazon GuardDuty、AWS Security Hub、IAM Access Analyzer で構成され、継続的なモニタリングと脅威検出を担います。検出結果は、Amazon EventBridge を使用した統合レイヤーを通じてルーティングされます。この統合レイヤーは、AWS Lambda ベースの自動修復をトリガーし、Amazon Simple Notification Service (Amazon SNS) を使用して通知を送信します。また、この統合レイヤーはネットワーク制御とも連携し、検出された脅威に基づいて Network Firewall の拒否ルールを自動的に更新し、DNS Firewall のブロックリストも更新します。

一元的なオブザーバビリティは、Amazon CloudWatch Logs と CloudWatch ダッシュボードによって実現されます。Network Firewall のフローログとアラートログは一元的に収集され、インシデントの調査やコンプライアンスレポートの作成に役立ちます。

このアーキテクチャは、従来のアプリケーションワークロードにも AI 駆動型ワークロードにも同様に適用できます。例えば、Amazon Bedrock で実行される AI エージェントは、通常、スポーク VPC 内に配置されます。このエージェントが外部 API を呼び出したり、インターネットへのアクセスを試みたりすると、そのトラフィックは Amazon Elastic Compute Cloud (Amazon EC2) やコンテナのワークロードと同じく、Transit Gateway と Network Firewall を経由する経路をたどります。エージェント専用の特別な出口が用意されているわけではなく、同じドメイン許可リスト、同じ DNS フィルタリング、同じデータ境界ポリシーが適用されます。

とはいえ、エージェントは通常の動作の一環として外部ツールやサードパーティーの API を呼び出すためにアウトバウンドアクセスを必要とすることが多く、許可リストの設計にはより細やかな配慮が必要です。広範なカテゴリ単位で開放するのではなく、許可するドメインを、エージェントが正当に必要とする特定のエンドポイントに厳密に絞り込むことをお勧めします。さらに、これらのネットワークレイヤーの制御を Amazon Bedrock Guardrails (有害なコンテンツのフィルタリングや、ネットワークレイヤーに到達する前のプロンプト攻撃の検出が可能) などのアプリケーションレイヤーのガードレールで補完することで、防御レイヤーを追加できます。

予防的コントロール

次の予防的コントロールは、データ流出を未然に防ぎます。トラフィックを能動的に遮断するため、潜在的に有害であることが確認されている、またはその可能性が高いアクティビティに限定して適用してください。

AWS Network Firewall

次のシナリオを考えてみましょう。権限のない第三者がスポーク VPC の 1 つにある EC2 インスタンスを侵害し、機密データを外部サーバーに流出させようとします。続いて、エージェンティック AI のシナリオも考えてみます。権限のない第三者がプロンプトインジェクションを使用して AI エージェントの目標を乗っ取り (OWASP ASI01)、トレーニングデータを外部のエンドポイントに流出させるよう仕向けます。いずれの場合も、不正な宛先は承認済みのドメイン許可リストに含まれていないため、Network Firewall はこうした試みをブロックするように設計されています。不正アクセスを受けた EC2 インスタンスからのデータ流出を阻止するのと同じ制御で、操作された AI エージェントからのデータ流出も阻止できます。

エグレスを一元的に検査しない場合、そのトラフィックは NAT ゲートウェイを経由してインターネットに直接流れます。Network Firewall は、レイヤー 3～7 にわたる一元的なディープパケットインスペクションと高度な脅威インテリジェンス機能を提供することで、これを防止します。具体的には、IP アドレス、ポート、プロトコルによるフィルタリングに加え、Suricata 互換ルールを使用したパケット内容の検査が可能です。

このアーキテクチャでは、Transit Gateway が複数のスポーク VPC からのインターネット向けトラフィックを、一元的な検査のために Network Firewall へ集約します。ファイアウォールエンドポイントは 0.0.0.0/0 ルートのターゲットとなり、アウトバウンドのインターネットトラフィックは、アドレス変換を行う NAT ゲートウェイに到達する前に検査されます。どちらのシナリオでも、Network Firewall はデータが環境外に出る前に、ネットワークレイヤーで流出の試みをブロックします。主な機能は次のとおりです。

ドメイン名フィルタリング: 不正な宛先へのトラフィックをブロック (コマンドアンドコントロールサーバーの *.untrusted-domain.com など)
IP とポートのルール: アプリケーションが本当に必要とする外部 IP について明示的な許可リストを定義し、それ以外をすべてブロック
ドメインカテゴリフィルタリング: ワークロードが決して通信すべきでないドメインのカテゴリ全体をブロック
IDS と IPS: Suricata 互換ルールを使用して、アウトバウンドトラフィック内の既知の攻撃パターンを検出してブロック
ポートとプロトコルの強制: 想定されるプロトコルのみが指定されたポートを使用するようにし (例えば、TCP ポート 443 では HTTPS のみ)、プロトコルトンネリングを防止
地理的 IP フィルタリング: 組織が取引関係を持たない地域へのアウトバウンドトラフィックをブロック
TLS 復号: 暗号化されたトラフィックを検査し、HTTPS 接続内に隠された流出の試みを検出
脅威インテリジェンスの統合: マネージド型の脅威インテリジェンスフィード (Amazon の脅威インテリジェンスシステム MadPot を使用するアクティブな脅威防御など) やカスタム Suricata ルールを使用して、想定外のパターンを検出
自動スケーリング: アベイラビリティーゾーンあたり最大 100 Gbps を処理

マルチアカウント環境では、AWS Firewall Manager を使用して組織のアカウント全体に Network Firewall を一元的にデプロイ、管理できるため、すべての環境で一貫したエグレスルールを維持しやすくなります。さらに、AWS Network Firewall Proxy (プレビュー) は、アウトバウンドのウェブトラフィックに対してアプリケーションレイヤーの検査を必要とするワークロード向けに、URL パスや HTTP メソッドレベルの制御を含むきめ細かな HTTP/HTTPS フィルタリングを備えた明示的プロキシ機能を提供します。

訳注: 明示的プロキシは 2026 年 8 月に AWS Network Firewall の機能として再導入され、2026 年 10 月時点では米国東部 (オハイオ) リージョンでパブリックプレビュー中です。参照: [Preview Announcement] Re-introducing Forward Proxy as AWS Network Firewall Functionality

Route 53 Resolver DNS Firewall

Route 53 VPC Resolver を通じて行われる DNS クエリは、Network Firewall やサードパーティーのファイアウォールが検査するアウトバウンドのネットワーク経路を通過しません。権限のない第三者はこれを悪用し、外部サーバーへの DNS クエリ内に機密データをエンコードして持ち出すことができます。これは DNS トンネリングと呼ばれる手法です。このリスクはエージェンティック AI のワークロードにも及びます。コード実行機能を持つエージェント (OWASP ASI05) がだまされて、機密データ (顧客レコード、モデルの重み、API キーなど) を、外部の第三者が制御するネームサーバー宛ての DNS クエリにエンコードするスクリプトを実行してしまう可能性があります。DNS Firewall は、接続が確立される前にリゾルバーレベルでフィルタリングを行うため、クエリの発生元が従来のワークロードでも AI エージェントでも、これらのクエリをブロックできるように設計されています。

DNS トラフィックは通常の運用に不可欠である一方、セキュリティアーキテクチャでは見落とされがちなため、不正なデータ流出によく使われるチャネルとなっています。Route 53 Resolver DNS Firewall は、VPC からのアウトバウンド DNS クエリをフィルタリングし、必要に応じてブロックすることで、このギャップを解消します。主な機能は次のとおりです。

不正なドメインのブロック: AWS は、マルウェア、ランサムウェア、ボットネット、スパイウェア、DNS トンネリングを対象とする Aggregate Threat List を含むマネージドドメインリストを提供
許可リストの適用: 承認済みドメインへのクエリのみを許可し、それ以外をすべてブロック
DNS Firewall Advanced の機能: AI と機械学習 (AI/ML) による、DNS トンネリング、ドメイン生成アルゴリズム (DGA)、辞書型 DGA の検出

設定は簡単です。ドメイン一致リストとアクション (ブロック、許可、アラート) を含むルールグループを作成し、VPC に関連付けます。DNS リゾルバーは、VPC 内のインスタンスから Route 53 Resolver を通じて行われるすべての DNS クエリにこれらのルールを適用します。これにより、権限のない第三者が DNS トンネリングを使用してデータを流出させることを防止できます。DNS トンネリングは、エグレス VPC のファイアウォールによる検査を完全に回避してしまう手法です。

DNS を利用した流出に関連するリスクと DNS Firewall Advanced の機能の詳細については、「Protect against advanced DNS threats with Amazon Route 53 Resolver DNS Firewall」を参照してください。

データ境界

データ境界とは、信頼できるアイデンティティのみが、想定されるネットワークから信頼できるリソースにアクセスできるようにする一連の予防的ガードレールです。前述の制御が環境外に向かうネットワーク経路を保護するのに対し、データ境界は API レベルの経路を保護します。これにより、権限のない第三者が有効な認証情報を入手した場合でも、AWS のサービスの API を使って組織外のリソースにデータを移動することを防ぐのに役立ちます。

この包括的なアプローチでは、AWS が提供する次の 3 つの主要機能を組み合わせて使用します。

SCP: アイデンティティが実行できる操作を制限する、組織全体の予防的コントロールです。エグレス保護の観点では、SCP を使用して、ユーザーがエグレス制御を回避するリソースを作成することを防止できます (例えば、DNS Firewall が関連付けられていない VPC の作成を防止したり、別のアウトバウンド経路を確立できるサービスの使用をブロックしたりできます)。
RCP: リソースへの API アクセスを制限する制御です。RCP は直接的なエグレス制御ではありませんが、補完的なレイヤーとして機能します。例えば、組織外から Amazon Simple Storage Service (Amazon S3) バケットへのアクセスの試みを、リソースレベルでブロックできます。
VPC エンドポイントポリシー: VPC エンドポイントを使用すると、トラフィックがインターネットを経由することなく、AWS のサービスとプライベートに通信できます。VPC エンドポイントポリシーは、リソースベースの AWS Identity and Access Management (IAM) ポリシーであり、そのエンドポイントを通じてアクセスできる対象を制御します。データ境界がエグレス制御として最も直接的に機能するのは、この部分です。

さまざまな AWS のサービスに対応する VPC エンドポイントポリシーの例は、こちらのリポジトリで確認できます。データ境界ポリシーは新たな権限を付与するものではなく、ガードレールを設けることでアクセスできる範囲を絞り込む、2 つ目の認可レイヤーとして機能します。IAM 条件キー aws:PrincipalOrgID、aws:ResourceOrgID、aws:SourceVpc、aws:SourceVpce などを使用してデータ境界を実装することで、意図しないアクセスパターンや設定ミスの防止に役立つ多層的な権限ガードレールを構築できます。

境界制御の実装の詳細については、AWS ホワイトペーパー「Building a Data Perimeter」を参照してください。

発見的コントロール

次の発見的コントロールは、発生したデータ流出の試みを事後に明らかにします。トラフィックを遮断するのではなく観察するものであるため、幅広く適用して、想定外のアクティビティを調査対象としてフラグ付けできます。検出結果を使用して、繰り返し発生する不正なパターンのうち、予防的コントロールに反映できるものを特定しましょう。

Amazon GuardDuty: エグレスの脅威に対する発見的コントロール

GuardDuty は、エグレス保護における重要な検出レイヤーとして機能し、予防的コントロールを回避または悪用するアウトバウンドの脅威を継続的にモニタリングします。GuardDuty は、進行中のデータ流出の試みを示す行動の異常や攻撃パターンを特定します。エグレスに焦点を当てた主な検出機能は次のとおりです。

DNS ベースのデータ流出の検出: 検出結果タイプ Trojan:EC2/DNSDataExfiltration は、EC2 インスタンスが DNS チャネルを通じてデータを転送している場合にアラートを発します。GuardDuty は、コマンドアンドコントロール通信によく使用される DGA ドメインへのクエリも特定します。
既知の悪意のあるアクターの検出: Exfiltration:S3/MaliciousIPCaller は、GetObject や CopyObject などの Amazon S3 データ API が、AWS の脅威インテリジェンスフィードに登録された IP アドレスから呼び出されたときにトリガーされ、進行中のデータ抽出の試みを示します。
多段階の攻撃シーケンスの相関分析: GuardDuty 拡張脅威検出は、複数の想定外のイベントを相関分析し、データ流出を狙った多段階の攻撃キャンペーンを特定します。例えば、AttackSequence: S3/CompromisedData は、権限のない第三者が S3 バケットポリシーを変更してアクセス範囲を広げたうえで、盗んだ認証情報を使用して体系的にデータを抽出する動きを検出します。

GuardDuty の検出結果は、エグレス戦略において 2 つの役割を果たします。失敗に終わった流出の試みに関するアラートは、予防的レイヤー (Network Firewall、DNS Firewall、データ境界) が効果的に機能していることを裏付けます。つまり、脅威は行動分析をトリガーする段階まで進行したために検出されたものの、実際のデータ流出は制御によってブロックされたということです。一方、データ流出が実際に発生したことを示す検出結果は、直ちにインシデント対応ワークフローをトリガーします。これにより、重大な損害が発生する前に、進行中のインシデントを封じ込め、盗まれた認証情報を無効化し、影響を受けたリソースを隔離できます。

GuardDuty を Security Hub と統合してセキュリティサービス全体の相関分析を一元化するとともに、EventBridge と Lambda 関数による自動対応を実装し、重大度の高い流出の検出結果が発生したときにリアルタイムで封じ込めができるようにしてください。

IAM Access Analyzer

IAM Access Analyzer は、AWS アカウントまたは組織の外部からアクセス可能なリソースを検出することで、潜在的なデータ流出経路の特定に役立ちます。自動推論テクノロジーを使用してリソースベースのポリシーを分析し、どのリソースに外部エンティティ (信頼ゾーン外のプリンシパル) がアクセスできるかを特定して、パブリックアクセスとクロスアカウントアクセスを継続的にモニタリングします。

外部アクセスアナライザーは、他の AWS アカウントなどの外部プリンシパルと共有されているリソースや、パブリックアクセスが許可されているリソースを特定します。例えば、バケットポリシー、ACL、アクセスポイントを通じて信頼ゾーン外からのアクセスを許可するように S3 バケットが設定されている場合、IAM Access Analyzer は、外部プリンシパルや付与されたアクセスレベルなど、アクセス経路の詳細を含む検出結果を生成します。セキュリティチームは、意図しないアクセス許可を直ちに取り消すか、EventBridge を通じて自動通知を設定して開発チームに修復を依頼することで対応できます。

AWS Security Hub

Security Hub のエクスポージャーの検出結果は、複数の AWS セキュリティサービスのデータを相関分析することで、潜在的なセキュリティリスクを包括的に把握できるようにします。これらの検出結果は、GuardDuty (脅威検出)、Amazon Inspector (脆弱性評価)、Security Hub CSPM (設定のコンプライアンス)、Amazon Macie (機密データの検出) からのインテリジェンスを統合し、データ流出に対して脆弱である可能性のあるリソースを特定します。例えば、パブリックに公開されている S3 バケットに機密データが含まれており、かつ保管時に暗号化されていない場合に、直ちに対応が必要な潜在的なデータ流出リスクとしてフラグ付けできます。

AWS Shield network security director (プレビュー) は、ネットワークトポロジを検出、分析して、アウトバウンドのインターネットアクセスが制限されていないリソースを特定することで Security Hub を補完し、環境全体に潜むエグレスの死角の検出を支援します。

エグレスセキュリティ戦略

これらの制御をすべて一度に実装する必要はありません。次の段階的なアプローチに従えば、組織の運用成熟度とリスク許容度に合ったペースで、エグレスのセキュリティポスチャを少しずつ強化できます。

フェーズ 1 – すぐに効果が出る施策: すべての VPC で Route 53 DNS Firewall を有効にして、DNS を利用したデータ流出に対する防御のギャップを解消します。すべてのアカウントで GuardDuty を有効にして、ベースラインとなる脅威検出を実現します。
フェーズ 2 – 基盤の構築: 組織全体のデータ境界 (SCP、RCP、VPC エンドポイントポリシー) をデプロイします。Network Firewall を Transit Gateway にアタッチされたファイアウォールとしてデプロイします。
フェーズ 3 – 効率化: IAM Access Analyzer を有効にして、外部アクセスを継続的に検出します。EventBridge と Lambda による自動修復を実装し、ファイアウォールルールをリアルタイムで更新します。検出結果を Security Hub に一元化し、自動アラートを設定します。

まとめ

エグレスセキュリティは単一の制御で実現するものではなく、多層的な戦略です。まず、ネットワークフィルタリング、DNS セキュリティ、データ境界、発見的コントロールの各観点から、現在のセキュリティポスチャを評価してください。ギャップを特定したら、この記事で説明した段階的なアプローチに従って、それらを順次解消してください。流出の試みをシミュレートした定期的なテストを行うことで、制御が効果的に機能していることを検証できます。これらの制御は、操作されたエージェントが意図しない流出経路になり得るエージェンティック AI のワークロードにも、同様に有効です。エグレスを制御下に置き、アウトバウンドの死角をモニタリングされたチェックポイントに変えましょう。

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ