【実務・中級編】 CASBとZTNAのデータ保護およびシャドーIT監視における連携パターン – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

こんにちは、シニアネットワークエンジニアの私だ。
これまでのキャリアで数え切れないほどの「境界防御の崩壊」と「社内ネットワークの無法地帯化」を目撃してきた。かつては、堅牢な社内LANにさえいれば安全神話が成立していたが、クラウドシフトとリモートワークの爆発的普及によって、そのお城の壁はもろくも崩れ去った。

「社内だから安全」という性善説は、もはや過去の遺物だ。今や私たちは、何者であっても一切信用しない「ゼロトラスト」の荒野を生き抜かなければならない。

そこで今回は、ゼロトラストアーキテクチャの要であるZTNA（Zero Trust Network Access）と、SaaSの利用状況を監視・制御するCASB（Cloud Access Security Broker）の連携について、現場の泥臭い知見を交えて徹底解説しよう。APIインライン検査、ポリシーの動的共有、そしてシャドーITのリアルタイムブロックまで、明日からインフラやAPI設計に即座に活かせる実践知を叩き込む。

—

1. なぜCASBとZTNAは「統合」されなければならないのか？

現場でよくある失敗が、ZTNAとCASBを別々の「お飾り」として導入してしまうケースだ。
ZTNAは「誰が・どの端末から・どのアプリにアクセスするか」というネットワーク・セッションの入り口を制御する。一方、CASBは「そのアプリの中で・どんなデータ（PIIや機密情報）を扱っているか」というアプリケーションの中身（ペイロード）を監視する。

この2つがサイロ化していると何が起きるか？
「ZTNAで正規のVPNレス・アクセスを許可された端末が、シャドーITとして野良のクラウドストレージに会社の機密ソースコードをアップロードし放題」という最悪の事態が生まれる。

リアルタイム脅威ブロックとポリシー共有のメカニズム

私たちが目指すべきゴールは、ZTNAのゲートウェイ（PDP: Policy Decision Point）と、CASBのAPIプロキシ/インライン検査エンジンが緊密に連携するアーキテクチャだ。

1. アクセス要求（ZTNA）: ユーザーが社外からクラウド上の業務アプリへアクセスを試みる。
2. コンテキスト評価（ZTNA + CASB）: ZTNAがデバイスのポスチャー（EDRの健全性や証明書の有無）を検証しつつ、CASB側でそのユーザーがアクセスしようとしているSaaSテナントが「情シス許可済み（サンクション）」か「野良（シャドーIT）」かを判定する。
3. インラインAPI検査（CASB）: セッション確立後、HTTPリクエストに含まれるJSONやマルチパートフォームデータのペイロードをCASBがリアルタイムスキャン。データ損失防止（DLP）ポリシーに抵触すれば、即座に通信をリセット（403 Forbidden等に書き換え）する。
4. 動的ポリシー更新: 異常検知イベントがCASBからAPI経由でZTNAコントローラーに飛び、該当ユーザーのセッション権限を即座に剥奪する。

この連携フローを頭に叩き込んでおいてほしい。

—

2. 通信フローとAPIインライン検査の裏側

では、パケットレベルでこの連携がどう行われているのか、シーケンスを追ってみよう。

[Client / User]
       │
       │ ① HTTPS Request (Bearer Token + Device Posture Header)
       ▼
[ZTNA Gateway (PDP/PEP)] ──(API連携: 端末・ID状態確認)──> [IdP / EDR]
       │
       │ ② リバースプロキシ転送 (X-CASB-Context付与)
       ▼
[CASB Inline Inspection Proxy]
       │
       │ ③ APIペイロードのDLP検査 (機密情報パターンマッチング)
       ├─── [検知!] ──> ④ 403 Forbiddenをクライアントへ返却
       │
       └─── [正常] ──> ⑤ SaaSアプリのオリジンサーバーへ転送

このフローの中で、ZTNAゲートウェイとCASBプロキシの間でやり取りされるHTTPヘッダーには、実務上極めて重要なパラメーターが含まれている。

主要なHTTPヘッダー・パラメーターの解説

インフラエンジニアやAPI設計者が必ず理解しておくべき拡張ヘッダーの例だ。

  • X-Forwarded-For: クライアントのグローバルIPアドレス。
  • X-ZTNA-Device-Posture: EDRのステータス（healthy, compromised, outdatedなど）をBase64等でエンコードしたもの。
  • X-CASB-Tenant-ID: 組織が許可している正規のSaaSテナントID（例: Office 365のテナント制限用 Restrict-Access-To-Tenants）。
  • X-DLP-Action-Trigger: インライン検査で引っかかった際、CASBがアクションを決定するための内部識別子。

—

3. 実装・設定サンプル：CASB/ZTNA連携の現場

口ばかりではエンジニアの信用は勝ち取れない。ここからは具体的な設定ファイルとコードの例を示そう。

A. ZTNAゲートウェイ側（NginxベースのカスタムPEPを想定）の設定例

ZTNAのポリシーエンジンが、認証済みユーザーのリクエストをCASBのインラインプロキシへ安全にフォワードするための設定だ。

# ZTNA Policy Enforcement Point (PEP) のルーティング設定
server {
    listen 443 ssl http2;
    server_name ztna-gateway.enterprise.internal;

    ssl_certificate /etc/ssl/certs/ztna_gateway.crt;
    ssl_certificate_key /etc/ssl/private/ztna_gateway.key;

    location / {
        # 1. 認証済みユーザーのコンテキストをヘッダーに注入
        proxy_set_header X-Authenticated-User $http_x_auth_userid;
        proxy_set_header X-ZTNA-Device-Posture $http_x_edr_status;
        
        # 2. CASBのインライン検査プロキシへ転送（チェーニング構成）
        proxy_pass https://casb-inline-scanner.security.internal;
        
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # 3. タイムアウト設定（インライン検査によるレイテンシーを考慮）
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

B. シャドーITおよびDLPを検証するPythonクライアント（テストスクリプト）

API開発者やセキュリティエンジニアが、ZTNA/CASB経由のデータ送信テストを行うためのPythonスクリプトだ。社外秘データ（ここではクレジットカード番号を模した文字列）を送信し、CASBによって即座にブロック（403）されるかを検証する。

import requests
import json

# ZTNAゲートウェイを経由したCASBインライン検査のエンドポイント
TARGET_URL = "https://ztna-gateway.enterprise.internal/api/v1/documents"

# デバイスポスチャーとユーザーIDを模したカスタムヘッダー
headers = {
    "Authorization": "Bearer eyJhbGciOiJSUzI1NiIs...", # 偽装トークン
    "X-Auth-UserId": "engineer01@enterprise.internal",
    "X-EDR-Status": "healthy",
    "Content-Type": "application/json"
}

# 送信データ（シャドーITやDLPのトリガーとなる機密データを含むペイロード）
payload = {
    "document_title": "Q3_Financial_Projection.xlsx",
    "department": "Finance",
    # DLP検知テスト用のクレジットカードパターン
    "confidential_body": "Test payload containing dummy data: 4111-2222-3333-4444"
}

try:
    print(f"[*] データを送信中: {TARGET_URL}")
    response = requests.post(TARGET_URL, headers=headers, data=json.dumps(payload), timeout=10)

    # ステータスコードによる判定
    if response.status_code == 200:
        print("[+] 成功: リクエストはCASBおよびZTNAを通過しました。")
        print(response.json())
    elif response.status_code == 403:
        print("[-] ブロック検知: CASBのインラインDLPポリシーにより遮断されました。")
        print(f"Server Response: {response.text}")
    else:
        print(f"[?] 予期せぬステータスコード: {response.status_code}")
        print(response.text)

except requests.exceptions.RequestException as e:
    print(f"[!] ネットワークエラーまたはタイムアウトが発生しました: {e}")

—

4. 現場でハマる「落とし穴」とトラブルシューティングTips

最後に、このアーキテクチャを導入・運用する際に、私が実際に現場の修羅場で直面した「あるあるトラブル」と、その処方箋を共有しておこう。

トラブル1: インライン検査による「レイテンシーの悪化」

  • 現象: ZTNA経由のSaaSアクセスにおいて、ファイルアップロード時に数秒の遅延が発生し、ユーザーからのクレームが殺到する。
  • 原因: CASBのインラインプロキシがすべてのHTTPボディ（特にバイナリや大容量JSON）をメモリ上で展開し、正規表現によるDLPスキャンを同期的に行っているため。
  • 対策:
  • 転送サイズ（Content-Length）にしきい値を設け、一定以上の巨大ファイルはインラインではなく、後続のアシンクロナスなAPIスキャン（Out-of-band CASB）へ迂回させる設計に変更する。
  • プロキシサーバー側のKeep-Alive設定やコネクションプーリングをチューニングする。

トラブル2: 誤検知（False Positive）による業務停止

  • 現象: ソースコードのテストデータを送信しただけなのに、CASBの機密情報パターンマッチにヒットし、開発者のAPIリクエストが頻繁に強制ブロックされる。
  • 原因: 汎用的な正規表現（例: 秘密鍵や特定のIDフォーマット）がソースコード内のコメントやダッシュボードのUUIDに過剰反応している。
  • 対策:
  • CASB側のポリシーで、除外パス（Exclusion Paths）や、検証済みの開発者グループ（ZTNAのアイデンティティグループと連動）に対するスキャン感度の調整（閾値の引き上げ）を行う。

—

まとめ

境界防御が完全に崩壊した現代において、ZTNAによる「アクセス制御」と、CASBによる「データ・アプリケーションの可視化・保護」は、もはや別々のソリューションではない。これらを統合し、動的なポリシー共有とリアルタイムのインライン検査を実現することこそが、真のゼロトラストアーキテクチャの完成形だ。

教科書を読むだけでは分からない、パケットの挙動や泥臭い例外処理の数々。それらを乗り越えた先にある堅牢なセキュリティ環境を、ぜひ君たちの手で構築してほしい健闘を祈る。

スポンサーリンク

コメント

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