VPN 全廃の現実化と ZTNA 主要製品の棲み分け
- 年、日本の大手企業でも「従来型 VPN を全廃した」と公言する事例が複数出始めた。トリガーとなったのは 2024〜2025 年に断続的に発生した VPN 機器の深刻な脆弱性（Ivanti Connect Secure の認証バイパス、Fortinet の SSL-VPN ゼロデイ連鎖）であり、監査対応工数と可用性リスクが移行コストを上回る状況に追い込まれた。金融庁の FISC 安全対策基準も 2026年改訂で「フラット内部ネットワーク前提の設計を見直すこと」が明文化され、ZTNA は流行語から監査必須項目へ格上げされている。
主要 ZTNA 製品は4層に整理できる。最上位は Zscaler Private Access（ZPA）と Google BeyondCorp Enterprise。次に Cloudflare One（Access + Warp + Tunnel）、その下にスタートアップ発の Tailscale・Twingate、最後に OSS の OpenZiti・Pomerium が位置する。年間 1 ユーザーあたり 2,000 円（Tailscale Team）から 25,000 円超（Zscaler Transformation Edition）まで 10倍以上の開きがあり、ユースケースと成熟度で選択肢が分かれる。
選定で最初に問うべきは「自社の IdP は何か」である。Google Workspace 一択なら BeyondCorp Enterprise が破格に滑らかで、デバイス信頼と Context-Aware Access が追加ライセンス無しで組める。Entra ID 中心なら Microsoft Entra Private Access が有力候補で、Conditional Access との連携が自然だ。Okta 中心なら Cloudflare Access か Zscaler が無難で、Okta Workflows による権限プロビジョニングとの相性が良い。
デバイスポスチャと mTLS: 「誰が」から「何から」へ
ZTNA の本質はネットワーク境界ではなく「リクエスト発信元の属性」で判定することにある。属性は3種類に分かれる。ユーザー属性（SSO ID、グループ、MFA 方式）、デバイス属性（OS バージョン、ディスク暗号化、EDR 稼働、管理対象か）、コンテキスト属性（送信元地域、時刻、過去の振る舞いとの乖離）。ユーザー属性のみで判定する設計は事実上「IP 制限付き SSO」であり、ZTNA とは呼べない。
デバイスポスチャの実装度は製品差が大きい。Cloudflare Access は WARP クライアントに加え、CrowdStrike・SentinelOne・Tanium とネイティブ連携し EDR の健全スコアをポリシーに流せる。BeyondCorp Enterprise は Chrome 組み込みの Endpoint Verification を起点に OS パッチ状態を ABAC ルールに乗せる。Tailscale は Device Posture を 2024 年に追加し、osquery ライクなデバイス情報とカスタム tags でゾーン分離できる。
mTLS は ZTNA の下層を支える。クライアント証明書を端末にプロビジョニングし、接続時にサーバー証明書と相互検証することで、盗まれたパスワードだけでは侵入できない層を作る。Cloudflare Access は mTLS Enforcement オプションで企業発行証明書の提示を強制できる。BeyondCorp は Chrome Enterprise の管理証明書を自動配布し、UX を損なわずに mTLS を強制できる点で優位だ。Tailscale は WireGuard 自体が公開鍵ベース相互認証のため mTLS は不要だが、Layer7 の HTTPS 保護には別途 PKI が必要になる。
SSO 統合の落とし穴: SCIM と JIT プロビジョニング
SSO 統合は SAML/OIDC で IdP と接続するところまでは容易だが、実運用で問題になるのは「ユーザーの追加・変更・削除」をどこで制御するかだ。SAML/OIDC は認証時の属性しか流れないため、退職者や部署異動者のアクセス取り消しを SSO だけに頼ると、最悪ケースで退職後数週間アクセス可能な状態が残る。
これを解決するのが SCIM 2.0 による自動プロビジョニング／デプロビジョニングだ。Okta、Entra ID、Google Workspace はいずれも SCIM 2.0 を標準サポートし、Cloudflare Access・Zscaler・Tailscale・Twingate はすべて SCIM 受信側に対応している。SCIM を有効化しない ZTNA 導入は「製品を買ってゼロトラストを名乗りつつ実質は古いアクセス管理と同じ」であり、監査指摘の標的になる。
step-up 認証（高リスク操作時の追加強認証）も ZTNA と IdP の境界で設計すべき領域だ。Okta FastPass、Entra ID の Authentication Context、Google の Reauthentication Policy が典型で、「このアプリのこの操作には 5分以内に取得された Passkey 認証が必須」といった条件分岐を書ける。ZTNA 側で「step-up が必要なリソース」を指定し、IdP 側で実際の認証強度を制御する責務分離が機能する。
日本法人導入のハードル: 社判・退職者・情シス権限
日本法人で ZTNA 導入を進める際、純粋に技術的でない障害が3つ立ち上がる。第一に「利用申請フロー」だ。日本の情シスは依然として「部長承認の申請書（電子化 Workflow か紙の社判）」を介してアクセス権を付与する文化が強い。ZTNA の「属性とポリシーで動的に判定する」思想と正面衝突する。移行戦略は申請フローを廃止するのではなく、「ServiceNow や SmartHR・freee 人事労務の承認結果を IdP グループに自動反映し、ZTNA ポリシーが参照する」という橋渡しを作ることだ。既存の承認文化を維持しながらポリシーは動的に動く。
第二に「退職者アカウントの扱い」だ。日本企業では退職後も有給消化期間中の業務アクセスが必要なケース、引き継ぎ作業が発生するケースが多く、単純に退職日で IdP 無効化する運用では現場が回らない。解決策は「雇用ステータスのステートマシンを IdP 属性に乗せる」ことである。active → notice → handover → terminated の4状態を定義し、各状態ごとに ZTNA ポリシーを切り替える。handover 状態では特定リポジトリのみ read-only、SaaS は閲覧のみ、といった制御が可能になる。
第三に「情シスと業務部門の権限分離」である。日本の情シスは伝統的に全権を持ちがちで、ZTNA 管理者権限も情シスに集中しやすい。JSOX・PCI DSS・ISMS いずれも職務分掌を求めるため、ZTNA 管理コンソールは少なくとも「ポリシー作成者」「ポリシー承認者」「監査閲覧者」の3ロールに分離し、同一人物が兼務しない運用が必要だ。Cloudflare・Zscaler・BeyondCorp は RBAC で細分化でき、Tailscale も 2025年後半から admin role 分割に対応している。
移行ロードマップと Break Glass 経路
典型的な移行は6〜12ヶ月で段階展開する。第1段階（1〜2ヶ月）は SSO・SCIM 整備。第2段階（2〜4ヶ月）で ZTNA 製品選定と社内 Web アプリ・SaaS の先行展開。第3段階（4〜8ヶ月）で SSH・RDP・DB アクセスをトンネル化し VPN 主要用途を代替。第4段階（8〜12ヶ月）で VPN 機器停止、監査ログの SIEM 集約、step-up 認証の全面適用を行い旧経路を物理的に閉じる。
KGA が支援する案件では、第2・3段階の間に「Break Glass」経路設計を必ず挟む。ZTNA 障害時に業務停止しないための極めて限定的な緊急アクセス経路で、物理トークン必須、利用時の全社通知、使用後72時間以内の事後監査会議、という運用を文書化する。ゼロトラストであっても「全停止」を許さない設計規律が、監査役会と業務部門の双方から支持を得る鍵となる。製品選定以前に、IdP・SCIM・HR システム・SIEM の運用一気通貫を点検することを、まず勧めたい。