Zenn
🤖

AWS Cloud Quest Security 学習記録 Day4: Amazon Virtual Private Cloud (VPC)

に公開
AWS
Security
VPC
AWS 認定試験
idea

はじめに

AWS Security Specialty取得を目指すAWS Cloud Quest学習の4日目として、ネットワークセキュリティの基盤となるAmazon Virtual Private Cloud (VPC)について学習しました。VPCは、AWSクラウド内で論理的に分離されたプライベートネットワーク環境を構築し、セキュアなアプリケーション運用を実現するための重要なサービスです。

本日学習した内容：

  • Amazon VPC概要と基本概念
  • インターネット接続性とネットワーク設計
  • ネットワークアクセス制御とセキュリティグループ
  • セキュリティアーキテクチャのベストプラクティス

Amazon VPC 概要

基本概念

Amazon Virtual Private Cloud (VPC)は、AWSクラウド内のプライベートクラウドとして機能し、以下の特徴を持ちます：

  • 論理的に分離されたAWSクラウドセクションをプロビジョニング
  • 定義した仮想ネットワーク内でAWSリソースを起動
  • AWSアカウント専用の仮想ネットワーク
  • 各リージョンに事前設定されたデフォルトVPCが提供

VPCの主要メリット

1. Simple（シンプル）

  • AWS Management Consoleを使用した迅速で簡単なVPC作成
  • セットアップと管理の時間を短縮
  • アプリケーション構築に集中できる環境

2. Customizable（カスタマイズ可能）

パブリックサブネット：

  • Webサーバー用途
  • インターネットアクセスが必要なリソース

プライベートサブネット：

  • バックエンドシステム（データベース、アプリケーションサーバー）
  • インターネットアクセス不要なリソース

ネットワーク拡張：

  • 企業ネットワークとの接続によるデータセンターの延長
  • 他のVPCとの接続

3. Secure（セキュア）

多層セキュリティ機能：

  • Network Access Control Lists (NACLs)：サブネットレベルの制御
  • Security Groups：インスタンスレベルの仮想ファイアウォール
  • VPC内限定Amazon S3アクセス：VPC内インスタンスのみアクセス可能なS3設定

VPCの基本構成要素

IP アドレッシングとCIDR

CIDR（Classless Inter-Domain Routing）ブロック

VPC作成時には、プライベートIPアドレスの範囲をCIDR表記で指定します：

許可されるCIDRブロックサイズ：

  • 最小：/28（16個のIPアドレス）
  • 最大：/16（65,536個のIPアドレス）

CIDR表記の例：

10.0.0.0/16

バイナリ表記での理解：

10.0.0.0/16 = 00001010 00000000 00000000 00000000
              ←─ 16ビット固定 ─→ ←─ 16ビット可変 ─→
  • 固定部分（16ビット）：ネットワーク部分
  • 可変部分（16ビット）：ホスト部分（65,536個のIPアドレス）

特別なCIDR：

  • 0.0.0.0/0：すべてのIPアドレス（インターネット全体）

IP アドレスの種類

プライベートIPアドレス：

  • VPC内のローカルアドレス
  • インターネット経由では到達不可
  • VPC内インスタンス間の通信に使用

パブリックIPアドレス：

  • グローバルに一意なIPv4アドレス
  • インターネット経由でのアクセスに必要
  • Elastic IP：静的（変更されない）パブリックIPアドレス

IPv6アドレス：

  • パブリックアドレス
  • インターネット経由で到達可能

サブネットとAvailability Zone

サブネットの特徴

  • VPCのIPアドレス範囲のパーティション
  • 単一のAvailability Zone内に完全に配置
  • 複数のAZにサブネットを配置することで耐障害性とアプリケーションの高可用性を実現

サブネット設計例

VPC: 10.0.0.0/16 (65,536個のIPアドレス)
├── サブネット1: 10.0.10.0/24 (251個のIPアドレス) - AZ-A
├── サブネット2: 10.0.20.0/24 (251個のIPアドレス) - AZ-B
└── サブネット3: 10.0.30.0/24 (251個のIPアドレス) - AZ-C

重要な制約：

  • AWS予約IPアドレス：各サブネットで5個のIPアドレスがAWS内部使用のため予約
  • サブネットのCIDRブロックは重複不可

VPCの制限

  • デフォルト制限：1つのAWSアカウントでリージョンあたり5つまでのVPC
  • 制限緩和：AWS Supportを通じて上限を増加可能

ルートテーブルとネットワーク制御

ルートテーブルの基本概念

自動作成されるメインルートテーブル

VPC作成時に自動的に作成され、以下のローカルルートが含まれます：

Destination: 10.0.0.0/16
Target: local
Status: Active

このルートにより、VPC内のすべてのリソース間で通信が可能になります。

カスタムルートテーブル

  • 特定の要件に応じて作成
  • サブネットごとに異なるルーティング設定が可能
  • 各サブネットは必ずルートテーブルに関連付けされる必要

サブネットタイプの定義

パブリックサブネット

特徴：

  • インターネットゲートウェイへのルートが存在
  • インバウンド・アウトバウンド両方向のインターネットアクセス

ルートテーブル例：

Destination     Target
10.0.0.0/16    local
0.0.0.0/0      igw-xxxxxxxxx

プライベートサブネット

特徴：

  • インターネットゲートウェイへのルートが存在しない
  • 直接的なインターネットアクセス不可
  • 一般的により多くのIPアドレスを割り当て

設計の考慮点：

  • パブリックサブネット：/24（251個のIPアドレス）
  • プライベートサブネット：/20（4,091個のIPアドレス）

インターネット接続性

Internet Gateway

基本特徴

  • 水平方向にスケーラブル
  • 冗長性を備えた高可用性設計
  • IPv4とIPv6の両方をサポート
  • VPCとインターネット間の通信を可能にする

インターネットアクセスを有効にする手順

  1. Internet GatewayをVPCにアタッチ
  2. サブネットのルートテーブルにルートを追加
    Destination: 0.0.0.0/0
Target: igw-xxxxxxxxx
  3. インスタンスにパブリックIPアドレスを割り当て
    • パブリックIPv4アドレス
    • IPv6アドレス
    • Elastic IPアドレス
  4. ネットワークACLとセキュリティグループでトラフィックを許可

Elastic IP アドレス

  • 静的パブリックIPv4アドレス（時間経過で変化しない）
  • インスタンスまたはネットワークインターフェース間で迅速に移動可能
  • 高可用性アーキテクチャでのフェイルオーバーに活用

NAT Gateway

目的と動作

プライベートサブネット内のインスタンスが以下を実現：

  • インターネットへの接続
  • インターネットからの直接接続の防止

Network Address Translation (NAT) プロセス

アウトバウンド通信:
プライベートIP → NAT Gateway → インターネット
(プライベートサブネット)  (パブリックサブネット)

インバウンド応答:
インターネット → NAT Gateway → プライベートIP
                (アドレス変換)

NAT Gateway設定手順

  1. パブリックサブネットでNAT Gatewayを作成
  2. Elastic IPアドレスをNAT Gatewayに関連付け
  3. プライベートサブネットのルートテーブルを更新
    Destination: 0.0.0.0/0
Target: nat-xxxxxxxxx

重要な制限：NAT GatewayはIPv6トラフィックをサポートしない

Egress-only Internet Gateway

IPv6専用のソリューション

  • IPv6トラフィック専用
  • プライベートサブネットからインターネットへのアウトバウンド通信を許可
  • インターネットからの直接接続を防止

ステートフル動作

  • プライベートサブネットからインターネットへトラフィックを転送
  • 応答トラフィックを自動的にインスタンスに返送

設定方法

IPv6ルートテーブル設定:
Destination: ::/0
Target: eigw-xxxxxxxxx

ネットワークセキュリティ

Network Access Control Lists (NACLs)

基本特徴

  • サブネットレベルのファイアウォール
  • ステートレス：インバウンドとアウトバウンドの明示的なルールが必要
  • 番号付きルールリストで評価順序を制御

デフォルトNACL vs カスタムNACL

デフォルトNACL：

  • すべてのインバウンド・アウトバウンドトラフィックを許可
  • VPCに自動的に付属
  • 変更可能

カスタムNACL：

  • デフォルトですべてのトラフィックを拒否
  • 許可ルールを明示的に追加する必要
  • より厳格なセキュリティ制御

ルール評価プロセス

評価順序：

  1. 最も小さい番号のルールから開始（最高優先度）
  2. トラフィックがルールに一致するまで順次評価
  3. 一致した時点で評価終了、ALLOWまたはDENYを適用

ルール例：

Rule#  Protocol  Port Range  Source        Allow/Deny
100    SSH(22)   22          172.31.1.2/32 ALLOW
200    ALL       ALL         0.0.0.0/0     DENY

制約事項

  • 複数のサブネットを1つのNACLに関連付け可能
  • 1つのサブネットは同時に1つのNACLにのみ関連付け可能
  • インバウンドとアウトバウンドの両方向で明示的なルールが必要

Security Groups

基本特徴

  • インスタンスレベルの仮想ファイアウォール
  • ステートフル：インバウンドトラフィックに対する応答は自動的に許可
  • ステートフル：すべてのルールを評価してからトラフィック許可を決定

デフォルト動作

新しいセキュリティグループ：

  • すべてのインバウンドトラフィックを拒否
  • すべてのアウトバウンドトラフィックを許可

DENYルール不要：

  • デフォルトで拒否されるため、ALLOWルールのみ設定
  • より簡潔なルール管理

トラフィック制御要素

セキュリティグループでは以下の要素でトラフィックを制限：

  • トラフィックタイプ（HTTP、HTTPS、SSH等）
  • IPプロトコル（TCP、UDP、ICMP等）
  • ポート範囲
  • トラフィックソース（IPアドレス、他のセキュリティグループ等）

セキュリティグループチェーンの実装

階層化セキュリティアーキテクチャ

企業では一般的に機能層ごとにセキュリティグループを作成し、トラフィックフローを厳密に制御します：

3層アーキテクチャの例：

インターネット
    ↓ HTTPS (Port 443)
┌─────────────────┐
│  Web Tier       │ ← Web Tier Security Group
│  (Web Servers)  │
└─────────────────┘
    ↓ HTTP (Port 80)
┌─────────────────┐
│ Application Tier│ ← Application Security Group  
│ (App Servers)   │
└─────────────────┘
    ↓ TCP (Port 3306)
┌─────────────────┐
│   Data Tier     │ ← Database Security Group
│  (Database)     │
└─────────────────┘

セキュリティグループルールの詳細

Web Tier Security Group：

Inbound Rules:
- Type: HTTPS
- Protocol: TCP
- Port: 443
- Source: 0.0.0.0/0 (Internet)

Application Security Group：

Inbound Rules:
- Type: HTTP
- Protocol: TCP  
- Port: 80
- Source: Web Tier Security Group

Database Security Group：

Inbound Rules:
- Type: MySQL/Aurora
- Protocol: TCP
- Port: 3306
- Source: Application Security Group

チェーン設計の利点

防御の深層化：

  • 各層で異なるセキュリティ制御
  • 単一障害点の排除

最小権限の原則：

  • 各層は必要最小限のアクセスのみ許可
  • 上位層からのトラフィックのみを受け入れ

侵害時の被害局限化：

  • 仮にWebサーバーが侵害されても、データベースへの直接アクセスは不可能
  • 攻撃者は各層のセキュリティを個別に突破する必要

NACLs vs Security Groups 比較

特徴 Network ACLs Security Groups
動作レベル サブネット境界 インスタンスレベル
ステート ステートレス ステートフル
ルールタイプ ALLOW・DENYルール ALLOWルールのみ
ルール評価 順次評価（番号順） すべてのルール評価
デフォルト動作 すべて許可 インバウンド拒否、アウトバウンド許可
関連付け サブネット インスタンス
明示的ルール インバウンド・アウトバウンド両方必要 インバウンドのみ（応答は自動許可）

VPCのセキュリティベストプラクティス

1. ネットワーク設計の原則

最小権限の原則

  • 必要最小限のネットワークアクセスのみ許可
  • 不要なポートやプロトコルのブロック
  • ソースIPアドレスの厳格な制限

防御の深層化

  • NACLsとSecurity Groupsの併用
  • 複数層でのセキュリティ制御
  • ネットワークレベルとアプリケーションレベルの両方で保護

2. サブネット分離戦略

パブリック vs プライベート分離

パブリックサブネット：

  • ロードバランサー
  • Webサーバー（必要な場合のみ）
  • NATゲートウェイ
  • Bastionホスト

プライベートサブネット：

  • アプリケーションサーバー
  • データベース
  • 内部API
  • 機密データを扱うサービス

機能別サブネット分離

  • DMZ（非武装地帯）サブネット：外部向けサービス
  • 内部サービスサブネット：社内システム
  • 管理サブネット：運用・監視ツール

3. セキュリティグループ管理

命名規則の確立

<環境>-<層>-<サービス>-sg
例：prod-web-nginx-sg, dev-app-api-sg

グループ参照によるルール設定

IPアドレス範囲ではなく、セキュリティグループIDを参照：

Source: sg-xxxxxxxxx (Application Security Group)

利点：

  • IPアドレス変更に対する柔軟性
  • より明確な関係性の表現
  • 管理の簡素化

4. 監視とログ記録

VPC Flow Logs

  • ネットワークトラフィックの記録
  • 異常なトラフィックパターンの検出
  • セキュリティインシデントの分析

CloudTrail統合

  • VPC設定変更の記録
  • セキュリティグループ変更の監査
  • コンプライアンス要件への対応

実装時の考慮事項

1. パフォーマンス最適化

地理的配置

  • 利用者に近いリージョンでのVPC配置
  • レイテンシーの最小化

帯域幅計画

  • NAT Gatewayの帯域幅制限を考慮
  • 複数のNAT Gatewayによる負荷分散

2. 高可用性設計

Multi-AZ配置

  • 複数のAvailability Zoneにわたるサブネット配置
  • 単一障害点の排除

冗長化

  • 複数のNAT Gateway（AZごと）
  • 複数のInternet Gateway（必要に応じて）

3. コスト最適化

NATゲートウェイコスト

  • データ転送量の監視
  • 不要なアウトバウンド通信の削減

Elastic IPコスト

  • 未使用Elastic IPの削除
  • 使用量の定期的なレビュー

まとめ

学習した主要ポイント

  1. Amazon VPCは、AWSクラウド内で論理的に分離されたプライベートネットワーク環境を構築
  2. サブネット設計により、パブリック・プライベートリソースの適切な分離を実現
  3. Internet Gateway・NAT Gatewayにより、セキュアなインターネット接続を提供
  4. NACLsとSecurity Groupsによる多層防御でネットワークセキュリティを強化
  5. セキュリティグループチェーンにより、階層化されたアクセス制御を実装

AWS Security Specialty取得に向けて

VPCは、AWS Security Specialtyにおいて以下の観点から重要です：

  • ネットワーク分離：論理的な分離によるセキュリティ境界の確立
  • アクセス制御：細かいネットワークレベルでのトラフィック制御
  • 防御の深層化：複数のセキュリティ層による包括的保護
  • コンプライアンス：規制要件に対応するネットワーク設計

Discussion