セキュリティグループ vs ネットワークACL:AWS VPCファイアウォールの選択
AWS VPCセキュリティの複雑さを理解するには、セキュリティグループ(SG)とネットワークACL(NACL)の違いを習得することが重要です。このエキスパートガイドでは、両方の制御の範囲、ステートフル性、ルール評価について説明します。SGがきめ細かいステートフルなインスタンス保護に最適であり、NACLが広範なステートレスなサブネットセグメンテーションと明示的な拒否ポリシーに不可欠である理由を学びます。クラウドインフラストラクチャに堅牢な多層ファイアウォール戦略を実装しましょう。
セキュリティグループ vs ネットワークACL:AWS VPCファイアウォールの選択
Amazon Web Services(AWS)で安全なVirtual Private Cloud(VPC)環境を設計する際、管理者はネットワークトラフィックを管理するために複数の制御層に依存します。ネットワークレベルでトラフィックをフィルタリングするための2つの基本コンポーネントは、セキュリティグループ(SG)とネットワークアクセスコントロールリスト(NACL)です。
コンソールでは似ていますが、失敗の仕方は大きく異なります。セキュリティグループは通常、アプリケーションの意図を記述する場所です。ネットワークACLは、広範なサブネット境界や緊急拒否を強制する場所です。
AWS VPCにおけるファイアウォールの役割
AWSはVPC内で2つの主要なレベルでネットワークセキュリティを提供します。
- インスタンスレベル(セキュリティグループ): 特定のEC2インスタンスやリソース(RDSデータベースやElastic Load Balancerなど)のファイアウォールとして機能します。ネットワークインターフェースへのトラフィックを制御します。
- サブネットレベル(ネットワークACL): サブネット全体のステートレスファイアウォールとして機能し、サブネット境界に入る、または出るトラフィックフローを制御します。
セキュリティグループ(SG)の詳細
セキュリティグループは、個々のリソースに対する主要なきめ細かいファイアウォールとして機能します。これらはステートフルであり、プロトコル、ポート、送信元または送信先でフィルタリングします。
セキュリティグループの主な特徴
| 機能 | 説明 | 使用への影響 |
|---|---|---|
| スコープ | インスタンスのElastic Network Interface(ENI)に直接適用されます。 | インスタンスへのおよびからのトラフィックフローを制御します。 |
| ステートフル性 | ステートフル。 インバウンドリクエストが明示的に許可されている場合、対応するリターントラフィック(アウトバウンド応答)は、アウトバウンドルールに関係なく自動的に許可されます。 | 設定を簡素化します。開始するトラフィックの方向のみを定義する必要があります。 |
| ルールタイプ | 許可のみ。 明示的な拒否ルールは不可能です。明示的なALLOWルールに一致しないトラフィックは暗黙的に拒否されます。 |
何が許可されるかを定義することに焦点を当てます。 |
| 評価 | 決定が下される前にすべてのルールが評価されます。番号は付けられておらず、すべてのALLOWルールが失敗するまで暗黙のDENYは処理されません。 |
順序は重要ではありません。すべてのルールは平等に扱われます。 |
セキュリティグループ設定例
EC2インスタンスへのSSHアクセス(ポート22)を許可するには、インバウンドルールのみが必要です。SSH応答のアウトバウンドルールは、SGのステートフルな性質によって自動的に処理されます。
| タイプ | プロトコル | ポート範囲 | 送信元 | 説明 |
|---|---|---|---|---|
| インバウンド | TCP | 22 | 0.0.0.0/0(または特定の管理者IP) | SSHアクセスを許可 |
| アウトバウンド | すべて | すべて | 0.0.0.0/0 | (デフォルト:すべてのトラフィックを許可しますが、必要に応じて制限できます) |
# ステートフルフローの概念的な表現
ユーザー(送信元IP) --> [インバウンドSGルール:許可22] --> EC2インスタンス
EC2インスタンス(応答) --> [暗黙の状態追跡] --> ユーザー(応答受信)
ベストプラクティスのヒント: セキュリティグループルールは常に最小権限の原則を使用して定義してください。可能な限り、0.0.0.0/0を許可する代わりに、送信元IP範囲を制限してください。
ネットワークACL(NACL)の詳細
ネットワークACLは、サブネット境界でステートレスフィルターとして機能する2番目の防御層を提供します。これらはネットワークセグメンテーションと広範な拒否ポリシーに強力です。
ネットワークACLの主な特徴
| 機能 | 説明 | 使用への影響 |
|---|---|---|
| スコープ | VPCサブネット全体に適用されます。サブネットは一度に1つのNACLにのみ関連付けることができます。 | サブネットに入る、または出るすべてのトラフィックを制御し、その中のすべてのインスタンスに影響を与えます。 |
| ステートフル性 | ステートレス。 インバウンドリクエストと対応するアウトバウンド応答の両方を明示的に許可する必要があります。 | リターントラフィック(エフェメラルポート)の注意深い設定が必要です。 |
| ルールタイプ | 許可と拒否。 トラフィックを許可またはブロックするルールを明示的に定義できます。 | 既知の悪意のあるIPをブロックしたり、特定のプロトコルをネットワーク全体で拒否したりするのに最適です。 |
| 評価 | ルールには番号(1から32766)が付けられ、最も低い番号から順に評価されます。最初に一致したルールがすぐに適用されます。 | ルールの順序は重要です。暗黙の拒否ルール(最後に処理されるルール)は、明示的に許可されていないすべてを拒否します。 |
ステートレストラフィックの処理(エフェメラルポート)
NACLはステートレスであるため、サーバーに接続するクライアントが使用するエフェメラルポートを考慮する必要があります。クライアントが接続を開始するとき、宛先ポート(例:HTTPの場合は80)と高い番号の送信元ポート(エフェメラルポート範囲、通常1024-65535)を使用します。
サブネットへのWebトラフィック(HTTP)を許可するには、2つのルールが必要です。
- インバウンドルール: 宛先ポート(例:80)のトラフィックを許可します。
- アウトバウンドルール: エフェメラル送信元ポートを使用してクライアントに戻るリターントラフィックを許可します。
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元/宛先 | ルールアクション |
|---|---|---|---|---|---|
| 100 | インバウンド | TCP | 80 | 0.0.0.0/0 | 許可(Webトラフィック入力) |
| 110 | アウトバウンド | TCP | 1024-65535 | 0.0.0.0/0 | 許可(Web応答出力 - エフェメラルポート) |
| * | 暗黙の拒否 | すべて | すべて | すべて | 拒否(最後に処理) |
警告: NACLでエフェメラルポートの対応するアウトバウンドルールを忘れると、トラフィックはインスタンスに到達しますが(インバウンドルールによる)、応答はサブネット境界でドロップされ、接続タイムアウトが発生します。
比較概要:SG vs NACL
次の表は、2つのファイアウォールタイプの重要な違いをまとめたものです。
| 機能 | セキュリティグループ(SG) | ネットワークACL(NACL) |
|---|---|---|
| 適用範囲 | インスタンス/ENIレベル | サブネットレベル |
| 状態 | ステートフル | ステートレス |
| ルールタイプ | 許可のみ | 許可と拒否 |
| ルール評価 | すべてのルールが評価され、特定の順序はありません。 | ルールは番号順に評価され(最も低いものが最初)、最初に一致したものが優先されます。 |
| デフォルト動作 | すべてのインバウンドを拒否し、すべてのアウトバウンドを許可します(制限がない場合)。 | デフォルトのNACLはすべてのインバウンド/アウトバウンドを許可します。カスタムNACLはすべてのインバウンド/アウトバウンドを拒否します。 |
| トラフィックへの影響 | トラフィックが関連付けられたリソース宛てまたは発信されている場合にのみルールを適用します。 | サブネット境界を通過するトラフィックをフィルタリングし、サブネット内のすべてのリソースに影響を与えます。 |
適切なファイアウォールの選択:シナリオとベストプラクティス
成功するVPCセキュリティは、SGとNACLを多層アプローチ(多層防御)で一緒に使用することに依存しています。
セキュリティグループを優先する場合
セキュリティグループは、そのステートフルな性質と他のSGを参照できる機能により、アプリケーション設定を簡素化するため、ネットワークアクセスをフィルタリングするための主要なツールであるべきです。
- きめ細かいアプリケーション制御: SGを使用して、特定のアプリケーションに必要なポートとプロトコルを正確に定義します(例:WebサーバーSGからデータベースSGへのポート3306のトラフィックのみを許可する)。
- 内部通信: 同じサブネット内またはサブネット間のインスタンス間のトラフィックのセキュリティを管理します(例:ロードバランサーがターゲットグループと通信できるようにする)。
- 管理の容易さ: ステートフルであるため、SGは必要なルールが少なく、NACLでエフェメラルポートを管理するよりもエラーが発生しにくいです。
ネットワークACLを実装する場合
NACLは、広範なネットワーク全体の境界とセグメンテーションポリシーを設定するのに最適です。
- 広範な拒否ポリシー: 明示的な
DENYルール(ルール番号100)を使用して、トラフィックがインスタンスに到達する前に、サブネット全体で特定の悪意のあるIPアドレスまたはIP範囲をブロックします。 - サブネットセグメンテーション: アーキテクチャの層間に厳格な境界を強制します(例:データベースサブネットNACLが、SGの設定方法に関係なく、インターネットからのすべてのインバウンドトラフィックを明示的に拒否するようにする)。
- コンプライアンス要件: 特定のコンプライアンス基準ではサブネットレベルのフィルタリングが必須となる場合があり、NACLが不可欠になります。
- ステートレスプロトコルフィルタリング: SGが単独で効果的に管理できないステートレスプロトコルをフィルタリングする必要がある場合、NACLが必要です(ただし、標準のTCP/UDPトラフィックではこれはまれです)。
障害を引き起こす間違い
最も一般的なNACLの障害は、リターントラフィックを忘れることです。誰かがパブリックサブネットへのインバウンドTCP 443を許可し、アウトバウンドルールを厳しくしすぎます。ロードバランサーまたはインスタンスはSYNを受信しますが、応答は送信時にドロップされます。クライアント側からはタイムアウトのように見え、インスタンス側からはサービスが完全に正常に見える場合があります。
もう1つの間違いは、アプリケーションごとのポリシーにNACLを使用することです。サブネットにWeb、ワーカー、管理インスタンスが含まれている場合、1つのNACLがそれらすべてに適用されます。あるワークロードのために追加されたルールが、同じサブネット内の別のワークロードを予期せず公開したり、壊したりする可能性があります。異なるネットワーク動作が必要な場合は、異なるセキュリティグループを使用し、実際に強制する境界がある場合にのみ、個別のサブネットを検討してください。
ルール番号付けにも注意が必要です。後で緊急ルールを挿入できるように、1、2、3ではなく、100、110、120などの間隔を空けてください。最初に一致したルールが優先されることを忘れないでください。ルール90での拒否は、コンソールを素早く見た人にはより具体的に見えても、ルール100での許可に勝ります。
セキュリティグループの場合、よくある間違いは広範な送信元範囲です。パブリックロードバランサーの443での0.0.0.0/0は正常かもしれません。SSH、RDP、Redis、PostgreSQL、または内部管理APIでの同じ送信元は、通常は問題です。VPC内ではセキュリティグループ参照を優先し、オペレーターアクセスには狭いCIDRを使用してください。
既存のVPCを引き継ぐ場合は、ルールをエクスポートし、目的別にグループ化してください:パブリックエントリポイント、アプリ間トラフィック、データストア、管理、緊急拒否。明確な所有者や理由がないルールは、古い露出が通常存在する場所です。
多層防御アプローチ
典型的な適切に設計されたVPCでは、トラフィックフローはNACLとセキュリティグループの両方を通過する必要があります。いずれかのセキュリティ制御がトラフィックを拒否すると、パケットはドロップされます。
- インバウンドフロー: トラフィックがサブネットに入る -> NACLがルールをチェック -> トラフィックがインスタンスENIに到達 -> セキュリティグループがルールをチェック -> トラフィックがアプリケーションに到達。
- アウトバウンドフロー: アプリケーションが応答を生成 -> セキュリティグループ(ステートフルチェック合格) -> トラフィックがインスタンスENIを出る -> NACLがルールをチェック -> トラフィックがサブネットを出る。
NACLを大まかなセグメンテーションと拒否ルールに活用し、SGを正確でステートフルなアプリケーションレベルの許可に活用することで、設定のシンプルさを維持しながらセキュリティの効果を最大化できます。
実用的な設計パターン
ほとんどのアプリケーションVPCでは、セキュリティグループから始めてください。ロードバランサーにパブリック向けセキュリティグループを、アプリケーションインスタンスにロードバランサーセキュリティグループからのトラフィックのみを受け入れるセキュリティグループを、データベースにアプリケーションセキュリティグループからのデータベースポートのトラフィックのみを受け入れるセキュリティグループを割り当ててください。このモデルはアプリケーションの依存関係グラフに従い、IP変更にも耐えます。
NACLはより控えめに使用してください。NACLの良いユースケースは、既知の悪意のあるCIDRに対するサブネットレベルの拒否、データベースサブネットの周りのハードバウンダリ、またはサブネット内の任意のENIにトラフィックが到達する前に適用する必要があるコンプライアンスルールです。チームがすべてのアプリケーションルールをそこにミラーリングしようとすると、NACLは面倒になります。ステートレスのリターンポートルールは間違えやすく、1つの低番号の拒否がサブネット全体を壊す可能性があります。
接続がタイムアウトした場合は、パケットパスの両方の層を確認してください。パブリックサブネット内のEC2インスタンスへのインバウンドインターネットトラフィックの場合、リクエストはインバウンドNACLルール、ルートテーブル、およびインバウンドセキュリティグループルールを通過する必要があります。応答は、ステートフルセキュリティグループ追跡とアウトバウンドNACLルールを通過する必要があります。SGが正しく見えてもクライアントがハングする場合、NACLのエフェメラルポートルールが欠落していることがよくあります。
最も明確なメンタルモデルは次のとおりです。セキュリティグループは、どのリソースがどの他のリソースと通信できるかを示します。NACLは、サブネットが決して許可しないものを示します。これらの役割を分離しておけば、設計の監査が容易になります。