【実務・中級編】 SASEアーキテクチャにおけるZTNAの位置づけと機能統合モデル – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御という「幻影」の終わり方：SASEとZTNAが描く新しいネットワークの地平

おい、そこの君。まだ社内ネットワークに入りさえすれば、どこを向いてもフリーパスだった「あの頃」の夢を見ているのかい？

「社内LANに繋がっているから安全」「VPNのトンネルを掘ったから信頼できる」。そんな境界防御（Perimeter-based Defense）の神話は、リモートワークの常態化とクラウドシフトの波によって、音を立てて崩れ去った。ランサムウェアが一度VPN機器の脆弱性を突けば、そこからフラットな社内ネットワークを縦横無尽に駆け巡る――そんな悪夢のようなインシデントを、僕らは現場の最前線で何度も目の当たりにしてきたはずだ。

だからこそ、いま僕たちが向き合うべき答えが「ゼロトラスト」であり、それをクラウドネイティブに具現化するアーキテクチャが「SASE（Secure Access Service Edge）」だ。

今回は、Gartnerが提唱したこのSASEフレームワークの中で、ZTNA（Zero Trust Network Access）がどのように他のセキュリティ機能と融合し、どうやって僕たちのインフラを守っているのか。その内部挙動と実務で使える設定・コードの裏側まで、徹底的に紐解いていこう。

—

1. SASEにおけるZTNAの位置づけと「機能統合」の正体

「SASEって結局のところ、何なんだ？」
若手エンジニアからよく受ける質問だ。一言で言えば、「ネットワーク（SD-WAN）とセキュリティ（SSE）を、クラウド上で一つに溶かし込んだもの」だ。

そのセキュリティ側のコアであるSSE（Security Service Edge）の中核を担うのが、以下の4つの要素技術だ。これらがバラバラに動くのではなく、一つの巨大なクラウド基盤（PoP）上で密に連携してこそ、本当のSASEと言える。

• ZTNA (Zero Trust Network Access)：社内アプリへのアクセス制御。「信じるな、常に検証せよ」の原則に基づき、接続元デバイスの状態やコンテキストを評価してアクセスを許可。
• SWG (Secure Web Gateway)：いわゆる「クラウドプロキシ」。インターネットへの出口対策として、URLフィルタリングやマルウェア検査を実施。
• CASB (Cloud Access Security Broker)：シャドーITの検知や、SaaS（Microsoft 365やSalesforceなど）上のデータ保護・DLP。
• FWaaS (Firewall as a Service)：クラウド上の次世代ファイアウォール。レイヤー4の通信制御や脅威防御を担当。

これらがバラバラのベンダー製品だとどうなるか？ ログの相関分析は面倒くさくなり、ポリシーの矛盾が生じ、何よりトラブルシューティングの際に「どの機器のパケットドロップで通信が遮断されたのか」を追うだけで夜が明けてしまう。

これをシングルペインオブグラス（単一の統合管理画面）で一元管理し、ユーザーがどこから（自宅のカフェからでも、出張先のホテルからでも）アクセスしようとも、同じポリシーを適用するのがSASEの真骨頂なのだ。

—

2. 通信の裏側で何が起きているのか？ ZTNAの接続シーケンス

では、ユーザーが社内業務アプリ（例: https://erp.example.com）にアクセスしようとしたとき、SASE/ZTNAの内部でパケットとAPIはどのようにやり取りされているのか。そのリアルなシーケンスを追ってみよう。

[クライアント (ブラウザ/エージェント)]
      │
      ├─ 1. HTTPSリクエスト送信 (GET /api/v1/users) ──> [SASE Edge PoP (ZTNA Proxy)]
      │                                                         │
      │                                           2. デバイスポスチャ＆ID検証
      │                                           (IdP / MDMと連携)
      │                                                         │
      │   <── 3. 認可NGの場合: 403 Forbidden or 認証リダイレクト ──┘
      │
      ├─ 4. 認可OKの場合: プロキシがバックエンドへ中継 ────────> [内部リバースプロキシ / 企業DC]
      │                                                         │
      │   <── 5. アプリケーションからのレスポンス ──────────────┘
      │
      └─ 6. クライアントへレスポンス返却 ──────────────────────>

ポイントは、クライアントが直接企業のバックエンドサーバーに到達するわけではないという点だ。
ZTNAの多くは「リバースプロキシ型（サービス-initiated）」または「軽量エージェント型（クライアント-initiated）」を採用しており、認証とデバイス検証（ポスチャチェック）が完了するまで、アプリケーションの存在自体がインターネットから隠蔽（Dark App）されている。

—

3. 実務で役立つ！ API連携とポリシー設定の実装例

ここからは、机上の空論を脱して、実務で直面するシチュエーションを想定したコードを見ていこう。

今回は、Web APIを開発・運用するエンジニアやインフラ担当者が知っておくべき、「ZTNAプロキシを経由したAPIリクエストの挙動」と、「APIクライアント側から見た実装例」、そして「クラウド型ZTNAのポリシー定義設定（イメージ）」を解説する。

3.1. クライアント側（Python）からのAPIリクエスト実装

ZTNA環境下では、リクエストヘッダーに有効なセッションJWT（JSON Web Token）や、デバイス証明書に基づく相互TLS（mTLS）が要求されることが多い。以下は、Pythonの requests ライブラリを使い、ZTNAプロキシ配下のAPIエンドポイントを叩く際のサンプルコードだ。

import requests
import sys

# ZTNAで保護された内部APIのエンドポイント
API_URL = "https://ztna-proxy.example.com/api/v1/inventory"

def fetch_inventory_data(auth_token, client_cert_path):
    """
    ZTNAプロキシを経由してセキュアにAPIデータを取得する関数
    
    Args:
        auth_token (str): 認証基盤（IdP）から発行されたJWTアクセストークン
        client_cert_path (tuple): mTLS用の (証明書ファイル, 秘密鍵ファイル) のパス
    """
    # 厳格なセキュリティ要件を意識したヘッダー構成
    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Content-Type": "application/json",
        "X-Device-Posture": "compliant" # クライアント側の状態を伝えるカスタムヘッダー（例）
    }

    try:
        # ZTNAゲートウェイへのリクエスト
        # 境界防御と異なり、ここではTLSの終端がSASEのPoPで行われるケースが多い
        response = requests.get(
            API_URL, 
            headers=headers, 
            cert=client_cert_path, # 端末証明書によるデバイス認証（mTLS）
            timeout=10
        )

        # ステータスコードに応じたハンドリング
        if response.status_code == 200:
            print("[INFO] APIリクエスト成功: データを正常に取得しました。")
            return response.json()
        elif response.status_code == 401:
            print("[ERROR] 認証エラー: トークンの有効期限切れか、不正なクレデンシャルです。", file=sys.stderr)
        elif response.status_code == 403:
            print("[ERROR] 認可エラー: ZTNAポリシーによりアクセスが拒否されました（ポスチャ不備の可能性）。", file=sys.stderr)
        else:
            print(f"[ERROR] 予期せぬステータスコード: {response.status_code}", file=sys.stderr)
            
        response.raise_for_status()

    except requests.exceptions.SSLError as e:
        print(f"[FATAL] mTLS証明書の検証に失敗しました: {e}", file=sys.stderr)
    except requests.exceptions.RequestException as e:
        print(f"[FATAL] ネットワークまたは接続エラーが発生しました: {e}", file=sys.stderr)

if __name__ == "__main__":
    # 実務では環境変数やセキュアなストレージから取得する値を想定
    dummy_token = "eyJhGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
    cert_files = ("/path/to/client.crt", "/path/to/client.key")
    
    # 実行
    # data = fetch_inventory_data(dummy_token, cert_files)

3.2. SASE/ZTNAコンソールにおけるアクセス制御ポリシー（YAML記述例）

次に、インフラエンジニアがシングルペインオブグラス（統合管理画面）の裏側で設定する、アクセス制御ポリシーの概念的な記述例を見てみよう。多くの先進的なSASEプラットフォームでは、ポリシーをコード（IaC）として管理できるようになっている。

# SASE/ZTNA アクセス制御ポリシーのサンプル定義
policy_version: "2024-10-01"
rule_name: "Restrict-ERP-Access-to-Compliant-Devices"
description: "人事・財務系ERPシステムへのアクセスは、管理された端末かつ特定グループのみに許可"

# 1. 誰からのアクセスか (Identity)
subject:
  user_groups:
    - "Corporate-Engineering"
    - "Finance-Department"
  identity_provider: "AzureAD-Okta-Federation"

# 2. どこへアクセスするか (Resource)
destination:
  applications:
    - "erp-production.internal.example.com"
  protocols:
    - "HTTPS"
  ports:
     - 443

# 3. どんなコンテキストか (Context & Posture - ZTNAの真髄)
conditions:
  device_posture:
    os_types:
      - "Windows"
      - "macOS"
    min_os_version:
      windows: "10.0.19045"
      macos: "13.0.0"
    security_requirements:
      disk_encryption_enabled: true     # BitLocker / FileVaultが有効か
      antivirus_active: true            # EDR/アンチウイルスが稼働しているか
      ip_address_ranges:                # 社内オフィスまたは許可されたVPN/IPレンジ
        - "203.0.113.0/24"
        
# 4. 判定アクション (Action)
action: "ALLOW" # 条件を満たさない場合は暗黙のDENY（遮断）

この設定を見てほしい。「誰が（User）」だけでなく、「どのデバイスで（Device Posture）」「どこから（Context）」アクセスしているかをリアルタイムに評価した上で、初めてバックエンドへの経路が開通する。これが従来のIPアドレスベースのファイアウォールルールとは一線を画す所以だ。

—

4. 現場のシニアが教える！ ZTNA導入・運用時のトラブルシューティングTips

最後に、僕がこれまでの現場で踏んできた数々の地雷と、そこから得た教訓をシェアしよう。ZTNAを導入した際によくあるトラブルとその対処法だ。

トラブル1: 「突然、社内アプリに繋がらなくなった」と問い合わせが殺到する

• 原因の特定: 大抵の場合、SWGやZTNAのエージェント側で「デバイスポスチャの再評価」が走り、OSのパッチ未適用やEDRの停止を検知してポリシーが DENY に切り替わったケース。
• デバッグ手法: SASE管理コンソールのリアルタイムログ（監査ログ）を開き、該当ユーザーのセッションIDでフィルタリングする。403 Forbidden の理由が Posture Check Failed: Antivirus out of date のように記録されているはずだ。ユーザーにEDRのアップデートを促せば即座に解決する。

トラブル2: APIサーバー側でクライアントの「本来のIPアドレス」が消えている

• 原因の特定: ZTNAプロキシがリバースプロキシとして動作しているため、バックエンドのAPIサーバーから見ると、アクセス元IPがすべて「SASE PoPのエグレスIP（またはプロキシの内部IP）」に見えてしまう。アクセスログの解析やアクセス制限（IPホワイトリスト）に支障が出る。
• 解決策: ZTNAプロキシとバックエンド（または社内リバースプロキシ）の間で、X-Forwarded-For ヘッダーや、標準化が進む Forwarded ヘッダーが正しくインジェクト・継承されているか確認する。また、プロキシ側の設定でクライアントIPの透過（Transparent Proxy）が有効になっているかも合わせてチェックしよう。

—

おわりに

境界防御という「高い城壁と頑丈な門」に頼っていた時代は終わった。これからのエンタープライズセキュリティは、城壁の内側・外側という概念を捨て去り、すべてのアクセスを疑い、その都度コンテキストを検証する――まさに「ゼロトラスト」の思想をSASEという実体あるインフラに落とし込むことが求められる。

最初は複雑怪奇に見えるシングルペインオブグラスや細かなポリシー設定も、パケットの流れと認証のライフサイクルさえ頭に叩き込んでおけば、恐れることは何もない。
さあ、古いネットワークの呪縛を断ち切り、真にセキュアでモダンなインフラを僕たちの手で構築しようじゃないか。