【実務・中級編】 プライベートサブネットの定義とセキュリティ分離の原則 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは。シニアSREの私だ。夜中に鳴り響くPagerDutyのアラート、そして「なぜかデータベースに直接アクセスできない」という若手からの焦ったSlack。君も一度は経験があるはずだ。

クラウドインフラの設計において、AWSのVPC（Virtual Private Cloud）を構築する際、パブリックサブネットとプライベートサブネットを分けることは、もはや呼吸をするのと同じくらい当たり前のプラクティスとなっている。しかし、「なぜプライベートサブネットに配置するのか」「インターネットからのアクセスをどうやって完全にシャットアウトしつつ、必要な安全性を担保するのか」というパケットレベルの挙動や設計思想の本質について、どれだけ自信を持って語れるだろうか。

今回は、実務の現場でWeb APIやバックエンドインフラを設計・運用するエンジニアに向けて、プライベートサブネットの定義、セキュリティ分離の原則、そしてパケットがルーティングされる実際のフローを、私の泥臭い経験を交えて徹底的に解説しよう。

—

1. プライベートサブネットとは何か？ その設計思想の根底にあるもの

インターネットという広大で危険な荒野に、自社の心臓部であるデータベースや機密性の高いバックエンドAPIを直接露出させる――これは、玄関の鍵を開け放したままリビングに金庫を置くようなものだ。

プライベートサブネットの定義は極めてシンプルである。それは、「AWSのインターネットゲートウェイ（IGW）への直接のルーティングを持たないサブネット」を指す。

セキュリティ分離の原則（Defense in Depth）

クラウドセキュリティの基本は「多層防御（Defense in Depth）」だ。万が一、フロントエンドのWebサーバー（パブリックサブネットに配置）がゼロデイ脆弱性やアプリケーションの不備によって踏み台にされたとしても、バックエンドのデータベース（プライベートサブネット）へ直接アクセスできなければ、被害を最小限（Blast Radiusの縮小）に食い止めることができる。

ネットワークレイヤーにおけるこの物理的・論理的な分離こそが、クラウドアーキテクチャにおける最後の砦となるのだ。

—

2. ルートテーブルとパケットの運命：通信フローの全体像

「プライベート」という名前がついているからといって、そのサブネットが外部の世界と完全に絶縁されているわけではない点に注意してほしい。アプリケーションのパッチ適用や外部SaaSとの連携のために、アウトパウンド（外向き）の通信が必要になるケースは多々ある。

ここで、パケットがどのようにルーティングされるのか、そのライフサイクルをシーケンスで見てみよう。

パケットルーティングのシーケンス

[プライベートサブネット内のECS/EC2]
       │
       ▼ (宛先がインターネット 0.0.0.0/0 のパケットを送出)
[プライベート用ルートテーブル]
       │
       ├─ (ローカル通信: 10.0.0.0/16 など) ──> [VPC内へ直接ルーティング]
       │
       └─ (外部通信: 0.0.0.0/0) ──────────> [NATゲートウェイ (パブリック側)]
                                                    │
                                                    ▼ (送信元IPをパブリックIPに変換/SNAT)
                                            [インターネットゲートウェイ (IGW)]
                                                    │
                                                    ▼
                                            [パブリックなインターネット]

このフローにおいて最も重要なのは、「外から中への通信（Inbound）は絶対に拒絶しつつ、中から外への通信（Outbound）のみをNATゲートウェイ経由で許可する」という非対称なトラフィック制御の実現だ。

ルートテーブルの設定例（Terraform）

実務でInfrastructure as Code（IaC）を書く際、プライベートサブネットのルートテーブルは以下のように定義する。余計なルートを一切持たせないことが、堅牢なインフラを作るコツだ。

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

  # 外部への通信はすべてNATゲートウェイに転送する
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }

  tags = {
    Name        = "prod-private-rt"
    Environment = "production"
  }
}

# プライベートサブネットとルートテーブルの関連付け
resource "aws_route_table_association" "private_us_east_1a" {
  subnet_id      = aws_subnet.private_a.id
  route_table_id = aws_route_table.private.id
}

この設定により、aws_subnet.private_a に属するインスタンスからはインターネットへ出られるが、インターネット上の任意のホストからこのインスタンスのプライベートIPへ直接パケットを到達させることは物理的に不可能になる。

—

3. 実務で直面する罠：セキュリティグループとNACLの二重防壁

サブネットを分けただけでは十分ではない。AWSにはパケットをフィルタリングする仕組みが2つ存在する。セキュリティグループ（SG）とネットワークACL（NACL）だ。

現場のトラブルシューティングで最も多いのが、「プライベートサブネットにあるDBに接続できない！」という叫びだ。大抵の場合、原因はこの2つのどちらかの設定ミスにある。

  • セキュリティグループ（ステートフル）: インスタンス（ENI）単位で適用される。インバウンドを許可すれば、対応するアウトパウンドは自動的に許可される。
  • ネットワークACL（ステートレス）: サブネット単位で適用される。インバウンドとアウトパウンドのルールを両方明示的に書く必要がある。

Pythonによるデータベース接続テストのコード例

プライベートサブネット内に配置されたRDS（PostgreSQLなど）へ、アプリケーションサーバーから正しく疎通ができるか確認するための実用的なPythonスクリプトを提示しよう。現場でデバッグする際、手元にこういうスクリプトがあると非常に重宝する。

import os
import sys
import psycopg2
from psycopg2 import OperationalError

def test_database_connection():
    # 環境変数からデータベースの接続情報を取得
    # プライベートサブネット内では、RDSのエンドポイント（内部DNS名）を指定する
    db_host = os.getenv("DB_HOST", "prod-db-instance.c1234567890.us-east-1.rds.amazonaws.com")
    db_name = os.getenv("DB_NAME", "app_production")
    db_user = os.getenv("DB_USER", "app_user")
    db_password = os.getenv("DB_PASSWORD", "secret_password")
    db_port = os.getenv("DB_PORT", "5432")

    print(f"Connecting to database at {db_host}:{db_port}...")

    try:
        connection = psycopg2.connect(
            host=db_host,
            database=db_name,
            user=db_user,
            password=db_password,
            port=db_port,
            connect_timeout=5 # タイムアウトを5秒に設定し、ハングを防ぐ
        )
        
        cursor = connection.cursor()
        cursor.execute("SELECT version();")
        db_version = cursor.fetchone()
        
        print("SUCCESS: Database connection established successfully!")
        print(f"PostgreSQL Version: {db_version[0]}")
        
        cursor.close()
        connection.close()
        
    except OperationalError as e:
        print("ERROR: Failed to connect to the database.", file=sys.stderr)
        print(f"Details: {e}", file=sys.stderr)
        print("Tips: Check if the Security Group allows inbound traffic on port 5432 from the App Server SG.", file=sys.stderr)
        sys.exit(1)

if __name__ == "__main__":
    test_database_connection()

もしこのスクリプトがタイムアウトエラーを吐く場合、パケットはプライベートサブネットの壁で途絶えている。AWSコンソールを開き、RDS側のセキュリティグループがアプリケーションサーバーからのTCP/5432を許可しているか、今一度確認してほしい。

—

4. シニアからの実践的なTips：VPCエンドポイントの活用

プライベートサブネット運用において、もう一つ知っておくべき重要事項がVPCエンドポイント（AWS PrivateLink）だ。

初期のクラウド設計では、プライベートサブネットからS3やDynamoDB、AWS Secrets ManagerなどのマネージドサービスにアクセスするためだけにNATゲートウェイを経由させ、多額のデータ転送費用（NAT Gatewayの処理課金）に泣かされるチームが後を絶たなかった。

プライベートサブネットのセキュリティ分離の原則を維持しつつ、コストを最適化するには、Gateway型またはInterface型のVPCエンドポイントを必ず導入すべきだ。

AWS CLIによるVPCエンドポイント確認コマンド

現在のVPCにS3用のエンドポイントが正しくルーティングされているか確認するには、以下のコマンドを叩く。

# 特定のVPCに紐づくVPCエンドポイントの一覧を取得する
aws ec2 describe-vpc-endpoints \
    --filters "Name=vpc-id,Values=vpc-0123456789abcdef0" \
    --query "VpcEndpoints[*].{Id:VpcEndpointId,Service:ServiceName,Type:VpcEndpointType}" \
    --output table

出力結果に com.amazonaws.us-east-1.s3 のようなエンドポイントが存在し、プライベートサブネットのルートテーブルにそのプレフィックスリストが登録されていれば、パケットはインターネット（NATGW）に出ることなく、AWSのバックボーンネットワーク内だけで安全かつ高速にS3と通信できる。これぞプロのアーキテクチャだ。

—

まとめ

プライベートサブネットの定義とセキュリティ分離の原則は、単に「外から見えなくする」という消極的な防御ではない。

1. 不要なインバウンドトラフィックを完全に遮断するルーティングの徹底
2. セキュリティグループとNACLを正しく理解した多層防御の構築
3. VPCエンドポイントを活用した、セキュアかつコスト効率の高い内部通信の担保

これらを網羅して初めて、夜中に起こされない強靭なクラウドインフラが完成する。
今日の学びを、次のインフラ設計やコードレビューにぜひ役立ててほしい。君の健闘を祈る！

スポンサーリンク

コメント

タイトルとURLをコピーしました