VPCセキュリティ設計実践ガイド｜AWS・Azureのサブネット分離・セキュリティグループ・NACLで内部ネットワークを守る

クラウドへの移行を進めているのに、VPC（仮想プライベートクラウド）のネットワーク設計をきちんと考えたことがない——そんな企業は思いのほか多いものです。「とりあえずAWSのVPCを作ってEC2を立てた」「Azureで仮想ネットワークを作ったがセキュリティグループのルールがよくわからない」という状態では、クラウドのメリットを享受しながら、オンプレよりも危険な環境を作り出してしまうリスクがあります。

VPCは「クラウド上のプライベートネットワーク」であり、オンプレミスのルーターやファイアウォールに相当する機能をソフトウェアで実現しています。設定が自由な分、誤った設定がそのまま本番稼働してしまいやすい側面もあります。

この記事では、AWSとAzureのVPCセキュリティ設計について、サブネット分離・セキュリティグループ・NACLの考え方から、VPCフローログによる可視化まで、現場で使えるレベルで解説します。情シス担当者が1人でも取り組める設計原則と、実際の設定方針をわかりやすくまとめます。

VPCとは？オンプレミスネットワークとここが違う

VPC（Virtual Private Cloud）は、パブリッククラウド上に構築する論理的に隔離されたプライベートネットワークです。AWSでは「Amazon VPC」、Azureでは「Azure Virtual Network（VNet）」と呼ばれます。

物理的なネットワーク機器の代わりに、ソフトウェアで以下を定義します。

・IPアドレス範囲（CIDR）: ネットワーク全体のアドレス空間を定義
・サブネット: VPCをさらに小さなネットワークに分割する単位
・ルートテーブル: パケットの経路を制御（どのサブネットからどこへ通信できるか）
・インターネットゲートウェイ（IGW）: インターネットとの接続口
・セキュリティグループ: EC2インスタンスなどリソース単位のファイアウォール（ステートフル）
・NACL（ネットワークACL）: サブネット境界のファイアウォール（ステートレス）

オンプレミスとの最大の違いは「境界が見えにくい」点です。物理的なケーブルやスイッチポートが存在しないため、設定ミスが「つながってしまう」形で顕在化しやすくなります。インターネットゲートウェイさえあれば、世界中からアクセスできる状態になりえます。

また、クラウドでは責任共有モデルの観点から、ネットワーク設計・セキュリティグループ・NACL設定はすべてユーザー側の責任です。クラウドプロバイダーが守ってくれるのは物理インフラ層だけです。責任共有モデルの詳細については、責任共有モデルとは？AWS・Azure・GCPでの境界線と企業が守るべきセキュリティ領域で整理しています。

VPCを狙うセキュリティリスク（敵を知る）

VPCの設定ミスや設計不備が招く主なリスクを把握しておきましょう。

【リスク1】過剰なインバウンドルール

セキュリティグループで「0.0.0.0/0（すべてのIPアドレス）」から「22番ポート（SSH）」を許可してしまうケースが後を絶ちません。SSH・RDP・データベースポートをインターネット全体に開放することは、ブルートフォース攻撃やクレデンシャルスタッフィング攻撃に直接さらされることを意味します。

【リスク2】サブネット未分離による横移動リスク

すべてのリソースをパブリックサブネットに配置したり、フロントエンドとデータベースを同一サブネットに混在させると、1台が侵害されたときの横移動（ラテラルムーブメント）経路が広がります。

【リスク3】VPCフローログ未設定による不審通信の見落とし

VPCフローログを有効化していないと、不審な通信があっても事後に確認する手段がなくなります。インシデント発生後に「ログがなかった」という状況は最悪です。

【リスク4】パブリックIPアドレスの意図しない付与

EC2インスタンス作成時のデフォルト設定によっては、パブリックIPが自動的に付与される場合があります。「社内システム用のサーバーにパブリックIPが付いていた」ということが起こりえます。

【リスク5】VPCピアリング・Transit Gatewayの過剰な接続

複数のVPCを安易に接続（ピアリング）すると、一方が侵害された際に隣接するVPCへの横移動経路になります。

VPCセキュリティを強化する5つの設計原則

1. サブネット分離設計：3層アーキテクチャを基本とする

VPCの設計で最も重要なのがサブネット分離です。一般的なWebサービスであれば、以下の3層構造を基本とします。

アプリサーバーやDBサーバーには直接インターネットからアクセスできない設計とし、パブリックサブネットのロードバランサー経由でのみアクセスを受け付けます。

AWSの場合、Bastionホスト（踏み台サーバー）はパブリックサブネットに置き、SSH接続は自社IPアドレスからのみに制限します。なお、Session Manager（SSM）を使えばBastionホストを廃止してSSHポートを閉じることも可能です。Session Managerを使うと、ポート22を一切開けずにEC2インスタンムへ接続できるため、攻撃面を大幅に縮小できます。

2. セキュリティグループの最小権限設定

セキュリティグループはEC2インスタンスやRDSなど、リソース単位で適用するステートフルなファイアウォールです。許可したインバウンドに対するレスポンスは、アウトバウンドルールなしでも自動的に許可されます（ステートフルの特性）。

最小権限の原則に基づいた設定のポイントを挙げます。

・ソースには「0.0.0.0/0」を使わない: アクセスを許可するIPアドレスは自社IPや特定のCIDRに限定する。社外からのアクセスが必要なエンドポイントはロードバランサーに集約し、その先のEC2はロードバランサーのセキュリティグループIDをソースに指定する
・SSHは22番を閉じるか、特定IPに限定: 踏み台サーバー以外のSSH許可は原則禁止。踏み台も自社出口IPのみに制限する
・DBポートはアプリサーバーSGからのみ許可: MySQLの3306、PostgreSQLの5432は、DBサーバーのSGのインバウンドにアプリサーバーのSGを指定する
・アウトバウンドも絞る: デフォルトの「全許可」から変更し、必要なポートと宛先だけを許可する（マルウェアのC2通信遮断に有効）

# セキュリティグループ設計の例（AWS CLIイメージ）
# ロードバランサーSG: インターネットから80/443のみ許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-alb-xxxx \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

# アプリサーバーSG: ロードバランサーSGからの8080のみ許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-app-xxxx \
  --protocol tcp --port 8080 \
  --source-group sg-alb-xxxx

# DBサーバーSG: アプリサーバーSGからの3306のみ許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-db-xxxx \
  --protocol tcp --port 3306 \
  --source-group sg-app-xxxx

3. NACLでステートレスな多層防御を加える

NACL（Network Access Control List）はサブネット境界に適用するステートレスなフィルタリングです。ステートフルなセキュリティグループとは異なり、インバウンドとアウトバウンドをそれぞれ明示的に設定する必要があります。

セキュリティグループだけでなくNACLを組み合わせることで、多層防御を実現できます。

NACLの主な活用シナリオを挙げます。

・特定IPのブロック: 攻撃元IPを検知したら即座にNACLのDENYルールで遮断できる（セキュリティグループはDENYルールがないため、NACLが有効）
・不要ポートの一括ブロック: プライベートサブネットへの外部からの直接アクセスをNACLで明示的にDENY
・エフェメラルポートの明示的許可: ステートレスのため、TCP通信の戻りパケットが使うエフェメラルポート（1024～65535）をアウトバウンドで許可する必要がある点に注意

Azureでは、Network Security Group（NSG）がセキュリティグループとNACLを統合した役割を担います。NSGはサブネットレベルとNICレベルの両方に適用でき、両方に設定することでAWSと同様の多層防御が実現できます。

4. VPCフローログで通信を可視化する

VPCフローログを有効化すると、VPC内のネットワークインターフェースを通過するIPトラフィック情報をCloudWatch LogsまたはS3に記録できます。セキュリティ監視・インシデント調査の両面で必須の設定です。

フローログで検知できる不審なパターンの例を挙げます。

・内部サーバーから外部の不審なIPへの定期的な通信（C2通信の疑い）
・深夜帯の大量データ転送（情報窃取の疑い）
・拒否（REJECT）されているポートスキャン的な通信パターン
・DBサブネットへのアプリサーバー以外からの接続試行

# VPCフローログの有効化（AWS CLI）
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxxxxxxxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-arn arn:aws:iam::XXXX:role/flowlogsrole

# CloudWatch Logs Insightsでのクエリ例（REJECTされた通信を集計）
# fields @timestamp, srcAddr, dstAddr, dstPort, action
# | filter action = "REJECT"
# | stats count() as reject_count by srcAddr, dstAddr, dstPort
# | sort reject_count desc
# | limit 20

フローログのコストは通信量に比例するため、最初はVPC全体ではなく重要なサブネットやENI（ネットワークインターフェース）単位で有効化し、段階的に拡大するアプローチも現実的です。

5. プライベートエンドポイントでデータをインターネットに出さない

S3やDynamoDB、SecretsManagerといったAWSサービスへの通信は、デフォルトではインターネット経由になります。これをVPC内のプライベート経路に変えるのがVPCエンドポイント（Azureではプライベートエンドポイント）です。

メリットは2点あります。

・通信がAWSネットワーク内に留まる: インターネットを経由しないため、盗聴リスクが下がり、NATゲートウェイの通信コストも削減できる
・エンドポイントポリシーで制限できる: 特定のS3バケットへのアクセスのみを許可するポリシーを設定できる

プライベートサブネット内のEC2インスタンムがS3やSecretsManagerと通信する場合は、VPCエンドポイントの利用を検討してください。

中小企業でも今日からできること

大規模なVPC再設計が難しくても、以下の手順から着手できます。

・まずセキュリティグループの「0.0.0.0/0」ルールを棚卸し: AWS ConsoleやAzure Portalで全SGのインバウンドルールを確認し、SSH（22）・RDP（3389）・データベースポートに「0.0.0.0/0」が設定されていないか確認する
・VPCフローログをすぐに有効化: まずはVPC全体に対してREJECTのみのフローログを取得するだけでも、不審な通信の兆候を掴める
・DBサブネットのインターネット経路を遮断: RDSなどのDBサブネットのルートテーブルから、インターネットゲートウェイへのルートを削除し、アウトバウンドも塞ぐ
・CSPMツールの活用: AWSであればSecurity HubやTrusted Advisor、AzureではMicrosoft Defender for Cloudが設定ミスを自動検知してくれる。まず無料枠で試してみることをおすすめします

クラウドのセキュリティ態勢管理についてはCSPM（クラウドセキュリティ態勢管理）とは？で詳しく解説しています。

また、VPCセキュリティはゼロトラストアーキテクチャの考え方と非常に相性が良いものです。ZTNA（ゼロトラストネットワークアクセス）やマイクロセグメンテーションと組み合わせることで、侵害された際の被害範囲を最小化できます。

よくある誤解と注意点

【誤解1】セキュリティグループだけ設定すれば十分

セキュリティグループはステートフルで使いやすい反面、「DENY」ルールが存在しません。特定の攻撃元IPをブロックしたい場合はNACLが必要です。セキュリティグループとNACLを組み合わせてはじめて多層防御が成立します。

【誤解2】「プライベートサブネット」はインターネットから完全に隔離されている

プライベートサブネットに配置したEC2でも、NAT Gatewayを通じてインターネットへのアウトバウンド通信は可能です。マルウェアがC2通信を行う際も、アウトバウンドは通ってしまう可能性があります。アウトバウンドのセキュリティグループルールも最小化し、エグレスフィルタリングを検討してください。

【誤解3】VPCピアリングで繋いだVPCは同一ネットワーク扱い

VPCピアリングは2つのVPCを直接接続しますが、ルートテーブルとセキュリティグループで必要な通信のみを許可する設定が必要です。ピアリングしたからといってすべての通信が通るわけではなく、明示的にルートとSGを設定する必要があります。

【注意】マルチAZ設計とセキュリティの組み合わせ

可用性確保のためにマルチAZ（複数のアベイラビリティゾーン）を使う場合、各AZに対応したサブネットを作成します。このとき、各サブネットにNACLとセキュリティグループの設定が漏れなく適用されているか確認が必要です。AZを追加するたびにセキュリティ設定の抜け漏れが発生しやすくなります。

本記事のまとめ

VPCのセキュリティ設計は「最初に正しく作ること」が最もコストが低く、後から修正するほど手間とリスクが増します。まず既存VPCのセキュリティグループの棚卸しとフローログの有効化から始め、段階的にサブネット分離とNACL設定を整備していきましょう。オンプレのネットワーク設計経験を持つエンジニアほど「クラウドの設定ミスは気づきにくい」という点を意識して取り組むことが重要です。

クラウドネットワーク全体の防御戦略については、SASEとは？ゼロトラストとSD-WANを統合する次世代ネットワークセキュリティもあわせて参照ください。