ネットワーク ACL とセキュリティグループ

AWSは、VPC内で異なる2種類のファイアウォール機構を提供しています。Security Groupsはインスタンスレベル（厳密にはENIレベル）で動作し、ステートフルです。Network Access Control Lists（NACLs）はサブネットレベルで動作し、ステートレスです。サブネットおよび関連付けられたインスタンスに出入りするすべてのトラフィックに対して、両方が評価されます。両方を組み合わせることで多層防御を実現できます。NACLはサブネット境界での第一線の防御、Security Groupはインスタンスごとのファイアウォールとして機能します。SAA-C03試験では、この2つの機構の比較が頻繁に出題されます。

Network ACL（NACL）は、サブネットの境界を通過するすべてのトラフィックに適用される、番号付きルールのリストです。NACLはステートレスであり、各パケットを個別に評価します。インバウンドTCPポート80を許可する場合、応答がサブネットから出ていけるように、戻りのアウトバウンドトラフィック（エフェメラルポート1024-65535）も明示的に許可する必要があります。ルールは番号の小さい順に評価され、最初に一致したルールが適用され、それ以降のルールは確認されません。各VPCには、すべてのインバウンドおよびアウトバウンドトラフィックを許可するデフォルトNACLが付属します。

NACLルールはルール番号の昇順（1から32766）で評価され、ルールが一致すると直ちに評価が停止します。同じトラフィックに対して、番号の小さいAllowルールであっても、さらに小さい番号のDenyルールによって上書きされます。AWSは、後からルールを挿入できるように、10または100刻みでルール番号を付けることを推奨しています。すべてのNACLの末尾にはデフォルトルール（* DENY）があり、明示的なルールに一致しないすべてのトラフィックを拒否します。この包括的なルールは編集も削除もできません。

NACLはステートレスであるため、すべての接続について両方向を考慮する必要があります。インターネット上のクライアントがポート443でEC2インスタンスに接続すると、インスタンスはクライアントのエフェメラルポート（ランダムな高位ポート。通常、Linuxでは1024-65535、Windowsでは49152-65535）に応答を返します。NACLのアウトバウンドルールでは、この範囲を明示的に許可する必要があります。NACLでよくある設定ミスは、インバウンドのポート443に対するAllowルールを作成したものの、アウトバウンドのエフェメラルポートを許可し忘れることです。その結果、接続は確立されても応答が黙って破棄されます。

ここで振り返りましょう。security groupsはインスタンス（またはENI）に関連付けられ、明示的なAllowルールのみを許可します（Denyはありません）。また、ステートフルであるため、許可されたインバウンドトラフィックへの応答は、ルールがなくても自動的にアウトバウンドで許可されます。関連付けられたすべてのルールをORロジックでまとめて評価します。送信元または送信先として他のSecurity Group IDを参照できるため、IP範囲を指定するよりも管理しやすくなります。Security Groupはインスタンスレベルのアクセス制御における主要な機構であり、NACLはサブネットレベルの追加層として機能します。

試験で重要な比較です。

• レベル：NACL = サブネット、SG = インスタンス（ENI）
• 状態：NACL = ステートレス、SG = ステートフル
• ルール：NACL = AllowとDeny、SG = Allowのみ（暗黙的な拒否）
• 評価：NACL = 順番に評価（最初の一致を採用）、SG = すべてのルールを評価（Allowが1つでもあれば許可）
• 適用範囲：NACLはサブネット内のすべてのインスタンスに適用、SGは関連付けられたインスタンスのみに適用
• インバウンド/アウトバウンド：NACLは両方向に明示的なルールが必要、SGはステートフル（応答にはインバウンドルールだけで対応可能）

NACLは次の用途に使用します。特定のIPをブロックする（Security Groupは拒否できず許可のみですが、NACLでは明示的なDenyルールを追加して、既知の悪意あるIPやスクレイパーをブロックできます）。サブネット全体に適用するルール（個々のSecurity Groupを変更せず、サブネット内のすべてのインスタンスに同じルールを適用できます）。追加の防御層（Security Groupの設定ミスで誤ってアクセスを許可してしまった場合でも、サブネット境界のNACL Denyルールでトラフィックをブロックできます）。実際には、多くのチームが主にSecurity Groupでアクセスを管理し、NACLは明示的なIPブロックに限定して使用しています。

すべてのVPCとともに作成されるデフォルトNACLは、すべてのインバウンドおよびアウトバウンドトラフィックを許可します。ルール100のAllow All Inboundと、ルール100のAllow All Outboundが設定されています。カスタムNACLに明示的に関連付けられていないサブネットは、デフォルトNACLを使用します。カスタムNACLを作成すると、デフォルトのDeny-Allルール（ルール*）だけが設定された状態で開始されるため、明示的なAllowルールを追加するまで、すべてのトラフィックがブロックされます。つまり、新しいカスタムNACLをサブネットに関連付けると、すべてのトラフィックが直ちにブロックされます。本番サブネットに関連付ける前に、必ずAllowルールを追加してください。

EC2インスタンスへのインバウンドトラフィックでは、まずサブネット境界のNACLを通過します（ルール順に評価されます）。NACLがトラフィックを許可すると、次にインスタンスのsecurity groupに到達し、Security Groupでも許可される必要があります。インスタンスに到達するには、両方がトラフィックを許可しなければなりません。アウトバウンドトラフィックでは、まずSecurity Groupが評価されます（ステートフルであり、許可されたインバウンドへの応答であれば許可します）。その後NACLが評価されます（ステートレスであるため、明示的なアウトバウンドAllowが必要です）。この順序を理解すると、ステートフルなSecurity Groupを使用していても、ステートレスなNACLに戻りのトラフィック用ルールが必要な理由が明確になります。

NACLはステートレスであるため、原因の特定が難しいネットワーク問題の一般的な原因になります。症状には、接続は確立するもののデータ転送が停止する（アウトバウンドのエフェメラルポートルールがない）、一方向にしかトラフィックが流れない（インバウンドまたはアウトバウンドルールがない）、特定のIPから接続できない（Allowルールより前に、番号の小さいDenyルールが一致している）などがあります。デバッグにはVPC Flow Logsを使用して、NACLレベルでパケットが ACCEPT か REJECT かを確認します。フローログには拒否されたパケットとその送信元/送信先が表示されるため、不足しているルールを特定するのに役立ちます。

多層 VPC セキュリティで推奨されるパターンは次のとおりです。パブリックサブネットのNACLでは、インターネットからのポート 80、443、および必要なエフェメラルポートのみを許可し、それ以外はすべて拒否します。ALB のパブリックサブネットのセキュリティグループでは、0.0.0.0/0 からの 80/443 のみを許可します。プライベートアプリケーションのセキュリティグループでは、ALB のセキュリティグループ ID からの通信のみを許可します。プライベートデータ層のセキュリティグループでは、アプリケーションのセキュリティグループ ID からの通信のみを許可します。この多層防御により、あるレイヤーの設定に誤りがあっても、別のレイヤーが保護を提供できます。これはすべてのレイヤーで最小限のアクセス権を設定するという原則です。

このレッスンで学んだ AWS Solutions Architect (SAA-C03) の概念について、理解度を確認しましょう。

このレッスンでは、NACL はサブネットレベルのステートレスなファイアウォールで、Allow と Deny の両方のルールをサポートし、番号順に評価されること、セキュリティグループはインスタンスレベルのステートフルなファイアウォールで、Allow ルールのみを使用し、すべてのルールがまとめて評価されること、そして明示的な IP ブロックやサブネット全体に適用するルールには NACL を、きめ細かなインスタンスアクセス制御にはセキュリティグループを使用することを学びました。これで VPC Basics モジュールは完了です。次は AWS の RDS とリレーショナルデータベースについて学びます。