AWS VPCセキュリティ：セキュリティグループ、NACL、ネットワーク保護

AWS Virtual Private Cloud（VPC）は、AWS内のプライベートネットワークです。VPCセキュリティを理解することは重要です。ネットワーク層は脅威に対する最初の防御線であり、他のコントロールが失敗した場合の最後の防御線でもあるからです。

なぜVPCセキュリティが重要なのか

従来のデータセンターでは、物理的なネットワーク境界が暗黙のセキュリティを提供していました。異なるネットワークセグメント上のサーバーは、明示的に接続されない限り通信できません。ネットワーク境界（ファイアウォール、ルーター、スイッチ）は、セキュリティコントロールの自然なチョークポイントを提供します。

クラウドでは、これらの物理的な境界は同じようには存在しません。AWSのすべてが同じ基盤インフラストラクチャを共有しています。VPCは論理的な境界を作成しますが、その境界のセキュリティを明示的に設定する必要があります。適切なVPCセキュリティがなければ：

VPC内のリソースが、本来アクセスされるべきでないのにインターネットからアクセス可能になる可能性がある
内部リソースが制限なしに相互に通信できる可能性がある
侵害されたインスタンスが他のリソースを攻撃するためにピボットできる可能性がある
データが検出されずにネットワークから流出する可能性がある

VPCセキュリティとは、ワークロードを保護するネットワーク境界を作成し、強制することです。

VPCの理解：プライベートネットワーク

VPCは、リソースを起動するAWSの論理的に分離されたセクションです。クラウド内の独自のプライベートデータセンターと考えてください。ただし、以下を完全に制御できます：

IPアドレス範囲：CIDRブロックを定義（例：10.0.0.0/16）
サブネット：VPCをセグメントに分割、各セグメントは特定のアベイラビリティゾーンに
ルーティング：サブネット間およびインターネットへ/からのトラフィックフローを制御
ゲートウェイ：インターネット、VPN、ピアリングVPCトラフィックの入口と出口を定義

パブリックサブネット vs プライベートサブネット

AWSにおける基本的なネットワークセキュリティ設計パターンは、パブリックサブネットとプライベートサブネットの分離です：

flowchart TB
    Internet["インターネット"] --> IGW["インターネットゲートウェイ"]

    subgraph VPC["VPC (10.0.0.0/16)"]
        IGW --> Public
        subgraph Public["パブリックサブネット"]
            ALB["ロードバランサー"]
            NAT["NAT Gateway"]
        end

        subgraph Private["プライベートサブネット"]
            App["アプリサーバー"]
            DB["データベース"]
        end

        ALB --> App
        App --> DB
        App --> NAT
        NAT --> IGW
    end

    style Internet fill:#ef4444,color:#fff
    style Public fill:#f59e0b,color:#000
    style Private fill:#22c55e,color:#fff

パブリックサブネットはインターネットゲートウェイへのルートを持っています。ここのリソースはインターネットから直接トラフィックを受信できます（セキュリティグループが許可している場合）。パブリックサブネットは以下に使用します：

ユーザートラフィックを受け取るロードバランサー
管理アクセス用の踏み台ホスト
NATゲートウェイ（プライベートサブネットにアウトバウンドインターネットアクセスを提供）

プライベートサブネットはインターネットへの直接ルートを持ちません。ここのリソースは直接のインターネットアクセスから保護されています。プライベートサブネットは以下に使用します：

アプリケーションサーバー
データベース
内部サービス
インターネットからのトラフィックを受信する必要がないリソース

この設計により、誰かがデータベースサーバーのプライベートIPを知っていても、インターネットからは到達できません。単純にルートがないからです。

セキュリティグループ：インスタンスレベルのファイアウォール

セキュリティグループは、インスタンス（ENI）レベルでトラフィックを制御する仮想ファイアウォールです。AWSで最も一般的に使用されるネットワークセキュリティコントロールです。

主な特徴

ステートフル：一方向でトラフィックを許可すると、反対方向のレスポンスは自動的に許可されます。HTTPSを許可するインバウンドルールを作成すると、明示的なアウトバウンドルールなしでレスポンストラフィックが許可されます。

許可のみ：セキュリティグループはトラフィックを許可することしかできません。明示的に拒否することはできません。どの許可ルールにも一致しないトラフィックは拒否されます。

すべてのルールを評価：NACLとは異なり、すべてのセキュリティグループルールが評価されてから決定されます。いずれかのルールがトラフィックを許可すれば、許可されます。

インスタンスレベル：各インスタンスは複数のセキュリティグループを持つことができます。有効なルールは、アタッチされたすべてのセキュリティグループの和集合です。

ステートフルが重要な理由

セキュリティグループのステートフルな性質は、設定を劇的に簡素化します。Webサーバーを考えてみましょう：

インバウンドルール：どこからでもTCP 443を許可
アウトバウンドルール：（デフォルトですべて許可）

クライアントがポート443で接続すると、サーバーはエフェメラルポート（例：49152）から応答します。セキュリティグループはステートフルなので、このレスポンスは自動的に許可されます。エフェメラルポートでのアウトバウンドトラフィックを明示的に許可する必要はありません。

セキュリティグループ参照

セキュリティグループの最も強力な機能の1つは、IP範囲の代わりに他のセキュリティグループを参照することです。これにより以下のようなパターンが可能になります：

データベースアクセスをアプリケーションサーバーからのみ許可（IPではなく、セキュリティグループメンバーシップで）
ロードバランサーのヘルスチェックをロードバランサーのセキュリティグループからのみ許可

このアプローチは：

自動的にスケール：新しいアプリサーバーを追加すると、すぐにデータベースアクセスを持つ
より安全：誤って間違ったIPを許可することがない
IP変更に対応：オートスケーリング、インスタンス置き換え、ルール更新不要

よくあるセキュリティグループの間違い

SSH/RDPに0.0.0.0/0を開く：これはインターネット上のどこからでも管理アクセスを許可します。攻撃者はこれらの開いたポートを常にスキャンしています。代わりに、Systems Manager Session Manager、制限付きアクセスの踏み台ホスト、またはVPNを使用してください。

「-1」プロトコル（全トラフィック）を使用：これはすべてのプロトコルとポートを許可します。実際に必要なことはまれで、攻撃対象面を劇的に増加させます。

セキュリティグループ参照を使用しない：IPアドレスをハードコーディングすると、インフラストラクチャが変更されたときに手動更新が必要になり、移行中にセキュリティギャップが発生する可能性があります。

ネットワークACL：サブネットレベルのファイアウォール

ネットワークアクセスコントロールリスト（NACL）はサブネットレベルで動作し、サブネットに出入りするトラフィックをフィルタリングします。

主な特徴

ステートレス：セキュリティグループとは異なり、NACLは接続を追跡しません。インバウンドとアウトバウンドの両方のトラフィックを明示的に許可する必要があります。レスポンストラフィックも含めて。

許可と拒否：NACLはトラフィックを明示的に拒否できます。これはセキュリティグループにはできません。

順序付きルール評価：ルールは順番に評価されます（最も低いルール番号が最初）。最初に一致するルールが適用され、評価は停止します。

サブネットレベル：サブネットに出入りするすべてのトラフィックがNACLを通過します。

ステートレスが重要な理由

NACLはステートレスなので、レスポンストラフィックを考慮する必要があります。HTTPSを許可するWebサーバーの場合：

必要なインバウンドルール：

どこからでもTCP 443を許可（クライアントリクエスト）
どこからでもTCP 1024-65535を許可（アウトバウンドリクエストへのレスポンス）

必要なアウトバウンドルール：

どこへでもTCP 1024-65535を許可（インバウンドリクエストへのレスポンス）
どこへでもTCP 443を許可（アウトバウンドHTTPSリクエスト）

エフェメラルポート範囲（1024-65535）は、レスポンスが高番号のポートを使用するため必要です。これはセキュリティグループよりも複雑ですが、追加の制御を提供します。

NACLを使用するべき場合

NACLは、セキュリティグループにない機能が必要な場合に輝きます：

明示的な拒否ルール：セキュリティグループが許可しても、サブネット境界で既知の悪意のあるIPアドレスをブロック。

サブネットレベルの制御：個々のセキュリティグループ設定に関係なく、サブネット内のすべてのリソースに一貫したルールを適用。

多層防御：追加の保護層を提供。セキュリティグループの設定が間違っていても、NACLがセーフティネットを提供できる。

コンプライアンス要件：一部のコンプライアンスフレームワークは、明示的な拒否機能またはサブネットレベルのログを要求。

セキュリティグループ vs NACL

flowchart LR
    subgraph SG["セキュリティグループ"]
        SG1["ステートフル"]
        SG2["許可のみ"]
        SG3["インスタンスレベル"]
        SG4["全ルール評価"]
    end

    subgraph NACL["ネットワークACL"]
        N1["ステートレス"]
        N2["許可 & 拒否"]
        N3["サブネットレベル"]
        N4["順序付きルール"]
    end

    style SG fill:#3b82f6,color:#fff
    style NACL fill:#8b5cf6,color:#fff

側面	セキュリティグループ	NACL
レベル	インスタンス/ENI	サブネット
状態	ステートフル	ステートレス
ルール	許可のみ	許可と拒否
評価	すべてのルール、和集合	順序付き、最初のマッチ
デフォルト	すべてのインバウンドを拒否、すべてのアウトバウンドを許可	すべて許可
一般的な用途	主要なアクセス制御	追加のブロッキング、コンプライアンス

実際には、ほとんどの組織がセキュリティグループを主要な制御として使用し、NACLは追加の多層防御または特定のブロッキング要件に使用します。

VPCエンドポイント：AWSトラフィックをプライベートに保つ

VPC内のリソースがAWSサービス（S3、DynamoDB、Secrets Manager）にアクセスするとき、デフォルトではそのトラフィックはインターネットを経由します。VPCエンドポイントは、このトラフィックを完全にAWSネットワーク内に保ちます。

なぜこれが重要か

セキュリティ：AWSネットワークを離れないトラフィックは、パブリックインターネットで傍受できません。

コンプライアンス：一部のコンプライアンスフレームワークは、データがプライベートネットワーク内にとどまることを要求します。

コスト：VPCエンドポイント経由のデータ転送は、インターネットエグレスよりも安くなる場合があります。

信頼性：AWSサービスに到達するためにインターネット接続に依存しません。

ゲートウェイエンドポイント vs インターフェースエンドポイント

ゲートウェイエンドポイント（S3とDynamoDBのみ）：

ルートテーブルエントリとして表示
時間当たりの料金なし
S3とDynamoDBに限定
エンドポイントポリシーでアクセス制御

インターフェースエンドポイント（他のほとんどのAWSサービス）：

サブネット内にENIを作成
時間当たりの料金 + データ処理
ほとんどのAWSサービスとサードパーティPrivateLinkサービスをサポート
セキュリティグループ + エンドポイントポリシーでアクセス制御
プライベートDNSをサポート（サービスエンドポイントがプライベートIPに解決）

エンドポイントポリシー

両方のエンドポイントタイプは、エンドポイントを通じてアクセスできるものを制限するポリシーをサポートします：

特定のS3バケットに制限
特定のAPIアクションのみを許可
条件を要求（ソースVPC、IAMプリンシパル）

これにより「このVPC内のリソースは、任意のバケットではなく、当社のS3バケットのみにアクセスできる」というパターンが可能になります。

AWS Network Firewall：ディープパケットインスペクション

Network Firewallは、VPCレベルでステートフルインスペクション、侵入検知・防止、ドメインフィルタリングを提供します。

Network Firewallが必要な場合

コンプライアンス要件がIDS/IPS機能を義務付けている
暗号化されたトラフィックを検査する必要がある（TLSインスペクション付き）
ドメイン名でフィルタリングしたい（*.amazonaws.comのみ許可）
複数のVPCにわたる集中ネットワークセキュリティが必要
カスタム検出のためのSuricata互換ルールが必要

仕組み

Network Firewallは、サブネット内に管理されたエンドポイントをデプロイします。ルートテーブルを使用してこれらのエンドポイントを経由するようにトラフィックをルーティングします。ファイアウォールはトラフィックを検査し、ルールを適用します：

ステートレスルール：シンプルなパケットフィルタリング（ソース/宛先IPとポート）。最初に評価され、ステートフルルールにトラフィックを渡すか、即座にドロップ/転送できます。

ステートフルルール：接続を認識した検査。ドメインリスト、Suricataルール、または標準の5タプルルールを使用できます。

ドメインフィルタリング：HTTP Hostヘッダーまたは TLS SNI（Server Name Indication）に基づいてトラフィックを許可またはブロック。

Network Firewall vs セキュリティグループ/NACL

Network Firewallは、セキュリティグループとNACLにはない機能を提供します：

ドメインベースのフィルタリング：*.amazonaws.comへのトラフィックを許可し、任意のドメインは不可
IDS/IPS：既知の攻撃パターンを検出してブロック
集中管理：複数のVPCにわたって一貫したルールを適用
詳細なログ：承認/拒否だけでなく、完全なトラフィック詳細をログ

コストは大きく（エンドポイントあたり$0.395/時間 + データ処理）、一般的な使用ではなく、コンプライアンス要件や高セキュリティ環境で通常使用されます。

AWS WAF：アプリケーション層の保護

Web Application Firewall（WAF）はレイヤー7（HTTP/HTTPS）で動作し、一般的なエクスプロイトからWebアプリケーションを保護します。

WAFが保護するもの

SQLインジェクション：リクエストパラメータ内の悪意のあるSQL
クロスサイトスクリプティング（XSS）：スクリプトインジェクション攻撃
一般的なエクスプロイト：一般的なソフトウェアの既知の脆弱性
ボットトラフィック：自動化された攻撃とスクレイピング
レートベースの攻撃：単一ソースからの過剰なリクエスト

AWSマネージドルール

AWSは、AWSセキュリティ研究者によって維持されるマネージドルールセットを提供します：

コアルールセット（CRS）：一般的な脅威に対する一般的な保護
SQLインジェクションルール：SQLiパターンを検出
既知の悪い入力：既知の悪意のあるパターンを持つリクエストをブロック
管理者保護：管理エンドポイントを保護
ボットコントロール：ボットトラフィックを識別して管理

これらのルールは新しい脅威が出現するとAWSによって更新されます。自分でメンテナンスする必要はありません。

WAFが適用される場所

WAFは以下を保護します：

CloudFrontディストリビューション
Application Load Balancer
API Gateway REST API
AppSync GraphQL API
Cognito User Pools

WAFはリソースを直接保護しません。トラフィックがリソースに到達するエントリポイントを保護します。

AWS Shield：DDoS保護

Shieldは、リソースをトラフィックで圧倒しようとする分散型サービス妨害（DDoS）攻撃から保護します。

Shield Standard（無料）

すべてのAWSお客様は自動的にShield Standard保護を受けます：

一般的なレイヤー3/4攻撃から保護
常時オンの検出と自動軽減
アクションは不要、自動的

Shield Advanced（月額$3,000 + データ転送）

より強力な保護が必要なアプリケーション向け：

より大規模で洗練された攻撃に対する強化された検出と軽減
Elastic IP、CloudFront、Route 53、Global Accelerator、ALB、NLBの保護
DDoSレスポンスチーム（DRT）への24時間365日アクセス
コスト保護（攻撃中のスケーリングコストに対するAWSクレジット）
保護されたリソースに追加コストなしでAWS WAF
詳細な攻撃の可視性と攻撃後の分析

Shield Advancedは、ダウンタイムコストがShield Advancedサブスクリプションを超えるビジネスクリティカルなアプリケーションに適しています。

VPCフローログ：ネットワークの可視性

フローログは、VPC内のネットワークトラフィックに関するメタデータをキャプチャします。セキュリティ監視、トラブルシューティング、コンプライアンスに不可欠です。

フローログがキャプチャするもの

各ネットワークフローについて、ログは以下を記録します：

ソースおよび宛先IPアドレス
ソースおよび宛先ポート
プロトコル
パケット数とバイト数
アクション（ACCEPTまたはREJECT）
インターフェース、サブネット、VPC識別子

フローログがキャプチャしないもの

パケットペイロード（メタデータのみ）
Route 53 ResolverへのDNSクエリ
インスタンスメタデータサービスへの/からのトラフィック
DHCPトラフィック
サブネット内の予約済みIPアドレスへのトラフィック

セキュリティのためのフローログの使用

異常を検出：予期しないトラフィックパターン、既知の悪いIPへの接続、または異常なポート使用を特定。

インシデントを調査：セキュリティイベントが発生したとき、フローログは何の通信が行われたかを示します。

セグメンテーションを検証：サブネット間のトラフィックが予想されるパターンと一致することを確認。

コンプライアンスの証拠：ネットワークコントロールが設計どおりに機能していることを実証。

フローログはCloudWatch Logs（リアルタイム分析用）またはS3（長期保存とAthenaクエリ用）に送信できます。

多層防御：レイヤードセキュリティ

効果的なVPCセキュリティは、複数層のコントロールを使用します。各層は、他の層が失敗した場合に保護を提供します：

flowchart TB
    subgraph L1["レイヤー1：エッジ"]
        E1["AWS Shield"]
        E2["AWS WAF"]
        E3["CloudFront"]
    end

    subgraph L2["レイヤー2：VPC境界"]
        P1["インターネットGW"]
        P2["Network Firewall"]
        P3["VPCエンドポイント"]
    end

    subgraph L3["レイヤー3：サブネット"]
        S1["ネットワークACL"]
        S2["ルートテーブル"]
    end

    subgraph L4["レイヤー4：インスタンス"]
        I1["セキュリティグループ"]
        I2["ホストベース制御"]
    end

    subgraph L5["レイヤー5：データ"]
        D1["転送中の暗号化"]
        D2["アプリ制御"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    style L1 fill:#ef4444,color:#fff
    style L2 fill:#f59e0b,color:#000
    style L3 fill:#eab308,color:#000
    style L4 fill:#22c55e,color:#fff
    style L5 fill:#3b82f6,color:#fff

レイヤーが重要な理由

単一障害点がない：セキュリティグループの設定が間違っていても、NACLがまだトラフィックをブロックするかもしれません。

異なる機能：各レイヤーは他にない機能を提供（例：NACLは拒否でき、WAFはHTTPを理解）。

異なる脅威に対する防御：エッジでのDDoS保護、アプリケーション層でのSQLインジェクション保護。

コンプライアンス要件：多くのフレームワークは複数層のネットワークコントロールを要求。

まとめ

VPCセキュリティとは、ネットワーク境界を作成し、強制することです：

コントロール	レベル	目的
セキュリティグループ	インスタンス	主要なアクセス制御（ステートフル、許可のみ）
NACL	サブネット	追加の制御（ステートレス、許可/拒否）
VPCエンドポイント	VPC	プライベートAWSサービスアクセス
Network Firewall	VPC	ディープインスペクション、IDS/IPS
WAF	アプリケーション	HTTP/HTTPS保護
Shield	エッジ	DDoS保護
フローログ	VPC	ネットワークの可視性と監査

主要な原則：

最小権限：明示的に必要なトラフィックのみを許可
デフォルトでプライベート：プライベートサブネット、VPCエンドポイントを使用
多層防御：複数層のコントロール
可視性：フローログを有効にし、トラフィックパターンを監視
セグメンテーション：ティア（Web、アプリ、データベース）を異なるサブネット/セキュリティグループに分離

ネットワークセキュリティは、機能しているときはしばしば見えず、失敗したときは壊滅的に見えます。適切なVPCセキュリティ設計への投資は、インシデントが発生する前に防ぎます。

参考資料

VPCセキュリティ
セキュリティグループ
ネットワークACL
AWS Network Firewall
Crane, Dylan. AWS Security. Manning Publications, 2022.
Muñoz, Mauricio, et al. Mastering AWS Security, 2nd Edition. Packt, 2024.