クラウドの「門番」を攻略せよ！NACL（ネットワークアクセスコントロールリスト）のステートレスな仕組みを完全理解
こんにちは！クラウドアーキテクトとして日々ネットワークの迷宮を探索しているSREです。
クラウドインフラに足を踏み入れると、必ず直面するのが「セキュリティグループ（SG）」と、今回お話しする「NACL（ネットワークアクセスコントロールリスト）」という2つの門番です。
「セキュリティグループがあるなら、NACLなんていらないのでは？」
そんな風に思ったことはありませんか？ 実は、この2つは役割が全く異なります。今回は、パケットの動きを郵便配達に例えながら、NACLの「ステートレス」という少し癖のある性格を優しく紐解いていきましょう！
—
1. NACLは「サブネットの玄関」にある警備員さん
セキュリティグループ（SG）が「サーバー（インスタンス）の部屋のドア」を守る警備員だとしたら、NACLは「サブネットというマンションの入り口」に立っている警備員さんです。
SGは「特定の通信が許可されたら、その戻り通信も自動的に許可する（ステートフル）」という気遣いができる賢い警備員ですが、NACLは一切の記憶を持たない「ステートレス」な警備員です。
「ステートレス」ってどういうこと？
ステートレスとは、「状態を保持しない」という意味です。
もしあなたが郵便物（パケット）を届けに来たとします。NACLの警備員さんは、「送り出した郵便物の返事」であっても、そのことを一切覚えていません。
「行き」の許可をルールリストで確認し、「帰り」の許可もまた別のルールリストで確認する。これがNACLの流儀です。「さっき通したから、帰りはOKだよね？」という甘えは一切通用しない、非常にストイックな仕組みなんです。
—
2. 厳格なルール評価：番号順が命！
NACLのルールは「ルール番号」が小さい順に評価されます。これは、レストランの待ち行列のようなものです。
1. ルール番号 100： 「IPアドレス 192.168.1.5 からの通信は許可！」
2. ルール番号 200： 「すべての通信を拒否！」
もし 192.168.1.5 からパケットが来たら、警備員さんは番号の若い 100 を見て「よし、通れ！」と判断します。一方で、それ以外のIPから来たら、100 に該当しないので 200 を見て「お断り！」と門前払いします。
重要なポイント：
ルールは一度でも「許可（Allow）」または「拒否（Deny）」に合致した瞬間に評価が終了します。後からどれだけ厳しいルールを書いても、先にマッチしたルールが絶対なのです。
—
3. 実践！NACLの設定サンプル
AWSのVPCを例に、Webサーバー（サブネット）を守るための基本的なNACL設定を見てみましょう。
インバウンド（外から入ってくる通信）
Webサーバーが外部からのリクエストを受けるには、まず80番ポート（HTTP）を許可する必要がありますね。
# インバウンドルール
ルール番号 | タイプ | ポート | 送信元 | アクション
-------------------------------------------------------
100 | HTTP | 80 | 0.0.0.0/0 | 許可
32768 | カスタム | 1024-65535 | 0.0.0.0/0 | 許可 <-- ※重要！ここで「なぜ 32768 からの通信を許可するの？」と思った方、素晴らしい着眼点です！
これが先ほどの「ステートレス」の正体です。サーバーが外部へ回答を返す際、通信には「エフェメラルポート（一時的なポート番号）」というものが使われます。帰りのパケットを通すためには、この広い範囲のポートも許可しておかないと、通信が遮断されてしまうのです。
アウトバウンド（内から外へ出ていく通信）
逆に、サーバーがアップデートを確認しに行くような通信を許可するには、アウトバウンドルールも必要です。
# アウトバウンドルール
ルール番号 | タイプ | ポート | 送信先 | アクション
-------------------------------------------------------
100 | HTTP/HTTPS | 80/443 | 0.0.0.0/0 | 許可
32768 | カスタム | 1024-65535 | 0.0.0.0/0 | 許可—
4. なぜこんな面倒な仕組みがあるの？
「SGだけでいいじゃん！」と思いますよね。でも、NACLにはNACLにしかできないことがあります。
- 特定のIPレンジを完全ブロックする： 悪意のある攻撃元からの通信を、サーバーに到達する前にサブネットの入り口で捨てることができます。
- 多層防御の要： 万が一、SGの設定を間違えて公開してしまっても、NACLが「ラストラインの防御」として踏みとどまってくれます。
最後に：一歩ずつ理解を深めよう
NACLは一見すると「手間がかかる面倒なルール」に見えるかもしれません。しかし、パケットの行き来を一つひとつ丁寧に定義するこの作業は、ネットワークの構造を深く理解する最高のエクササイズになります。
最初は複雑に感じるかもしれませんが、「行きの切符」と「帰りの切符」を別々に用意するというシンプルな原則さえ覚えておけば大丈夫です。
ぜひ、実際のクラウド環境で「通信が繋がらない！」という時は、このステートレスな警備員さんの顔を思い出してみてください。「あ、帰りのルールを書き忘れていないかな？」と確認するだけで、トラブル解決の糸口が見えてくるはずですよ！
皆さんのクラウドインフラが、強固で安全なものになることを応援しています。それでは、また次回の記事でお会いしましょう！
コメント