第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)の考え方が実務では意識されます。
VPCとサブネットという「土地」の区画
セキュリティグループやネットワークACLを理解するうえで前提になるのが、VPC(Virtual Private Cloud)という、AWSアカウント内に作る仮想的なネットワーク区画です。VPCの中はさらにサブネットという単位に分割され、インターネットから直接アクセスできる「パブリックサブネット」と、直接アクセスできない「プライベートサブネット」を使い分けるのが一般的な設計です。データベースサーバーのようにインターネットから直接アクセスさせたくないインスタンスはプライベートサブネットに置き、Webサーバーのように外部公開が必要なインスタンスだけをパブリックサブネットに置く、という構成がよく使われます。第3章で扱ったSession Managerは、こうしたプライベートサブネット上のインスタンスにも安全に接続できる点で重宝します。
セキュリティグループの既定の挙動
新しく作成したセキュリティグループは、既定ではインバウンド(外部からの通信)をすべて拒否し、アウトバウンド(外部への通信)をすべて許可する状態になっています。運用上は、インバウンドルールに必要な通信元・ポートだけを個別に追加していく形で絞り込みます。アウトバウンド側も必要に応じて制限することで、万が一インスタンスが侵害された場合に外部への不審な通信を防ぐ、という考え方も存在します。
通信元をIPアドレスではなくセキュリティグループで指定する
セキュリティグループのルールでは、通信元を203.0.113.10/32のようなIPアドレスだけでなく、「別のセキュリティグループ」そのものを指定できます。たとえば、Webサーバー用セキュリティグループのインバウンドルールで、通信元を「データベースサーバー用セキュリティグループ」ではなく「アプリケーションサーバー用セキュリティグループ」に設定しておけば、アプリケーションサーバーのインスタンスがどれだけ増減しても、IPアドレスの変更に合わせてルールを書き換える必要がありません。台数が動的に変わりやすいクラウド環境ならではの指定方法で、固定的なIPアドレス管理を前提にしたオンプレミスのファイアウォール運用との違いが表れる部分です。
ネットワークACLを設定する場合の注意点
ネットワークACLはステートレスなため、セキュリティグループとは違い「戻りの通信」も明示的に許可しておく必要があります。たとえば、Webサーバーへのインバウンド通信(80番ポート)を許可する場合、応答パケットの戻り先となるエフェメラルポート(クライアント側が動的に使う1024番以降の一時的なポート)へのアウトバウンド通信も、あわせて許可しておかないと通信が成立しません。
| ルール番号 | 種類 | プロトコル | ポート範囲 | 送信元/送信先 | 許可/拒否 |
|---|---|---|---|---|---|
| 100 | インバウンド | TCP | 80 | 0.0.0.0/0 | ALLOW |
| * | インバウンド | すべて | すべて | 0.0.0.0/0 | DENY |
| 100 | アウトバウンド | TCP | 1024-65535 | 0.0.0.0/0 | ALLOW |
| * | アウトバウンド | すべて | すべて | 0.0.0.0/0 | DENY |
ステートフルなセキュリティグループではこうしたエフェメラルポートを意識する必要がなかったため、ネットワークACLを個別にカスタマイズする場合は、この違いを忘れると「インバウンドは通っているのに応答が返ってこない」という分かりにくい障害につながります。
この章のまとめ
セキュリティグループはインスタンス単位・ステートフル・許可のみ、ネットワークACLはサブネット単位・ステートレス・許可と拒否の両方、という違いを整理しました。さらに、VPC・サブネットというネットワーク区画の考え方と、AWS側のネットワーク制御とOS側のファイアウォールを組み合わせる多層防御の考え方も押さえました。次章では、EC2起動時の初期設定を自動化するuser-dataとAMIを扱います。