こんにちは！インフラやセキュリティの世界へようこそ。
クラウドでのサーバー構築やネットワーク設定、最初は覚えることがたくさんあって大変ですよね。「セキュリティグループを設定したから大丈夫だよね？」と思っていませんか？
実は、クラウドの要塞化（ハーデニング）において、セキュリティグループの影に隠れがちですが、ものすごく重要なもう一つの門番が存在します。それが今回お話しする「ネットワークACL（NACL）」です。
今回は、このNACLの仕組みを、私たちの身近な「家の防犯」に例えながら、初心者の方にもわかりやすく、そして実務でそのまま使える設定のコツまで一歩ずつ紐解いていきましょう！
—
1. セキュリティグループとNACLは、家で例えるとどこにあたる？
クラウドの世界（特にAWSなどの環境）では、サーバーを守るために「二重の壁」を用意するのが鉄則です。この二重の壁を、私たちが暮らす「家」に例えてみましょう。
セキュリティグループ ＝ 「玄関のスマート鍵」
セキュリティグループは、サーバー1台1台の直前に置かれる門番です。「この人（IPアドレス）は入れていい？」「この部屋（ポート番号）に入っていい？」を、個別に判断してくれます。
しかも、このセキュリティグループは「ステートフル」という賢い性質を持っています。どういうことかと言うと、「家の中から外へ出かけた人」のことはしっかり覚えていて、その人が帰ってきたときは鍵を開けなくてもスッと通してくれます。
ネットワークACL ＝ 「マンションのエントランスと防犯ゲート」
一方、今回主役として取り上げるNACLは、サーバー1台ずつではなく、「サブネット（サーバーがいくつか集まった区画・フロア）」全体を守る外側の門番です。マンション全体のエントランスや、外構のフェンスのようなイメージですね。
そして、NACLの最大の特徴は「ステートレス」であるということです。これが、私たち初心者が最初につまずきやすいポイントであり、攻撃者が隙を突いてくるポイントでもあるんです。
—
2. なぜ「ステートレス」だと難しいの？（攻撃者視点の盲点）
「ステートレス」って聞くだけで、なんだか難しそうですよね。
身近な例で言い換えてみましょう。
- ステートフル（セキュリティグループ）：
「あ、さっき私が出した郵便配達の人だな。お疲れ様です！」と、往復のやりとりを記憶してくれます。
- ステートレス（NACL）：
物覚えが一切ないロボットだと思ってください。郵便配達員が帰ってくるたびに、「行き」の許可証だけでなく、「帰り」の許可証も両方チェックします。
もし、NACLで「外部からの通信を許可するルール（インバウンド）」だけを作って、「内部から外部への返事の通信を許可するルール（アウトバウンド）」を書き忘れたらどうなるでしょうか？
サーバーは「よし、返事を送ろう！」とデータを送り出しますが、NACLのエントランスのロボットが「おい、お前が出ていく許可証（アウトバウンドルール）を隠し持っていないぞ！」と言って、返事のデータを没収（ブロック）してしまうのです。
これが原因で、「なぜかWebサイトが表示されない」「APIの通信がタイムアウトする」というトラブルが現場で頻発します。初心者の頃は、本当にここでよくハマるんですよね。
—
3. 実践！NACLのインバウンド・アウトバウンド設計
それでは、実際に安全で確実なNACLのルールを設計してみましょう。
今回は、インターネットからアクセスされる「Webサーバー」が置かれたサブネットを想定します。
実務で設定する際は、次のような考え方に沿ってルール（エントランスのルールブック）を書き込んでいきます。
NACL設定の基本ルール
1. ルール番号（プライオリティ）が小さいものから順番にチェックされます（例: 100, 200 など）。
2. 一番最後に、設定にマッチしなかったすべての通信を拒否する「全否定（*）」のルールが自動的に隠し味として効いています。
【設定例】Webサーバー用サブネットのNACL設定
以下の設定は、インフラの自動化コード（TerraformやCloudFormationなど）でもよく使われる王道のパターンです。
/* --- インバウンド（外から中へのルール） --- */
Rule Number: 100
Type: HTTP (TCP ポート 80)
Source: 0.0.0.0/0 (世界中どこからでも)
Action: ALLOW (許可)
# コメント: 誰でも私たちのWebサイトを見られるようにします。
Rule Number: 110
Type: HTTPS (TCP ポート 443)
Source: 0.0.0.0/0 (世界中どこからでも)
Action: ALLOW (許可)
# コメント: 暗号化された安全な通信（HTTPS）も許可します。
Rule Number: 120
Type: カスタムTCP (TCP ポート 32768-65535)
Source: 0.0.0.0/0 (世界中どこからでも)
Action: ALLOW (許可)
# コメント: ここが重要！外からサーバーへアクセスしたときの「一時的な帰り道のポート（エフェメラルポート）」を許可します。
/* --- アウトバウンド（中から外へのルール） --- */
Rule Number: 100
Type: すべてのトラフィック (All Traffic)
Destination: 0.0.0.0/0 (どこへでも)
Action: ALLOW (許可)
# コメント: サーバー側からOSのアップデートをダウンロードしたり、外部のAPIを叩きに行く通信をすべて許可します。ここで「あれっ？」と思った方、素晴らしい着眼点です！
インバウンドの設定にある 「エフェメラルポート（一時的なポート 32768-65535）」 って何だろう？と思いましたよね。
先ほど、「NACLはステートレス（物覚えが悪い）」と言いました。外からユーザーがホームページを見に来たとき、サーバーはランダムな臨時ポートを使って返事を送り返します。NACLはこの「臨時ポートでの通信」もあらかじめ許可しておかないと、返事を外に出してくれないのです。この仕組みを忘れると、通信がピタリと止まってしまいます。
—
4. 現場のプロからのアドバイス：どう使い分けるべき？
「NACLとセキュリティグループ、どっちをどう使えばいいの？」という疑問が残りますよね。最高セキュリティ責任者の視点から、現場のベストプラクティスをお伝えします。
- 基本はセキュリティグループで守る：
サーバーごとのきめ細かいアクセス制御（「この踏み台サーバーからしかSSH接続させない」など）は、ステートフルで扱いやすいセキュリティグループで行うのが現代のクラウドセキュリティの主流です。
- NACLは「最後の砦（ネットワーク全体のブロック）」として使う：
例えば、「特定の不審な国からのアクセスをごっそり遮断したい」「サブネット単位で絶対に通信させたくない境界線を作りたい」という、大きなくくりでの防御にNACLを使いましょう。
セキュリティは、一度に完璧を目指す必要はありません。
「あ、今回はステートレスだから帰り道のルールも書かなきゃいけないんだな」という気づきを一つずつ重ねていくことが、何よりも強固なシステムを作る近道です。
一歩ずつ、確実に安全なインフラを作っていきましょう！応援しています。
コメント