VPCピアリング接続のためのルーティングテーブルのアクセス権限設定について

2025.08.15

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、「どうやって直すのか？」 という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

今回は、Amazon EC2が配置されるVPCにおいて、VPCピアリング接続のためのルーティングテーブルが最小限のアクセス権限に設定されていない 状態について、そのリスクと対策を解説します。具体的には、「0.0.0.0/0」からのアクセスを許可しているケースに焦点を当てます。

リスク

VPCピアリング接続は、2つのVPC間でプライベートなネットワーク接続を確立し、IPアドレスを使用してインスタンスが相互に通信できるようにする機能です。この接続のためのルーティングテーブルが最小権限の原則に従わず、特に「0.0.0.0/0」などの広範な設定でアクセスを許可している場合、以下のような重大なセキュリティリスクが発生します。

  • 意図しないネットワークアクセス: ルーティングテーブルですべてのアクセスを許可していると、ピアリングされたVPC内のすべてのIPアドレス範囲からのトラフィックが許可されてしまいます。これにより、本来アクセスを許可すべきではないサブネットやインスタンスから、機密性の高いリソースへのアクセスが可能になる可能性があります。
  • 攻撃経路の拡大: 片方のVPCが侵害された場合、ルーティングテーブルの広範な設定が原因で、攻撃者がピアリング接続を介してもう一方のVPC内のリソースに容易に横展開（ラテラルムーブメント）できる経路を提供してしまいます。これにより、単一のVPCの侵害が、組織全体のネットワークセキュリティを脅かす事態に発展する可能性があります。
  • デバッグやトラブルシューティングの複雑化: 広範なルーティング設定は、ネットワークトラフィックの流れを不明瞭にし、セキュリティ問題や接続の問題が発生した際に、その原因を特定し、デバッグするプロセスを複雑にします。
  • 偶発的なデータ漏洩のリスク: 広範なアクセスが許可されていることで、誤設定やヒューマンエラーによって、本来意図しないVールでデータが公開されたり、アクセスされたりする偶発的なデータ漏洩のリスクが高まります。

対策

VPCピアリング接続のためのルーティングテーブルを最小限のアクセス権限に設定することは、AWS環境のネットワークセキュリティを強化し、意図しないアクセスや攻撃経路の拡大を防ぐために不可欠なベストプラクティスです。

  • 具体的なCIDRブロックの指定: ルーティングテーブルのエントリでは、「0.0.0.0/0」のようなワイルドカードを使用せず、ピアリングされたVPC内の特定のCIDRブロック（例: 10.0.0.0/24 や 10.0.1.0/28 など）のみを宛先として指定します。これにより、必要なトラフィックのみを許可し、不要なアクセスを制限します。
  • 必要な経路のみを定義: VPCピアリング接続を介して通信する必要がある特定のサブネットやサービスのみに絞ってルーティングエントリを定義します。必要のない通信経路は一切設定しないようにします。
  • 双方向のルーティング確認: VPCピアリング接続は双方向であるため、両方のVPCのルーティングテーブルに、相手のVPCの適切なCIDRブロックへの経路がピアリング接続を介して設定されていることを確認します。
  • セキュリティグループとネットワークACLとの組み合わせ: ルーティングテーブルはネットワークトラフィックの経路を制御しますが、実際のトラフィック許可/拒否はセキュリティグループやネットワークACLで行います。ルーティングテーブルと合わせて、これらのネットワークACLも最小権限の原則で設定されていることを確認し、多層防御を構築します。
  • 定期的なレビューと監査: VPCピアリング接続とそれに関連するルーティングテーブルの設定を定期的にレビューし、ビジネス要件の変化に合わせて最新の状態に保ちます。AWS Configなどのサービスを利用して、設定変更の監視とコンプライアンスチェックを自動化することも推奨されます。
  • CloudTrailによる監視: ルーティングテーブルの変更イベントをCloudTrailでログ記録し、不審な変更がないか監視します。CloudWatch Logsと連携してアラームを設定することで、変更があった場合に即座に通知を受け取ることができます。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、VPCピアリング接続のためのルーティングテーブルを最小限のアクセス権限に設定します。

前提: 既にVPCピアリング接続が確立されており、ルーティングテーブルに広範な（0.0.0.0/0 を含む）エントリが存在していると仮定します。

  1. VPCサービスへ移動: AWSコンソールにログインし、Amazon VPC サービスを開きます。
  2. ルーティングテーブルの選択: 左側のナビゲーションペインで「ルートテーブル」を選択します。
  3. 対象のルートテーブルの選択: VPCピアリング接続に関連付けられているルートテーブル（通常、プライベートサブネットに関連付けられたもの）を選択します。
  4. ルートの編集: ルートテーブルの詳細ページで、「ルート」タブを選択し、「ルートを編集」をクリックします。
  5. 不適切なルートの削除:
    • 宛先が「」や、ピアリングされたVPCの広範なCIDRブロック（例: 0.0.0.0/0 などのデフォルトルート）で、ターゲットがVPCピアリング接続（pcx-xxxxxxxx）になっているエントリがあれば、それを削除します。
    • 重要: 通常のインターネットへのアウトバウンドトラフィックのための 0.0.0.0/0 とインターネットゲートウェイ（igw-xxxxxxxx）のルートは削除しないでください。これは、インターネット接続に必須です。
  6. 適切なルートの追加: 「ルートの追加」をクリックします。
    • 宛先: ピアリングされたVPC内の通信を許可したい特定のCIDRブロックを入力します。例えば、ピアリング先VPCのCIDRが 172.31.0.0/16 で、その中の 172.31.10.0/24 サブネットにのみアクセスを許可したい場合は、172.31.10.0/24 と入力します。
    • ターゲット: ドロップダウンメニューから、対応するVPCピアリング接続ID（pcx-xxxxxxxx）を選択します。
    • 複数の特定のCIDRブロックへのアクセスが必要な場合は、この手順を繰り返して、必要なすべてのエントリを追加します。
  7. 変更を保存: 設定を確認し、「変更を保存」をクリックします。
  8. もう一方のVPCのルーティングテーブルも同様に設定: VPCピアリングは双方向接続です。ピアリングしているもう一方のVPCにもログインし、同様の手順でルーティングテーブルが最小権限の設定になっていることを確認・修正します。宛先は、あなたのVPCの特定のCIDRブロックになります。
  9. VPCのルートテーブルを開き、以下のように「0.0.0.0/0」でピアリング接続されていないことを確認します。

Terraformでの修復手順

TerraformでVPCピアリング接続のためのルーティングテーブルを最小限のアクセス権限に設定するには、aws_route_table および aws_route リソースを使用します。既存の広範なルートを削除し、より具体的なルートを追加します。

前提:

  • aws_vpc_peering_connection が既に定義されているか、データソースとして参照されている。
  • 関連するaws_route_tableが既に定義されているか、データソースとして参照されている。
# (例) 既存のVPCピアリング接続を参照
data "aws_vpc_peering_connection" "example_peering" {
  vpc_id        = "vpc-0abc123def4567890" # あなたのVPC IDに置き換え
  peer_vpc_id   = "vpc-0fedcba9876543210" # ピアリング先VPC IDに置き換え
  status        = "active"
}

# (例) ルーティングテーブルを参照 (通常、プライベートサブネットに関連付けられたもの)
data "aws_route_table" "main_route_table" {
  vpc_id = "vpc-0abc123def4567890" # あなたのVPC IDに置き換え
  filter {
    name   = "association.main"
    values = ["true"] # メインルートテーブルの場合
  }
  # または、特定のルートテーブルIDを参照
  # id = "rtb-xxxxxxxxxxxxxxxxx"
}

# 既存の広範なVPCピアリングルートを削除する (もし存在する場合)
# Terraformは既存の非管理リソースを削除しないため、手動で削除するか、
# importして管理対象にする必要があります。
# ただし、特定のルートをTerraformで「管理外」として扱う（無視する）ことは可能です。

# より具体的なVPCピアリングルートを追加
# 宛先はピアリング先VPCの特定のCIDRブロックに限定する
resource "aws_route" "peer_to_specific_subnet_a" {
  route_table_id            = data.aws_route_table.main_route_table.id
  destination_cidr_block    = "172.31.10.0/24" # ピアリング先VPCの特定のサブネットCIDRに置き換え
  vpc_peering_connection_id = data.aws_vpc_peering_connection.example_peering.id
  # depends_on = [data.aws_vpc_peering_connection.example_peering] # 明示的な依存関係
}

resource "aws_route" "peer_to_specific_subnet_b" {
  route_table_id            = data.aws_route_table.main_route_table.id
  destination_cidr_block    = "172.31.20.0/24" # ピアリング先VPCの別の特定のサブネットCIDRに置き換え
  vpc_peering_connection_id = data.aws_vpc_peering_connection.example_peering.id
}

# 補足：
# もしVPCピアリング先のVPC全体のCIDR（例：172.31.0.0/16）にアクセスが必要で、
# そのCIDRが他のルートと競合しない場合、以下のように定義します。
# しかし、セキュリティのベストプラクティスとしては、必要なサブネットのみを許可することが望ましいです。
# resource "aws_route" "peer_to_whole_vpc" {
#   route_table_id            = data.aws_route_table.main_route_table.id
#   destination_cidr_block    = "172.31.0.0/16" # ピアリング先VPCのCIDR
#   vpc_peering_connection_id = data.aws_vpc_peering_connection.example_peering.id
# }

# 別のVPCのルートテーブルも同様に設定する必要があります
# provider "aws" {
#   alias  = "peer_account"
#   region = "ap-southeast-1" # ピアリング先VPCのリージョン
#   # assuming this is a cross-account peering and you have appropriate provider config
# }

# data "aws_route_table" "peer_main_route_table" {
#   provider = aws.peer_account
#   vpc_id = "vpc-0fedcba9876543210" # ピアリング先VPC ID
#   filter {
#     name   = "association.main"
#     values = ["true"]
#   }
# }

# resource "aws_route" "peer_from_this_vpc" {
#   provider = aws.peer_account
#   route_table_id            = data.aws_route_table.peer_main_route_table.id
#   destination_cidr_block    = "10.0.0.0/16" # あなたのVPCのCIDR
#   vpc_peering_connection_id = data.aws_vpc_peering_connection.example_peering.id
# }

上記のTerraformコードでは、aws_route リソースを使用して、VPCピアリング接続を介した具体的な宛先CIDRブロックへのルートを追加しています。

  • destination_cidr_block: ここに、ピアリングされたVPC内で通信を許可したい具体的なサブネットのCIDRブロックを指定します。 や 0.0.0.0/0 などの広範な値は使用しません。
  • vpc_peering_connection_id: 使用するVPCピアリング接続のIDを指定します。

重要な考慮事項:

  • 既存ルートの削除: Terraformは、Terraformコードで定義されていない既存のルートを自動的に削除しません。もし既存のルーティングテーブルに広範な ( や 0.0.0.0/0 など）VPCピアリングへのルートが存在する場合、Terraformでこの設定を適用する前に、手動でコンソールからそのルートを削除するか、Terraformの import コマンドでそのルートをTerraformの管理下に置き、コードから削除する 必要があります。
  • 双方向設定: VPCピアリング接続は双方向です。上記の例では片方のVPCのルーティングテーブルのみを示していますが、ピアリングしているもう一方のVPCのルーティングテーブルも同様に、あなたのVPCの特定のCIDRブロックへのルートを設定する 必要があります。クロスアカウント/クロスリージョンの場合は、適切なプロバイダーエイリアスを使用します。

vpc-0abc123def4567890 や 172.31.10.0/24 などのプレースホルダーは、実際の環境に合わせて修正してください。

最後に

この記事では、VPCピアリング接続のためのルーティングテーブルを最小限のアクセス権限に設定することの重要性について解説しました。特に「*」のような広範な設定は、セキュリティ上の大きなリスクとなるため、必要なCIDRブロックに限定してルーティングを行うことが不可欠です。

貴社のVPCピアリング接続では、ルーティングテーブルが最小権限の原則に従って設定されていますか？この機会にぜひ設定を確認・強化してみてください。

こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る