>
>
公開日
最終更新日
ZTNAはゼロトラストネットワークアクセスのことで、社内システムへの接続をアプリケーション単位で制御する技術です。
リモートワーク、SaaS利用、外部委託先との協業が増えた企業では、VPN接続後に広い社内ネットワークへ到達できる構成が残っていることがあります。ZTNAはこの到達範囲を絞る手段になりますが、VPNを一律に廃止する技術ではありません。IdP、多要素認証、端末管理、既存アプリの通信要件を整理し、移行できる業務から段階的に適用する設計が現実的です。
本記事は、50名未満でVPN運用の見直しを始める企業、50〜300名で委託先・SaaS・複数部署のアクセス管理を整えたい企業、300名超で拠点・海外利用者・特権アクセスを統合したい企業の情シス担当者を対象にしています。
ZTNAとは
ZTNAとは、利用者をネットワーク全体へ接続させず、認証結果とポリシーに応じて必要なアプリケーションだけへ接続させるアクセス制御です。
5分で分かる結論：ZTNAはVPNの完全な置き換えではなく、アプリ単位でアクセス範囲を絞る制御レイヤーです。Webアプリ・委託先ポータル・管理画面はZTNAへ移行しやすく、独自プロトコル・低遅延・大容量通信はVPNや専用回線を残します。導入の前提はIdP・MFA・端末管理・ログ取得の整備です。
導入判断フロー
VPN経由のアプリを一覧化し、利用者・通信プロトコル・データ区分・停止許容時間を記録する。
IdPで個人単位のアカウントとMFAが使えるかを確認する。使える場合は手順3へ、使えない場合はIdP整備・MFA適用を先行する。
Webベースのアプリが対象に含まれる場合、影響範囲が小さい1〜2アプリを選んでZTNAのPoCを実施する。
PoC期間中に独自プロトコル・低遅延・大容量の通信を洗い出し、VPN・VDI・専用回線での継続対象として明文化する。
PoCの認証成功率・アクセス拒否理由・問い合わせ件数を記録し、全社展開の可否を判断する。
本記事のポイント
ZTNAは、ユーザー・端末・アプリケーションごとに最小権限アクセスを設計する仕組みです。
ゼロトラストは、社内外の場所ではなく、アクセス要求ごとに信頼を検証する考え方です。
VPNが直ちに危険という意味ではなく、広範なネットワーク権限を持つVPN構成の見直しにZTNAが役立ちます。
ZTNAの効果は、IdP、MFA、EDR、MDM、ログ監視との統合設計によって変わります。
米国国立標準技術研究所（NIST）は、NIST SP 800-207「Zero Trust Architecture」（2020年8月、csrc.nist.gov）で、ゼロトラストを「ネットワークの場所に基づく暗黙の信頼を排し、保護対象のリソースを中心に設計する考え方」と整理しています。つまり、社内LANに接続していること自体を信頼根拠にせず、誰が何へアクセスするのかを継続的に判断する設計です。
ゼロトラストの定義
ゼロトラストは「何も信頼しない」という意味ではありません。本人確認、端末状態、利用時間、接続元、アクセス先、データの機密性などの根拠を用いて、必要な範囲だけを許可する運用モデルです。認証に成功しても、管理外端末や危険度が高い接続元であれば追加認証やアクセス拒否を行う設計が含まれます。
ZTNAは、このゼロトラストの考え方を主にプライベートアプリケーションへの接続に適用します。経費精算、開発環境、管理画面、ファイル共有、社内ポータルなどを対象に、利用者が必要なリソースだけへ接続できる状態を作ります。
境界型セキュリティとの違い
従来の境界型セキュリティでは、社内ネットワークとインターネットの境界にファイアウォール、VPNゲートウェイ、プロキシを置き、社内側を比較的信頼する構成が一般的でした。ネットワーク分離、ACL、MFA、監視を適切に組み合わせれば、境界型の環境でもリスクを下げられます。
一方でZTNAでは、ネットワークへ接続できた後の範囲ではなく、アプリケーション、FQDN、ポート、ユーザー属性を単位として許可を定義します。経理担当者には経費精算システム、開発担当者には開発環境、委託先には特定ポータルだけを許可するため、侵害されたアカウントからの横展開を抑えやすくなります。
規模別の導入判断
50名未満の企業では、すべての社有端末を管理でき、社内アプリも少ないなら、VPNのMFA化、アカウント棚卸し、OS更新の徹底が先行課題になる場合があります。外部委託先やBYODから管理画面へ接続させる場合は、対象アプリを限定してZTNAを試行します。
50〜300名規模では、部署別権限、委託先アカウント、SaaS利用が増えやすいため、IdPのグループとZTNAのアクセスルールを連携させる効果が出やすくなります。300名超で複数拠点、海外拠点、多数の委託先を抱える場合は、VPN装置更新だけでなく、ID・端末・ログ基盤を含む全社アクセス統制として検討します。
ZTNAの仕組みと接続方式
ZTNAは、IdPによる本人確認と端末・利用状況の評価を基に、アプリケーション単位で接続を許可する仕組みです。
アクセス判定の流れ
一般的な構成では、利用者が最初にIdPで認証されます。IdPとは、Microsoft Entra IDやOktaなど、シングルサインオンと多要素認証を担う認証基盤です。その後、ZTNAのポリシーエンジンが、所属グループ、端末の管理状態、OSの更新状況、EDRの稼働状況、接続元、時間帯、アクセス先を基に許可・拒否・追加認証を判断します。
端末健全性の確認、継続的なリスク評価、データ損失防止が、すべてのZTNA製品に必ず含まれるわけではありません。EDR、MDM、UEM、CASB、DLPとの連携によって実現する構成もあります。たとえば「EDRが停止している端末は管理画面を拒否する」というルールは、ZTNAとEDRの状態情報を連携できる場合に実装できます。
アプリケーション非公開化
多くのZTNAサービスでは、社内またはクラウド上にコネクタを配置し、利用者からの認証済み接続だけをアプリケーションへ中継します。この構成では、アプリケーション側にインターネットからの受信ポートを直接開けずに済む場合があり、攻撃者から対象システムを発見されにくくする効果が期待できます。
ただし、アプリケーションの非公開化が可能かどうかは、製品の接続方式、アプリの配置、通信プロトコル、名前解決、冗長化設計に左右されます。接続元・宛先・ポート・TCPまたはUDP・必要帯域の棚卸しで公開IPが不要な構成を確認できれば、実通信の検証へ進みます。要件を満たせない通信が残る場合は、VPNや専用回線などを対象外通信として設計に残します。
エージェント型とエージェントレス型
社有PCを主な対象にするなら、端末状態を取得しやすいエージェント型が適します。協力会社や短期利用者など、ソフトウェアを導入できない端末には、ブラウザ経由で利用するエージェントレス型が候補になります。
比較項目 | エージェント型 | エージェントレス型 |
|---|---|---|
主な対象 | 社有PCを利用する従業員 | BYOD、協力会社、短期利用者 |
端末状態の確認 | OS、EDR、証明書、暗号化状態を確認しやすい | ブラウザ情報中心で確認範囲が限られやすい |
対応アプリ | Web、クライアント・サーバー型、管理ツールを扱いやすい | Webアプリ、限定的なリモートデスクトップ用途に向く |
導入負担 | エージェント配布、更新、障害対応が必要 | 端末配布は不要だが利用機能に制約が出る場合がある |
適した用途 | 開発環境、社内業務、特権アクセス | 委託先ポータル、申請業務、閲覧中心の外部公開 |
エージェントレス型を外部委託先へ提供する場合は、画面コピー、クリップボード、ファイルダウンロード、印刷、セッション記録をどこまで制御できるかが判断材料になります。操作ログを取得できるなら、機密性が中程度のポータルから限定検証に進みます。取得できない場合は、閲覧専用化、VDI経由、ダウンロード禁止などの代替運用を設計します。
サービス起点型と端末起点型（本記事における接続アーキテクチャの整理）
ここでいう「サービス起点型」と「端末起点型」は、正式な製品分類ではなく、本記事で接続アーキテクチャを比較するために設けた整理軸です。端末エージェントを起点に幅広い通信を制御する方式と、アプリケーション側のコネクタを起点に特定サービスへの到達を仲介する方式として捉えます。各製品の機能名や実装は異なるため、製品比較では公式のアーキテクチャ図、対応プロトコル、コネクタ配置を照合します。前者は端末状態を細かく扱いやすく、後者はアプリケーションを外部へ直接公開しない構成を取りやすい傾向があります。
どちらが適するかは、社有端末率、対象アプリの種類、外部委託先の割合、OT環境の有無で変わります。Windowsクライアントから独自通信を使う基幹アプリが多いなら端末エージェント型を検証し、ブラウザ利用が中心で委託先が多いならエージェントレス接続での操作制御を優先評価します。
▲ ZTNAにおける認証からアプリケーションアクセス許可までの処理プロセス
SASE・SSE・CASBとの役割分担
ZTNAはプライベートアプリケーションへの接続を担い、SSEとSASEはZTNAを含むより広いクラウドセキュリティ基盤です。
用語を混同すると、VPN代替だけを求めて大規模なネットワーク刷新を始めたり、SaaSのデータ統制をZTNAだけで実現しようとしたりする設計ミスにつながります。対象データと通信経路を分けて考えると、必要な機能範囲を決めやすくなります。
用語 | 主な対象 | 主な役割 | 着手しやすい課題 |
|---|---|---|---|
ZTNA | 社内アプリ、プライベートクラウド | アプリ単位の最小権限アクセス | VPN経由の社内システム接続 |
SSE | Web、SaaS、社内アプリ | ZTNA、SWG、CASB、DLPの統合 | 利用者ごとのセキュリティポリシー統合 |
SASE | 拠点、利用者、クラウド | ネットワークとセキュリティの統合 | SD-WANや拠点回線も含む再設計 |
CASB | SaaS | 利用可視化、設定監査、データ制御 | 未承認SaaS、共有設定、情報持ち出し |
ZTNAとSSEの関係
SSEは、Security Service Edgeの略で、クラウド上でセキュリティ機能を提供する枠組みです。一般に、ZTNA、セキュアWebゲートウェイ、CASB、DLPを統合して提供します。社内アプリだけでなく、Web閲覧、SaaS、生成AIへのアクセスまで横断的に制御したい企業では、ZTNA単体とSSE統合基盤の運用負荷を比較します。
すでにEDR、プロキシ、CASBを個別導入している場合は、すべてを同時に入れ替える必要はありません。ログ形式、IdP連携、契約更新時期、管理者の運用工数を一覧化し、既存製品と連携できるZTNAから導入するか、SSEへ統合するかを判断します。
CASBとの役割の違い
CASBは、SaaS利用の可視化、共有設定の監査、外部公開の検知、データ操作の統制を主な対象にします。ZTNAが「誰が社内アプリへ接続できるか」を制御するのに対し、CASBは「SaaS上のデータを誰と共有できるか」「未承認サービスを利用していないか」を扱います。
たとえば、勤怠システムが社内ネットワーク上にあり外部接続を制限したいならZTNAが中心です。Microsoft 365やGoogle Workspaceの共有設定、外部共有、生成AI連携を統制したいならCASBやDLPが中心になります。両方の課題がある企業では、利用者IDを共通化してポリシーとログを連携させます。
ZTNAとVPNの違いと使い分け
ZTNAとVPNの違いはアクセス制御の単位にあり、VPNを残すべき通信とZTNAへ移すべき業務を分けることが導入の要点です。ただし、VPNでも細かなACLやセグメント制御を組み合わせることはでき、ZTNAにもプロトコル対応範囲が広い製品があります。下表は一般的な傾向を示したもので、製品・構成によって実際の境界は異なります。
VPNは、インターネット上に暗号化トンネルを作り、利用者または拠点を企業ネットワークへ安全に接続する技術です。VPN自体が安全でないわけではありません。ネットワーク分離、ACL、端末証明書、MFA、脆弱性対策、ログ監視を組み合わせれば、リスクを抑えた運用ができます。
ただし、従来型のVPN運用では、接続後に広いIPアドレス帯や複数セグメントへ到達できる権限を付与している例があります。この構成では、認証情報の窃取や端末感染が発生した際、攻撃者が内部の別サーバーへ移動する余地が生まれます。ZTNAは到達先をアプリケーション単位に絞り、この範囲を縮小します。
比較項目 | ZTNA | VPN |
|---|---|---|
主な制御単位 | ユーザー、端末、アプリ、FQDN、ポート | ネットワーク、IPアドレス帯、セグメント |
接続後の公開範囲 | 許可済みアプリを中心に公開 | 設定により複数ネットワークへ到達可能 |
認証連携 | IdP、SSO、条件付きアクセスと統合しやすい | VPN製品の機能や追加構成に依存 |
レガシー通信 | 製品・プロトコルにより制約がある | 幅広いIP通信を扱いやすい |
主な運用課題 | ポリシー設計、IdP整備、アプリ棚卸し | 装置の脆弱性管理、帯域、過剰権限 |
移行に向く業務
Webベースの社内ポータル、経費精算、ワークフロー、管理画面、クラウド上の開発環境は、ZTNAへ移行しやすい候補です。利用者とアクセス先を対応付けやすく、ポートやFQDNで接続先を明確化しやすいためです。外部委託先が利用するポータルも、エージェントレス型を使える場合があります。
一方、大容量の設計データ、低遅延が必須の映像処理、独自UDP通信、ブロードキャスト、古いクライアント・サーバー型アプリ、工場設備の保守通信は、VPN、専用回線、VDIを併用する判断が残ります。ZTNAがVPNより常に高速または低コストになるわけではなく、アクセスポイントの位置、アプリ配置、コネクタ冗長化、回線品質、暗号化処理で性能は変わります。
利用シナリオ別の判断
利用シナリオ | 優先候補 | 並存を検討する接続 | 判断材料 |
|---|---|---|---|
社員のWebアプリ利用 | エージェント型ZTNA | 独自通信アプリはVPN維持 | IdPグループ、MFA、端末管理 |
協力会社の業務利用 | エージェントレス型ZTNA | 大容量転送はSFTPやVPN | 操作制限、監査ログ、契約期限 |
管理者の特権アクセス | ZTNA＋条件付きアクセス | 緊急時専用の保守回線 | 特権ID分離、時間制限、承認記録 |
工場・OT環境 | 資産可視化と許可リスト制御 | 専用回線、既存VPN | 停止許容時間、通信プロトコル |
コスト比較では、ZTNAライセンスだけでなく、VPN装置更新、帯域増強、脆弱性対応、アカウント発行、障害対応の工数を合算します。たとえばVPN接続申請が月30件、1件20分なら、発行作業だけで月10時間です。IdPのグループと連携して権限を自動付与できればこの作業は減らせますが、初期のグループ設計、例外申請、監査ログ設計の工数も見積もります。
▲ VPNとZTNAにおけるアクセス許可範囲と横展開リスクの比較
導入メリット
ZTNAの導入効果は、到達範囲の縮小、委託先管理、認証運用の統合を対象アプリごとに設計した場合に得られます。
横展開リスクの抑制
アプリケーション単位でアクセスを分けると、認証済み利用者であっても別部署のサーバーや管理画面へ自動的に到達できない構成を作れます。ランサムウェア対策はZTNAだけで完結しませんが、MFA、EDR、バックアップ、脆弱性管理、ネットワーク分離と組み合わせることで、侵入後の被害範囲を縮小する対策になります。
IPAは「情報セキュリティ10大脅威 2025」（ipa.go.jp）で、組織向け脅威の1位としてランサムウェアによる被害を挙げています。警察庁も、ランサムウェア被害に関する報告（npa.go.jp）でVPN機器などの境界機器を侵入経路の一つとして扱っています。VPN機器を利用する場合は、ZTNA移行の有無にかかわらず、脆弱性情報の収集、修正プログラム適用、不要な公開停止、MFA、ログ監視を継続します。
委託先アクセスの管理
外部委託先にVPNアカウントとネットワーク権限を個別発行すると、契約終了後の削除漏れや、作業範囲を超えた接続が起きやすくなります。ZTNAとIdPを連携すると、所属グループ、契約期間、端末条件、許可アプリを基にアクセス権を管理できます。
委託先アカウントを管理する場合は、「誰が、どの端末で、どのアプリに、いつまで、どの操作を行うか」を申請項目にします。契約終了日をIdPの無効化日と連携できるなら自動停止へ進みます。連携できない場合は、月次棚卸しの担当者と証跡を固定し、削除未実施を監査対象にします。
ZTNA導入時のデメリットと失敗パターン
ZTNA導入で失敗しないためには、VPNの一括置換ではなく、アプリ・ID・端末・運用の4領域を事前に整理します。
レガシーアプリの通信停止
やってはいけないことは、通信要件を把握しないまま全アプリを一斉にZTNAへ切り替えることです。Webアプリは移行しやすい一方、独自UDP通信、固定IPを前提とする業務ソフト、ファイル共有、プリンター探索、古いリモート保守ツールは、製品や構成によって接続できない場合があります。
導入前に、アプリ名、利用部門、利用者数、通信方向、宛先、ポート、プロトコル、認証方式、ピーク帯域、停止許容時間を一覧化します。ZTNAで要件を満たすことが確認できれば先行移行し、満たせなければVPN、VDI、専用回線を維持します。全アプリの移行完了を導入条件にしないことが、業務停止を避ける実務上の判断です。
IdPとMFAの未整備
ZTNAは、利用者を正確に識別できなければ最小権限を判断できません。共有アカウント、部署共通ID、退職者アカウントの残存、MFA未適用がある状態では、ZTNAを導入しても権限管理の精度は上がりません。
人事情報をIdPのグループへ連携できるなら、雇用区分・所属・役割を反映し、入社・異動・退職に合わせて権限を更新します。連携できない場合は、特権アカウントと外部委託先を対象に、個人ID化とMFA適用を先に実施します。この2つが整わない場合は、全社展開ではなく利用者を限定した検証に留めます。
過剰権限の再現
ZTNAを導入しても、「全社員に業務アプリ群を許可する」「広いIPアドレス範囲を許可する」設定では、従来VPNの過剰権限を再現します。製品導入だけでゼロトラストになるわけではありません。
アクセスルールは、利用者、端末、対象アプリ、操作内容、時間帯、期限を組み合わせて定義します。管理者アクセスには通常業務用とは別のアカウントを使い、承認済み端末、MFA、接続時間帯、必要に応じた承認フローを適用します。拒否時の問い合わせ窓口と緊急解除の承認者を決めておくと、運用開始後に恒久的な例外ルールが増える事態を防げます。
性能と運用負荷
ZTNAでは、コネクタ障害、DNS設定、証明書更新、IdP障害、端末エージェント更新がアクセス障害の原因になります。VPN装置を撤去すれば運用が不要になるわけではなく、管理対象がクラウドサービス、ID、端末、ポリシーへ移ると考えるべきです。
高可用性が必要な業務では、コネクタの冗長化、障害時の接続経路、IdP停止時の業務継続、ログ保管先を設計します。監査ログを取得し、利用者・時刻・端末・対象アプリ・許可または拒否理由を追跡できるなら、対象業務を増やします。追跡できない場合は、監査要件の低い用途に限定します。
導入判断チェックリスト
以下を満たす範囲から始めると、移行可否を判断しやすくなります。
対象アプリの利用者、通信方式、データ区分、停止許容時間を一覧化している。
IdPで個人単位のアカウントとグループを管理している。
MFAを対象利用者へ適用できる。
社有端末のOS更新状況、ディスク暗号化、EDR稼働状況を取得できる。
アクセスログを保存し、障害時に利用者・時刻・対象アプリを追跡できる。
ZTNA対象外アプリをVPN、VDI、専用回線のどれで継続するか決めている。
アクセス拒否時の窓口、緊急時の承認者、例外ルールの有効期限を決めている。
認証、MFA、ログ取得、対象アプリの通信要件が確認できれば、影響が小さいWebアプリで検証を開始します。通信棚卸しが未完了なら、利用者数が少なく、業務停止時の代替手段があるアプリに対象を絞ります。
▲ アプリケーションの通信特性に応じたZTNA移行判断フロー
2025年以降のZTNA動向
2025年以降のZTNAは、リモートアクセスの置き換えにとどまらず、SSE統合、社内拠点、OT・IoT、生成AI利用の統制へ対象を広げています。提供時期や対象機能は製品、地域、契約プランによって異なるため、比較時は各ベンダーの機能一覧、リリースノート、契約条件を照合します。必要な機能が標準提供されていれば検証対象に含め、追加契約や未提供の場合は既存のセキュリティ製品との役割分担を残します。
Universal ZTNAの広がり
従来のZTNAは、主に社外から社内アプリケーションへ接続する用途で利用されてきました。近年は、社内オフィス、キャンパス、有線・無線ネットワーク、OT・IoT機器を含め、接続場所にかかわらず一貫したアクセス判断を行うUniversal ZTNAという考え方が広がっています。
社内からのアクセスも無条件に信頼しない設計では、利用者・端末・アプリ・ネットワークの状況に応じて許可を変えます。ただし、工場設備や医療機器など停止影響が大きいOT環境へ、IT端末と同じポリシーを一括適用しません。資産可視化、通信の許可リスト化、IT/OT分離、保守ベンダー接続の記録を先行し、停止許容時間を基に適用範囲を決めます。
生成AIガバナンス
生成AIの業務利用では、未承認AIサービスへの機密情報入力、ソースコードの貼り付け、個人情報を含むプロンプト送信が課題になります。ZTNA単体は生成AIへのデータ送信を検査する機能ではありませんが、SSEのSWG、CASB、DLPと連携すると、アクセス先の制御や特定データパターンの送信検知・遮断を設計できます。
生成AIを利用する企業では、許可サービス、利用可能なアカウント、入力禁止情報、ログ保管期間、例外申請を先に文書化します。DLPが機密情報を十分な精度で検出できるなら遮断へ進みます。誤検知が業務を止める場合は、最初は監査モードで検知内容を分析し、禁止語やデータ分類を調整してからブロックを適用します。
NIST実装ガイド
NISTは2025年6月、ゼロトラストの実装例をまとめたSP 1800-35「Implementing a Zero Trust Architecture」（nccoe.nist.gov、2025年6月）を公開しました。このガイドは、概念を示すSP 800-207を補完し、複数の商用技術を組み合わせた19の実装例を扱っています。
SP 1800-35は、特定製品を導入すればゼロトラストが完成するという文書ではありません。自社のID管理、端末管理、ネットワーク、ログ基盤、データ保護の現状に対応付けるための参照資料です。IdPとEDRを導入済みならアクセスルール設計から始めやすく、未導入なら認証基盤と端末可視化を先行させる判断になります。
市場拡大と導入判断
IDC Japanは2025年8月21日、「ゼロトラストセキュリティの普及で成長する 国内SD-WAN市場の予測を発表」で、国内SD-WAN市場が2024年の173億円から、年間平均成長率9.9％で推移し、2029年に277億円へ達すると予測しています。市場予測は導入の必要性を直接示すものではありませんが、ZTNAを単体のVPN代替ではなく、SSEやSASEの一部として検討する企業が増えている背景を読む材料になります。
市場予測よりも優先すべきなのは、自社のアクセス権が業務単位で説明できるかどうかです。誰がどのアプリを使うかを棚卸しできているならZTNAの要件定義へ進みます。説明できない場合は、まずVPN接続後の到達範囲、共有アカウント、委託先IDを可視化します。
参考情報
NIST SP 800-207「Zero Trust Architecture」（公開日：2020年8月、参照日：2026年8月20日）
NIST SP 1800-35「Implementing a Zero Trust Architecture」（公開日：2025年6月、参照日：2026年8月20日）
IPA「情報セキュリティ10大脅威 2025」（公開年：2025年、参照日：2026年8月20日）
Zscaler公式の武田薬品工業顧客事例（参照日：2026年8月20日）
Akamai公式のLIXIL顧客導入事例（参照日：2026年8月20日）
導入計画と製品比較の観点
ZTNA比較では、機能名やライセンス価格だけでなく、対象アプリ、端末、認証、ログ、移行方法を同じ軸で評価します。
比較項目の整理
ZTNA製品は、対応プロトコル、エージェントレス接続の範囲、端末健全性評価、IdP連携、EDR連携、DLP連携、コネクタ配置、ログ出力、国内サポートで違いがあります。料金は利用者数、端末数、機能セット、契約期間、サポート条件で変動し、公式サイトで個別見積もりとなる製品が多いため、非公開料金を推測して比較しません。
評価軸 | 確認内容 | 判断への影響 |
|---|---|---|
対象アプリ | Web、RDP、SSH、TCP、UDP、独自通信への対応 | 対応外通信はVPNやVDIを残す |
端末管理 | EDR、MDM、証明書、OS状態との連携 | 社有端末中心なら端末条件を強化する |
外部委託先 | エージェントレス接続、操作制御、期限管理 | 端末配布不可ならブラウザ接続を検証する |
認証 | IdP、MFA、SCIM、グループ連携 | 人事異動・退職時の権限更新を自動化する |
可用性 | コネクタ冗長化、障害時の接続、ログ保管 | 基幹業務なら冗長構成と復旧手順を設計する |
費用 | ライセンス、初期設定、運用、VPN更新費 | 3〜5年の総保有コストで比べる |
段階導入のフェーズ
導入は、全社展開よりも対象を限定した検証から始めます。第1フェーズでは、IdP、MFA、対象アプリ、利用者、ログ保管先を決めます。第2フェーズでは、管理画面や社内ポータルなど影響を限定しやすいWebアプリで接続成功率、認証失敗、問い合わせ件数、ログ取得を確認します。
第3フェーズでは、外部委託先、特権アクセス、開発環境へ範囲を広げます。最後に、VPNを維持する通信を明文化し、VPNとZTNAの二重管理期間における責任分担を決めます。移行判断を毎月行うなら、対象アプリ数、利用者数、アクセス拒否件数、例外ルール数、障害件数を同じ指標で記録すると、拡大・停止の判断を説明しやすくなります。
PoCで測定する指標
PoCでは「接続できたか」だけを評価しません。利用者別の認証成功率、平均接続時間、アクセス拒否理由、ヘルプデスク問い合わせ、アプリ応答時間、ログ欠損、管理者の設定工数を測定します。たとえば対象者50名で1か月検証する場合、問い合わせ件数を利用者別・アプリ別に分けると、教育不足と通信非対応を区別できます。
接続成功率が高くても、例外ルールが増え続ける場合は、権限設計またはアプリの通信要件が不十分です。例外の期限、申請者、承認者、対象アプリを記録し、恒久ルールへ変更する条件を定めます。例外を無期限で残す運用は、最小権限設計を崩す原因になります。
よくある質問
ZTNAの導入範囲、認証基盤、企業規模に関する質問のFAQです。
Q：既存のVPNをすべてZTNAに置き換えるべきですか？
必ずしも全置換は必要ありません。Webアプリ、管理画面、委託先ポータルはZTNAへ移行しやすい一方、独自プロトコル、大容量通信、低遅延が必要な業務はVPNや専用回線を併用します。対象アプリの通信要件がZTNA製品の対応範囲に収まればZTNAへ移し、収まらなければ既存接続を維持して検証します。
Q：IdPがなくてもZTNAは導入できますか？
製品によってはローカル認証などで利用できる場合がありますが、個人単位の認証、MFA、グループ別権限管理を継続するにはIdP連携が有効です。IdPが未整備なら、特権アカウントと外部委託先の個人ID化、MFA適用、退職者IDの棚卸しから始めます。
Q：小規模企業でもZTNAは必要ですか？
小規模企業でも、外部から管理画面やファイルサーバーへ接続する、委託先に業務システムを使わせる、BYODを認める場合は検討対象です。利用者と対象アプリが少ないなら、まずMFA、端末更新、VPN権限の見直しを行い、必要なアプリだけZTNAで保護します。
Q：ZTNAを導入すればランサムウェアを防げますか？
ZTNAだけでランサムウェアを防ぐことはできません。アプリ単位のアクセス制御により侵害後の横展開を抑える効果は期待できますが、MFA、EDR、脆弱性管理、オフラインまたは不変性を持つバックアップ、監視を組み合わせます。
Q：エージェントレス型は安全ですか？
エージェントレス型でも、認証、アクセス先制限、操作制御、ログ取得を適切に設計すれば外部委託先の限定利用に活用できます。ただし端末健全性の確認範囲はエージェント型より制限されやすいため、機密データを扱う場合はダウンロード禁止、閲覧専用化、VDI利用を組み合わせます。
まとめ
ZTNAはゼロトラストネットワークアクセスのことであり、ゼロトラストの考え方に基づいて、利用者を社内ネットワークへ広く接続させず、必要なアプリケーションだけへ接続させる技術です。VPNとZTNAは対立するものではなく、Webアプリや委託先アクセスはZTNA、独自通信や低遅延が必要な業務はVPN・専用回線といった使い分けが実務的です。
情シス部門が明日から始める最初の一歩は、VPN経由で使われているアプリを一覧にし、「利用者」「通信プロトコル」「データ区分」「停止許容時間」を記録することです。IdP、MFA、端末管理、ログ取得がそろうWebアプリを1つ選べば、全社の一括移行を避けながらZTNAの効果と運用負荷を検証できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
