パケットの裏側で何が起きているのか？SASE/CASBにおけるTLSインスペクションと証明書再署名の深淵
ネットワークエンジニアやセキュリティアーキテクトであれば、誰もが一度は頭を悩ませたことがあるだろう。「暗号化されたトラフィックの中身を覗き見たい。しかし、モダンな暗号プロトコルを完全に破壊することなく、どうやって安全にインスペクションを行えばいいのか？」と。
境界防御という概念が完全に崩れ去り、ユーザーがどこからでも社内リソースやSaaSへアクセスする現代において、SASE（Secure Access Service Edge）やCASB（Cloud Access Security Broker）は、企業ネットワークの新たな心臓部となった。その中核をなす機能の一つが、フォワードプロキシ方式における TLSインスペクション（SSL Decryption） と、それに伴う 動的な証明書再署名（Re-signing） だ。
一見すると「トラフィックを一度受けて、復号して、スキャンして、また暗号化して流すだけ」のシンプルな処理に思えるかもしれない。だが、パケットキャプチャを開き、TLSのハンドシェイクの裏側やTCPのウィンドウ制御の挙動まで目を凝らせば、そこにはインフラエンジニアの知的好奇心を刺激する、極めて泥臭く、かつ美しいエンジニアリングの世界が広がっている。
今回は、このTLSインスペクションと証明書再署名のメカニズムを、プロトコル層、暗号数学、そして現場で生きるチューニングの観点から徹底的に解剖していこう。
—
1. パケットレベルで追うTLSインスペクションのライフサイクル
フォワードプロキシ方式のSASE/CASBエッジにおいて、クライアント（エンドポイント）からインターネット上の宛先サーバー（例えば api.example.com）へ向かうHTTPS通信は、どのようにハンドリングされているのだろうか。
ここでの最大のパラドックスは、「クライアントは宛先サーバーとエンドツーエンドで暗号化通信を確立したいのに対し、セキュリティ機器はそれを途中でインターセプトしたい」という点にある。この矛盾を解決するため、SASEエッジは「人間が仕組んだ安全な中間者（Man-in-the-Middle）」として振る舞う。
具体的なパケットの往来は、以下のようなステップで進行する。
1. TCP 3-Way Handshakeの終端:
クライアントが送信した SYN パケットは、実際の宛先サーバーではなく、SASEエッジのプロキシIPアドレスで受動オープンされる。ここでTCPのコネクションは一旦分断され、クライアントとSASE間、およびSASEとリモートサーバー間で別々のTCPセッションが確立される。
2. Client Helloのインターセプト:
クライアントは Client Hello を送信し、サポートする暗号スイート（Cipher Suites）やTLSのバージョン（TLS 1.2 / TLS 1.3）、SNI（Server Name Indication）を通知する。SASEエッジはこの Client Hello を解析し、宛先のドメイン名（api.example.com）を特定する。
3. 擬似サーバー証明書の動的生成（証明書再署名）:
ここが心臓部だ。SASEエッジは、あらかじめエンドポイントのトラストストア（信頼されたルート証明書ストア）にインストールされている「企業独自の中間CA証明書」の秘密鍵を使用し、api.example.com の偽のサーバー証明書をオンザフライ（リアルタイム）で動的生成する。
4. クライアントとのTLSハンドシェイク完了:
SASEエッジは、生成した偽の証明書を同梱した Server Hello をクライアントに返す。クライアント側のOSやブラウザは、自身のルートストアを起点としてこの証明書を検証し、「信頼できる」と判断するため、エラーを出さずにTLSセッションが確立される。
5. バックエンドとのセッション確立とインスペクション:
同時に、SASEエッジは本物の api.example.com との間に独自のTLSセッションを張る。クライアントから送られてきた平文データはSASEエッジ上で一旦復号され、DLP（情報漏洩対策）エンジンやマルウェアスキャンにかけられた後、バックエンド用のTLSセッションで暗号化されて再送される。
—
2. 現代の暗号化における課題：TLS 1.3とSNI/ECHの壁
ここで一つ大きな問題が立ち塞がる。TLS 1.3の普及と、プライバシー保護を目的とした技術の進化だ。
従来のTLS 1.2では、ハンドシェイクの初期段階である Client Hello は完全に平文で流れていたため、プロキシは容易にSNIからアクセス先を特定できた。しかし、TLS 1.3、そしてさらにその先にある ECH（Encrypted Client Hello） の世界では、SNI自体が暗号化されるか、あるいはDNS層でのカプセル化（HTTPSレコードなど）によって隠蔽される傾向が強まっている。
もしSASEエッジが Client Hello の中身を復号できなければ、証明書を動的に発行するための「宛先ドメイン名」すら取得できなくなる。このため、モダンなSASEアーキテクチャでは、クライアント側のエージェント（EDRや専用プロキシクライアント）が密に連携し、OSのネットワークスタックレベルで宛先情報を事前にキャプチャしてSASEへセキュアに伝達するアプローチ、あるいは、インスペクション対象外（Bypass）とするトラフィックをあらかじめ綿密にルーティングする設計が不可欠となっている。
—
3. パフォーマンスの呪縛：RTT増大とTCP/TLSバッファチューニング
セキュリティを強化する代償として、パケットが一度SASEエッジで「終端・再暗号化」されるという事実は、物理的なレイテンシーの増大をもたらす。
RTT（Round Trip Time）の増加要因
通常の直通通信であれば、DNS解決の後に1回のTCPハンドシェイクと1回のTLSハンドシェイクで済むところが、フォワードプロキシを挟むことで、以下のオーバーヘッドが追加される。
- クライアント ⇔ SASE間のTCP/TLSハンドシェイク
- SASE ⇔ リモートサーバー間のTCP/TLSハンドシェイク（コネクションプーリングが効いていない場合）
この遅延を極限まで削ぎ落とすためには、インフラレイヤーでの徹底的なチューニングが求められる。以下に、LinuxベースのSASEエッジやプロキシサーバー（Squid、Envoy、独自Go/C++製プロキシなど）で適用すべき代表的なカーネルパラメータの設定例を示す。
# /etc/sysctl.d/99-sase-proxy-performance.conf
# ネットワークスタックとTCPバッファの極限チューニング
# TIME_WAIT状態のソケットを迅速に再利用し、ポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
# TCPウィンドウのスケーリングを有効化し、帯域幅遅延積（BDP）に対応する
net.ipv4.tcp_window_scaling = 1
# 送受信の最大TCPソケットバッファサイズを拡大（16MB）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 接続バックログキューのサイズを拡大し、急激なトラフィックバーストに耐える
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# TLSセッションキャッシュとコネクションプーリングの最適化（アプリケーション層の指針）
# - SASEエッジとバックエンドサーバー間のTLSセッションは積極的に再利用（Session Resumption / TLS Session Tickets）し、
# ラウンドトリップ数を削減すること。これらのパラメータは、数千・数万の同時TLSハンドシェイクを処理するプロキシワーカーが、CPUバウンドやメモリ枯渇に陥るのを防ぐための防壁となる。
—
4. 運用の罠：証明書ピンニング（Certificate Pinning）と例外処理
TLSインスペクションを導入した現場のエンジニアが真っ直ぐ直面する悪夢、それが 証明書ピンニング（Certificate Pinning） によるアプリケーションの通信断だ。
近代的なモバイルアプリや、厳格なセキュリティ要件を持つSaaSクライアント（例えば、大手企業の業務系デスクトップアプリや開発ツールのCLIなど）は、通信先のサーバー証明書が「組織があらかじめアプリ内にハードコードした特定の公開鍵（または証明書）」と一致するかどうかを厳しく検証する。
ここでSASEエッジが動的生成した「偽の証明書」を提示すると、アプリは「中間者攻撃（MiTM）を受けている！」と誤認し、容赦なくコネクションを切断する。
現場で取るべき現実解とアーキテクチャ設計
この問題に直面したとき、力技で全てのトラフィックを無理やりインスペクションしようとするのは愚策である。実務では以下の戦略を使い分ける。
1. インスペクション除外リスト（SSL Bypass）の精緻な運用:
金融系API、高度なセキュリティツール、証明書ピンニングが必須なアプリケケーショントラフィックについては、ドメイン単位またはプロセス単位でTLSインスペクションの対象外（Bypass）に設定する。
2. CASB等によるアプリケーションIDベースの制御:
復号できないトラフィックであっても、SNIやIPアドレス、アプリケーシードメインのメタデータに基づき、アクセス制御ポリシーを適用する。
3. エンドポイントセキュリティ（EDR）との連携:
プロキシで復号できない領域を、端末上のEDRやCASBクライアントエージェントがプロセス監視によって補完する。ゼロトラストの思想において、「全てを1箇所のプロキシで見通す」という幻想を捨て、多層防御でカバーすることが重要だ。
—
5. まとめ：パフォーマンスとセキュリティの絶妙なバランス
フォワードプロキシ方式におけるTLSインスペクションと証明書再署名は、暗号化の恩恵（プライバシーと完全性）と、組織の統制（可視化と脅威検知）という、相反する2つの要求を調停するための高度な錬金術である。
単に「セキュリティ製品の導入マニュアル通りにスイッチをONにする」だけでは、レイテンシーの悪化、一部アプリの全面停止、そしてプロキシサーバーのCPU高騰という泥沼にハマることになる。
パケットがNICを叩く瞬間から、カーネル空間とユーザー空間を行き交うバッファの挙動、そしてTLSの暗号数学的ハンドシェイクのプロセスまでを脳内でイメージし、インフラ全体をチューニングし切る。それこそが、真のネットワークセキュリティスペシャリストの仕事なのだ。
コメント