2026年9月28日
ゼロトラストWGリーダー　諸角昌宏

背景

ゼロトラスト実装の5ステップ（NSTACモデル）入門シリーズについての質問で、ZTNAとZTAの違いを詳しく説明してほしいという意見がある。特に、ZTNAの導入ではZTを実現したとは言えないというのはどういうことかという質問が寄せられている。

そこで、本ブログでは、ZTNAだけでは十分でない理由、および、SASE／SSE・IdPと組み合わせても残る課題について掘り下げてみる。

はじめに

Zero Trust Network Access（ZTNA）は、VPNの代替として急速に普及している。「ゼロトラスト実装の5ステップ」シリーズ第3回でも、SDPと並ぶ代表的な実装パターンの一つとして紹介した。しかし、「ZTNAを導入した＝ゼロトラストを実現した」という理解は誤解である。

本シリーズが依拠するNSTACの5ステップは、ゼロトラストという抽象的な原則（「決して信頼せず、常に検証する」）を、組織が実際に手を動かして実装していくための、実践的な進め方である。ZTNAやSASE/SSEといった技術は、この5ステップのうち主にステップ3（アーキテクチャの構築）を実現する手段の一つにすぎず、5ステップ全体を代替するものではない。

今回は、ZTNAだけでは十分でない理由を整理し、そのうえでSASE／SSEやIdP（アイデンティティプロバイダー）と組み合わせた場合に何が改善し、何が改善しないのかを検討する。

ZTNAだけでは十分でない理由

ZTNAは、ZTA（ゼロトラストアーキテクチャ）を構成する要素の一つであり、ネットワークアクセス制御に特化した技術カテゴリである。つまりZTNAは、ZTAという大きな設計図の一部分にすぎない。具体的には、次の理由がある。

① 単独では、5本柱を包括的にカバーしない

ZTNAは、CISAのゼロトラスト成熟度モデルにおけるネットワークの柱を中心に、アイデンティティ、デバイス、アプリケーションへのアクセス制御にも関係する。接続を許可するにはユーザーを認証する必要があり、多くの製品はデバイスの状態も判断材料に含め、制御の単位もネットワーク全体ではなくアプリケーション単位である。しかし、ZTNAだけで5本柱および3つの横断的能力（可視化と分析・自動化とオーケストレーション・ガバナンス）を包括的に実現できるわけではない。データの分類・保護や、エンドポイントの詳細な健全性管理などは、別の仕組みで補う必要がある。

② 「入口」は絞れても、「入った後」の制御には限界がある

多くのZTNA製品は、接続開始時にユーザー/デバイスを検証して「このアプリへのアクセスを許可するか」を決めることに主眼を置いている。しかし、いったんアクセスが許可された後、そのセッションの中で何が行われるかまでは見ていないことが多い。真のゼロトラストは、一度きりの検証ではなく、継続的な検証を要求している。

③ ラテラルムーブメント（横移動）対策は「軸」によって効き方が違う

従来型VPNでは、接続後のアクセス範囲を適切に制限していない場合、広範なネットワークリソースへの到達が可能となり、横移動のリスクが高まる。一方ZTNAは、アクセス対象をアプリケーション等の単位に限定することで、このリスクを低減する。常に検証し、最小権限による制御を前提とする設計であることも、この違いを支えている。

ただし、ここには以下の2つの異なる軸がある。

軸	何の話か	ZTNAの役割
A：ユーザー→アプリの横移動（VPN文脈）	アクセス範囲が適切に制限されていない場合、リモートユーザーが広範なネットワークリソースに到達できてしまう問題	ZTNAはアクセス対象をアプリ単位に限定し、このリスクを低減する
B：サーバー・ワークロード間の横移動（マイクロセグメンテーション文脈）	攻撃者がいったん社内の1台に侵入した後、サーバー間・サービス間を東西(east-west)に動き回る問題	ZTNAは通常ここまでは踏み込まない。別の技術（マイクロセグメンテーション）の役割である

表1：ZTNAが効く横移動と、効かない横移動

Target社の事件では、外部委託先の認証情報を悪用した侵入後、内部ネットワークでの横移動が発生した。本ブログでの分類では、特に軸Bに相当する問題を示す事例である。

④ 非人間アイデンティティへの対応が弱い

多くのZTNA製品は、人間のユーザーがアプリにアクセスする場面を想定して設計されており、サービスアカウントやAPI、ワークロード間の通信、AIエージェントのような非人間の主体に対するコントロールは、そのままでは不十分なことが多い。「Whoには人だけでなく非人間も含める」という、シリーズ第4回で説明した原則が、ZTNA単体では十分にカバーしきれない領域である。

⑤ 通信内容の脅威検査は、別の機能に委ねられる

アクセス制御を主機能とするZTNAは、マルウェアやゼロデイ攻撃を通信内容から検出・防御すること自体を主目的としていない。こうした脅威に対応するには、ZTNAと連携する脅威検査機能やエンドポイント保護等が必要になる。

⑥ 5ステップで言えば「ステップ3の一部」にすぎない

ZTNAは、5ステップのうちステップ3（アーキテクチャの構築）で選べる実装パターンの一つにすぎない。ZTNAをどれだけ高度に導入しても、プロテクトサーフェスの定義（ステップ1）を飛ばしていれば何を守るべきか曖昧なままであり、トランザクションフローのマッピング（ステップ2）がなければポリシーの中身がスカスカになり、監視と保守（ステップ5）がなければ時間とともにポリシーが陳腐化する。ZTNAという「箱」を導入しただけでは、その中身（ポリシー、プロテクトサーフェスの定義、継続的な運用）が伴わなければ機能しない。

ZTNAとIdPを組み合わせるとどうなるか

ZTNAの限界を踏まえると、「IdP（アイデンティティプロバイダー）と組み合わせればどうか」という発想が浮かぶ。これは第3回で説明した「ZTNAという枠組みに、IdPをデータソースとして接続する」という構成そのものであり、実務でも広く行われている。

ただし、ここで前提を一つ補足しておきたい。ZTNAをSSEやSASEの構成要素として提供するベンダーが存在し、SWGやCASB等との統合が進められている。SASE（Secure Access Service Edge）は、SD-WAN等のネットワーク機能とクラウド提供型のセキュリティ機能を統合するアーキテクチャである。一方、SSE（Security Service Edge）は、SASEのセキュリティ機能部分に相当し、ZTNA、SWG、CASB等を中心に構成される。ZTNAは、このSSEに含まれる機能の一つにすぎない。なお「ZTNA 2.0」は、SASEやSSEという製品カテゴリを指す言葉ではなく、ZTNAという機能自体を、継続的検証やインライン脅威検査まで含めてより高度に実装したものを指す、ベンダー側の呼称である。三者は並列の同義語ではなく、ZTNAはSASE/SSEを構成する機能の一つである。ZTNA 2.0は、そのZTNA機能を高度化したものを指すベンダー提唱の概念であり、SASE/SSEの実装に組み込まれる場合がある。

こうした統合が進むベンダーの構成を踏まえ、以下では「ZTNA単体＋IdP」ではなく、「SASE／SSE＋IdP」という組み合わせで、先の課題がどこまで解消するかを見直してみる。結論から言えば、かなり改善するが、埋まらない穴は変わらず残ると考えられる。

ZTNA単体の課題

ZTNA単体の課題	SASE/SSE ＋ IdP	改善の程度（構成条件による）
① 5本柱を単独では包括的にカバーしない	アイデンティティの柱をIdPが補強し、SASE/SSEはネットワーク以外の柱にも機能を広げる	○
② 接続時の検証だけで、その後は見ない	IdPとSASE/SSEの連携により、リスク変化の検出と接続後のコントロールを強化できる。ただし、実現範囲は製品・構成に依存する	◎
③-A ユーザーの横移動（VPN文脈）	ZTNAによるアプリケーション単位のアクセス制御により、広範なネットワーク到達に伴う横移動リスクを低減する	◎
③-B サーバー・ワークロード間の横移動	マイクロセグメンテーションはSASE/SSEとは別の機能・製品として提供される場合があり、別途対応が必要となることがある	△
④ 非人間アイデンティティに弱い	IdP側の対応範囲拡大に加え、SASE/SSE側も進みつつあるが発展途上	△
⑤ 通信内容の脅威検査は、別の機能に委ねられる	SSEに含まれるSWG等の機能が脅威防御を、DLPが機密情報の持ち出し制御を担う。ただし対象通信・構成は製品によって異なる	○
⑥ 5ステップのうちステップ3の一部にすぎない	ステップ4（ポリシー）の判断に利用できる情報が拡充する。ただし、ステップ1・2・5は製品によって支援・自動化できても、組織の責任そのものは代替できない	△

表2：ZTNA単体の課題と、SASE／SSE＋IdPを組み合わせた場合の改善の程度
凡例：◎＝大きく改善する、○＝一定程度改善する、△＝限定的な改善にとどまる

⑤はかなり埋まる。ただし条件と構成に依存する

SSEに含まれるSWG等の機能により、対応する通信についてマルウェア検査や脅威防御を実施できる。また、DLPによって機密情報の不適切な持ち出しを検出・制御できる。ただし、TLS復号の可否、検査対象となる通信、適用されるセキュリティポリシーは製品や構成によって異なる。これにより、ZTNA単体では扱えなかった「通信内容の脅威検査」は、条件が整えば大きく前進する。

特に注意したいのは、同じベンダーの製品であっても、ZTNAを担うサービスと脅威検査を担うサービスは、別々に設計・提供されていることが多いという点である。両者を連携させる設定を明示的に行わなければ、ZTNA経由の通信が脅威検査を自動的に通るとは限らない。

「SASE/SSEを導入した」だけでは足りず、構成として正しくつなぎ込まれているか、対象通信・ポリシーが意図どおりかの確認が要る。

③-Bは、SASE/SSEに広げても、なお埋まりにくい

一方、マイクロセグメンテーション（サーバー・ワークロード間の横移動対策）は、SASE/SSEとは別の機能・製品として提供される場合があり、導入時には両者の機能範囲や連携状況を確認する必要がある。

つまり、「SASE/SSEまで導入したから安心」という判断は早計であり、Target社事例のような内部の横移動対策は、依然として別の検討が必要である。

特に効くのが②：継続的なリスク評価

これが一番の実質的な進歩である。一部のIdP製品は、認証後もユーザーやセッションのリスク変化を検出・評価する機能を備えている。ただし、リスク評価と既存セッションのコントロールは別の機能である。IdPの評価結果をZTNAやSSEのアクセス制御に反映し、必要に応じて再認証・アクセス制限・セッション終了を実行できるよう、製品間の連携とポリシーを適切に構成する必要がある。こうした連携によって、接続時だけでなく、接続後の状況変化にも対応できる。

これはまさに、第3回で説明したCBAC（コンテキストベースアクセス制御）が目指す「セッション中も継続的に再評価する」という原則を、実装レベルで具体化したものである。

それでも、組織の責任そのものは代替できない

ここが本ブログの核心である。ベンダーがZTNAの機能を、SASE・SSEというプラットフォームや「Zero Trust Platform」といった上位概念に組み込み、どれだけ機能を束ねて上位概念に昇華させても、以下の3点は製品によって支援・自動化できるが、組織の責任そのものは代替できない。

• プロテクトサーフェスの定義（ステップ1）
• トランザクションフローのマッピング（ステップ2）
• 監視と保守（ステップ5）

資産管理ツールやCMDBは棚卸しを助け、フロー可視化ツールはマッピングを助け、SIEMやアクセスレビュー自動化ツールは監視・保守を助ける。しかし、「何を守るべきか」「どこにコントロールを置くべきか」という最終的な判断と責任は、組織にしかできない仕事である。むしろ、ベンダーが機能を統合すればするほど、「それでも組織の責任は残る」という結論が、より際立って正しく見えてくる。

「組織の責任は代替できない」ことで、実際に何が起きるか

ここは、単に「代替できない」と言うだけでは足りない。放置すると、具体的に次の3つの問題が起きる可能性がある。

1. 高機能な製品を入れても、「何を守るか」を考えていなければ意味がない
   プロテクトサーフェスの定義（ステップ1）を組織自身が行わなければ、何を重点的に保護すべきかが曖昧となり、保護すべき対象がアクセス制御の対象から漏れる可能性がある。また、保護対象に応じた適切なアクセス制御を設計できず、業務への影響を避けるために広すぎるアクセス許可を敷いてしまう場合もある。その結果、高機能なプラットフォームを導入していても、本来守るべき重要な資産が十分に保護されない状態になりかねない。
2. ポリシーの中身がスカスカになる
   トランザクションフローのマッピング（ステップ2）がなければ、「誰が・どこへ・何のためにアクセスするか」の実態が分からないままポリシーを書くことになる。フローのマッピングはポリシーの“下書き”であり、下書きがなければポリシーは推測や慣習で書かれ、必要なアクセスを誤って止めて業務が止まるか、逆に不要なアクセスを許してしまうことになる。
3. 導入時は良くても、時間とともに劣化する
   監視と保守（ステップ5）がなければ、業務やシステムが変化してもポリシーは自動では更新されず、ポリシーの腐敗がそのまま進行する。最新のプラットフォームを入れた初日は良い状態でも、1年後には形骸化している、という事態になる。

この問題について以下のよく知られた事件を5ステップの観点から分析し整理してみる。なお、これらは各社の公式な原因発表そのものではなく、5ステップという枠組みに照らして整理した分析である点に留意されたい。

事例	関連するステップ	何が起きたか
Capital One（2019年）	ステップ1、4	攻撃者は設定上の脆弱性を悪用して不正アクセスし、過大な権限を持つIAMロールを利用してS3上の情報を取得した。米国約1億人、カナダ約600万人が影響を受けた。保護対象の特定（ステップ1）だけでなく、アクセス権限の最小化と設定管理（ステップ4）の重要性を示す事例と解釈できる
Colonial Pipeline（2021年）	ステップ5	攻撃者は、当時使用されていなかったものの有効な状態だったVPNアカウントを悪用した。当該レガシーVPNではMFAが適用されていなかった。アカウントのライフサイクル管理、アクセス権限の定期的な見直し、MFA適用という、継続的な運用（ステップ5）の重要性を示す事例と解釈できる
Equifax（2017年）	ステップ5	既知のApache Strutsの脆弱性に対するパッチ適用が行われていなかった。また、ネットワーク監視に利用する証明書が約19か月間期限切れとなっており、暗号化通信の監視に支障が生じていた。攻撃による侵害は約76日間継続し、約1億4,800万人の個人情報が影響を受けた

表3：組織的な作業の観点から分析した主な事例

いずれも、高度なセキュリティ製品の有無とは別の次元で、組織的な判断・継続的な運用という観点から解釈できる事件である。

一言でいえば、「製品が高機能かどうか」と「その製品が正しく機能するかどうか」は別問題である。SASE/SSEは、正しいポリシーを、正しく強制する道具にすぎない。「何を・なぜ・どのように守るか」という中身は、組織が用意しなければならない。「組織の責任は代替できない」ことの本当の問題は、「良い製品を買えば安心」という誤った安心感を生み、実際にはザルなポリシーのまま運用されてしまうリスクがあるということである。

ZTNAやSASE/SSEは、ZTAにおけるアクセス制御やポリシーの実施を担う技術として利用できる。また、IdPはアイデンティティ情報や認証結果を提供し、アクセス判断を支える。ただし、これらの製品を組み合わせても、組織として何を保護対象とし、どの通信経路にどのようなコントロールを適用するかが自動的に決まるわけではない。第3回で説明したとおり、PEは、組織が定めたポリシーと各種データソースから得られる情報に基づいてアクセスを判断する。しかし、その判断の基礎となる保護対象の定義やアクセス方針を策定する責任は、組織にある。そのポリシーの中身は、プロテクトサーフェスの定義とトランザクションフローの理解に基づいて、業務オーナーとセキュリティ担当が作り込むものであり、これを用意するのは、あくまで組織の仕事である。

さらに、いったん作ったポリシーも、業務やシステムの変化に応じて陳腐化していく。ステップ5の監視と保守、つまりマッピングと実態の突き合わせ、ポリシーの検証と見直しを継続しなければ、どれほど高機能な製品を導入していても、ポリシーはやがて「腐敗」する。ZTNA・IdP・SASE/SSEをはじめ、あらゆる技術的な対策は、この組織的な土台があって初めて意味を持つことになる。

まとめ

SASE/SSE＋IdPの組み合わせは、「誰が」という軸（アイデンティティ）と「通信の脅威検査」という軸の両方を大幅に強化し、しかも一度きりでなく継続的に検証できるようにする、という点で非常に理にかなっている。ただし、以下の点はこの組み合わせでも埋まらない。

• 内部の横移動対策（マイクロセグメンテーション）：　SASE/SSEだけでは対応範囲が十分でない場合があり、別途の対策を検討する必要がある
• プロテクトサーフェスの定義・トランザクションフローのマッピング・監視保守という組織的な作業（ステップ1・2・5）：　製品によって支援・自動化できるが、組織の責任そのものは代替できない

「SASE/SSE＋IdPを入れれば十分」ではなく、「それらは、5ステップの中の“良いパーツ”の一つ」と捉えるのが正確であると考える。ベンダーがZTNAの機能を、SASE/SSEといった上位のプラットフォームに組み込んでも、とりわけステップ1・2・5は、製品の導入では代替できない、組織自身が担うべき中核的な仕事である。ゼロトラストは製品の組み合わせで完成するものではなく、5ステップという手順そのものを、組織として回し続けることで実現される。これは、本シリーズが一貫して伝えてきた考え方に、改めて行き着く結論である。

参考資料

• Portnox「Why Do ZTNA Solutions Fall Short When It Comes to Zero Trust?」
• Cato Networks「ZTNA Alone Won’t Win the Zero Trust Race」
• Palo Alto Networks「What is Zero Trust Network Access (ZTNA) 2.0」
• Reco AI「Top Zero Trust Security Solution」
• そのほか、事件に関する公開情報

以上