ZTNAはVPNの代替か？
違いとリモートアクセス設計のポイントを解説

リモートワークの普及とともに、VPNは社外から社内システムへアクセスするための手段として広く利用されてきました。

一方で近年、VPNの脆弱性や運用上の課題が指摘され、「VPNはもはや安全ではない」といった議論も増えており、実際に、VPNの廃止や見直しを進める組織も出てきています。
こうした背景から、VPNに代わる新たなリモートアクセス手段として「ZTNA（Zero Trust Network Access）」が注目されています。
ZTNAは“VPNの代替製品”として語られることが多いものの、この理解は必ずしも正確ではありません。

本記事では、ZTNAが単純なVPNの代替ではない理由を、リモートアクセスの前提となってきたVPNの構造を整理しながら解説します。あわせて、「ZTNAを導入すれば課題は解決するのか」という問いをもとに、現実的にアクセス制御をどう設計するべきか整理します。

VPNはなぜ“限界”が指摘されているのか

VPNは、社外から社内ネットワークへ安全に接続するための仕組みとして、長年利用されてきました。しかしその仕組みは、「一度接続すれば内部ネットワークの一員として扱う」という前提に基づいています。この前提は、リモートアクセスの利用範囲が限定的だった時代には有効に機能していました。

一方で現在では、働き方やシステム構成の変化により、この構造自体がリスクとなるケースが増えています。

VPNの内部ネットワーク前提が生む横展開リスク

VPNでは、認証に成功したユーザーや端末は内部ネットワークに接続されます。その結果、アクセス制御はネットワーク単位で行われることが多く、必要以上に広い範囲へのアクセスが可能になる場合があります。

この状態で端末が侵害された場合、攻撃者はVPN接続を経由して内部ネットワークへ侵入し、他のシステムへとアクセスを広げることが可能になります。いわゆるラテラルムーブメント（横展開）が発生しやすい構造です。

VPN利用主体の拡張とサプライチェーンリスク

さらに近年では、VPNを利用する主体が自社の従業員にとどまらず、委託先やグループ会社など外部にも広がっています。これにより、社内ネットワークへ接続する経路は、自社の管理範囲を超えて拡張されています。例えば、委託先の端末がマルウェアに感染した状態でVPN接続された場合、そのまま内部システムへアクセスできてしまう可能性があります。

このように、侵害の起点が自社外に存在するリスク、いわゆるサプライチェーンリスクが顕在化しています。

VPNの前提が現実の利用環境に追いついていない理由

リモートワークの常態化やクラウドサービスの利用拡大により、「社内」と「社外」の境界は曖昧になっています。また、アクセス主体も多様化し、「誰が接続しているのか」「どの端末からなのか」を一律に信頼することは難しくなっています。

このような状況において、「接続した時点で内部として扱う」というVPNの前提は、現実の利用環境と乖離しつつあります。

こうした前提を見直し、アクセスごとに信頼を判断するという考え方がゼロトラストです。ZTNAは、その考え方をリモートアクセスに適用するアプローチの一つと位置づけられます。

ZTNAはVPNの代替なのか

VPNの課題が指摘される中で、「ZTNAはVPNの代替」として語られることが増えています。しかし、この理解は必ずしも正確ではありません。

ZTNAは、VPNのように“安全な接続手段”を提供するものではなく、アクセスの前提そのものを見直すアプローチです。

VPNは「接続する」こと自体が前提になっている

VPNでは、ユーザーや端末が認証されると、社内ネットワークへの接続が確立されます。つまり、「接続できること」が前提となり、その後のアクセスはネットワーク内の制御に委ねられる構造です。このため、アクセス制御はIPアドレスやネットワーク単位で行われることが多く、結果としてアクセス範囲が広くなりがちです。

ZTNAは「接続」ではなく「アクセスの可否」を制御する

一方でZTNAは、ネットワークへの接続そのものを前提としません。

ユーザーや端末がどこにいるかではなく、「どのリソースにアクセスしてよいか」を個別に判断します。具体的には、ユーザーのIDや端末の状態、アクセス先のアプリケーションといった情報をもとに、アクセスの可否を都度判定します。その結果、ユーザーは必要なリソースにのみアクセスが許可され、それ以外のネットワークは見えない状態となります。

制御単位はネットワークからアプリケーションへ変わる

この違いは、アクセス制御の単位に表れます。

VPNでは「ネットワークに接続する」ことを前提としているため、アクセス制御はネットワーク単位になりやすくなります。一方でZTNAでは、「どのアプリケーションにアクセスできるか」を基準とするため、制御の単位はより細かくなります。

つまり、VPNが「どこに接続するか」を制御する仕組みであるのに対し、ZTNAは「何にアクセスしてよいか」を制御する仕組みと言えます。

ZTNAはVPNの代替ではない

このように、VPNとZTNAは解決しようとしている問題の前提が異なります。そのため、ZTNAを単純にVPNの上位互換として捉えると、設計の前提を誤る可能性があります。ZTNAは、VPNの機能を置き換えるものではなく、アクセス制御の考え方そのものを見直すためのアプローチです。

ZTNAで本当に解決できるのか

ここまで見てきたように、ZTNAはVPNとは異なる前提でアクセス制御を行うアプローチです。では、ZTNAを導入すれば、これまでの課題は解決するのでしょうか。

結論から言えば、ZTNAを導入するだけで問題が解決するわけではありません。

ZTNAが成立するために必要な前提

ZTNAによるアクセス制御は、以下の複数要素に基づいて判断されます。

• ユーザーのIDや認証情報

• 端末の状態（セキュリティ対策の有無や準拠状況）

• アクセス先のリソース情報

• アクセス時の状況（場所や時間など）

これらの情報が適切に取得・連携されていなければ、ZTNAによる制御は成立しません。情報が分断された状態ではアクセス判断に一貫性がなくなり、結果として過剰な許可や運用の属人化を招く可能性があります。

アクセス許可の設計が不十分な場合に残る課題

ZTNAでは、アクセス可否をどのような条件で判断するかを設計する必要があります。

こうした設計や前提が不十分な場合、ZTNAを導入しても従来と大きく変わらない状態になる可能性があります。

• どのユーザーに、どのアプリケーションへのアクセスを許可するのか

• どのような端末状態であればアクセスを許可するのか

• 特定の条件で制御を変えるのか

• ID管理が不十分

• 端末状態を評価できない

• ログや可視化が不十分

このような状態では、ZTNAの効果を十分に発揮できません。

ZTNAは“機能”ではなく“設計前提”

重要なのは「ZTNAを導入すること」ではなく、「どのような基準でアクセスを許可・制御するのかを設計すること」です。

現実的にどう設計すべきか

ZTNAは単なる接続手段ではなく、アクセス制御の前提を見直すアプローチです。そのため、導入を検討する際には「どのようにアクセスを制御するか」という観点で設計する必要があります。

アクセス制御を構成する4つの要素

①　 誰がアクセスするのか（ID / ロール）
②　 どの端末からアクセスするのか（デバイス状態）
③　 どのリソースにアクセスするのか（アプリケーション単位）
④　 どのような条件でアクセスするのか（コンテキスト）

これらを組み合わせて設計することが重要です。

設計イメージ（ユースケース）

例えば、営業担当者がクラウド上の業務アプリケーションにアクセスするケースでは、以下のような設計が考えられます。

• ID：営業部門のユーザーのみアクセスを許可

• デバイス：管理された端末（MDM準拠）のみ許可

• リソース：CRMなど業務に必要なアプリケーションに限定

• コンテキスト：海外からのアクセス時は追加認証を要求

このように、複数の条件を組み合わせてアクセスを制御することで、必要最小限のアクセスを実現します。

アクセス制御を成立させるために必要な視点

• 認証基盤との連携

• 端末状態の評価

• アクセスログの可視化

ID、デバイス、アクセス制御といった要素が個別に分断されている場合、ポリシーの整合性を維持することが難しくなります。

こうした要素を個別に管理すると、運用負荷やポリシー不整合が生じやすくなります。そこで、認証・端末評価・アクセス制御を一体的に扱える基盤の選定が必要になります。例えば、弊社の取り扱い製品であるHPE Aruba Networking SSEやCato SASE Cloudのようなソリューションでは、リモートアクセスに必要な制御を一元的に扱うことができます。

その結果、分断されがちなポリシーを一貫した形で適用しやすくなり、設計内容をそのまま運用に反映しやすくなります。

まとめ

VPNはこれまで、リモートアクセスの標準的な手段として利用されてきました。しかし、その前提は現在の利用環境において見直しが求められています。

ZTNAは、VPNの代替ではなく、アクセス制御の考え方そのものを見直すアプローチです。重要なのは「何を導入するか」ではなく、「どのように設計するか」です。

ここまで見てきた通り、ZTNAの検討は“製品選定”ではなく“設計整理”から始める必要があります。ZTNAの導入やVPNの見直しを検討されている場合でも、設計前提が整理されていないと期待した効果は得られません。

• 自社のリモートアクセス設計が適切か分からない

• ZTNAを検討しているが、どこから整理すべきか迷っている

といった場合には、現状整理から設計方針の検討までご支援しています。まずはお気軽にご相談ください。

また、ZTNAやリモートアクセスの見直しを検討する際には、まずVPNが抱えるリスクと、現在も残る役割の両方を整理しておくことが重要です。ぜひ以下のVPN関連記事も参考にしてみてください。

▶「情報漏洩のケース別でみるVPNのリスクと対策」を知りたい方はこちら
本当に「VPN」は悪者？昨今のサイバー攻撃被害から考えるVPN対策まとめ

▶「そもそもVPNとは何か、主要なVPN実現する方法、VPNでどこまで守れるのか」知りたい方はこちら
VPNは危険？役割と限界、代替にSASEが語られる理由を解説