皆さん、こんにちは！インフラやセキュリティの世界へようこそ。
クラウドを使ったシステム開発、楽しいですよね。ボタン一つでサーバーが立ち上がり、世界中にサービスを公開できる。本当に便利な時代になりました。
でも、ちょっと待ってください。「便利」の裏側には、常に「危険」が隣り合わせなのがサイバーセキュリティの世界です。
今日は、新人のIT担当者や「セキュリティってなんだか難しそう……」と身構えてしまう開発者の皆さんのために、クラウドの門番である「ネットワークACL（NACL）」についてお話しします。
難しい専門用語はなるべく使わず、私たちの身近にある「防犯」の仕組みに例えて一歩ずつ紐解いていきますね。それでは、一緒に安全なクラウドの要塞づくりを学んでいきましょう！
—
1. 家のセキュリティに例える「セキュリティグループ」と「NACL」
クラウド（ここではAWSをイメージしてください）のネットワークを守るとき、私たちは主に2つの壁を用意します。それが 「セキュリティグループ（SG）」 と 「ネットワークACL（NACL）」 です。
この2つ、役割が似ていて最初は混乱しやすいのですが、おうちの防犯に例えると一発で理解できます。
セキュリティグループは「玄関のスマートロック」
セキュリティグループは、サーバー1台1台に直結している「個別のドア（玄関）」のようなものです。
「このお友達（特定のIPアドレス）だけが入っていいよ」「ウェブを見るための通信（ポート80や443）だけ通してね」というように、誰を中に入れるか（許可）をきめ細かく設定できます。
NACLは「マンションのエントランスと防犯ゲート」
一方、今回主役にするNACL（Network Access Control List）は、サーバー個別のドアではなく、サーバーが入っている「ネットワークのエリア（サブネット）」全体の入り口にある大きなゲートです。
マンションに例えるなら、個別の部屋の鍵とは別に、1階の自動ドアや敷地の外周フェンスをイメージしてください。
ここで重要な違いがあります。セキュリティグループは「通す通信（許可）」だけを決めるのが基本ですが、NACLは「この人は絶対にダメ！（明確な拒否）」というルールが作れるのです。
—
2. NACL最大の特徴：なぜ「ステートレス」が強力なのか？
セキュリティ用語でよく出てくる「ステートレス（Stateless）」という言葉。なんだかロボットみたいな名前で難しそうですよね。これも身近な例で考えてみましょう。
- ステートフル（セキュリティグループ）：記憶力がいい番人。あなたが「こんにちは！」と外から話しかけると、番人は「あ、さっき話した人だね。じゃあ帰りも通すよ」と、行きと帰りのセットを自動で覚えていてくれます。
- ステートレス（NACL）：記憶力がゼロの厳格な番人。あなたが外から行くときも、サーバーから返事をするときも、「行き」と「帰り」の切符を両方とも厳しくチェックします。
「えっ、行きと帰りの両方チェックされるなんて、なんだか面倒くさそう……」って思いましたか？
実はここに、攻撃者をシャットアウトするための最大の強みがあるんです。
例えば、悪意のあるハッカー（泥棒）が私たちのサーバーにアタックしてきとき、NACLなら「この怪しいIPアドレスからの通信は、行きも帰りも、一切合切すべて受け付けません！」と、門前払いにできるのです。セキュリティグループの「許可のルール」をすり抜けてきた厄介な攻撃も、このNACLという防犯ゲートでバッサリと切り捨てることができます。これが、私たちがNACLという「もう一つの防御層（多層防御）」を設ける理由です。
—
3. 実践！NACLの設定と具体的なルール
百聞は一見にしかず。実際にクラウド上でNACLを設定するときのイメージを見てみましょう。
NACLでは、ルールに「ルール番号（優先度）」をつけます。番号が小さいものから順番にチェックされ、ヒットした時点で判定が確定します。
以下の設定例は、「特定の信頼できる社内ネットワークからのアクセスだけを許可し、それ以外をすべて拒否する、かつ絶対に外部からアクセスさせたくない怪しいIPをブラックリスト登録する」という実務でよくあるシチュエーションです。
# ==========================================
# インバウンドルール（外から中に入る通信の制御）
# ==========================================
[ルール番号: 100]
- プロトコル: TCP
- ポート範囲: 443 (HTTPS)
- 送信元IP: 203.0.113.50/32 （例：会社の固定IPアドレス）
- アクション: 許可 (ALLOW)
-> コメント: 信頼できる本社からのアクセスのみHTTPSを許可する
[ルール番号: 200]
- プロトコル: すべて (ALL)
- ポート範囲: すべて
- 送信元IP: 198.51.100.99/32 （例：過去に攻撃を仕掛けてきた悪意あるIP）
- アクション: 拒否 (DENY)
-> コメント: 既知の攻撃者からのアクセスは徹底的にブロックする
[ルール番号: 300]
- プロトコル: TCP
- ポート範囲: 1024-65535 (エフェメラルポート)
- 送信元IP: 0.0.0.0/0 （すべての場所）
- アクション: 許可 (ALLOW)
-> コメント: サーバーから外部へ問い合わせた「返事の通信」を受け取るため
[ルール番号: 400 (デフォルトルール)]
- プロトコル: すべて
- ポート範囲: すべて
- 送信元IP: 0.0.0.0/0
- アクション: 拒否 (DENY)
-> コメント: 上記のどれにも当てはまらないものはすべて門前払いここで「おっ？」と思った鋭い読者の方もいるかもしれません。
「あれ？ ステートレスだから、サーバーからの返事を通すためにポート 1024-65535 の許可（ルール300）をわざわざ書かなきゃいけないの？」
その通りです！ここにNACLの難しさ、そして面白さがあります。セキュリティグループであれば自動でやってくれる「返事の通信の許可」も、NACLでは人間が明示的に「往復分の切符」を用意してあげなければいけません。これを忘れると、「サーバーは動いているのに、なぜか画面が真っ白で表示されない……！」という典型的なインフラトラブル（ハマりどころ）に直結します。
—
4. 現場のプロが教える、NACL運用における「泥臭い」注意点
教科書には「NACLで細かくIPをブロックしましょう」と書いてありますが、実際の現場（インフラ運用の最前線）では、いくつか気をつけなければならない「泥臭い罠」があります。
1. ルールの順番ミスで自爆する
ルール番号の若い順に評価されるため、もし最初に「すべてを拒否（DENY）」のルールを書いてしまうと、その下にあるどんなに正しい許可ルールもすべて無視されてしまいます。設定を変更した瞬間に自分自身がサーバーから締め出される「自爆テロ」をインフラエンジニアは何度も経験しています。設定変更時は必ず別の経路（踏み台サーバーなど）を確保しておきましょう。
2. ルールの数の限界（クォータ）に注意する
NACLに登録できるルールの数には上限があります。「あれもこれもIPごとに拒否設定を書こう！」とやっていると、あっという間に上限に達して管理できなくなります。ピンポイントな拒否はNACLで行いつつ、広範囲なブロックや悪意あるアクセスの遮断は、AWS WAF（Web Application Firewall）などの専用サービスに任せるという「役割分担」が、プロの現場ではスマートとされています。
—
まとめ
いかがでしたでしょうか？
ネットワークACL（NACL）は、一見すると「ステートレスで設定が面倒くさい」「セキュリティグループだけで十分なのでは？」と思われがちです。
しかし、
- 「サーバー個別のドア（SG）」とは別に、ネットワークの入り口に「厳格な門（NACL）」を構える多層防御
- 「絶対にこのIPを通さない」という強力な拒否ルールの活用
これらを理解して使いこなせるようになると、あなたの作るクラウドインフラの安全性は段違いに跳ね上がります。
セキュリティは、一度にすべてを完璧にする必要はありません。「今回はNACLの仕組みがなんとなく分かったぞ！」という一歩を踏み出せたことが素晴らしい成果です。ぜひ、ご自身の検証環境などでルールを触りながら、その動きを体感してみてくださいね。
それでは、また次回のセキュリティ解説でお会いしましょう！安全で快適なクラウドライフを！
コメント