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

こんにちは！クラウドインフラの構築や、開発の現場に飛び込んだばかりの新人エンジニアの皆さん、日々の業務本当にお疲れ様です。

AWSをはじめとするクラウド環境、とっても便利ですよね。ボタン一つでサーバーが立ち上がり、世界中にサービスを公開できる。まるで夢のような魔法の道具です。でも、その魔法の道具、裏を返せば「ちょっとした設定のミスで、泥棒を我が家に招き入れてしまうリスク」も隣り合わせだったりします。

今日は、そんなクラウドの世界でよくある「VPCピアリングを介した横展開（ラテラル・ムーブメント）」という、ちょっと物騒だけど絶対に知っておかなければならないセキュリティのテーマについて、身近な例えを交えながら優しく紐解いていきたいと思います。

一歩ずつ、一緒に学んでいきましょうね！

—

1. 家の鍵に例える「VPC」と「VPCピアリング」

まずは、クラウドの基本的な仕組みを私たちの生活に置き換えて考えてみましょう。

皆さんが暮らす「家」を想像してください。この家には玄関の鍵があり、家族以外の人が勝手に入れないように守られていますよね。クラウドの世界において、この「一軒家」にあたるのが VPC（Virtual Private Cloud） です。VPCは、あなた専用の仮想的なネットワーク空間であり、外部から隔離された安全なプライベート空間になります。

さて、あなたが引っ越しをして、隣の家（別のVPC）に住むお友達と「もっと仲良くなりたい！」と思いました。毎回わざわざ外に出てインターホンを鳴らすのは面倒なので、「二人の家のベランダを直接つなぐ通路」を作りました。

この「家と家を直接つなぐ専用通路」こそが、今回のお話の主役であるVPCピアリングです。

VPCピアリングを使えば、違うネットワークにあるサーバー同士が、まるで同じ部屋にいるかのように通信できるようになります。システム連携の観点からは、非常に便利で欠かせない機能なんですよね。

—

2. 泥棒のテクニック：「横展開（ラテラル・ムーブメント）」とは？

ここで、少し嫌な想像をしてみましょう。もし、あなたの家の裏口の鍵が壊れていて、そこに泥棒が侵入してしまったらどうなるでしょうか？

泥棒はまず、玄関から入ってすぐのリビング（公開されているWebサーバー）に忍び込みます。でも、泥棒の本当の目的はそこではありません。本当に盗みたい「金庫（重要データを保存したデータベースサーバー）」は、もっと奥の部屋にあります。

しかし、もしリビングと、お隣さんの家をつなぐベランダのドアが開きっぱなしだったらどうでしょう？

泥棒はこう考えます。
「おっ、隣の家の金庫の方が警備が甘いぞ！ この通路を伝って、隣の家に忍び込んでしまおう！」

この、「最初に侵入した足がかり（Webサーバーなど）を起点にして、ネットワークのつながった別の領域へと次々に侵入を広げていく攻撃手法」を、セキュリティの世界で横展開（ラテラル・ムーブメント）と呼びます。

クラウド環境において、VPCピアリングでつながった別VPCへの対策を怠っていると、まさにこの「隣の家への侵入経路」をタダで提供してしまうことになるのです。

—

3. 防犯の基本！「セキュリティグループ」と「ネットワークACL」で部屋ごとに鍵をかける

「うわ、VPCピアリングって怖い機能なんだ……使わないほうがいいのかな？」
なんて思っちゃいましたか？ 大丈夫です、安心してください！

現実世界でも、お隣さんとベランダをつなぐのは自由ですが、ちゃんとその通路の入り口に「頑丈な鍵付きのドア」をつけておけば、泥棒は侵入できませんよね。

クラウドの世界でも同じです。ネットワークをつなぐのはいいけれど、「誰が、どこから、どこへ通っていいか」のルールを厳しく設定（マイクロセグメンテーション）してあげればいいのです。

ここで登場するのが、AWSの守りの要であるセキュリティグループとネットワークACL（NACL）です。

  • セキュリティグループ: 個別のサーバー（部屋のドア）につける警備員さん。
  • ネットワークACL: サブネット（部屋のエリア全体の門）につける門番さん。

これらを使って、「AのVPCのこのサーバーからしか、BのVPCのデータベースにはアクセスさせない！」という厳密なルール（マイクロセグメンテーション）を設計していきましょう。

—

4. 実践！安全なVPCピアリングのための設定例

それでは、実務でそのまま参考にできるTerraform（インフラをコードで管理するツール）の設定サンプルを見てみましょう。

今回は、「フロントエンド用のVPC」から「データベース用のVPC」へVPCピアリング接続を行う際、余計な通信を絶対にさせない（最小権限の原則）ための設定例です。

# ==========================================
# 1. セキュリティグループの設定（サーバーごとの門番）
# ==========================================

# データベース側VPCにあるDBサーバー用のセキュリティグループ
resource "aws_security_group" "db_server_sg" {
  name        ="db-server-security-group"
  description ="データベースサーバーへのアクセスを厳格に制限するセキュリティグループ"
  vpc_id      = aws_vpc.database_vpc.id

  # 【重要】許可するのは「フロントエンドVPCからの特定の通信（例: PostgreSQLの5432ポート）」のみ！
  # 「何でもどうぞ！」という全許可（0.0.0.0/0）は絶対に避けます。
  ingress {
    description = "フロントエンドVPCからのデータベース接続のみ許可"
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    # ここでピアリング元のVPC全体ではなく、特定のCIDR（IPアドレス範囲）を指定するのがコツです
    cidr_blocks = ["10.1.0.0/16"] 
  }

  # 外への通信（アウトバウンド）の制御も必要に応じて行います
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "DB-Server-SG"
  }
}

# ==========================================
# 2. ルートテーブルの設定（道案内の看板）
# ==========================================

# フロントエンドVPC側のルートテーブル
resource "aws_route" "frontend_to_db_peering" {
  route_table_id            = aws_route_table.frontend_rt.id
  destination_cidr_block    = "10.2.0.0/16" # データベース側VPCのネットワーク範囲
  vpc_peering_connection_id = aws_vpc_peering_connection.example.id
  
  # これにより、「あそこのデータベースへ行くには、このピアリング用の専用道路を使ってね」と案内されます
}

コードのポイント

  • cidr_blocksの限定: むやみに 0.0.0.0/0（すべての場所からのアクセス）を許可せず、必要最小限のIPアドレス範囲だけを指定しています。これがマイクロセグメンテーションの第一歩です！
  • 通信ポートの絞り込み: データベースに必要な通信（今回の例ではPostgreSQLの 5432 ポート）以外は、すべてシャットアウトするように設定しています。

—

5. まとめ：安全なクラウドインフラを目指して

今回は、VPCピアリングを介した横展開のメカニズムと、それを防ぐためのマイクロセグメンテーションの考え方を、身近な例えを交えて解説しました。

  • VPCピアリングは便利な「家と家をつなぐベランダ」のようなもの。
  • 鍵（セキュリティグループやルートテーブル）をかけ忘れると、片方のトラブルがもう片方へ一瞬で広がってしまう（横展開のリスク）。
  • 設定時は「必要な通信だけを許可する（最小権限の原則）」を徹底する。

最初は覚えることが多くて大変に感じるかもしれませんが、「自分が住む家を泥棒から守る防犯」と同じように考えると、ぐっとイメージしやすくなったのではないでしょうか？

一歩ずつ、確実になめらかなセキュア・インフラを作れるエンジニアを目指していきましょう！それでは、次回の記事もお楽しみに！

スポンサーリンク

コメント

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