第4章 セキュリティグループとLinuxファイアウォールの違い

これまで学んだfirewalld・iptables・nftablesといったLinux側のファイアウォールと、AWS側のセキュリティグループ・ネットワークACLの役割の違いを整理し、それぞれをどう使い分けるかを扱います。

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

セキュリティグループは、EC2インスタンス(正確にはネットワークインターフェース)単位で適用される、ステートフルな許可(Allow)ルールの集合です。拒否(Deny)ルールは設定できず、許可しない通信はすべて拒否される、という設計になっています。「ステートフル」とは、行きの通信を許可すれば戻りの通信は自動的に許可される、という意味で、Linuxのiptables/nftablesにおけるconntrackによるステート管理と似た考え方です。

ネットワークACL(NACL)との違い

ネットワークACLは、セキュリティグループとは異なりサブネット単位で適用され、ステートレス(行きと戻りそれぞれに個別のルールが必要)で、許可・拒否の両方のルールを番号順に評価します。多くの構築では、セキュリティグループだけで通信制御を行い、ネットワークACLは既定のまま(すべて許可)にしておくことも少なくありませんが、両者の違いは理解しておく必要があります。

セキュリティグループネットワークACL
適用範囲インスタンス(ネットワークインターフェース)単位サブネット単位
ステートステートフル(戻りの通信は自動許可)ステートレス(行き・戻り両方に設定が必要)
ルール許可(Allow)のみ許可・拒否の両方、番号順に評価

OS側のファイアウォールとの役割分担

セキュリティグループやネットワークACLは、インスタンスの外側(AWSのネットワークレイヤー)で通信そのものを遮断する「外側の壁」にあたります。一方、firewalldやiptables/nftablesといったOS側のファイアウォールは、インスタンス内部でさらに細かい制御を行う「内側の壁」です。片方だけに頼るのではなく、両方を組み合わせて防御する多層防御(defense in depth)の考え方が実務では意識されます。

よくある間違い: セキュリティグループで通信を許可しているのに、OS側のfirewalldでブロックされていて接続できない、あるいはその逆に気づかない、というトラブルはよく起こります。接続できないときは、AWS側とOS側の両方の設定を順番に確認する習慣をつけましょう。

VPCとサブネットという「土地」の区画

セキュリティグループやネットワークACLを理解するうえで前提になるのが、VPC(Virtual Private Cloud)という、AWSアカウント内に作る仮想的なネットワーク区画です。VPCの中はさらにサブネットという単位に分割され、インターネットから直接アクセスできる「パブリックサブネット」と、直接アクセスできない「プライベートサブネット」を使い分けるのが一般的な設計です。データベースサーバーのようにインターネットから直接アクセスさせたくないインスタンスはプライベートサブネットに置き、Webサーバーのように外部公開が必要なインスタンスだけをパブリックサブネットに置く、という構成がよく使われます。第3章で扱ったSession Managerは、こうしたプライベートサブネット上のインスタンスにも安全に接続できる点で重宝します。

セキュリティグループの既定の挙動

新しく作成したセキュリティグループは、既定ではインバウンド(外部からの通信)をすべて拒否し、アウトバウンド(外部への通信)をすべて許可する状態になっています。運用上は、インバウンドルールに必要な通信元・ポートだけを個別に追加していく形で絞り込みます。アウトバウンド側も必要に応じて制限することで、万が一インスタンスが侵害された場合に外部への不審な通信を防ぐ、という考え方も存在します。

通信元をIPアドレスではなくセキュリティグループで指定する

セキュリティグループのルールでは、通信元を203.0.113.10/32のようなIPアドレスだけでなく、「別のセキュリティグループ」そのものを指定できます。たとえば、Webサーバー用セキュリティグループのインバウンドルールで、通信元を「データベースサーバー用セキュリティグループ」ではなく「アプリケーションサーバー用セキュリティグループ」に設定しておけば、アプリケーションサーバーのインスタンスがどれだけ増減しても、IPアドレスの変更に合わせてルールを書き換える必要がありません。台数が動的に変わりやすいクラウド環境ならではの指定方法で、固定的なIPアドレス管理を前提にしたオンプレミスのファイアウォール運用との違いが表れる部分です。

実務のヒント: 特定の管理者のIPアドレスからのSSH接続だけを許可する、といった固定的な通信元にはIPアドレス指定が向いていますが、同じAWS環境内のサーバー同士の通信には、セキュリティグループ同士の指定を使うほうが管理がシンプルになることが多いです。

ネットワークACLを設定する場合の注意点

ネットワークACLはステートレスなため、セキュリティグループとは違い「戻りの通信」も明示的に許可しておく必要があります。たとえば、Webサーバーへのインバウンド通信(80番ポート)を許可する場合、応答パケットの戻り先となるエフェメラルポート(クライアント側が動的に使う1024番以降の一時的なポート)へのアウトバウンド通信も、あわせて許可しておかないと通信が成立しません。

ルール番号種類プロトコルポート範囲送信元/送信先許可/拒否
100インバウンドTCP800.0.0.0/0ALLOW
*インバウンドすべてすべて0.0.0.0/0DENY
100アウトバウンドTCP1024-655350.0.0.0/0ALLOW
*アウトバウンドすべてすべて0.0.0.0/0DENY

ステートフルなセキュリティグループではこうしたエフェメラルポートを意識する必要がなかったため、ネットワークACLを個別にカスタマイズする場合は、この違いを忘れると「インバウンドは通っているのに応答が返ってこない」という分かりにくい障害につながります。

この章のまとめ

セキュリティグループはインスタンス単位・ステートフル・許可のみ、ネットワークACLはサブネット単位・ステートレス・許可と拒否の両方、という違いを整理しました。さらに、VPC・サブネットというネットワーク区画の考え方と、AWS側のネットワーク制御とOS側のファイアウォールを組み合わせる多層防御の考え方も押さえました。次章では、EC2起動時の初期設定を自動化するuser-dataとAMIを扱います。

確認クイズ

Q1. セキュリティグループの特徴として、正しい説明はどれですか?

解説: セキュリティグループはステートフルな許可ルールのみを設定でき、行きの通信を許可すれば戻りの通信は自動的に許可されます。

Q2. セキュリティグループとネットワークACL(NACL)の違いの説明として、正しいものはどれですか?

解説: セキュリティグループはステートフルでインスタンス(ネットワークインターフェース)単位、ネットワークACLはステートレスでサブネット単位に適用される、という違いがあります。

Q3. 「セキュリティグループでは通信を許可しているのに、実際にはEC2インスタンスに接続できない」というトラブルの原因として、確認すべき点はどれですか?

解説: セキュリティグループを許可していても、インスタンス内部のOS側ファイアウォール(firewalldやiptables/nftablesなど)でブロックされていると接続できないため、両方を確認する必要があります。