【入門編】セキュアなアウトバウンドフィルタリングと宛先ドメインベース制御 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！SREとしてクラウドのインフラやKubernetesのネットワーク基盤を日々いじり倒している筆者です。

クラウドの世界へ足を踏み入れたばかりの頃、「プライベートサブネットにあるサーバーから外部へ安全に通信させたい」「でも、どこへでも自由に通信できるのはセキュリティ上、夜も眠れないくらい怖い…」そんなモヤモヤを抱えたことはありませんか？

教科書を開くと、NATゲートウェイやらプロキシサーバーやら、初学者泣かせのカタカナ用語が並んでいて、思わずそっとブラウザを閉じたくなる気持ち、痛いほどよく分かります。

今回は、そんなインフラ初学者のあなたに向けて、パケットがネットワークを駆け巡るリアルな挙動を身近な例え話に置き換えながら、セキュアなアウトバウンド（外向き）通信の仕組みを一緒に解き明かしていきましょう！一歩ずつ丁寧に解説するので、リラックスしてついてきてくださいね。

—

1. そもそもプライベートサブネットってどんな場所？

まずは、私たちのサーバーが暮らす「お部屋」の話から始めましょう。

クラウド（AWSやGCPなど）の中には、インターネットの荒波に直接さらされる「パブリックサブネット」と、外の世界から完全に隔離された安全な「プライベートサブネット」が存在します。

郵便局員とマンションの住民に例えてみよう

パブリックサブネット（1階の窓口）: 道路に面していて、誰でも出入りできる場所です。ここにいるサーバーには外から直接手紙（リクエスト）を届けることができます。
プライベートサブネット（要塞マンションの奥深く）: 外の道路からは直接見えない、セキュリティ万全の居住エリアです。外の世界の人間が勝手に入ってくることはできません。

「じゃあ、プライベートサブネットにいるサーバーは、外の世界（例えば、OSのアップデートをダウンロードしたり、外部のAPIを叩いたり）と一切お話しできないの？」と思いますよね。

ここで登場するのが、おなじみの NATゲートウェイ です。

—

2. NATゲートウェイは「外の世界へ行くための専用おつかい窓口」

プライベートサブネットのサーバーが外へ出たいとき、勝手に外の道路へ飛び出すことはできません。そこで、境界線にある「おつかい窓口」である NATゲートウェイ に頼みごとをします。

サーバーが「これ買ってきて！」と手紙を NATゲートウェイ に渡すと、NATゲートウェイ は自分の住所（グローバルIPアドレス）に書き換えて、外のインターネットへ買い出しに行ってくれるのです。

ここに大きなセキュリティの罠がある！

この NATゲートウェイ、非常に便利なのですが、「頼まれたものを何でも買ってきてしまう」という素直すぎる性格をしています。

もし、プライベートサブネットで動いているアプリケーションが何らかの脆弱性を突かれ、悪意あるハッカーに乗っ取られてしまったらどうなるでしょう？
ハッカーは NATゲートウェイ を踏み台にして、世界中にある怪しい司令塔サーバー（C2サーバー：Command and Controlサーバー）と通信し、大切なデータを盗み出してしまうかもしれません。

「外へ通信はさせたいけれど、怪しい宛先には一歩も行かせたくない！」
この切実な願いを叶えるのが、今回主役となる「宛先ドメインベースのフィルタリング」です。

—

3. 宛先ドメインベースのフィルタリングとプロキシの連携

IPアドレスベースの制限（例：「このIPからの通信だけ許可する」など）は、相手のサーバーのIPが変わるとすぐに破綻してしまいます。今のインターネットの世界では、1つのサービスが裏側で何百ものIPアドレスを持っていますからね。

そこで登場するのが、フォワードプロキシ（中継サーバー）です。

「優秀なコンシェルジュ」を挟もう

郵便の例えをもう一度使います。
プライベートサブネットのサーバーが直接外に行くのではなく、間に「超優秀なコンシェルジュ（プロキシサーバー）」を配置します。

1. サーバーは、外へ手紙を出すとき、宛先のドメイン名（例: api.github.com など）をコンシェルジュに伝えます。
2. コンシェルジュは、ホワイトリスト（許可リスト）を確認します。「おっ、このドメインは社内規程で許可されている正規の宛先だな」と確認できたら、代わりに外へ通信しに行きます。
3. もし、裏で乗っ取りを受けたサーバーが evil-c2-server.com のような怪しい宛先を指定したら……コンシェルジュは「申し訳ありません、この宛先への取り次ぎはお断りしております！」とバッサリ切り捨てる（ブロックする）わけです。

—

4. 実践！Squidプロキシを使ったドメインフィルタリングの設定例

百聞は一見に如かず。実際にインフラの現場でよく使われるオープンソースのプロキシソフト Squid を使って、特定のドメインだけに通訳・制限をかける設定を見てみましょう。

「設定ファイル」という言葉に身構える必要はありません。日本語のコメントを読みながら、流れを掴んでいきましょう。

# /etc/squid/squid.conf の設定イメージ

# 1. 社内からプロキシへのアクセスを許可するネットワークの定義
acl my_private_network src 10.0.0.0/16

# 2. 許可したい宛先ドメインのリスト（ホワイトリスト）を定義
acl allowed_domains dstdomain .github.com .amazonaws.com .letsencrypt.org

# 3. 許可されたポート番号の定義（基本はWeb通信の 80 と 443）
acl Safe_ports port 80
acl Safe_ports port 443
http_access deny !Safe_ports

# 4. 【ここがキモ！】プライベートネットワークからの通信かつ、
# 許可されたドメインへの通信だけを「許可（allow）」する
http_access allow my_private_network allowed_domains

# 5. 上記以外のすべての通信は「拒否（deny）」する
http_access deny all

# プロキシが待ち受けるポート番号
http_port 3128

設定のポイントを優しく解説！

acl allowed_domains: ここに書かれているドメイン（.github.com など）の先にあるサーバーにしか通信が通らなくなります。ドメインの頭にドット（.）をつけることで、そのサブドメイン（api.github.com や raw.github.com など）もまとめて許可することができます。
http_access deny all: リストに載っていない宛先への通信は、容赦なくシャットアウトします。これがセキュアなアウトバウンド制御の要です。

—

5. クラウド（AWS）での実際のアーキテクチャ構成

実際のAWS環境では、この仕組みを以下のように美しく配置します。

[プライベートサブネット]
  |
  +-- アプリケーションサーバー (例: 10.0.1.10)
        |
        | (HTTP/HTTPSの宛先をプロキシへ向ける)
        v
[プロキシサーバー（Squid等）を置いたサブネット、または専用EC2]
        |
        | (許可されたドメインの通信だけを外へ流す)
        v
[NATゲートウェイ]
        |
        v
    [インターネット（外部APIやOSアップデート元）]

サーバーの環境変数（http_proxy や https_proxy）にプロキシサーバーのIPとポート（例: http://10.0.2.100:3128）を設定しておくだけで、アプリケーション側は意識することなく安全な通信経路を通ることができます。

—

クラウドやKubernetesのネットワークの世界は、最初は複雑なパズルに見えますが、一つひとつのコンポーネントが持つ「役割（誰が、どこへ、どうやって）」を整理していくと、とてもロジカルで美しい仕組みの上に成り立っていることが分かります。

「安全性を高めたいけれど、どこから手を付ければいいかわからない」と悩んだときは、ぜひ今回紹介した「おつかい窓口と優秀なコンシェルジュ」のアイデアを思い出してみてくださいね。

それでは、また次回の技術解説でお会いしましょう！SREライフを一緒に楽しんでいきましょう！