セキュリティグループとネットワークACLって何が違うの?
こんにちは、kkです。
本日はAWSのセキュリティサービスである、セキュリティグループとネットワークACLについて
お話しようと思います。
AWSを触っていてよく耳にするセキュリティグループとネットワークACLですが、
これらの違いは何なのでしょうか。
本記事では具体的な例をもとに、セキュリティグループとネットワークACLの違いについて
お話していきます。
セキュリティグループとネットワークACLの概要
2つの違いについてお話する前に、それぞれの概要を把握していきましょう。
セキュリティグループについて
まずはセキュリティグループについてです。
セキュリティグループについては、AWSの公式ドキュメントでは下記のように説明されています。
セキュリティグループは、関連付けられたリソースに到達するトラフィックおよびリソースから離れるトラフィックを制御します。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_SecurityGroups.html
例えば、セキュリティグループを EC2 インスタンスに関連付けると、インスタンスのインバウンドトラフィックとアウトバウンドトラフィックが制御されます。
このようにセキュリティグループは、関連付けられたリソース(EC2など)に対して
インバウンドトラフィックとアウトバウンドトラフィックを制御することができます。
そのため、自宅のPCからAWSのEC2にSSHなどで接続しようとすると、
自宅のIPを接続したいEC2に関連付けられているセキュリティグループで
許可設定する必要がある場合も多いかと思います。
セキュリティグループはデフォルトセキュリティグループと、カスタムセキュリティグループに
分かれます。
デフォルトセキュリティグループはインスタンス起動の際に、セキュリティグループを指定しないと
自動的に選択されるセキュリティグループで、VPCを作成すると自動で作成されます。
またカスタムセキュリティグループは自身で名前を付け、
用途ごとに複数作成することが可能となっています。
Webサーバ用やメールサーバなど用途によって、
セキュリティグループを作成しておくと便利かもしれません。
ネットワークACLについて
続いてネットワークACLについてです。
ネットワークACLも公式ドキュメントの記述を見ていきましょう。
ネットワークアクセスコントロールリスト (ACL) は、
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-network-acls.html
サブネットレベルで特定のインバウンドまたはアウトバウンドのトラフィックを
許可または拒否します。
ネットワークACLは上記のような説明でした。
なんだかセキュリティグループと似たような説明ですね。
違いについては次章でお話するとして、ここではネットワークACLそのものを見ていきましょう。
ネットワークACLはサブネット単位で通信可否の設定が可能です。
そのため例えば、Aサブネット内でEC2が複数台稼働している場合はすべてのEC2で
Aサブネットに関連づいたネットワークACLの設定が適用されます。
ネットワークACLにもデフォルトネットワークACLとカスタムネットワークACLに分かれます。
まずはデフォルトネットワークACLについてみていきましょう。
これはVPCを作成すると自動で作成されるものになります。
下記がデフォルトネットワークACLのデフォルト設定となります。
- インバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可(Allow) |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否(Deny) |
- アウトバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信先 | 許可/拒否 |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可(Allow) |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否(Deny) |
インバウンドルール、アウトバウンドルールともに許可(Allow)と拒否(Deny)の設定がありますね。
ここで注目していただきたいのは、「ルール番号」です。
インバウンドルール、アウトバウンドルールのどちらも許可(Allow)のルール番号が
「100」になっており、拒否(Deny)のルール番号が「＊」となっていますね。
ルール番号は数が小さい順に適用され、
どのルールにもあてはまらない場合は「＊」のルールが適用されます。
ですので上記の画像の通り、デフォルトルールはインバウンドトラフィックと、
アウトバウンドトラフィックともに全て許可となっています。
カスタムネットワークACLは、VPC作成とは別に自身で作成することも可能であり、
こちらもカスタムセキュリティグループ同様、用途によって複数作成するものです。
ここまでがセキュリティグループとネットワークACLについての大まかな説明となります。
この2つについてはまだまだ言及する部分もありますが、一旦ここで両者の違いについて
触れていこうと思います。
セキュリティグループとネットワークACLの違い
今回は大きな違いをいくつか紹介しようと思います。
ステートフルとステートレス
初めにステートフルとステートレスについてお話していきます。
セキュリティグループは「ステートフル」であり、ネットワークACLは「ステートレス」という
特性があります。
ここがまず大きな違いとなります。
そもそもステートフルとステートレスとは何でしょうか。
簡潔にいうと、前回の状態を保持するのかしないのかといった違いです。
ステートフルが前回の状態を保持する、ステートレスが前回の状態を保持しないものになります。
このように言われてもあまりピンとこないと思います。
そのため、具体的な例を挙げてみていきましょう。
まずはセキュリティグループについて確認していきましょう。
設定は下記の通りにしています。
- インバウンドルール
| IP バージョン | タイプ | プロトコル | ポート範囲 | ソース |
| IPv4 | SSH | TCP | 22 | 0.0.0.0/0 |
※上記の他、「名前」や「セキュリテグループID」等を設定しますが今回は省略しています。
アウトバウンドルールは「許可設定なし」としています。
また、ネットワークACLはデフォルトのままです。
(インバウンドルール、アウトバウンドルールともにすべて許可)
上記のように設定したセキュリティグループを関連付けたEC2にSSH接続してみましょう。
[kk-test3@ip-10-0-0-108 ~]$ curl inet-ip.info
54.255.173.44
[kk-test3@ip-10-0-0-108 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
Last login: Sat Feb 25 17:22:09 2023 from ec2-54-255-173-44.ap-southeast-1.compute.amazonaws.com
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[kk-test1@ip-10-0-0-104 ~]$ curl inet-ip.info
175.41.233.136接続できましたね。
これは問題なさそうです。
続いてネットワークACLです。
セキュリティグループは上記のままネットワークACLのみ設定を変更してみましょう。
ネットワークACLは下記のような設定にしました。
アウトバウンドルールを全拒否しています。
- インバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | SSH | TCP | 22 | 0.0.0.0/0 | 許可 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
- アウトバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
SSH接続してみましょう。
[kk-test3@ip-10-0-0-108 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
ssh: connect to host 175.41.233.136 port 22: Connection timed out今回はタイムアウトで接続できませんでしたね。
ではアウトバウンドルールを全許可にしてみましょう。
- アウトバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
[kk-test3@ip-10-0-0-108 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
Last login: Sat Feb 25 17:54:26 2023 from ec2-54-255-173-44.ap-southeast-1.compute.amazonaws.com
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[kk-test1@ip-10-0-0-104 ~]$接続できましたね。
セキュリティグループの場合はインバウンドルールで許可したのみで、接続できましたが
ネットワークACLはアウトバウンドルールも明示的に許可しないと接続できないようです。
これがステートフルとステートレスの違いです。
ステートフルは前回の状態を保持するため、
行きの通信を許可すれば自動的に戻りの通信が許可されます。
そのためセキュリティグループはインバウンドルールのみ設定すれば、
SSH接続できるようになります。
行きの通信と戻りの通信を同じように判断してくれているわけです。
それに対してネットワークACLはステートレスですので、
行きの通信のみ許可しても状態を保持しない為、SSH接続はできません。
そのため戻りの通信も許可しないとSSH接続できないということです。
こちらは行きの通信と戻りの通信が別々に判断されるというわけですね。
※今回の場合は行きの通信をインバウンドトラフィック、戻りの通信をインバウンドトラフィックに
対するアウトバウンドトラフィックとして表現しています。
拒否設定の違い
セキュリティグループはホワイトリスト形式であるのに対し、
ネットワークACLはブラックリスト形式であることも大きな違いです。
セキュリティグループはホワイトリスト形式の為、
許可IPの設定をすることは可能ですが、明示的な拒否設定をすることができません。
そのため例えば特定のIPを明示的に拒否する場合にセキュリティグループを用いることができません。
それに対してネットワークACLはブラックリスト形式の為、特定のIPを拒否することが可能です。
しかし、ネットワークACLはサブネット単位の設定ですので、サブネット内のすべてのEC2に適用されることに注意してください。
ルールの適用について
セキュリティグループはルールがすべて適用されますが、
ネットワークACLはルール番号が小さい順にルールが適用されていきます。
文面でみてもイメージしにくいと思いますので、こちらも具体的な例を挙げて見ていきましょう。
また「拒否設定の違い」にて、ネットワークACLは明示的な拒否設定が可能と記載しましたので
こちらも併せてみていきましょう。
まずはネットワークACLの設定を下記のようにしてみます。
テストサーバの接続元IPをルール番号「101」で拒否設定してみました。
- インバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | SSH | TCP | 22 | 0.0.0.0/0 | 許可 |
| 101 | SSH | TCP | 22 | 54.255.173.44/32 | 拒否 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
- アウトバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
[kk-test3@ip-10-0-0-108 ~]$ curl inet-ip.info
54.255.173.44
[kk-test3@ip-10-0-0-108 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
Last login: Sat Feb 25 20:00:32 2023 from 59-168-73-246.rev.home.ne.jp
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[kk-test1@ip-10-0-0-104 ~]$接続できましたね。
これはテストサーバの接続元IPの拒否設定(ルール番号101)よりも、SSH全体の許可設定(ルール番号100)が優先される為、接続ができたというわけです。
それでは次に下記のようにルールを変更してみましょう。
- インバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 99 | SSH | TCP | 22 | 54.255.173.44/32 | 拒否 |
| 100 | SSH | TCP | 22 | 0.0.0.0/0 | 許可 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
- アウトバウンドルール
| ルール番号 | タイプ | プロトコル | ポート範囲 | 送信元 | 許可/拒否 |
| 100 | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 許可 |
| ＊ | すべてのトラフィック | すべて | すべて | 0.0.0.0/0 | 拒否 |
[kk-test3@ip-10-0-0-108 ~]$ curl inet-ip.info
54.255.173.44
[kk-test3@ip-10-0-0-108 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
ssh: connect to host 175.41.233.136 port 22: Connection timed out接続できませんでしたね。
ほかのサーバからアクセスしてみましょう。
[kk-test2@ip-10-0-0-167 ~]$ curl inet-ip.info
13.229.94.253
[kk-test2@ip-10-0-0-167 ~]$ ssh -i ~/.ssh/kk-test1.key kk-test1@175.41.233.136
Last login: Sat Feb 25 20:18:44 2023 from ec2-13-229-94-253.ap-southeast-1.compute.amazonaws.com
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[kk-test1@ip-10-0-0-104 ~]$こちらは接続できましたね。
ルール番号「99」のルールの条件にマッチしなかった為、問題なく接続できたものとなります。
このようにネットワークACLでは明示的な拒否設定が可能であることがわかり、
ルール番号順でルールが適用されていることがわかりますね。
最後に
いかがだったでしょか。
ここまでセキュリティグループとネットワークACLの違いについてお話してきました。
それぞれの特性を理解し、適切な設定を行わなければサーバへのアクセスができないといった事態にも
なりかねないため慎重に設定していく必要があります。
以上です。ありがとうございました。
