CASBとZTNAの融合：境界の消滅した世界におけるデータ保護とリアルタイム脅威ブロックの極意
ネットワークエンジニアとして生きてきた人間にとって、「社内ネットワーク＝安全地帯」という神話が崩れ去って久しい。VPNのゲートウェイを叩き割られ、ランサムウェアがラテラルムーブメントを完了した後に残されるのは、冷徹なログの山と経営陣からの詰問だけだ。
今や、境界防御という概念はレガシーな遺物となった。ユーザーはどこからでも社内リソースやSaaSにアクセスし、データはクラウドの海を回遊している。このカオティックな現代において、エンタープライズのセキュリティアーキテクチャを支える双頭の龍が、ZTNA（Zero Trust Network Access）とCASB（Cloud Access Security Broker）である。
今回は、このZTNAとCASBがどのようにデータを守り、シャドーITを監視し、そしていかにしてシームレスかつセキュアなポリシー共有とリアルタイム脅威ブロックを実現しているのか。プロトコルスタックの深部とカーネルレベルの挙動にまで踏み込みながら、その実装の極意を紐解いていこう。
—
1. 境界防衛の終焉と、ZTNA×CASBの必然的コンバージェンス
従来の境界防御モデルは、城壁（ファイアウォール）の内側を無条件で信頼する「城堡型（Castle-and-Moat）」の思想に基づいていた。しかし、SaaSの普及とリモートワークの常態化により、城壁そのものが消滅した。
ここで登場するのが、「Never Trust, Always Verify（決して信頼せず、常に検証せよ）」を掲げるZTNAである。ZTNAは、アプリケーション単位のきめ細かなアクセス制御を提供し、ユーザーのアイデンティティ、デバイスのポスチュアル（健全性）、コンテキストを評価して接続を許可する。
しかし、ZTNA単体では「接続の安全」は担保できても、「データの安全性」や「未認用のクラウドサービス（シャドーIT）の挙動」までを完全にハンドリングできるわけではない。ここでCASBの出番となる。
- CASBの役割: クラウドサービス利用の可視化（Discovery）、データ損失防止（DLP）、コンプライアンス監査、そしてマルウェア検知（Threat Protection）。
- ZTNAの役割: アイデンティティベースのセキュアなトランスポート層の確立、最小特権に基づくネットワークアクセスの動的制御。
この2つがサイロ化したままでは、管理者はポリシーの矛盾に苦しみ、エンドユーザーはレイテンシーの増大という悪夢に直面する。いまや求められているのは、ZTNAのネットワークパスと、CASBのインライン/API検査エンジンが完全に統合されたプラットフォームなのだ。
—
2. パケットレベルで見るトラフィックの全貌とTLSハンドシェイクの最適化
では、ユーザーが社外からSaaSやプライベートアプリにアクセスする際、ネットワーク上では何が起きているのか。そのパケットの挙動を追ってみよう。
通常、ZTNAはリバースプロキシ型やセカンド/サードパーティのエージェント（EDR連動型など）を介して、トラフィックをエッジノード（POP）へと誘導する。ここで発生するのが、「多重のカプセル化とTLS終端（Termination）のオーバーヘッド」だ。
TLSの再暗号化とパフォーマンスのジレンマ
CASBのインライン検査（Inline Inspection）を行う場合、エッジノードはクライアントからのTLSセッションを一旦終端し、ペイロード（HTTP/HTTPSリクエスト）の中身をデコードしてDLPやマルウェアスキャンを実施。その後、宛先サーバーに向けて再度TLSハンドシェイクを行う（TLSインセプション）。
このプロセスはセキュリティ上有益である反面、RTT（Round Trip Time）の増大とCPU負荷を直撃する。これを極限まで最適化するためのアプローチが以下の通りだ。
1. Session Resumption（セッション再開）の徹底:
TLS 1.3の 0-RTT（Zero Round Trip Time）ハンドシェイクを活用し、過去に確立したセッションのチケットを利用して暗号化通信の確立遅延をゼロにする。
2. HTTP/3 (QUIC) とUDP最適化:
TCPのヘッド・オブ・ライン・ブロック（HoLB）を回避するため、エッジ・プロキシ層でのHTTP/3終端を実装し、パケットロスに対する耐性を高める。
3. Linuxカーネルパラメータのチューニング（エッジプロキシサーバー向け）:
高スループットなTLS終端を行うリバースプロキシ（EnvoyやNginxなど）を稼働させるLinuxノードでは、ソケットバッファのチューニングが不可欠である。
以下に、高負荷なTLS/TCPプロキシ処理を支えるための /etc/sysctl.conf の推奨設定例を示す。
# --- ZTNA/CASBエッジノード向け Linuxカーネルチューニング ---
# TIME_WAITソケットの迅速な再利用を許可し、ポート枯渇を防ぐ
net.ipv4.tcp_tw_reuse = 1
# TCPウィンドウサイズのスケーリングを有効化し、広帯域・高遅延ネットワークでのスループットを最大化
net.ipv4.tcp_window_scaling = 1
# 送受信ソケットバッファの最大値とデフォルト値を拡大 (単位: バイト)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 最大接続バックログキュー（SYNキュー）の拡張
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# BBR混雑制御アルゴリズムの有効化 (パケットロスが多い環境でのスループット劇的改善)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrこのBBR（Bottleneck Bandwidth and Round-trip propagation time）アルゴリズムの適用は、グローバルに分散するZTNAエッジからのトラフィックにおいて、レイテンシーのブレを最小限に抑えるための必須要件と言っていい。
—
3. ポリシー共有とリアルタイム脅威ブロックの実装パターン
ZTNAとCASBが真に連携するとはどういうことか。それは、「ZTNAが持つコンテキスト情報（誰が、どのデバイスで、どこからアクセスしているか）」と、「CASBが持つデータインテリジェンス（アップロードされるファイル機密性、API経由の異常検知）」をリアルタイムにクロスリファレンスさせることだ。
アーキテクチャのシークエンス
1. アイデンティティ＆デバイス検証: ユーザーがZTNAゲートウェイへ接続を試みる。この際、EDRから取得したデバイスのパッチ適用状況、ディスク暗号化状態がポスチュアルとして評価される。
2. インラインHTTPヘッダーインジェクション: CASBインラインプロキシが、トラフィックに対してテナント制限（Tenant Restriction）ヘッダー（例: Sec-Restriction-Header や Microsoft.AAD.BrokerPlugin 関連のヘッダー）を動的に挿入する。これにより、シャドーIT（個人のGoogleアカウントや野良のOneDriveなど）へのデータ持ち出しをブロック。
3. リアルタイムAPIインスペクション: ファイルアップロードなどのPOST/PUTリクエストを検知した場合、CASBのDLPエンジンがペイロードをストリーミング検査。機密情報（マイナンバー、ソースコード、社外秘タグ）が含まれている場合、ZTNAセッション側へ即座にドロップバックのシグナルを送出する。
これを具現化するための、APIゲートウェイ/プロキシ（ここではEnvoy Proxyを想定）の設定スニペットを見てみよう。CASBのセキュリティ判定を反映させるためのWASM（WebAssembly）拡張モジュールの概念的設定だ。
# Envoy Proxyルーティング設定におけるCASB/ZTNA連携のイメージ
static_resources:
listeners:
- name: ztna_casb_edge_listener
address:
socket_address:
address: 0.0.0.0
port_value: 443
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
# TLS終端と証明書設定
...
filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: dynamic_cloud_apps
virtual_hosts:
- name: saas_gateway
domains: ["*.enterprise-saas.com"]
routes:
- match:
prefix: "/"
route:
cluster: saas_upstream_cluster
http_filters:
# CASBのインラインDLPおよび脅威ブロックを行うWASMフィルターの呼び出し
- name: envoy.filters.http.wasm
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
config:
name: casb_inline_dlp_engine
vm_config:
runtime: envoy.wasm.runtime.v8
code:
local:
filename: "/etc/envoy/wasm/casb_dlp_filter.wasm"
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.RouterこのWASMフィルター内部では、HTTPリクエストボディをバッファリングすることなく、チャンクごとにストリーミング解析（RegexやMLベースの機密情報検知）を行い、しきい値を超えた瞬間に HTTP 403 Forbidden を返す、あるいはZTNAセッション自体を強制切断（TCP RSTの送出）する制御が行われる。
—
4. シャドーIT監視の罠と、ネットワークトラフィックからの脱却
「すべての通信をプロキシに通せばシャドーITは防げる」というのは、教科書的な綺麗事だ。現実のエンタープライズネットワークでは、以下のような「監視の死角」が常にエンジニアを悩ませる。
1. 証明書ピニング（Certificate Pinning）を行うネイティブアプリ:
Slackや各種クラウドストレージのデスクトップアプリは、独自のルート証明書を検証するため、CASBのインラインプロキシによるTLSインセプションが破綻し、コネクションエラーを引き起こす。
2. QUIC (HTTP/3) を用いた非UDP 443ポートのバイパス:
ブラウザが標準でQUICを有効にしている場合、ファイアウォールがUDP 443を塞いでいない限り、従来のプロキシの検知網をすり抜けて直接クラウドへ到達するケースがある。
対策：API連携型CASB（API-CASB）とCASB/ZTNAのハイブリッド監視
インラインプロキシだけではカバーしきれないシャドーITに対しては、API連携型CASBを組み合わせる必要がある。Office 365やGoogle Workspace、AWSなどの主要SaaSの監査ログ（API）を常時ポーリングし、社外からの不審なログインや、共有リンクの公開設定（Anyone with the link）をリアルタイムで検知・自動修復（Remediation）するのだ。
ここでZTNAが果たす役割は、「社内・社外を問わず、すべてのクライアントが必ずZTNAエッジを経由する強制力」を持たせることにある。デバイス側で常時稼働するZTNAクライアントエージェントが、ネットワーク層でのスプリットトンネリングを厳格に制限し、未許可のUDP/TCPトラフィックを黒洞（Blackhole）へ沈める。この徹底こそが、シャドーITの温床を断つ唯一の解となる。
—
5. 結びにかえて：真のゼロトラストの実現に向けて
ZTNAとCASBの連携は、単なる「セキュリティ製品の買い増し」や「機能の統合」ではない。それは、ネットワークのパケットが流れるその瞬間から、エンドポイントの健全性、ユーザーのアイデンティティ、そして流れるデータの機密性に至るまで、全方位で信頼を検証し続けるシステムアーキテクチャの構築そのものだ。
プロトコル層の細部、TLSのハンドシェイクコスト、カーネルのバッファチューニング、そしてWASMによる高速なインライン検査。これらを深く理解し、泥臭くチューニングを重ねるインフラエンジニアの執念があって初めて、ゼロトラストはその実効性を伴う。
境界防御という幻想を捨て、動的なコンテキストとデータ保護が一体となった次世代のセキュリティ基盤を、あなたの手で設計し、実装してほしい。
コメント