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

Amazon VPCでは、リソースに届く通信をセキュリティグループで制御し、サブネットを出入りする通信を**ネットワークACL（ネットワークアクセスコントロールリスト）**で制御できます。両方を適切に使えば、リソース単位の許可設定とサブネット境界の追加制御を組み合わせられます。ただし、それぞれの適用位置と判定方法は異なります。

通信要件を読むときは、「どのリソースに通信させるか」「サブネット全体で何を許可または拒否するか」「応答通信のルールが必要か」を切り分けます。この違いを押さえると、接続開始の許可だけでよい場面と、往路・復路の両方のルールが必要な場面を判断できます。

適用範囲と役割

比較項目	セキュリティグループ	ネットワークACL
関連付ける対象	EC2インスタンスなどのネットワークインターフェイス（ENI）	サブネット
適用される範囲	ENIに届く、またはENIから出る通信	サブネットへ入る通信、サブネットから出る通信
通信状態	ステートフル	ステートレス
ルールで指定する動作	許可	許可または拒否
ルールの評価	すべてのセキュリティグループの許可ルールを適用	方向ごとに番号の小さいルールから評価し、最初の一致を適用
戻り通信	許可した接続の応答を状態に基づいて扱う	応答側の通信も、該当方向のルールで許可する

セキュリティグループはネットワークインターフェイスに関連付けられます。EC2インスタンスを例にすると、インスタンスそのものに加えて、そのインスタンスが使うENIが制御点です。1つのENIには複数のセキュリティグループを関連付けられ、適用される許可ルールが通信可否の判断に使われます。セキュリティグループには明示的な拒否ルールがないため、特定の送信元を拒否したい場合は別の制御方法を検討します。

ネットワークACLはサブネットに関連付けられ、そのサブネットへ入る通信と出る通信を別々に評価します。1つのサブネットに同時に関連付けられるネットワークACLは1つですが、同じネットワークACLを複数のサブネットに関連付けることはできます。サブネット内にある個々のENIの許可設定を置き換えるものではなく、セキュリティグループと併用する境界の制御です。

ネットワークACLはサブネット境界を通る通信を評価します。そのため、同じサブネット内のリソース間の通信をネットワークACLで遮断することはできません。個々のリソース同士の通信を絞るには、それぞれのネットワークインターフェイスに適用するセキュリティグループを使います。

ステートフルとステートレス

ステートフルな制御では、ファイアウォールが許可した接続の状態を追跡します。接続開始時の通信がルールで許可されると、それに対応する応答通信は既存の接続に属するものとして扱われます。このため、応答だけのために逆方向のセキュリティグループルールを追加する必要はありません。

ステートレスな制御では、各パケットを接続履歴とは独立して評価します。ネットワークACLは受信ルールと送信ルールを別々に持ち、片方向の通信を許可しても反対方向の通信は自動では許可されません。要求と応答の両方を成立させるには、パケットが各サブネット境界を通過する方向ごとに必要なルールを設定します。

「ステートフルだから通信をすべて許可する」「ステートレスだからより安全」といった意味ではありません。どちらも設定したルールに従って通信を制御します。違いは、接続状態を使って応答を扱うか、応答も含めて個々の方向のルールを明示するかです。

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

セキュリティグループでは、受信ルールと送信ルールを設定します。ルールはプロトコル、ポート範囲、送信元または送信先で許可する通信を指定します。たとえば、社内向けの在庫管理APIをTCPポート8443で提供するなら、APIサーバーのセキュリティグループで、信頼するアプリケーション層からのTCP 8443受信を許可します。

セキュリティグループは許可ルールの集合です。どのグループにも一致する許可ルールがなければ通信は通りませんが、拒否ルールを追加して例外的にブロックすることはできません。複数のセキュリティグループを同じENIに付けた場合、各グループの許可ルールがまとめて評価されます。番号順に1つのルールだけを選ぶNACLとは評価方法が異なります。

セキュリティグループはステートフルであるため、許可した通信の応答は接続状態に基づいて戻せます。サーバーが受信したAPI要求へ応答するケースでは、受信ルールで要求先ポートを許可すれば、応答のためだけの送信ルールを追加する必要はありません。新しい接続を開始する通信は別に許可が必要です。たとえばサーバー自身から外部のサービスへ新たなHTTPS接続を開始させるなら、その送信通信を送信ルールで許可します。

セキュリティグループのデフォルト

初めて作成したカスタムセキュリティグループでは、受信ルールはありません。送信ルールは初期状態で全送信先への通信を許可する設定が含まれるため、運用要件に応じて必要な宛先やポートに絞ります。

VPCに最初から用意されているデフォルトセキュリティグループは、カスタムグループの初期状態とは異なります。同じデフォルトセキュリティグループが関連付けられたリソースからの受信を許可し、送信はすべて許可します。したがって、「デフォルトのセキュリティグループならVPC内部の通信をすべて許可する」と一律に考えるのではなく、どのグループの初期ルールかを区別します。

ネットワークACLのルール

ネットワークACLでは、受信と送信のそれぞれに番号付きルールを設定します。各ルールはプロトコル、ポート範囲、送信元または送信先のCIDRブロック、許可または拒否する動作を指定します。許可ルールで通常の通信を通しつつ、拒否ルールで特定の送信元ネットワークをブロックする、といった使い方ができます。

ルールは番号の小さい順に評価され、条件が最初に一致したルールの動作が適用されます。たとえば 198.51.100.32/27 からの通信を拒否するルールを番号90に置き、より広い許可ルールを番号100に置けば、拒否ルールが先に評価されます。許可ルールの後に拒否ルールを追加しても、その通信が先行ルールですでに一致していれば、後の拒否ルールは評価されません。明示したルールのいずれにも一致しない通信は暗黙的に拒否されます。

NACLのルール番号は、後からルールを挿入できるよう間隔を空けて割り当てると管理しやすくなります。受信ルールの番号と送信ルールの番号は別々に評価されます。ネットワークACL全体として1本の番号順があるのではなく、通信がサブネットへ入るときは受信側、サブネットから出るときは送信側のルールを確認します。

ネットワークACLのデフォルト

VPCのデフォルトネットワークACLは、初期状態で受信・送信ともにすべてのIPv4通信を許可します。カスタムネットワークACLを新規作成した場合は、初期状態ではユーザー定義の許可ルールがなく、明示的に追加した通信以外は拒否されます。IPv6を使う場合はIPv6用のルールも個別に確認します。

デフォルトネットワークACLの状態を見て「NACLはデフォルトですべて許可」と一般化してはいけません。VPCに用意されるデフォルトACLと、自分で作成するカスタムACLで初期状態が違います。同様に、セキュリティグループもカスタムグループとVPCのデフォルトグループでは受信ルールが異なります。

エフェメラルポートと戻り通信

クライアントがTCP接続を開始すると、接続先サービスの待受ポートに加えて、クライアント側では一時的な送信元ポートが選ばれます。この一時的に割り当てられるポートをエフェメラルポートと呼びます。範囲はOSやクライアント環境によって異なり、固定の1つの範囲がすべての通信元に当てはまるわけではありません。

例として、EC2上のジョブが外部の成果物レジストリにHTTPS接続を開始する場合を考えます。クライアントはローカルのエフェメラルポートを送信元に使い、宛先TCP 443へ要求を送ります。応答は送信元ポート443から始まり、接続を始めたEC2のエフェメラルポートを宛先として戻ります。

この通信をネットワークACLで制御するには、要求がサブネットから出る方向で宛先TCP 443を許可し、応答がサブネットへ戻る方向では宛先となるエフェメラルポートを許可します。ネットワークACLは要求を許可したことを応答の判断に引き継がないため、戻りの受信ルールがなければ応答は遮断されます。実際の許可範囲は、接続元のOS、使用するクライアント、ネットワーク構成に合わせ、必要な範囲に絞って設計します。

セキュリティグループでは、EC2からTCP 443への新規送信を許可すると、その接続の応答通信は状態に基づいて扱われます。応答のためだけに受信側のエフェメラルポート範囲をルールへ追加する必要はありません。セキュリティグループとネットワークACLで、同じ接続の戻り通信に必要なルールが異なる理由がここにあります。

外部クライアントがサーバーへ接続する場合も同じ考え方です。サーバーのサブネットへ入る要求ではサービスの待受ポートを、応答がサブネットから出るときはクライアントが接続開始時に使用したエフェメラルポートを確認します。サーバーのセキュリティグループでは要求を許可する受信ルールが必要ですが、確立した接続の応答は状態に基づいて許可されます。

多層防御としての組み合わせ

セキュリティグループはENIに適用する許可ルール、ネットワークACLはサブネット境界の許可・拒否ルールとして役割を分けます。たとえばアプリケーション用サブネットでは、セキュリティグループでAPIサーバーへの必要な接続だけを許し、ネットワークACLで特定の送信元CIDRをサブネット境界で拒否できます。

この構成でも、NACLがセキュリティグループのルールを書き換えたり、SGにない拒否ルールを追加したりするわけではありません。それぞれが適用位置で評価されるため、通信には必要な制御すべてを通過する条件が必要です。NACLはサブネット間やサブネット外との境界通信に適用され、同じサブネット内の通信を止める手段にはなりません。

通信が通らないときは、送信元のENIに付いた全セキュリティグループの許可、宛先のENIに付いた全セキュリティグループの許可、経路上の各サブネットに関連付けられたNACLの両方向ルールを確認します。ステートフルな制御の応答許可と、ステートレスな制御で必要な往路・復路のルールを混同しないことが重要です。

学習の要点

• セキュリティグループはENI単位：EC2などのネットワークインターフェイスに関連付ける。許可ルールのみを定義し、明示的拒否はできない。
• ネットワークACLはサブネット単位：受信と送信のルールを分け、許可と拒否の両方を定義できる。同じサブネット内だけで完結する通信には適用されない。
• 状態を追跡するかで応答ルールが変わる：セキュリティグループは許可済み接続の応答を状態に基づいて扱う。NACLは戻り方向も独立に評価する。
• NACLは最初に一致したルールを使う：番号の小さい順に受信・送信それぞれを評価するため、拒否ルールを許可ルールより前に置く。
• デフォルトルールは対象を区別する：デフォルトSGは同じグループからの受信と全送信を許可するが、新規カスタムSGには受信許可がない。デフォルトNACLは全許可、カスタムNACLは初期状態で全拒否。
• エフェメラルポートは接続元が選ぶ一時ポート：ステートレスなNACLでは宛先サービスのポートだけでなく、応答先のエフェメラルポートも方向ごとに許可する。
• 二つの制御を組み合わせる：ENI単位の許可とサブネット境界の追加制御を重ね、通信経路上の各ルールが接続開始と応答の両方に合うことを確認する。

公式ドキュメント

• セキュリティグループ
• セキュリティグループの接続追跡
• ネットワークACL