「NATゲートウェイを通せば安心」は幻想だ。アウトバウンド通信の出口戦略を再考する
クラウドネイティブな環境で、プライベートサブネットに配置したアプリケーションから外部APIを叩くとき、皆さんはどうしていますか？
「NATゲートウェイ（NAT GW）を置いておけばOK。あとはセキュリティグループでインバウンドを絞れば万全だ」
もしそう考えているなら、少し立ち止まってください。それは「家中の鍵をかけておきながら、窓を全開にして泥棒を招き入れている」のと同じかもしれません。NAT GWは確かに通信の「出口」ですが、それはあくまでIPベースのルーティングを行うだけの黒子に過ぎません。
今回は、C2サーバー（Command & Control）への不正通信や、意図しないデータ流出を水際で防ぐための、ドメインベースのアウトバウンドフィルタリングについて、現場の泥臭い実体験を交えて解説します。
—
なぜNAT GWだけでは不十分なのか
NAT GWの役割はシンプルです。プライベートIPをパブリックIPに変換し、ルーティングテーブルに従ってパケットをインターネットへ送り出すこと。
ここで恐ろしいのは、「NAT GWはL7（アプリケーション層）の内容を一切気にしない」という点です。
例えば、攻撃者があなたのサーバーに侵入し、バックドアを仕掛けたとしましょう。そのバックドアが malicious-attacker.com に向かってデータを送信しようとしたとき、NAT GWは「あ、これ通信経路の宛先だね、はいどうぞ」とパケットを通します。IPアドレスがブラックリストに入っていない限り、この通信は止まりません。
実務で求められるのは、「特定のFQDN以外への通信は、問答無用で遮断する」というホワイトリスト方式の出口制御です。
—
アーキテクチャの解：フォワードプロキシの導入
この要件を満たす最も堅牢な方法は、プライベートサブネットとNAT GWの間に、「出口専用のフォワードプロキシ」を配置することです。
全体像
1. App Server: https://api.trusted-service.com への通信をプロキシに投げる。
2. Egress Proxy: 送信先ドメインがホワイトリストに含まれるか検証。
3. NAT GW: 許可された通信のみをインターネットへ転送。
この構成により、アプリケーションからのリクエストは必ずプロキシの検閲を通ることになります。
—
実践：Squidによるドメインフィルタリング設定
現場でよく使われるプロキシサーバー Squid を例に、特定のドメインのみを許可する設定を見てみましょう。
/etc/squid/squid.conf に以下のように記述します。
# 許可するドメインリストを定義
acl whitelist dstdomain .trusted-api.com .github.com
# ホワイトリスト以外へのアクセスを遮断
http_access deny !whitelist
http_access allow whitelist
# 透過プロキシとしてではなく、明示的プロキシとして動作させる
http_port 3128これで、このプロキシを経由する通信は trusted-api.com 関連以外、全て 403 Forbidden を返すようになります。
—
アプリケーションコードからの呼び出し方
インフラでプロキシを立てたら、次はアプリ側です。環境変数 HTTPS_PROXY を設定するのが最もスマートな方法です。
Pythonでの実装例
requests ライブラリを使用する場合、環境変数を読み込んで自動的にプロキシを経由してくれます。
import os
import requests
# 実行環境で HTTPS_PROXY を設定しておく
# export HTTPS_PROXY="http://proxy-server.internal:3128"
def call_external_api():
url = "https://api.trusted-service.com/v1/data"
try:
# プロキシ経由でリクエストが飛ぶ
response = requests.get(url, timeout=5)
response.raise_for_status()
return response.json()
except requests.exceptions.ProxyError as e:
print(f"プロキシによる遮断または接続エラー: {e}")
except Exception as e:
print(f"予期せぬエラー: {e}")
print(call_external_api())—
トラブルシューティングの勘所
この構成を導入すると、現場で必ずと言っていいほど「通信が繋がらない！」というアラートが上がります。その際、SREが確認すべき順序は以下の通りです。
1. DNS解決はできているか？:
curl -v を叩いて、DNSの名前解決がプロキシを経由しているか確認してください。
2. 接続先がIPで指定されていないか？:
コード内で https://1.2.3.4/api/... のように直接IPを指定していると、dstdomain によるフィルタリングが効きません。必ずドメイン名でアクセスするよう改修が必要です。
3. ログの確認:
/var/log/squid/access.log を tail -f で監視しながら通信を飛ばします。
TCP_DENIEDが出ていれば、ホワイトリスト漏れです。TCP_MISSであれば、プロキシの出口（NAT GW）やセキュリティグループの問題です。
—
まとめ：ゼロトラストの第一歩
「境界防御」は終わったと言われて久しいですが、クラウドのネットワーク設計においては、依然として「出口の制御」が最もコストパフォーマンスの高いセキュリティ施策です。
ドメインベースのフィルタリングは、最初は面倒に感じるかもしれません。しかし、万が一の侵害が発生したとき、不正なアウトバウンド通信を1バイトも外に出さない強固な障壁が、あなたのサービスと信頼を守り抜きます。
「NAT GWを通したから安心」という油断を捨て、プロキシという名の「検問所」を設置する。これこそが、信頼性の高いシステムを運用するSREのたしなみです。
皆さんのインフラにも、ぜひこの「出口戦略」を取り入れてみてください。運用が落ち着いた頃、ログの中に「遮断された不正な試行」を見つけるたび、きっとこの設計のありがたみを感じるはずです。
コメント