【実務・中級編】プライベートサブネットの定義と外部接続の遮断 – クラウド＆コンテナネットワーク実践ガイド

はじめに：クラウド時代の「本当の要塞」をどう築くか

「プライベートサブネットを作ったから、うちのDBやバックエンドAPIはもう安全だよね？」

先日、新規プロジェクトのインフラ構成レビュー会で、若い開発者からこんな質問を受けました。私は思わず苦笑いしながら、「本当に外部から守られていると言い切れるかい？」と問い返しました。

コンソール画面で「インターネットゲートウェイ（IGW）へのルートがないサブネット」をポチポチと作成しただけで、セキュアな環境ができたと安心していませんか？現代のクラウドネットワークにおいて、プライベートサブネットの真の定義とは、単に「外から入れないこと」ではありません。「意図せぬトラフィックの漏洩を完全に防ぎつつ、必要なセキュリティ境界を厳格にコントロールすること」を指します。

今回は、AWS（VPC）やGCP（VPC）などのメガクラウド、そしてKubernetesのポッドネットワークをも見据えながら、プライベートサブネットの設計思想、パケットのルーティング、そして外部接続遮断のメカニズムを、現場のシニアエンジニアの視点から徹底的に解説します。

—

1. RFC 1918が定める「プライベート空間」の基本と落とし穴

まずは、私たちが日常的に使っているプライベートIPアドレスの基本に立ち返りましょう。IETFがRFC 1918で定義したプライベートIPアドレス空間は以下の3つです。

10.0.0.0/8 （大規模ネットワーク向け）
172.16.0.0/12 （中規模ネットワーク向け）
192.168.0.0/16 （ホームネットワーク・小規模向け）

これらはインターネット上のルーターではルーティングされない（グローバルIPとしてはルーティング不能な）アドレスです。しかし、VPC内において単にこれらのIPレンジを使っているからといって、それだけで「外部から守られている」わけではありません。

パケットはどこへ流れるべきか？

プライベートサブネットに配置されたインスタンスやコンテナが安全であるためには、パケットの出口（ルーティングテーブル）が完全に制御されていなければなりません。

パケットがたどる運命は、ルートテーブル（Route Table）のルーティングエントリによって一意に決まります。
例えば、デフォルトルート（0.0.0.0/0）の向き先がインターネットゲートウェイ（IGW）やNATゲートウェイを向いていれば、そのサブネットは実質的に「パブリック」か、あるいは「外へ出ていけるプライベート（アウトバウンド通信可能）」です。

真の意味での「外部接続を完全に遮断したプライベートサブネット（アイソレート・サブネット）」とは、デフォルトルートにインターネットへの出口を持たず、VPCの内部CIDR（例: 10.0.0.0/16）のローカル通信を除き、外部へのパスが完全に断たれたサブネットを指します。

—

2. 外部接続を完全に遮断するネットワークアーキテクチャ

インターネットからの直接到達性を完全に排除しつつ、セキュアな環境を構築するためには、以下の3つの要素を組み合わせる必要があります。

1. インターネットゲートウェイ（IGW）の不接続: サブネットに関連づけられたルートテーブルに、IGWやNATへのルートを書かない。
2. セキュリティグループ（Security Group / SG）のステートフルな制御: インスタンスレベルでのトラフィックの絞り込み。
3. ネットワークACL（NACL）のステートレスな防御: サブネット境界でのパケットフィルタリング。

典型的なルーティング構成（アイソレートサブネット）

以下は、AWSのVPCにおける完全プライベートなサブネットのルートテーブルのイメージです。

| 宛先 (Destination) | ターゲット (Target) | 説明 |
| :— | :— | :— |
| 10.0.0.0/16 | local | VPC内の通信（VPC内トラフィックは許可） |
| 0.0.0.0/0 | None (または非存在) | 外部へのデフォルトルートは存在しない |

この構成では、サブネット内のリソースからインターネットへの通信は1ビットも発信できません。同時に、インターネット側からもこのサブネット内のリソースへパケットを届けることは物理的・論理的に不可能です。

—

3. 実務で直面するジレンマ：「外部接続遮断」と「パッチ当て・API連携」

ここで実務上の大きなジレンマが発生します。
「データベースや機密APIサーバーを完全に遮断したい。しかし、OSのセキュリティパッチ（yumやapt、npmパッケージなど）はどうやって当てるのか？」「外部のSaaS型Web APIを呼び出す必要がある場合はどうするのか？」

ここで安易にNATゲートウェイを置いてしまうと、「外部からのインバウンドは遮断しつつ、アウトバウンドは許可する」状態になり、厳密な意味での完全遮断ではなくなります（データexfiltration（情報漏洩）のリスクが残ります）。

VPCエンドポイント（PrivateLink）を活用した解法

外部接続を完全に遮断しつつ、AWSのマネージドサービス（S3、DynamoDB、Secrets Managerなど）や、外部のセキュアなWeb APIと通信するためには、VPCエンドポイント（AWS PrivateLink / GCP Private Service Connect）を使用します。

これにより、パケットはインターネットを経由せず、クラウドプロバイダーのバックボーンネットワーク内（プライベートIP空間）だけでルーティングされます。

Terraformによる完全プライベートなS3エンドポイントの定義例

インフラストラクチャ・アイズ・コード（IaC）として、インターネットを経由せずにセキュアにS3へアクセスするVPCエンドポイント（Gateway型）の設定例を見てみましょう。

# プライベートサブネット用のルートテーブル
resource "aws_route_table" "isolated_private" {
  vpc_id = aws_vpc.main.id

  # デフォルトルートはあえて設定しない（外部への出口を完全に断つ）
  
  tags = {
    Name = "isolated-private-rt"
  }
}

# S3へのVPCエンドポイント（Gateway型）の定義
# これにより、インターネットを経由せずプライベートネットワーク経由でS3にアクセス可能になる
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = aws_vpc.main.id
  service_name = "com.amazonaws.us-east-1.s3"
  
  route_table_ids = [aws_route_table.isolated_private.id]

  tags = {
    Name = "s3-vpc-endpoint"
  }
}

この設定により、0.0.0.0/0 のルートがなくても、アプリケーションはプライベートなルーティング経由で安全にS3と通信できます。

—

4. コードからの接続テストとデバッグ手法

完全プライベートサブネット上にデプロイされたアプリケーション（例えば、PythonやNode.jsで書かれたバックエンドAPI）から外部への接続遮断、および内部通信の挙動を確認するためのコード例とデバッグ手順です。

Pythonによる疎通確認スクリプト（check_connectivity.py）

実務の現場では、コンテナやインスタンスにログインして curl を叩く前に、アプリケーションコードレベルで意図した通信制御ができているかをテストします。

import urllib.request
import urllib.error
import socket

def test_connectivity():
    # 1. 許可されている内部サービス（例: 内部DBやプライベートエンドポイント）への接続テスト
    internal_target = "internal-db.local:5432"
    print(f"[*] 内部サービスへの接続テスト: {internal_target}")
    try:
        # タイムアウトを3秒に設定してソケット接続を確認
        socket.create_connection(("10.0.1.50", 5432), timeout=3)
        print("[+] 成功: 内部サービスへのルーティングは正常です。")
    except socket.error as e:
        print([-] 失敗（または異常）: 内部接続エラー -> {e}")

    # 2. ブロックされているべき外部インターネット（例: パブリックなWeb API）への接続テスト
    external_url = "https://api.ipify.org?format=json"
    print(f"\n[*] 外部インターネットへの接続テスト（遮断されているべき）: {external_url}")
    
    try:
        # 完全プライベートサブネットであれば、ここでタイムアウトするかルーティングエラーになるはず
        req = urllib.request.Request(external_url)
        with urllib.request.urlopen(req, timeout=3) as response:
            body = response.read().decode('utf-8')
            print(f"[-] 警告: 外部接続が通ってしまいました！ レスポンス: {body}")
    except (urllib.error.URLError, socket.timeout) as e:
        print(f"[+] 期待通り: 外部への通信は正常に遮断されています。 (エラー内容: {e})")

if __name__ == "__main__":
    test_connectivity()

トラブルシューティングの現場Tips：なぜか通信できてしまうときの原因

もし上記のスクリプトで、完全プライベートサブネットにいるはずなのに「外部接続が通ってしまった」場合、シニアエンジニアが疑うべきポイントは以下の3つです。

1. ルートテーブルの勘違い: 実はそのサブネットに 0.0.0.0/0 -> nat-xxxxxxxx のルートが残っていた。
2. プロキシサーバーの存在: 環境変数（HTTP_PROXY, HTTPS_PROXY）が設定されており、踏み台プロキシ経由で外に出てしまっている。
3. ENI（Elastic Network Interface）のマルチホーム: インスタンスに複数のネットワークインターフェースがアタッチされており、パブリックなサブネット側のNICからパケットが送出されている。

Linuxのコマンドラインでデバッグを行う際は、ip route get コマンドを使ってパケットがどのインターフェースからどのゲートウェイに向かおうとしているかを必ず確認しましょう。

# パケットのルーティングパスを検証する
ip route get 8.8.8.8
# 期待される出力例（ルートがない場合）:
# RTNETLINK answers: Network is unreachable

この Network is unreachable という冷徹なエラーメッセージこそが、私たちインフラエンジニアがプライベートサブネットの安全性を確信する最高の瞬間なのです。

—

おわりに：セキュアなネットワークは一日にしてならず

プライベートサブネットの定義と外部接続の遮断は、クラウドインフラのセキュリティにおける最も基礎的でありながら、最も妥協してはいけない防壁です。「動けばいいや」と安易にNATゲートウェイや不要なルーティングを追加してしまうと、将来的にマルウェアの侵入やデータ流出といった致命的なインシデントを引き起こす原因になります。

パケットの流れる先を頭の中で完全にシミュレーションし、コードと設定の整合性を厳しく保つこと。それこそが、モダンなSREやクラウドアーキテクトに求められるプロフェッショナルな姿勢です。

明日、あなたの担当するVPCのルートテーブルを、もう一度冷静に見直してみませんか？