ZTNA（ゼロトラストネットワークアクセス）とは？VPNとの違い・仕組み・中小企業への導入ガイド

リモートワークが当たり前になってから、こんな状況に直面した情シス担当者は多いはずです。

「VPN接続さえすれば、社内の基幹システムにもファイルサーバーにも自由にアクセスできてしまう」「VPNゲートウェイの脆弱性を突かれた認証情報漏洩の事例を見て、他人事と思えなくなった」「テレワーク利用者の増加でVPN帯域が逼迫し、通信が重くて業務に差し支えている」

これらはVPNの構造的な問題です。「ネットワーク内に入れたら信頼する」という境界型セキュリティの限界が、リモートワーク普及によって一気に表面化しています。

この記事では、VPNの代替・補完として注目されているZTNA（ゼロトラストネットワークアクセス）の仕組み・VPNとの違い・中小企業でも段階的に取り組める導入ステップを、現場で使えるレベルで解説します。

ZTNAとは？「ネットワークへの接続」から「アプリへの接続」へ

ZTNA（Zero Trust Network Access、ゼロトラストネットワークアクセス）は、「誰がどのアプリケーションに、どの端末から、どんな条件でアクセスするか」を毎回検証し、許可された組み合わせのみ通す仕組みです。

ゼロトラストの「Never Trust, Always Verify（決して信頼せず、常に検証する）」という原則を、ネットワークアクセスの仕組みとして実装したものと考えるとわかりやすいでしょう。

従来のVPNが「ネットワーク（トンネル）に入れたら内側を自由に使わせる」モデルだとすると、ZTNAは「特定のアプリケーションへのアクセスだけを、条件を満たした場合のみ許可する」モデルです。この違いが、セキュリティの質を大きく変えます。

・アクセス制御の粒度: VPNはネットワーク単位、ZTNAはアプリケーション単位
・信頼の前提: VPNは「ネットワーク内なら信頼」、ZTNAは「常に検証してから許可」
・攻撃者が侵入した場合: VPNは横移動しやすい、ZTNAは許可されたアプリにしかアクセスできない
・ユーザー体験: VPNはトンネル確立が必要、ZTNAはアプリケーション単位で透過的に接続できる

ZTNAはGartnerが提唱した概念で、SASEアーキテクチャの重要コンポーネントの一つでもあります。国内外でもCrowdStrike・Zscaler・Cisco・Okta等のベンダーがZTNAソリューションを提供しており、クラウドネイティブな企業を中心に導入が加速しています。

従来型VPNが抱える3つの構造的問題

ZTNAを理解するには、まずVPNの問題点を整理するのが近道です。

1. ネットワークへのフルアクセスが攻撃者にも開放される

VPNは「認証に成功した利用者をネットワーク内に入れる」仕組みです。一度ネットワーク内に入ると、許可設定が甘い環境では他のサーバーや端末への横移動（ラテラルムーブメント）が可能になります。

攻撃者がVPNの認証情報を窃取すれば、正規ユーザーと同じ権限でネットワーク内を自由に動き回れてしまいます。2024年以降、VPNゲートウェイを標的にしたランサムウェア攻撃が急増している背景には、この構造的な弱点があります。

2. VPNゲートウェイ自体が攻撃対象になる

VPNゲートウェイはインターネットに直接公開されている機器です。CVSSスコア9.8を超える重大脆弱性がVPN製品に相次いで発見されており、パッチ適用の遅れが侵害につながる事例が後を絶ちません。

FortinetやIvanti（旧Pulse Secure）、Cisco ASAなど主要VPN製品に対して、認証バイパスやリモートコード実行の脆弱性が毎年報告されています。攻撃者がゲートウェイ自体を乗っ取れば、接続している全端末が危険にさらされます。

3. 帯域とコストのスケール問題

テレワーク利用者が増えるほどVPN帯域が逼迫し、通信遅延や切断が発生します。帯域を増強するためにVPNゲートウェイを増設・更新するコストも無視できません。またクラウドサービスへのアクセスをVPN経由にすると、一度オフィスを経由してから外に出す経路になって逆に通信が遅くなるケースもあります。

VPNスプリットトンネリングはこの問題を緩和する設定ですが、制御が不十分だとセキュリティリスクを生みます。根本的な解決策がZTNAへの移行です。

ZTNAの仕組み：4つのコンポーネントを理解する

ZTNAは大きく4つの要素で構成されます。

1. IDプロバイダー（IdP）：「誰か」を確認する

ユーザーIDの管理とシングルサインオン（SSO）認証を担います。Microsoft Entra ID（旧Azure AD）、Okta、Google Workspaceなどが代表的です。多要素認証（MFA）と組み合わせることで、認証情報の窃取だけでは突破できない仕組みを作れます。

SSOの仕組みとセキュリティリスクについては別記事で詳しく解説しています。

2. ZTNAコントローラー：アクセスポリシーを判定する

「このユーザーが、この端末から、このアプリに、このコンテキストでアクセスしようとしている」という情報を受け取り、事前に設定したポリシーに照らして許可・拒否を判定するコンポーネントです。端末の健全性（マルウェア感染の有無・パッチ適用状況）も判定材料に含めるのがZTNAの特徴で、「ユーザーIDは正しくても、端末が感染していればブロックする」という制御が可能になります。

3. ZTNAゲートウェイ・コネクタ：アプリへの接続を仲介する

コントローラーから許可が下りた場合のみ、ユーザーと対象アプリケーションを接続します。オンプレミス型（自社データセンターにゲートウェイを置く）とクラウド型（クラウドサービス経由で接続する）があります。

クラウド型では、アプリケーション側にコネクタを設置して外向きの接続を確立することで、アプリのIPアドレスをインターネットに公開しない構成が可能です。攻撃者からアプリの存在自体を隠せるため、攻撃対象面（アタックサーフェス）が大幅に縮小されます。

4. エンドポイントエージェント：端末状態を報告する

ユーザーのPCやスマートフォンにインストールするクライアントソフトウェアです。端末のOSバージョン・パッチ適用状況・EDRの動作状況などを収集し、ZTNAコントローラーに報告します。「条件を満たした端末からのみ接続を許可する」というコンテキストアウェアなポリシー制御の要となります。

エージェントレス型ZTNAも存在しますが、端末状態の検証精度が落ちるため、管理対象外のデバイスが多い環境では注意が必要です。

ZTNAの具体的な導入手順

1. 現在のVPN利用状況を棚卸しする

まず「誰が・どのシステムに・どの頻度でアクセスしているか」を把握します。VPNのアクセスログを分析し、実際に使われているシステムと使われていないシステムを仕分けます。

この棚卸しがZTNA移行の土台になります。「全員がすべてのシステムにVPN経由でアクセスできる状態」から「必要な人が必要なシステムにだけアクセスできる状態」への移行を設計するためには、現状把握が不可欠です。

# VPNアクセスログからユニークアクセス先を抽出する例（FortiGateの場合）
# grep でVPNセッションのログを抽出し、接続先IPとユーザー名を集計
grep "action=tunnel-up" /var/log/fortigate/vpn.log |   awk '{print $3, $5}' | sort | uniq -c | sort -rn | head -50

# 接続先リソースと接続ユーザー数の把握が目的
# この結果をもとにZTNAポリシーを設計する

2. IDプロバイダー（IdP）を整備する

ZTNAはID管理が基盤になります。既にMicrosoft 365やGoogle WorkspaceをIdPとして使っている場合は、そのままZTNAの認証基盤として活用できます。

重要なのはMFAを全ユーザーに適用することです。MFAなしでZTNAを導入しても、認証情報の窃取には無力です。MFAの全社展開はZTNAの最初の必須ステップだと考えてください。

IAM（アイデンティティ・アクセス管理）の整備と合わせて進めることで、アクセス制御の一貫性が保てます。

3. パイロット対象のアプリケーションを選ぶ

最初から全システムをZTNA対象にする必要はありません。リスクが高く、外部からのアクセスが多いシステムから始めるのが現実的です。

例えば「社内の業務システムへのリモートアクセス」「クラウドに移行済みのアプリへのアクセス」などからパイロットを開始し、問題がなければ対象を広げていきます。

4. アクセスポリシーを定義する

「誰が（ユーザー・グループ）」「どの端末から（端末の健全性条件）」「どのアプリに」「どの時間帯に」アクセスを許可するかをポリシーとして定義します。

最小権限の原則に基づき、「このユーザーにはこのアプリのみ」という形でポリシーを絞り込みます。「全員にすべてのアプリへのアクセスを許可」では、VPNと本質的に変わりません。

5. 段階的にVPNを縮小する

ZTNAへの移行は一夜にして完了するものではありません。VPNとZTNAを並行運用しながら、アプリケーションを一つずつZTNA経由に切り替えていくアプローチが安全です。特定のアプリへのアクセスをZTNA経由に切り替え、問題がないことを確認してから次のアプリに進みます。

中小企業でも今日からできること

ZTNAへの完全移行は大企業でも数年かかる取り組みです。中小企業や情シス1人体制の組織では、まず以下のステップから始めることをお勧めします。

・MFAの全社展開: ZTNAの前提となるID認証強化の第一歩です。Microsoft 365やGoogle Workspaceのユーザーであれば追加コストなしで設定できます
・VPNアクセスログの確認: 誰がどのシステムにVPN経由でアクセスしているかを可視化するだけでも、不要なアクセス権の発見につながります
・Cloudflare Accessの無料枠の活用: Cloudflare Accessは50ユーザーまで無料で使えます。社内の特定Webアプリへのアクセスを試験的にZTNA化するのに最適です
・条件付きアクセスの設定: Microsoft Entra IDやGoogle Workspaceには「条件付きアクセス」機能があります。「管理対象外の端末からはアクセスを拒否する」などのポリシーをIdP側で設定でき、ZTNAへの移行準備になります
・アプリケーション棚卸しの実施: 社内で使われているアプリ・システムとそのアクセス権者を一覧化します。この作業はZTNA導入後のポリシー設計に直結します

クラウドと組み合わせたネットワークセキュリティの全体設計については、姉妹サイトCloudMasters.TOKYOでも詳しく解説しています。

SASE（Secure Access Service Edge）はZTNAをネットワークセキュリティと統合したアーキテクチャです。中長期的なロードマップとして参照することをお勧めします。

よくある誤解と注意点

【誤解1】ZTNAを導入すればVPNは完全に不要になる

ZTNAはアプリケーション単位のアクセス制御が得意ですが、ネットワークレベルの接続が必要な用途（特定のポートを使うレガシーシステムや、プリンターなど非HTTP機器への接続等）ではVPNの方が適している場合があります。ZTNAとVPNを使い分ける「ハイブリッド運用」が現実的な企業も多くあります。

【誤解2】ZTNAは大企業向けの高価な技術だ

Cloudflare AccessやTailscaleなど、中小企業でも導入しやすい価格帯のZTNAソリューションが増えています。また、既存のIdP（Microsoft Entra ID等）に付属する条件付きアクセス機能をZTNAの第一歩として活用することで、追加投資なしで始められます。

【誤解3】ZTNAを導入すれば端末管理は不要になる

ZTNAは端末の健全性を確認してアクセスを制御しますが、その前提として端末管理（MDMによるパッチ適用・設定管理）が必要です。ZTNAは端末管理の代替ではなく、端末管理を前提として機能するものです。端末管理が整っていない状態でZTNAを導入しても、十分なセキュリティ効果を得られません。

【注意】移行期間中のVPN設定の厳格化

ZTNAへの移行期間中、VPNは引き続き使われます。この期間にVPNのアクセス制御を緩めると、移行が完了するまでの間にリスクが高まります。VPNのアクセス制御を現状より厳格に維持しながらZTNAに移行するのが安全な進め方です。VPNの不要なポート開放やアカウントの見直しも合わせて実施してください。

本記事のまとめ

ZTNA（ゼロトラストネットワークアクセス）は、従来のVPNが抱える「ネットワーク全体を信頼する」という構造的な問題を解決する仕組みです。

中小企業での第一歩は「MFAの全社展開」と「VPNアクセスログの可視化」です。そこから条件付きアクセスの設定、パイロットアプリのZTNA化と段階的に進めることで、大きな予算がなくてもゼロトラストの考え方をネットワークアクセスに取り入れられます。

VPNをすぐに廃止する必要はありませんが、「VPNに入れば何でもできる」という状態を放置することは、今の脅威環境では受け入れがたいリスクです。できるところから着実に進めることが重要です。