【テクニカル・上級編】 ゼロトラストネットワークアクセス（ZTNA）と従来のVPNの比較・移行戦略 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

さらば境界防御、そしてVPNの黄昏：ゼロトラストネットワークアクセス（ZTNA）へ至る深層パケット解析と移行戦略

夜ごとのパケットキャプチャで、TCPの3ウェイハンドシェイクの乱れやTLSの再ネゴシエーションに美しさを見出すインフラエンジニアの皆さん、こんにちは。

社内ネットワークという「聖域」を作り上げ、その外側を冷徹なファイアウォールで固める――そんな境界防御の時代は、静かに、しかし確実にかつての彼方へと去ろうとしている。リモートワークの常態化、SaaSの爆発的な普及、そして巧妙化するランサムウェアの横行により、従来の「VPN（Virtual Private Network）」という名の魔法のトンネルは、いまやセキュリティにおける最大のアキレス腱と化している。

VPNに接続した瞬間、端末はフラットな社内ネットワークの住民権を得る。これは、一度城門を破られたら城内がフリーパスになる中世の城塞と同じだ。ラテラルムーブメント（横方向の移動）を許容するVPNの設計思想は、現代の脅威モデルの前ではもはや時代遅れと言わざるを得ない。

今回は、パケットの挙動、TLSハンドシェイクの裏側、Linuxカーネルのバッファチューニング、そして既存のVPNからZTNA（Zero Trust Network Access）へ移行するための泥臭い現実解まで、ネットワークの底流から徹底的に解き明かしていこう。

—

1. 痛感するVPNの限界：パケットとプロトコル層から見る構造的欠陥

まずは、私たちが長年依存してきたIPsec VPNやSSL-VPN（TLS-VPN）の内部挙動を、プロトコルスタックの観点から冷静に分解してみる。

IPsec VPN：レイヤー3の重厚長大とNAT越えの苦悩

IPsecは、OSI参照モデルの第3層（ネットワーク層）で動作し、ESP（Encapsulating Security Payload）やAH（Authentication Header）を用いてパケット全体を暗号化する。セキュリティ強度は極めて高いものの、その裏では膨大なオーバーヘッドが発生している。

フレキシブルなルーティングを提供する反面、本社ルーターやクラウド上のゲートウェイ（AWSのVGWなど）でカプセル化と非カプセル化の処理がCPUに重い負荷をかける。さらに、NAT（Network Address Translation）環境下でのUDPカプセル化（NAT-T / RFC 3947）が必要となり、ポート4500でのパケットロスやフラグメンテーションに泣かされた運用の記憶を持つエンジニアも少なくないはずだ。

SSL-VPN：レイヤー4/7の利便性と「トンネル」の恐怖

一方、SSL-VPN（実体はTLSベースのHTTPSトンネリングや、独自のUDPベースプロトコル）は、ファイアウォールのポート443を通過できる利便性から一世を風靡した。しかし、ここには致命的な設計上の矛盾がある。

ユーザー認証が成功した瞬間に確立されるのは、「アプリケーション単位のアクセス許可」ではなく、「仮想インターフェース（tun0など）を介したL3/L4のネットワーク接続」である。つまり、悪意ある攻撃者が従業員の踏み台端末を乗っ取った場合、SSL-VPNのセッションを通じて社内データベースやDC（データセンター）の管理セグメントへ自由にアクセス（スキャニング）できてしまうのだ。

[クライアント] === (TLSトンネル / ポート443) === [VPNゲートウェイ]
                                                      │
                       ┌──────────────────────────────┴──────────────────────────────┐
                       ▼                                                             ▼
         [安全なはずの社内NW: 10.0.0.0/16]                         [放置された古い社内サーバー: 10.0.1.50]
         (ラテラルムーブメントによる全域スキャンが可能)

この「接続イコール信頼」という暗黙の前提を根底から覆すのが、ZTNAのアーキテクチャである。

—

2. ZTNAの真髄：アイデンティティとコンテキスト駆動の細粒度制御

ZTNA（Zero Trust Network Access）の基本哲学は極めてシンプルだ。「いかなるユーザーも、いかなるデバイスも、検証されるまでは信頼しない（Never Trust, Always Verify）」。

従来のVPNが「ネットワークへの接続権」を配るのに対し、ZTNAは「特定のアプリケーションへのアクセス権」を毎回動的に評価して付与する。ここでのアクセス制御決定（PEP: Policy Enforcement Point / PDP: Policy Decision Point）には、以下のコンテキストがリアルタイムで組み込まれる。

  • アイデンティティ（誰が）： OktaやAzure AD（Entra ID）等と連携した強固な多要素認証（MFA）の成否。
  • デバイスコンテキスト（何を）： EDR（CrowdStrikeやMicrosoft Defenderなど）のシグナルに基づく、マルウェア感染の有無、OSパッチの適用状況、ディスク暗号化（FileVault / BitLocker）の有効化。
  • ネットワーク/ロケーション（どこから）： 社外の未知の公衆Wi-Fiか、社内の信頼されたオフィスネットワークか。

パケットの流れる経路も根本的に異なる。ZTNA（特に次世代のクラウドベースZTNA / SDP形式）では、クライアントは社内ネットワークそのものにはルーティングせず、アイデンティティプロキシ（POP: Point of Presence）に対してのみ暗号化セッションを張る。認可されたアプリケーションへのトラフィックだけが、適切なセキュリティ検査（CASBやDLP）を経てバックエンドにプロキシされるのだ。

—

3. パフォーマンスの最適化：RTT削減、TCPバッファチューニング、TLSハンドシェイク

「セキュリティを厳格にすると、ネットワークが遅くなる」――これはインフラエンジニアの永遠の悩みだ。しかし、最新のZTNAプロトコル（特にHTTP/3やQUICベース、あるいは最適化されたgRPC/TLS 1.3）を採用することで、かえってVPNよりも高速なユーザー体験を実現できる。

TLS 1.3と0-RTT（Zero Round Trip Time）の活用

従来のVPN（TLS 1.2ベース）では、TCPの3ウェイハンドシェイク（1 RTT以上）の後にTLSハンドシェイク（さらに2 RTT）が必要だった。つまり、最初のデータパケットが飛ぶまでに少なくとも3〜4回の往復遅延（RTT）が発生していた。

ZTNAのゲートウェイ設計において、TLS 1.3を強制し、セッション再開時の0-RTTハンドシェイクを有効化することで、ハンドシェイクのオーバーヘッドを劇的に削ぎ落とすことができる。

LinuxカーネルにおけるTCPバッファのチューニング

リモートワーカーが遅延の大きな回線からZTNAゲートウェイへアクセスする際、カーネルのバッファ設定が不適切だと、BDP（Bandwidth-Delay Product）を活かせずスループットが頭打ちになる。ZTNAゲートウェイ（Linuxベース）の /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

# BBR混雑制御アルゴリズムの有効化 (高遅延・パケットロス環境でのスループット改善)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# TIME_WAITソケットの再利用を許可し、高負荷時のポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1

これらのパラメータは、数千規模の同時接続をさばくZTNAエッジプロキシのパフォーマンスを安定させるための必須の処方箋である。

—

4. 移行戦略：明日から始める段階的かつ現実的なロードマップ

「明日から全社VPNを廃止してZTNAに切り替える」などと言おうものなら、ヘルプデスクの電話が鳴り響き、経営陣から血祭りに上げられるのがオチだ。レガシーなクライアントサーバー型アプリケーションや、社内IPアドレスをハードコーディングした旧式システムが、いまだに企業の足元を支えているからだ。

ここで、現場のエンジニアが実践すべき、痛みを伴わない段階的移行のロードマップを提示しよう。

フェーズ1：アイデンティティ基盤の統合と可視化（Shadow ITのあぶり出し）

まずは、既存のVPNをそのまま維持しつつ、認証基盤をSaaS型IdP（Okta / Entra ID）に一本化する。同時に、CASBやプロキシログを活用して、「誰が、どの社内アプリに、どの頻度でアクセスしているか」のトラフィックプロファイルを完全に可視化する。ここで判明する「誰も使っていないレガシーシステム」の多さに驚くはずだ。

フェーズ2：リスクの高いワークロード（SaaS・外部公開アプリ）からZTNAへ

社内インフラの心臓部に手を付ける前に、外部からアクセスされるSaaSや、クラウド（AWS/Azure）上に構築されたWebアプリケーションへのアクセスをZTNA（またはSWG: Secure Web Gateway）経由に切り替える。ここでデバイスのコンテキスト評価（EDR連携）の動作検証を入念に行う。

フェーズ3：レガシーアプリへのエージェントレス/エージェント型ZTNAの適用

社内DCに残るファイルサーバーやDB等のレガシーシステムに対して、社内リバースプロキシ型（Connector方式）のZTNAコンポーネントを配置する。

[クライアント (ZTNAエージェント)] 
       │ (暗号化トンネル / アイデンティティ検証済)
       ▼
[クラウドZTNA POP / 制御プレーン]
       │ (セキュアなアウトバウンド接続)
       ▼
[社内DCのZTNAコネクター (Connector)] 
       │ (ローカルルーティング)
       ▼
[レガシー社内アプリ (DB/File Server)]

この構成の最大のミソは、社内DC側からインターネットに向けてインバウンドのポートを開ける必要がないという点だ。ZTNAコネクターは社内からクラウドのZTNAプロキシに向けて常時アウトバウンドのアフィニティコネクション（gRPCやWebSocket等）を張るだけなので、外部からの不正スキャンやDDoS攻撃の標的面（アタックサーフェス）を綺麗に消し去ることができる。

フェーズ4：VPNゲートウェイの完全なシャットダウン

すべての主要アプリがZTNA経由で安全にルーティングされ、例外的なルーティング要望がなくなった段階で、ようやく長年お世話になったVPNゲートウェイの電源を落とす。ファイアウォールから「TCP 500/4500」や「TCP 443（VPN用）」のルールを削除する瞬間は、インフラエンジニアにとって最高のカタルシスとなるだろう。

—

おわりに：セキュリティとは「信頼」ではなく「検証」の継続である

VPNからZTNAへの移行は、単なる「ツールの置き換え」ではない。それは企業のネットワーク哲学を「境界による防衛」から「アイデンティティとコンテキストに基づく動的制御」へとパラダイムシフトさせる壮大なプロジェクトだ。

パケットの流れる世界は冷徹で、設定のミス一つでシステムは沈黙する。しかし、プロトコルの内部挙動を深く理解し、適切なチューニングと段階的なアーキテクチャ設計を行えば、セキュリティとパフォーマンスは決してトレードオフではなく、高い次元で両立させることができる。

さあ、古いルーティングテーブルを閉じ、新しいゼロトラストのパケットを流し込もう。あなたのネットワークは、もっとセキュアで、もっと速くなれる。

スポンサーリンク

コメント

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