はじめに
金融IT本部 2年目の坂江 克斗です。
業務にてアウトバウンドセキュリティを考えるタイミングがあったため、本記事を書きました。
初学者の視点で疑問に感じる部分も含め、アウトバウンドセキュリティ全体の基本的な概念を解説できればと思います。
アウトバウンドセキュリティの概要
Webアプリケーション開発においては、SQLインジェクションや XSS、DDoS など、インバウンド通信に対するセキュリティを意識する機会が多い一方で、アウトバウンド通信のセキュリティについては、あまり意識されないことが多いように感じます。
しかし、AWS re:Inforce 2025 - Outbound network controls made easyでも述べられているとおり、アウトバウンドセキュリティは 防御（Prevention） と 可視性（Visibility） の両面において、近年ますます重要になっています。
防御の観点では、以下のケースが挙げられます。
- マルウェアに感染したサーバから外部の悪意あるエンドポイントへの通信を防止。
- ソフトウェアサプライチェーンにおいて、意図しない参照先や汚染されたOSSへのアクセスを制御。
- 直接的な通信遮断に至らない場合であっても、不正アクセスや異常な通信パターンを検知する機会の増加。
可視性の観点では、以下のケースが挙げられます。
- NAT Gateway と VPC エンドポイントの使い分けのような設定ミスの検知
- SOC（Security Operations Center）における分析・調査のためのセキュリティログや分析材料の充実。
よって、防御と可視性の両面において、アウトバウンドセキュリティが重要であることが分かります。
アウトバウンドセキュリティは大枠として、DNSベース、パケットヘッダ（3層-7層）ベース、ボディベースでのフィルタリングが中心となり、組み合わせることで多層防御を形成します。（ただし、ボディの解析は処理負荷があるため、セキュリティと性能のバランスを考慮した設定が必要となると思われます）
AWSでは以下の表に示すアウトバウンドセキュリティ対策が挙げられ、中でもマネージドに提供されているものとして Route 53 Resolver DNS Firewall（DNSベース）およびNetwork Firewall（L3 - L7パケットヘッダベース） 、AWS Network Firewall Proxy（L3 - L7パケットヘッダベース） が存在します。
| レイヤ | 制御観点 | AWSサービス | 料金 | 特徴 |
|---|---|---|---|---|
| DNS (名前解決) | ドメイン名 | Route53 Resolver DNS Firewall | 低（DNSクエリ） | DNSクエリを制御。ローカルでの名前解決やIP直打ち、独自DNS使用の通信は防御不可。 |
| L3–4 | IP / Port | SG / NACL | 無料 | ファイアウォール。ネットワークセキュリティのベースとなるフィルタリング。 |
| L3–7 | IP / Port, TCPヘッダ / HTTP ヘッダ / TLS ヘッダ | Network Firewall, GatewayLoadBalancer + サードパーティソフト | 高（AZ毎の常時稼働エンドポイント＋処理量） | 柔軟な制御が可能で、マネージドにも運用可能。 |
| DNS + L3–7 | IP / Port, HTTP ヘッダ / TLS ヘッダ | AWS Network Firewall Proxy | 調査中 | マネージドなフォワードプロキシサービス。現状はパブリックプレビュー中で無料使用可能。 |
AWSのアウトバウンドセキュリティサービス
Route53 Resolver DNS Firewall
Route 53 Resolver は、VPCのCIDRブロックにおける +2 の予約済みIPアドレスで提供されるマネージドリゾルバです。例えば、10.0.0.0/16のVPCでは、10.0.0.2がRoute 53 Resolver の IP アドレスとして割り当てられます。このIPアドレス自体はVPC内で共通ですが、実際にDNSクエリを処理するリゾルバのエンドポイントはAZごとに配置されており、高可用性を考慮した構成となっています
VPC 内のアプリケーションからこの Route 53 Resolver を経由して送信されるアウトバウンド DNS クエリに対してVPC単位でフィルタリングを行うサービスが、Route 53 Resolver Firewall となります。
ドメインリストを基に ALLOW / BLOCK / ALERT を設定することで、特定のドメイン群に対する通信を許可・拒否、またはアラートとして検知することができます。
また、BLOCK の場合にはカスタム DNS レスポンスを設定することで、CNAME を用いて特定のドメインへの名前解決に誘導することも可能です。
さらに、CNAME による変換後のドメインについても検証対象とするかを設定できるため、Allow List / Deny List のいずれにおいても柔軟な構成が可能です。
CNAME による変換後のドメイン検証
Deny List 構成では、CNAME 変換後のドメインまでを検証対象とすることで、悪質なドメインへの名前解決を防止できます。
Allow List 構成において CNAME 変換後のドメインまで全て許可対象とする場合、管理すべきドメイン数が増加し、運用負荷が高くなる傾向があります。そのため、運用方針によっては CNAME 変換後の検証を行わない設定とし、管理コストを抑える選択肢も考えられます。
Network Firewall
AWS Network Firewall は、AWS マネージドのファイアウォールおよび IDS/IPS サービスであり、インバウンド / アウトバウンドに対してサブネット単位で設定したルール（ステートレスルール / ステートフルルール）に基づいて、パケットを ALLOW / DROP / ALERT に分類し制御します。
（1つのNetwork Firewallを複数のVPCで共有できる機能も公開されています）
ステートレスルールは、全てのパケットを個別に評価して判定を行います。一方、ステートフルルール（Suricata互換）では、TCP や TLS、HTTP などの一連の通信（コネクション）を単位として制御することが可能です。
例えば、ステートレスルールでは TCP の 3 ウェイハンドシェイクを構成する各パケットをそれぞれ独立してフィルタリングしますが、ステートフルルールでは TCP の通信全体をひとまとまりとして扱い、コネクションの状態（established か否か）を追跡しながらフィルタリングを行います。
Network Firewall では、上図に示すようにルートテーブルの設定によって、検査対象となる通信の往路・復路の両方を同一の Firewall Endpoint に通過させることで、ステートフルな通信制御を実現しています。（非対称ルーティングの回避）
これは、各 Firewall Endpoint が通信状態を個別に管理しており、TCP や HTTP などのハンドシェイクにおいてリクエストとレスポンスの両方を確認することで、通信が正しく確立されたものであるかを判断する必要があるためと考えられます。
今回は比較的シンプルな構成を例に紹介しましたが、Network Firewallのデプロイモデルには複数のパターンが存在します。
実際の設計においては、通信要件や可用性、運用負荷を考慮したうえで、適切なモデルを選択することが重要です。
Network Firewall と Gateway Load Balancer（GWLB）
Network Firewall は、内部的に Gateway Load Balancer と連携して動作するマネージドサービスです。
Gateway Load Balancer は、GENEVE プロトコルを用いてサードパーティ製のインスペクションサービスへトラフィックをトンネリングする仕組みを提供するもので、インバウンド / アウトバウンド のセキュリティ対策に利用できます。
一方で、Network Firewall を利用することで、こうしたインスペクション機能そのものを AWS マネージドサービスとして構成できるため、構築・運用負荷を大きく下げることができます。
Network Firewall Proxy
2025年11月末にマネージドなフォワードプロキシサービスである AWS Network Firewall Proxy が発表されました。現在はパブリックプレビュー中のため、オハイオ(us-west-2)リージョン限定で利用可能となっています。
厳密にはNetwork Firewallの機能の一部に当たりますが、役割の明確化のために分けて説明いたします。
AWS Network Firewall Proxy はいわゆるWebプロキシのように、HTTP / HTTPS通信専用のマネージドなフォワードプロキシであり、Route 53 Resolver DNS Firewall や Network Firewallと同様にアウトバウンドセキュリティに適したAWSサービスとなります。
以下の構成（Architecture overviewより引用）により使用可能であり、NATゲートウェイと統合して動作するものとなっています。
本サービスでは、以下の図（Securing Egress Architectures with Network Firewall Proxyより引用）に示すように名前解決前（Pre-DNS）、名前解決後の接続先サーバへのHTTPリクエスト（Pre-request）、HTTPレスポンス（Post-response）の3段階で評価を行い、名前解決に使用するドメイン名からL3-L7（IP / Port, HTTP / TLS ヘッダ） までの情報を評価に使用可能となります。
詳細な挙動や設計上の注意点については、こちらの記事で紹介しておりますので、是非ご参照ください。
アウトバウンドセキュリティの設計方針
セキュリティ全体としては、セキュリティ効果と運用負荷のバランスを踏まえ、以下の 3 つの方針が重要となります。
- 多層防御を活用する
- 導入コストやリスクが低く、効果の高い対策から着手する
- 最初から完璧を目指さず、運用を通じて継続的に改善する
アウトバウンドセキュリティにおける具体的な設計方針として、AWS re:Inforce 2025 - Outbound network controls made easyで紹介されている考え方に基づき、Deny List / Strict Allow List / Generous Allow List の 3 つの方針を紹介します。
Deny List （拒否リスト）
明示的に拒否する対象のみを定義する方式であり、以下のようなメリットがあります。
- 導入が容易
- AWS ではマネージドな拒否リストを利用可能
- 拒否された通信はログとして記録されるため、通信内容の分析や調査が可能（なお、ALERT を挟んだ Allow List 構成においても、同様に情報を取得可能）
一方で、悪質な宛先は無数に存在するため、全てを網羅的に拒否リストへ登録することは現実的ではありません。
そのため、未知の通信先が許可されてしまう可能性が残り、Allow List と比較するとリスク低減効果は限定的である点がデメリットとなります。
2025年に公開されたAWS Network Firewall with Active Threat Defenseでは、AWS がグローバルに展開する独自のハニーポットから収集した脅威情報を活用し、既知の悪意あるインフラに対する拒否ルールを動的に更新することが可能となっています。
これにより、従来の静的な Deny List が抱えていた運用負荷や追従性の課題を一定程度緩和できます。
また、AWS Network Firewallの地理的IPフィルタリングも、ルール管理を簡素化する観点から、同様に運用負荷の軽減に寄与する機能と言えます。
Strict Allow List （厳格な許可リスト）
明示的に許可する対象のみを定義する方式であり、以下のようなメリットがあります。
- リスク低減効果が最も高い
- 通信先の追加・変更・削除時に、設計レビューや承認といった定められた運用手順を強制しやすい
一方、デメリットとしては以下の内容が挙げられます。
許可すべき通信が限定的なサービスにおいては非常に有効な手段となりますが、多様な外部サービスやAPIと連携する必要があるシステムに対しては導入コストも高く相性が悪い方式となります。
Generous Allow List （寛容な許可リスト）
Allow List のリスク低減と Deny List の運用コストの低さを組み合わせた、最も推奨される方針となります。
AWS Network Firewallにおいては、主に以下の方針で Deny List および Allow List を構成します。
- Deny List
- Generous Allow-List
Generous Allow List では、初期段階では厳格に絞り込みすぎず、比較的寛容な範囲でドメインリストを設定します。
その上で、運用開始後に取得したログを基に継続的な評価と見直しを行い、Allow List / Deny List の精度を段階的に高めていくことが重要です。
このような運用を支援する手段として、Reporting on network traffic in Network Firewall の機能を利用することで、過去の通信ログからドメイン単位のアクセス状況を分析・可視化し、ルール設計や改善に活用することができます。
まとめ
- アウトバウンド対策は DNS / L3–7（IP / Port / TCP / HTTP / TLS ヘッダ）/ ボディ のレイヤで整理すると理解しやすい。
- AWS のマネージドな主要選択肢として、Route 53 Resolver DNS Firewall / Network Firewall / Network Firewall Proxy が挙げられる。
- 次回以降の記事で詳細検証しますが、要件に応じたAWSサービスの主軸の使い分けは以下のイメージを持っています。
- Generous Allow List を基に、まずは低コストで効果の高い対策から導入し、ログを活用しながら継続的に改善していくことが現実的である。
おわりに
本記事では、AWS におけるアウトバウンドセキュリティ全体の概要を整理しました。
今回は基礎的な内容を中心に取り上げましたが、今後は実際の設計・検証・運用を通じて、より実践的な理解を深めていきたいと思います。
執筆：@sakae.katsuto
レビュー：@nagamatsu.yuji
（Shodoで執筆されました）
