セキュリティグループとNACL：パケットの「関所」を極めるアーキテクチャ設計
クラウドインフラを設計する際、多くのエンジニアは Security Group (SG) を「鉄壁の防御」と信じて疑わない。確かに、SG はインスタンス単位で動くステートフルなファイアウォールとして極めて優秀だ。しかし、ネットワークの最前線でパケットを捌くSREとして言わせてもらえば、SG だけでセキュリティを完結させるのは、巨大な城の「門」だけを固めて「外壁」を放置するようなものだ。
今回は、サブネット単位でパケットを制する Network ACL (NACL) の深淵と、それがパフォーマンスやセキュリティに与える影響について、パケットレベルの挙動から紐解いていこう。
—
1. SGの「ステートフル」とNACLの「ステートレス」の決定的な違い
まず、心に刻んでおくべきは「パケットの往復」に対する処理コストだ。
- Security Group (ステートフル): パケットの「戻り」を自動的に許可する。カーネルレベルでコネクション追跡（
conntrack）が行われ、許可された通信の応答パケットは、ルールに関わらず通過する。 - NACL (ステートレス): 送信と受信、双方のルールを個別に定義する必要がある。
TCPの3ウェイ・ハンドシェイク（SYN->SYN/ACK->ACK）を考えると、戻りのパケットのためにエフェメラルポート（1024-65535）を空けておく必要がある。
この「ステートレス」ゆえの面倒さが、逆に強力な武器になる。例えば、特定の攻撃元IPからの通信をネットワーク境界で完全に遮断（DENY）したい場合、SG は個別のインスタンスへの到達を許してしまうが、NACL であればサブネットの入り口でパケットを即座に破棄（DROP）できる。
—
2. パフォーマンスへの影響：RTTとTCPチューニングの盲点
NACL はレイテンシにほとんど影響を与えないと言われるが、高トラフィック環境では話が変わる。特に TCP バッファや MTU の不整合が絡むと、NACL によるパケットフィルタリングがボトルネックになる可能性がある。
TCPバッファチューニングの極意
高スループットを維持するには、Linuxカーネルの TCP ウィンドウサイズを最適化し、RTT（往復遅延時間）を最小化する必要がある。/etc/sysctl.conf で以下のように設定するのが定石だ。
# TCPウィンドウサイズを拡張し、広帯域でのスループットを最大化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCP Fast Openを有効化し、ハンドシェイクのRTTを削減
net.ipv4.tcp_fastopen = 3NACL を設定する際、これらの高速化されたパケットに対して、ルール番号（Rule Number）の順序がパフォーマンスに影響する。ルールは番号の若い順に評価されるため、頻繁に発生する通信はできるだけ若い番号に配置するのが鉄則だ。
—
3. 実践的設計：防御の多重化（Defense in Depth）
現場での鉄板パターンは、SG を「アプリケーションのアクセス制御」、NACL を「ネットワーク全体の汚染防止」として使い分けることだ。
推奨されるNACL設定（サンプル）
# インバウンドルール設定例
100: TCP | 443 | 0.0.0.0/0 | ALLOW (HTTPS受信)
110: TCP | 1024-65535 | 10.0.0.0/16 | ALLOW (戻りパケット用)
* : DENY (明示的な拒否)
# アウトバウンドルール設定例
100: TCP | 1024-65535 | 0.0.0.0/0 | ALLOW (戻りパケット用)
110: TCP | 443 | 0.0.0.0/0 | ALLOW (外部APIへのHTTPS接続)ここで重要なのは、1024-65535 のエフェメラルポートをどう扱うかだ。最近のモダンな構成では、NAT Gateway や ALB を経由するため、これらの中間機器が必要とするポート範囲を正確に理解しておく必要がある。
—
4. トランスポートセキュリティとヘッダー圧縮
現在、Webの主戦場は HTTP/3 (QUIC) へと移行している。QUIC は UDP をベースとしており、従来の TCP 向けの NACL 設定だけでは通信が確立されないケースが多い。
HTTP/3 を採用する場合、NACL で UDP の 443 ポートを明示的に許可する必要がある。また、TLS 1.3 のハンドシェイク最適化（0-RTT）を利用する場合、リプレイ攻撃のリスクを考慮したアーキテクチャが必要となる。
さらに、パフォーマンスの追求において、HPACK や QPACK といったヘッダー圧縮アルゴリズムを正しく機能させるには、ネットワーク層でのパケットロスを極限まで抑える必要がある。NACL は「全トラフィックを通すか、捨てるか」の判断しかできないが、そのフィルタリングが CPU 負荷を高め、結果として微細な遅延（マイクロバースト）を生む可能性があることを、テックリードは常に意識しておくべきだ。
結論：ネットワークを「制御」するという意識
NACL は、ただのファイアウォールではない。それは、クラウドという広大な海の中で、あなたのアプリケーションが守るべき「聖域」の境界線だ。
1. SGはIDベースのきめ細かな制御に集中させる。
2. NACLはサブネット境界での「不正アクセスの遮断」と「トラフィックの整理」に徹する。
この二段構えこそが、可用性とセキュリティを両立させる唯一の道だ。今日から、NACL のルール番号を見直し、無駄な評価フローを削ぎ落とすことから始めてみてほしい。パケットの一秒を惜しむ姿勢こそが、最高峰のエンジニアの証なのだから。
コメント