境界防御の深淵：AWS Network Firewallを用いたDPIアーキテクチャの最適解
クラウドネイティブなネットワーク設計において、VPC境界は単なる「境界」ではない。それは、セキュリティとパフォーマンスが絶えずせめぎ合う戦場だ。特に、AWS Network Firewall（ANFW）を用いたステートフルインスペクションを導入する際、多くのアーキテクトが「スループットの低下」と「レイテンシの増大」という壁に突き当たる。
本稿では、Suricataエンジンを核とするANFWの挙動をパケットレベルで解剖し、いかにしてDPI（ディープパケットインスペクション）の恩恵を最大化しつつ、RTT（Round Trip Time）の劣化を最小限に抑えるかについて、現場の知見を交えて解説する。
—
1. ANFWの裏側：パケットが「覗かれる」仕組み
AWS Network Firewallは、VPCのトラフィックをGateway Load Balancer（GWLB）経由でインラインに配置する。パケットは一度カプセル化され、ファイアウォールエンドポイントへと転送される。
ここで注意すべきは、ANFWがステートフルインスペクションを行う際、TCPのシーケンス番号（SEQ）と確認応答番号（ACK）の整合性を厳密に追跡している点だ。もしパケットが順不同で届いたり、パケットロスが発生して再送が頻発したりすると、IDS/IPSエンジン内部のステートテーブルに負荷がかかり、CPUバウンドなボトルネックが発生する。
DPIとパフォーマンスのジレンマ
Suricata互換ルールを用いたDPIでは、アプリケーション層のペイロードまで解析する。ここでTLS 1.3が普及した現在、SNI（Server Name Indication）以外の可視性が限定的であることに留意が必要だ。もし暗号化トラフィックに対して無理にL7検査をかけようとすれば、当然ながら負荷は跳ね上がる。
—
2. トランスポート層の最適化：TCPバッファとウィンドウ制御
ANFWを通過する際、パケットの往復回数（RTT）は物理的なホップ数以上に、インスペクション処理による「微小な遅延」が積み重なる。この遅延をTCPレベルで吸収するためには、クライアントおよびサーバー側でのTCPバッファのチューニングが欠かせない。
特に、BDP（Bandwidth Delay Product）を考慮したウィンドウサイズの調整は必須だ。
# LinuxカーネルにおけるTCPウィンドウサイズチューニングの例
# インスペクションによる遅延が想定される場合、受信バッファを拡大する
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# スループットを向上させるためのTCP高速再送設定
sysctl -w net.ipv4.tcp_slow_start_after_idle=0—
3. Suricataルールセットの磨き方：計算量を減らす「順序」
ルールセットの記述順序は、IDS/IPSのパフォーマンスに直結する。ANFWのエンジンは、パケットがルールにマッチするまでリストを上から順に評価する。頻出する正常トラフィックを先に許可し、複雑な正規表現（pcre）を用いた拒否ルールは極力下位に配置するのが鉄則だ。
以下は、最適化を意識したSuricataルールのサンプルである。
# 最適化されたルール記述例
# 1. 頻出する許可ルールを先に配置（評価回数を減らす）
pass tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Allow HTTPS to trusted endpoints"; sid:1000001; rev:1;)
# 2. 複雑なDPI（正規表現）は最後の方に記述
# 正規表現によるインスペクションはCPU負荷が高いため、必要最低限に絞る
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Detect SQL Injection attempt"; content:"UNION SELECT"; nocase; pcre:"/UNION\s+SELECT/i"; sid:1000002; rev:1;)—
4. 脆弱性回避とネットワーク設計の勘所
TLSハンドシェイクの最適化
DPIを介在させる環境では、TLSハンドシェイクの遅延が体感速度を大きく左右する。可能であれば、TLS 1.3の0-RTT（Early Data）の利用を検討すべきだが、これはリプレイ攻撃のリスクを伴う。ANFWで厳密な検査を行うのであれば、むしろTLS 1.3の高速なハンドシェイク特性を活かしつつ、アプリケーション側でセッションの再利用（Session Resumption）を強制する設計が堅牢だ。
パケット断片化（Fragmentation）への備え
悪意のある攻撃者は、パケットを意図的に断片化（フラグメンテーション）させ、IDSのインスペクションをすり抜けようとする。ANFWはこれらを再構築（Reassembly）してから検査するが、メモリ消費が激しい。
VPCのMTUを9001（ジャンボフレーム）に設定している場合、断片化されたパケットの処理コストが高くなるため、セキュリティ要件とパフォーマンスのバランスを計算しておく必要がある。
—
5. 最後に：インフラエンジニアの矜持
AWS Network Firewallは強力な武器だが、それを使いこなすには「パケットが今どこで、どのように処理されているか」を脳内で視覚化できるスキルが求められる。
パフォーマンスチューニングは、単なる設定変更の積み重ねではない。アプリケーションの特性、ネットワークトポロジー、そして脅威モデルを統合的に理解し、その上で「どのパケットを落とし、どのパケットを通すべきか」を判断する。これこそが、現代のSREにおける真の「防衛」であると私は確信している。
設計に行き詰まったら、一度パケットキャプチャ（VPC Traffic Mirroring）を取り、WiresharkでTCPのDelta Timeを確認してほしい。数字は嘘をつかない。そこにある遅延こそが、君たちのアーキテクチャを次のステージへ導くための羅針盤となるはずだ。
コメント