VPC多層防御設計 — ネットワークセキュリティの実践パターン

多層防御（Defense in Depth）の概念

単一の防御ラインではなく、複数の独立したセキュリティ層を設ける。
各層が侵害されても次の層で食い止める設計。

AWSネットワーク多層防御の層:
  Layer 1: CloudFront + WAF（エッジでのフィルタリング）
  Layer 2: AWS Shield（DDoS保護）
  Layer 3: ALB（L7トラフィック処理）
  Layer 4: セキュリティグループ（ステートフルFW）
  Layer 5: NACL（ステートレスFW、サブネットレベル）
  Layer 6: AWS Network Firewall（高度なL7フィルタリング）
  Layer 7: アプリケーション認証・認可

標準的なVPCセキュリティ設計

インターネット
  ↓
CloudFront（WAF統合）
  ↓
パブリックサブネット（ALB、NAT GW）
  ↓
プライベートサブネット（アプリケーション層）
  ↓
データサブネット（RDS、ElastiCache）

サブネット分離の原則:
  パブリックサブネット: インターネットからアクセスが必要なリソースのみ
  プライベートサブネット: アプリケーション、コンテナ
  データサブネット: DB、キャッシュ（完全プライベート）

セキュリティグループ（SG）の設計

SGのベストプラクティス:
  → 最小権限: 必要なポート・送信元のみ許可
  → SG参照: IPではなく別SGを送信元として指定
  → 送信ルール: アウトバウンドも絞る（デフォルトは全許可）
  → 命名規則: sg-[service]-[tier]（例: sg-webapp-app）

# 多層SGの設計例
# ALB SG
aws ec2 create-security-group --group-name sg-alb --description "ALB SG" --vpc-id vpc-xxx
aws ec2 authorize-security-group-ingress --group-id sg-alb --protocol tcp --port 443 --cidr 0.0.0.0/0

# アプリSG（ALB SGからのみ許可）
aws ec2 create-security-group --group-name sg-app --description "App SG" --vpc-id vpc-xxx
aws ec2 authorize-security-group-ingress --group-id sg-app --protocol tcp --port 8080 --source-group sg-alb

# DB SG（アプリSGからのみ許可）
aws ec2 create-security-group --group-name sg-db --description "DB SG" --vpc-id vpc-xxx
aws ec2 authorize-security-group-ingress --group-id sg-db --protocol tcp --port 5432 --source-group sg-app

NACL の活用（サブネットレベルの制御）

NACLの使いどころ（SGを補完）:
  1. 特定のIPアドレスブロックを明示的に拒否
     → 攻撃元IPを素早くブロック（SGは拒否ルール不可）
  
  2. エフェメラルポートの制御（注意が必要）
     → TCPレスポンスにエフェメラルポート（1024-65535）が必要
     → NACLはステートレスのためアウトバウンドルールに許可が必要
  
  3. サブネット全体への強制適用
     → 誤設定されたSGをNACLでカバー

NACL ルール例（プライベートサブネット）:
  インバウンド:
    100  TCP 8080  10.0.0.0/24（パブリックサブネット） ALLOW
    200  TCP 1024-65535  0.0.0.0/0 ALLOW（エフェメラルポート）
    900  ALL 203.0.113.0/24 DENY（攻撃元IPをブロック）
    *    ALL 0.0.0.0/0 DENY（暗黙的）
    
  アウトバウンド:
    100  TCP 5432  172.16.0.0/24（データサブネット） ALLOW
    200  TCP 443  0.0.0.0/0 ALLOW（HTTPS送信）
    300  TCP 1024-65535  10.0.0.0/24 ALLOW（エフェメラルポート応答）
    *    ALL 0.0.0.0/0 DENY

AWS Network Firewall

VPC内のトラフィックをL7レベルで検査する高度なファイアウォール。

# Network Firewall の作成
aws network-firewall create-firewall \
  --firewall-name my-vpc-firewall \
  --firewall-policy-arn arn:aws:network-firewall:...:firewall-policy/my-policy \
  --vpc-id vpc-xxx \
  --subnet-mappings '[{"SubnetId": "subnet-firewall-aaa"}]'

Network Firewallの機能:
  → ステートフルな深パケット検査（DPI）
  → ドメイン名フィルタリング（example.com をブロック）
  → TLSインスペクション
  → Suricataルールによるシグネチャ検知
  → VPCエンドポイントとして配置
  
Network Firewallが必要なケース:
  → アウトバウンドトラフィックを特定ドメインのみに制限
  → C2（コマンド＆コントロール）通信の検知・ブロック
  → 高度なインバウンドフィルタリング

踏み台サーバーの廃止（SSM Session Manager）

従来: 踏み台サーバー（Bastion Host）でSSH接続
  → 踏み台サーバーの管理が必要
  → SSHポート22を開放（攻撃面）
  → キーペア管理のリスク

現在推奨: SSM Session Manager
  → ポート開放不要（SSMエージェントがAWS側に通信）
  → IAMで接続権限を管理
  → 操作ログをCloudTrail/S3/CloudWatch Logsに記録
  → EC2インスタンスにSSMエージェントが必要

# SSM Session Managerで接続（ポート開放不要）
aws ssm start-session --target i-xxx

# SSHポートフォワーディング経由の安全なDB接続
aws ssm start-session \
  --target i-xxx \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["rds.xxx.ap-northeast-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

試験頻出ポイント

シナリオ	回答
特定のIPをネットワークレベルでブロック	NACL（拒否ルール）またはNetwork Firewall
サブネット間の通信をL7で制御	AWS Network Firewall
踏み台サーバー不要でEC2に接続	SSM Session Manager
アウトバウンドを特定ドメインのみ許可	AWS Network Firewall（ドメインフィルタリング）
複数層のトラフィック制御	SG（ステートフル）+ NACL（ステートレス）の組み合わせ

まとめ

VPCの多層防御はCloudFront+WAFでのエッジフィルタリング、セキュリティグループ+NACLによる多層ネットワーク制御、Network Firewallによる高度なL7検査を組み合わせて構成する。踏み台サーバーはSSM Session Managerに置き換えることで攻撃面を削減できる。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感