【入門編】 セキュリティグループとネットワークACLのNATゲートウェイ周辺での適用順序 – クラウド＆コンテナネットワーク実践ガイド

こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「パケットって、一体いまどこをどう通っているんだろう？」という疑問にぶつかることがよくありますよね。

AWSなどのクラウドを使っていると、必ずと言っていいほどお世話になるのが「プライベートサブネット」と「NATゲートウェイ（NAT GW）」、そして「インターネットゲートウェイ（IGW）」という言葉たちです。

「外の世界に出たいプライベートな空間」と「世界につながる扉」のあいだで、セキュリティを守る門番として立ちはだかるのが、セキュリティグループ（SG）とネットワークACL（NACL）という2つの強力な仕組み。

「あれ？ どっちが先にチェックされるんだっけ？」
「ステートフル？ ステートレス？ なんだか呪文みたいで頭が痛い……」

そんな風に悩んだことはありませんか？
大丈夫です！難解な英語の仕様書は一旦置いておいて、まずは身近な「郵便配達」や「厳重な警備ビル」の仕組みに例えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 例え話でイメージする「プライベートサブネット」と「NATゲートウェイ」

まずは、私たちが普段暮らしている世界に置き換えて考えてみましょう。

  • プライベートサブネット（社内オフィス）:

外からの不審者は絶対に入れないけれど、中にいる社員たちは安全に仕事ができるように守られた、秘密のオフィスビルです。

  • NATゲートウェイ（受付ロビー・内線電話係）:

「外の世界（インターネット）へ手紙を出したいけれど、オフィスの住所をそのまま外に出すのは危ないなぁ……」というときに、オフィスの代表として外に手紙を出し、返事を受け取って本人に届けてくれる、頼れる受付係です。

  • インターネットゲートウェイ / IGW（大通り・玄関口）:

オフィスのビルから外の世界へと飛び出す、一番最初の大きな玄関口です。

プライベートサブネットにあるサーバー（社員）が、「外のWebサイトを見たい！」とリクエストを送るとき、パケット（手紙）は必ずこのNATゲートウェイを経由して外の世界（IGW）へと旅立ちます。

この旅の途中で、パケットは2種類の「セキュリティの関所」を通過することになります。それが ネットワークACL (NACL) と セキュリティグループ (SG) です。

—

2. セキュリティグループとネットワークACLの「性格」を知ろう

関所のルールを覚える前に、この2つの門番の「性格」をしっかり押さえておきましょう。ここが一番のポイントです！

ネットワークACL（NACL）は「融通のきかない、サブネットの門番」

  • 性格: ステートレス（無記憶）
  • 特徴: サブネットの入り口と出口に立ちふさがる、真面目だけど少し不器用な門番です。「行き」のチェックと「帰り」のチェックを、まったく別のものとして厳格に審査します。
  • 例え: 外から来る手紙だけでなく、中から外へ出す手紙の返事ですら、「お前の身分証を見せろ！」ともう一度チェックし直すタイプです。そのため、外から通信を呼び戻すためには、戻りの通信用のルールも自分でわざわざ書いてあげる必要があります。

セキュリティグループ（SG）は「気が利く、サーバーのボディガード」

  • 性格: ステートフル（有記憶）
  • 特徴: 守るべきサーバーのすぐそばにピタリと寄り添う、優秀なボディガードです。「行き」の通信を許可してあげれば、その通信に対する「帰り」の通信は、自動的に許可してくれます。
  • 例え: 「あ、さっきうちの社長があなたに手紙を出したから、返事なんですね。どうぞお入りください！」と、記憶力抜群でスムーズに通してくれるタイプです。

—

3. パケットが通る「評価の順序」はどうなっているの？

それでは本題です。プライベートサブネットからNATゲートウェイを経由してインターネットへ向かうとき、パケットはどの順番でこの2つの関所を通るのでしょうか？

答えは、通信の「向き（行きと帰り）」によって変わります。分かりやすく整理してみましょう！

パターンA：プライベートサブネットからインターネットへ向かう「行き」の通信

私たちのサーバーが「外に行きたい！」と声を上げたとき、パケットは以下の順番で審査を受けます。

1. ネットワークACL（サブネットの関所・往路）

  • まずはサブネットの境界線でNACLがチェックします。「このネットワークから外に出ていい通信か？」をステートレスに判定します。

2. セキュリティグループ（サーバーのボディガード・往路）

  • 次に、サーバーに到達する直前（または直後）でSGがチェックします。

3. NATゲートウェイでの変換

  • 関所を無事に抜けたパケットは、NATゲートウェイに到着し、プライベートIPアドレスからグローバルIPアドレスに「お召し替え（NAT変換）」されて、IGW（大通り）へと飛び出します！

パターンB：インターネットからNATゲートウェイを経由して戻ってくる「帰り」の通信

外の世界から、私たちが求めていたデータ（お返事）が返ってきたとき、パケットは逆のルートをたどります。

1. NATゲートウェイでの逆変換

  • IGWを通ってきた返事のパケットは、まずNATゲートウェイで「あ、これはさっきあのサーバーが出した手紙の返事だな」と認識され、元のプライベートIPアドレスに戻されます。

2. セキュリティグループ（サーバーのボディガード・復路）

  • ここで驚きなのが、SGは「ステートフル（記憶している）」なので、往路の通信を許可していれば、復路のSGチェックは自動的にパス（実質的にスルー）されます！なんてスマートなんでしょう。

3. ネットワークACL（サブネットの関所・復路）

  • 最後に、サブネットの出口（あるいは入り口）で、NACLのチェックが待ち構えています。ここで注意！NACLは「ステートレス（忘れん坊）」なので、外から帰ってきたパケット用のルール（インバウンドルール）がちゃんと設定されていないと、ここで無慈悲にパケットを捨てられてしまいます！

> 💡 現場のトラブルシューティングで一番多い罠
> 「セキュリティグループで全部許可したのに、なぜかNATゲートウェイ経由の通信が返ってこない！」というトラブルの9割は、この 「NACLのインバウンド（戻り用）ルールを書き忘れていた」 というケースです。初学者が必ずハマる登竜門なので、ぜひ覚えておいてくださいね！

—

ジグザグに進むパケットのライフサイクルを、テキストの図解で俯瞰してみましょう。

[プライベートサブネット内のサーバー]
  │
  ├─ 1. 【SG（送信）】チェック: 通信OK！
  ├─ 2. 【NACL（送信）】チェック: 通信OK！
  ▼
[NATゲートウェイ] (IPアドレスの変換)
  │
  ▼
[インターネットゲートウェイ (IGW)] ──> [インターネット（外の世界）]
  │
  (通信の折り返し・レスポンス)
  │
  ▼
[NATゲートウェイ] (IPアドレスの逆変換)
  │
  ├─ 3. 【NACL（受信）】チェック: ★ここを忘れるとパケットがここでドロップされる！
  └─ 4. 【SG（受信）】ステートフルなので自動で通過！
  ▼
[サーバーに到着 🎉]

—

4. 実務で役立つ！設定のベストプラクティスとコード例

「仕組みはわかったけれど、実際の現場ではどう設定するのがベストなの？」という声にお応えして、AWSのインフラをコードで管理する際に使われる Terraform の設定サンプルをご紹介します。

実務では、NACLは非常に複雑になりやすいため、基本的には「デフォルトですべて許可（あるいは必要最小限に厳格化）」しておき、細かいアクセス制御は使い勝手の良いセキュリティグループに任せる、という設計手法が王道です。

サンプルコード：NACLとセキュリティグループの基本設定（Terraform）

# ==========================================
# 1. ネットワークACL (NACL) の設定
# ==========================================
# ステートレスなため、インバウンド・アウトバウンドの両方を明示的に定義します。
resource "aws_network_acl" "private_nacl" {
  vpc_id     = aws_vpc.main.id
  subnet_ids = [aws_subnet.private.id]

  # 【インバウンド】外から帰ってくる通信（エフェメラルポート含む）を許可するルール
  ingress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 1024 # 動的ポート（エフェメラルポート）の開始
    to_port    = 65535 # 動的ポートの終了
  }

  # 【アウトバウンド】プライベートサブネットから外へ出ていく通信を許可するルール
  egress {
    protocol   = "-1" # すべてのプロトコル
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }

  tags = {
    Name = "production-private-nacl"
  }
}

# ==========================================
# 2. セキュリティグループ (SG) の設定
# ==========================================
# ステートフルなため、アウトバウンドを設定すればインバウンドの戻りは自動で許可されます。
resource "aws_security_group" "app_server_sg" {
  name        = "app-server-sg"
  description = "Application server security group for NAT communication"
  vpc_id      = aws_vpc.main.id

  # アウトバウンド（外へ出ていく通信）：HTTPS通信をNATゲートウェイ経由で許可
  egress {
    description = "Allow outbound HTTPS to internet via NAT Gateway"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # どこへでも行けるようにする
  }

  tags = {
    Name = "production-app-server-sg"
  }
}

このコードのポイントは、NACLのインバウンド設定（ingress）において、外から返ってくる通信を受け取るためのポート範囲（1024 から 65535）をちゃんと開けている点です。ここを忘れないようにすることが、プロのインフラエンジニアの技の見せどころですね！

—

5. おわりに：ネットワークの動きが見えると、インフラはもっと楽しくなる！

今回は、パブリック/プライベートサブネットとNATゲートウェイの周辺における、セキュリティグループとネットワークACLの評価順序について、直感的な例えを交えながら解説しました。

  • SGはステートフル（気の利くボディガード）で、帰りの通信を自動で通してくれる。
  • NACLはステートレス（忘れん坊の門番）で、往路も復路もルールをそれぞれ書いてあげる必要がある。
  • パケットが帰ってくるときは、NATで逆変換 ➔ NACLのチェック ➔ SGの自動通過 という順番で処理される。

最初は複雑に思えるクラウドのネットワークも、パケットの気持ちになって「今、どの関所を通っているんだっけ？」と頭の中でイメージできるようになると、トラブルシューティングのスピードが劇的に上がります。

もし現場で「あれ、通信できないぞ？」となったときは、この記事の図を思い出して、落ち着いてNACLとSGのルールを見直してみてくださいね。あなたのインフラ運用の旅が、より楽しく快適なものになりますように！

スポンサーリンク

コメント

タイトルとURLをコピーしました