【テクニカル・上級編】クラウド環境におけるVPCピアリングを介した横展開(Lateral Movement) – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

VPCピアリングは「信頼の境界」か、それとも「侵入の高速道路」か

クラウドアーキテクトが最も陥りやすい罠がある。それは、「VPCピアリングは同じAWSアカウント（あるいは組織）内にあるのだから、基本的には安全である」という、根拠なき性善説に基づいた設計だ。

しかし、レッドチームの視点から言えば、VPCピアリングは単なるネットワーク接続ではない。それは、「境界防御が物理的に崩壊した後の、内部ネットワークにおける横展開（Lateral Movement）の最速ルート」に他ならない。

1. ピアリングが孕むアーキテクチャの盲点

VPCピアリングを構成する際、多くのエンジニアはセキュリティグループ（SG）の「ソース」に「別のVPCのCIDR」を指定することで満足する。だが、これはネットワークACL（NACL）とSGのレイヤリングを理解していない証左だ。

攻撃者は、侵害したインスタンスのメタデータサービス（IMDSv2）を叩き、IAMロールを奪取する。そこから何をするか？ピアリング先のVPCのサブネットに対してポートスキャンを仕掛け、ターゲットを探す。もし、ピアリング先のSGが「同じセキュリティグループIDを許可」している場合、攻撃者はそのインスタンスになりすますことで、認証をバイパスするケースすらある。

攻撃者が狙うプロトコル構造の隙間

通信プロトコルそのものの脆弱性よりも、クラウドの「抽象化されたネットワーク」の設計ミスを突く方が圧倒的に効率がいい。特に、UDPベースのサービスや、内部で稼働している古いRPC（Remote Procedure Call）のバッファオーバーフローを突く手法は、依然として現役だ。

2. セキュリティグループとNACLの「多層防御」を再定義する

多くの現場では、SGに依存しすぎてNACLを「デフォルト（全許可）」のまま放置している。これは非常に危険だ。NACLはステートレスであり、パケットの入出力を厳密に制御できる。

実践的なアーキテクチャ設計（Terraform例）

以下は、ピアリング接続に対して最小権限の原則を適用した設定例だ。

# ピアリング経由の通信を許可するが、NACLでプロトコルとポートを固定する
resource "aws_network_acl" "main_nacl" {
  vpc_id = aws_vpc.main.id

  # ピアリング経由のインバウンド制御：特定のポート以外は拒否する
  ingress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "10.0.0.0/16" # ピアリング先のCIDR
    from_port  = 443
    to_port    = 443
  }

  # ステートレスなNACLの特性上、エフェメラルポートの戻り通信も許可が必要
  egress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "10.0.0.0/16"
    from_port  = 1024
    to_port    = 65535
  }
}

この設定の肝は、「ピアリング先の全通信を許可する」という怠惰なセキュリティグループルールを廃止し、NACLでネットワークレベルのパケットフィルタリングを強制する点にある。

3. 生成AI時代の新たな脅威：プロンプトインジェクションとネットワーク

最近のトレンドとして、LLMを搭載した内部APIサーバーがピアリング先のDBにアクセスするケースが増えている。ここで発生するのが、「プロンプトインジェクションによる内部SQLインジェクション」だ。

攻撃者がWebフロントエンドに悪意あるプロンプトを注入し、バックエンドのLLMが意図しないクエリをピアリング先のデータベースに投げる。これが成立すると、ネットワーク境界（SG/NACL）は無力化される。なぜなら、通信自体は「許可された正当な経路」を通っているからだ。

防御層（ガードレイル）の設計指針

通信の認可（Authorization at Application Layer）: ネットワークレベルの許可だけでなく、JWTやMutual TLS (mTLS) を用いて、サービス間通信自体に強力な署名を要求する。
ガードレイルの配置: APIゲートウェイとアプリケーションの間に、プロンプトの妥当性を検証する中間層を挟む。
最小特権ロールの徹底: ピアリング先のデータベースへアクセスするIAMロールは、特定のテーブル、特定のクエリのみを許可する最小限の権限に絞る。

4. 結び：レッドチームからの提言

ペネトレーションテストの現場で、私は「ネットワーク的に繋がっているか？」よりも「その先で、信頼の連鎖がどこで切れているか？」を真っ先に確認する。

VPCピアリングは便利だが、それは「信頼の拡張」であると同時に、「攻撃のベクトルの拡張」でもある。今日から、クラウドの管理コンソールを開き、すべてのピアリング接続に対して「本当にその通信が必要か？」「NACLで厳格に絞り込んでいるか？」を自問自答してほしい。

セキュリティは静的な設定ではない。攻撃者の思考を先回りし、動的に防御を更新し続けるエンジニアだけが、この荒野を生き残ることができる。