ZTNAとは何か？「脱VPN」と言われる理由から導入時の注意点まで解説

はじめに

NTT西日本の寺崎 智博です。

本記事では広く使われている一方で、意味が曖昧になりやすい、Zero Trust Network Access（略してZTNA）について解説します。 私はこれまで、数々のお客様のリモートアクセス環境見直しやZTNA導入を支援してきました。その中で強く感じるのは、ZTNAが非常に注目されている一方で、言葉だけが先行し、実態が誤解されやすいテーマでもあるということです。

「ZTNAはVPNとまったく違うのか」「脱VPNは本当に必要なのか」といった疑問は、導入検討の現場で何度も向き合ってきました。そうした実務の現場で得た知見をもとに、ZTNAの考え方、VPNとの違い、導入時の注意点を整理して解説します。

本記事の内容は2026年2月時点の情報に基づきます。

---

対象読者

本記事が想定する対象読者は以下の通りです。

• リモートアクセス環境の見直しを考えているシステム管理者の方
• VPNを狙った攻撃に不安を感じている経営者の方
• ゼロトラストに関心をお持ちのエンジニアの方
• セキュリティに興味をお持ちの学生さん

---

目次

---

1. 背景

現在、さまざまなメーカーやベンダーが「ゼロトラスト」というワードを引っ提げてマーケティングを展開しており、正直なところ言ったもの勝ちの状態になっています。特に Zero Trust Network Access (ZTNA) については拡大解釈が多く、導入を検討されるお客様が混乱しているケースを多々見てきました。

最近でも大手企業でVPN機器を侵入経路としたランサムウェア被害が大々的に報道され、 脱VPN や ゼロトラスト というワードがWeb上を賑わせています。しかし、具体的な仕組みを理解されている方は意外と少ないのではないでしょうか。

本記事の目的は、バズワード化した「ゼロトラスト」の中心的存在であるZTNAが一体どのような仕組みで、なぜ今必要とされているのかを正しく理解していただくことです。不確かな情報に振り回されず、自社に最適なネットワーク環境を構築するための一助となれば幸いです。

2. Zero Trust Network Access (ZTNA) とは

ZTNAを一言で表すと、「インターネットを介して、場所に依存せず社内リソースへ安全にアクセスする仕組み」です。

実は界隈では、「ZTNAはVPNとは全く違う」と主張する派閥と、「新しい世代のVPNもZTNAに含める」派閥が存在します。これが大きな混乱の元なのですが、根底にはメーカー各社の考え方の違いが絡んでいます。

まずは難しく考えず、「社内リソースへ安全にアクセスする仕組み」と捉えていただければ問題ありません。

3. 普及したきっかけ

ゼロトラストという概念自体は2006年頃から存在していましたが、一気にバズワード化したのは2020年の新型コロナウイルスのパンデミックがきっかけです。急遽始まった在宅勤務に対応するため、世界中の企業が突貫工事でVPN環境を整備・拡大しました。その結果、攻撃者にとって格好のターゲット（VPN機器）が世界中に爆増したのです。

ちょうどこの頃、警察庁のデータ（令和4年上半期）でも、ランサムウェア被害の感染経路の多くがVPN機器であったことが示されています。（下図）

令和4年上半期におけるサイバー空間をめぐる脅威の情勢等について（警察庁）

出典： https://www.npa.go.jp/publications/statistics/cybersecurity/data/R04_kami_cyber_jousei.pdf

VPN機器の脆弱性を狙ったサイバー攻撃が急増したことで、リモートワーク環境のセキュリティを根本から見直すソリューションとして「ゼロトラスト」が脚光を浴び、「脱VPN」という言葉が広く使われるようになりました。

4. ZTNAの定義

では、公的な定義はどうなっているのでしょうか？

ゼロトラストの拠り所となるガイドラインとして最も公的なものと言えば、アメリカのNISTが発行した「NIST 800-207 Zero Trust Architecture」というドキュメントですが、このドキュメントは非常に難解で、「ネットワークアクセス」そのものズバリの定義は薄いのが実情です。どちらかと言うとゼロトラストという考え方全体を概念的に記載したものになっています。

参考：NIST SP 800-207 Zero Trust Architecture https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

そこで、ZTNAという言葉の生みの親であるガートナー社の定義を見てみましょう。

ZTNAは、アプリケーションやデータへのアクセスを「場所」ではなく「IDとコンテキスト」に基づいて制御する仕組みです。リソースを不可視化し、ネットワーク内の横移動（ラテラル・ムーブメント）を防ぐとともに、最小限のアクセス範囲を確保します。

出典：https://www.gartner.co.jp/ja/topics/zero-trust

おそらく、この説明だけで腹落ちする方は稀でしょう。ここから、この定義を分かりやすく噛み砕いていきます。

5. なぜ「脱VPN」が叫ばれるのか？

序盤に「ZTNAはVPNとは違う」派閥と「新しい世代のVPNもZTNAに含める」派閥に分かれると述べました。

「あれ？脱VPNじゃなかったの？VPNもZTNAと呼ぶなら脱VPNじゃなくない？」と思われる方も多いと思います。実際、私も今まで数多くのお客様からこのような疑問を問いかけられました。

ここを理解するために「なぜVPNが悪者扱いされ、脱VPNと言われているのか」を解説します。

5.1. 従来型VPNの課題とZTNAの利点

従来型VPN（Virtual Private Network）は、通信内容を暗号化する技術としては優れており、盗聴の心配はほぼありません。問題は、VPN機器の接続口（例えばHTTPSなら443番ポート）がインターネットに堂々と公開されていることです。もちろん固定のグローバルIPアドレスを持っているため、攻撃者からすれば「ここを攻撃してください」と言わんばかりの的になっており、脆弱性が発見されると即座に狙われる傾向があります。

従来型VPN構成

一方ZTNAは、インターネットから直接到達可能な接続口（リスニングポート）を公開しません。 外部からの接続点は、ZTNA事業者が管理する堅牢なクラウド上に存在します。この接続点は市販されているVPN機器と違い、仕様がブラックボックスになっていることに加え、接続点の脆弱性管理やアップデートもZTNA事業者が行うため、可用性・信頼性向上に加え、運用負荷が低減するという大きなメリットがあります。

ZTNA構成

ここまでで、従来型VPNとZTNAの接続点に関する違いをご説明いたしました。ここでさらに、ZTNAを実現するためのアーキテクチャ（構成方式）についても触れておきます。現在、ZTNAの構成には大きく分けて2つの方式があります。ここでは"便宜上" 「IAP型」 と 「VPN型」 と表現します。（本記事での便宜上の分類であり、一般的な用語ではありません）

5.2. IAP型ZTNA

IAPとは「Identity Aware Proxy」の略で、直訳すると「ID認識型プロキシ」です。企業ネットワーク上にコネクターと呼ばれるプロキシサーバーを立てて、このプロキシサーバーがリモートアクセス通信の仲介を行います。
このプロキシサーバーは常にクラウド上の接続ポイントと通信しており、リモートアクセスの通信が来たら代理で内部のサーバーに通信を行い、結果をクライアントに返します。「ID認識型」という名前の通り、接続元のユーザーIDを識別してアクセス権がある場合にのみ通信を成立させることから、この名前が付けられています。

IAP型ZTNA

多くのサービスでは、このプロキシサーバーは簡単に拡張できるようになっています。冗長化や負荷分散の目的で、このプロキシサーバーは複数台設置し、足りなくなれば数を増やすという運用をします。

5.3. VPN型ZTNA

VPN型の方は、企業ネットワーク上にはルーターを置きます。このルーターがIPsecなどの技術を使ってクラウド上の接続ポイントとトンネリングします。

VPN型ZTNA

VPN型の場合は、IAP型のように足りなくなれば増やすというような柔軟な対応はあまり得意ではありませんが、そもそもルーターなので、元から結構な量のトラフィックを捌けることから、拡張性はあまり問題になりません。もしトラフィック量が増えてどうしようもなくなったら、その時はハイスペックなルーターに置き換えることになります。

この2つが最初に述べた2つの派閥で、「VPNとZTNAは違う派」がIAP型ZTNAで、「新しい世代のVPNもZTNAに含める派」がVPN型ZTNAです。

双方にメリット・デメリットがあり、どちらの方が優れているというものではありませんので、今後仮にどちらか片方のネガティブキャンペーンをしている話を耳にされることがあったら、この解説を思い出していただけると幸いです。

参考｜違う名前の同じような言葉

少し横道にそれますが、IAPと似た概念の言葉で「SDP (Software Defined Perimeter)」という言葉があります。
直訳すると「ソフトウェアで定義された境界」です。ファイアウォールを境とした「社内ネットワーク／社外ネットワーク」という物理的な境界ではなく、ソフトウェアの力でアクセス権を動的に判断しようという、ZTNAのベースとなった概念です。
現在はIAPもSDPもZTNAという言葉の陰に隠れて、あまり聞かなくなった印象があります。

6. ZTNAの肝：認証と認可

ここからは機能の核心に迫ります。ガートナー社の定義の一つ目「場所ではなく“IDとコンテキスト”に基づいて制御」という部分です。

ID（誰が）は分かりやすいですが、コンテキストとは何でしょうか？これは「パスワード以外の付加情報（状態・環境）」を指します。例えば、「ついさっき日本でログインしたIDが、5分後にヨーロッパからログインを試みている」といった不自然な状況（コンテキスト）を加味してアクセスを制御することです。これを「動的な認証認可」と呼びます。

ここで「認証」と「認可」の違いを車の検問に例えてみます。

• 認証（ログイン）： 「免許証を見せてください」と本人確認すること。
• 認可（アクセス制御）： 「中型免許をお持ちですね。では通ってよし」と権限を確認すること。
• 動的な認証認可（ZTNAの肝）： 「お酒も飲んでおらず、シートベルトも締めていますね（安全な状態ですね）。では通ってよし」と、状況に応じて許可を出すこと。

というイメージです。

実はZTNAの導入時、「認証」は既に各社の環境で使われている既存のIdP*1（OktaやMicrosoft Entra IDなど）に任せることが大半です。ZTNAが本当に頑張るべきは、細かいコンテキストを判断する「認可」の部分なのです。

6.1. Device Posture

この細かな「認可」を実現するのが、多くのZTNA製品に搭載されているDevice Postureという機能です。「Posture」を直訳すると「姿勢」なのですが、私は「状態」と考えるのがわかりやすいと思っています。デバイスの状態に応じたアクセス制御をする機能で、これこそがゼロトラストの真骨頂と言えます。

デバイスの状態チェックには、一例として以下のような項目があります。

• 事前に会社が登録した端末か
• OSが指定のバージョン以上にアップデートされているか
• 指定のセキュリティソフトが正常に稼働しているか

ZTNAはこれらのチェックをクリアした「安全性が確認できた端末」だけを社内リソースに接続させます。

さらに、「スケジューラーは本人確認だけでOKだが、顧客データベースは会社支給かつ全セキュリティ条件をクリアした端末のみアクセス可」といったように、アクセス先のリソースごとに細かくルール（ポリシー）を設定できるのが強みです。製品によっては、EDR*2がマルウェア感染などの危険なアラートを出していないかをチェックする機能を持つものもあり、こういった機能をうまく使うと、「マルウェア感染の心配がない端末だけが接続できる」というようなスマートな制御も可能となります。

6.2. マイクロセグメンテーション

次に、ガートナー社の定義の2つ目のポイントである「リソースを不可視化し、ネットワーク内の横移動（ラテラル・ムーブメント）を防ぐとともに、最小限のアクセス範囲を確保」という部分について解説します。これは一般に「マイクロセグメンテーション」という言葉で表現されます。

マイクロセグメンテーションとは「必要最小限のアクセス権だけ付与する」という考え方です。利便性を考えると、AさんもBさんもすべてのシステムに接続できる方が便利で設定もラクなのですが、不要なシステムへも通信できることは、当然ながらセキュリティ上は望ましくありません。

理想は「Aさんは、aシステムとbシステムだけに通信できる。Bさんはbシステムとcシステムにだけ通信できる。」という風に小さくアクセス権を付与することです。この時に、ユーザー単位のアクセス制限だけでなく、通信プロトコルやポート番号、前述のDevice Posture条件なども組み合わせて制限することでよりセキュアになります。

マイクロセグメンテーション

このように必要最小限のアクセスに絞ることで、万が一攻撃者に侵入された場合も、横展開を最小限に抑えることができます。

実はこういったアクセス制御は、ZTNAならではの機能ではありません。 従来型VPNでも同じようなことが出来るのに、多くの企業でちゃんと設定されていなかったものなのです。ZTNA製品ではマイクロセグメンテーションの原則にならって、小さくアクセス権を設定することが推奨されています。

なお、ZTNA製品の中でも特にIAP型の製品では、細かくアクセス権を設定しないと通信できないように作られており、面倒ながら、やらざるを得ない状況を仕様的に作り出しています。

7. ZTNAさえ導入すれば安心？

ここまでZTNAのメリットをお伝えしてきましたが、「ZTNA製品を買ってくれば、即ゼロトラストで安心！」となるでしょうか？ 答えは “No” です。
ZTNAはあくまで仕組みです。せっかくZTNAを導入したのに「全社員、パスワード認証さえ通れば全ての社内サーバーにアクセス可能」という緩い設定にしてしまえば、従来型VPNとセキュリティレベルはあまり向上しません。

　「誰が・どのデバイスで・どの状態なら・何にアクセスしてよいか」というポリシーを適切に設計・設定して初めて意味を成します。

したがって、ZTNA導入の際はどのシステムに対し、どんな状態であれば通信を許可するのかをじっくり考えて設定する必要があります。ここはメーカーやSIerに任せきれない部分ですので、お客様ご自身でしっかりとポリシーを検討すべきポイントです。

8. VPNは本当に時代遅れなのか？

「脱VPN」が叫ばれる中、VPNという技術自体が悪者のように扱われることがありますが、「必ずしもそうではない」というのが私の意見です。

世界中の数々のVPNが標的となっていますが、侵入されたケースを調べてみると、

• 脆弱性があるのにアップデートしていなかった
• IDとパスワードだけでログインできるようになっていた
• ログインした後はアクセス制御をしていなかった

というようなケースばかりです。弊社のお客様でも、上記のような状態で大きなランサムウェア被害にあわれたお客様が何社もいらっしゃいます。

逆に言うと、たとえ従来型VPNを利用していたとしても、きちんと最新のソフトウェアにアップデートし、認証を強化し、アクセス制御を細かく設定していれば大多数の被害は防ぐことができます。

したがって、適切な設計と運用が実施されているVPN環境は、今後もコストとセキュリティのバランスに優れた選択肢の一つだと言えます。ただし、これらの条件が満たされない場合は積極的にZTNAへの移行を検討すべきでしょう。

9. 導入時の注意点とつまづきやすいポイント

最後に、私が今までのZTNA導入プロジェクトで直面してきた、つまづきポイントと注意すべきポイントを4つご紹介します。

9.1. Webアクセスセキュリティの見直しもセットになり意外と大変

ZTNAは「社内」へのアクセスを守りますが、社員はインターネット上のサービスも利用します。そのため、Webアクセス通信を守るSWG*3も同時に導入するケースがほとんどです。

実は最近ではそもそもZTNAとSWGがセットになった製品が大半です。いわゆる「SASE*4」とか「SSE*5」と呼ばれるソリューションがこれに当たります。従来型VPNをZTNAに変えるだけなら、システム更改にかかる労力はそこまで大きくないかもしれませんが、SWGの導入＝インターネットプロキシの更改となるので、労力はグンと大きなものになります。

社内の各ユーザーへの展開にもそれなりに時間がかかることを覚悟しておくことをお勧めします。

9.2. VPNでつながっていた通信が通らなくなる

VPNはネットワーク全体をつなぐのに対し、ZTNAはアプリケーション単位でアクセス制御することが前提になっているものが多くあります。特にIAP型ZTNAはそうです。

先ほどのマイクロセグメンテーションの項でも触れましたが、ネットワーク全体にアクセスできるようにすることはセキュリティ上推奨されていません。しかし従来型VPN製品の場合、あまり細かいアクセス制限をせず、VPNさえ接続してしまえばあとは中で自由に通信できる状態になっているケースが非常に多いです。

こういった環境からZTNAに切り替えたとき、運用開始後に利用者から「あのサーバーにつながらない」といった申告が出てくるケースが非常に多いです。どこの会社にもシステム管理者が把握していないシステムや設定時に見落としているシステムがあるものです。ZTNA製品の場合はこれらのアプリケーション単位でポリシー設定をするため、見落としていたアプリケーションはつながらなくなってしまいます。

そのため、運用後しばらくはユーザーからの申告に基づいて、すぐにポリシー追加できるような準備をしておくのがお勧めです。

9.3. SaaSに登録していた固定IPアドレス問題

SaaSサービスでは、「このIPアドレスからのアクセスじゃないとログインできないよ」という風に送信元IPアドレスを用いたアクセス制限がかけられるサービスがたくさんあります。従来型VPNからZTNAに切り替えた場合、これが出来なくなって大騒ぎになるケースがあります。

IPアドレスが変わるだけなら登録しなおして終わりですが、ZTNA/SWGサービスによっては、送信元IPアドレスを固定する機能自体を提供していないものがあります。

さらに、最近では情シスが把握していない各事業部が独自に契約しているSaaSサービスも多く、そこで送信元IPアドレス制限機能を有効にしている場合も多いです。こういった場合、導入後につながらなくなって初めて発覚し、情シス担当者が大慌てしたことが過去にありました。

こういう事態を回避するためにも、ZTNA導入時は各事業部に対し、独自で契約しているSaaSサービスを事前に確認しておくことをお勧めします。

9.4. Active Directory (AD) との通信問題

特にIAP型のZTNA製品の場合、ADとの通信が重要なポイントになります。

製品によっては使用できるプロトコルに制限があり、ADで必要になるLDAPやKerberosなどの通信プロトコルが通らないケースがあります。こういった場合、「リモートの時だけADにつながらないくらいなら問題ないよ」と割り切るのか、「ADと通信できないなんて話にならないから別製品にする」と切り替えるのかは判断が分かれるところです。

一般的に、多機能な製品ほど高価格になるので機能とコストを天秤にかけて判断を下すポイントです。「必須の通信」なのか「妥協できる通信」なのかをコスト比較しながら検討することが重要です。

Active Directoryとの通信

上記のように、多かれ少なかれZTNA導入時には、従来型VPN環境では起こらなかった問題が出てくるものです。そのため、本格導入の前に本番環境での検証を行い、社内のシステムがちゃんと使えるか試験運用することを "強く" お勧めします。

手間がかかりそうに感じられるかもしれませんが、これはネガティブに捉えるのではなく、今までザルだった環境をセキュアな環境に切り替えるための必要コストだと考えていただけると幸いです。

---

10. おわりに

ZTNAの機能やポイントについて解説しましたが、これからZTNAを導入しようとしているシステム管理者の方に一番伝えたいメッセージは 「運用を考えた設計」 が一番大切だということです。

Device Posture機能を知ると、つい「OS最新、EDR必須、定義ファイルも最新のみ許可！」とガチガチのポリシーを作りたくなったり、ポリシーのバリエーションも増やしたくなります。しかし、最初からこういったガチガチ設計をすると、Windows Updateのタイミングが少しズレただけで翌朝社員が業務できなくなったり、情シスへのクレーム電話が鳴り止まなくなるかもしれません。

さらに、「なぜか分からないけどつながらない」みたいなケースも想定されます。「業務システムにつながらないから故障だと思ったら、OSをアップデートしていないからブロックされているだけだった」みたいなケースも出てくるかも知れません。

こういった運用トラブルを回避するためにも、最初は緩めの条件からスタートし、ログを見ながら徐々に厳格化していくスモールスタートしていくのが現実的な進め方です。セキュリティは「ビジネスを止めるため」ではなく「ビジネスを安全に進めるため」にある という基本を忘れず、自社に最適なゼロトラスト環境を構築してください。

---

執筆者

寺崎 智博（NTT西日本 セキュリティ&トラスト部所属）
2020年に社内でゼロトラストプロジェクトを立ち上げ、西日本各地のお客様のセキュリティ強化支援に従事。NTT西日本社内IT環境のゼロトラスト化にも設計者として参画。
老後の夢はカレー屋。

出典

警察庁｜令和４年上半期におけるサイバー空間をめぐる脅威の情勢等について https://www.npa.go.jp/publications/statistics/cybersecurity/data/R04_kami_cyber_jousei.pdf

NIST｜SP 800-207 Zero Trust Architecture https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

ガートナー｜ゼロトラストとは？今求められるセキュリティ戦略の基本と導入ポイント https://www.gartner.co.jp/ja/topics/zero-trust

商標

• Okta は、Okta, Inc. の商標または登録商標です。
• Microsoft Entra ID は、Microsoft Corporation の商標または登録商標です。

*1:Identity Provider

*2:Endpoint Detection and Response

*3:Secure Web Gateway

*4:Secure Access Service Edge

*5:Security Service Edge