クラウドサービスやリモートワークの普及により、社内ネットワークへ接続してから業務システムを利用する従来型VPNの見直しが進んでいます。
その移行先として注目されているのが、ZTNA（Zero Trust Network Access）です。
ただし、VPN機器をZTNA製品へ置き換えるだけでは、ゼロトラスト型のアクセス環境は完成しません。利用者の認証、端末の状態確認、アプリケーションごとの権限管理、ログ監視まで含めて設計する必要があります。
本記事では、VPNとZTNAの違いから、導入方式の選び方、PoC、段階展開、VPN停止前の確認事項まで、移行の実務をわかりやすく解説します。
VPNとZTNAの違いはアクセスを許可する範囲にある
VPNとZTNAは、どちらも社外から企業のシステムへ安全に接続するための仕組みです。しかし、アクセスを許可する考え方には大きな違いがあります。
VPNは社内ネットワークへの接続を許可する
一般的なリモートアクセスVPNでは、利用者がID・パスワードなどで認証を受けると、社内ネットワークに接続できます。
VPN自体が危険というわけではありません。暗号化された通信経路を確保できる点は重要です。
一方、一度接続した利用者に広いネットワーク範囲への通信を許可している場合、認証情報や端末が侵害されたときに、攻撃者が内部システムを探索する「横展開」のリスクが生じます。
また、通信を本社やデータセンターのVPN装置に集約する構成では、利用者の増加によって通信が集中し、クラウドサービスの応答速度やWeb会議の品質に影響することがあります。
ZTNAは業務に必要なアプリケーションだけを許可する
ZTNAでは、社内ネットワーク全体ではなく、利用者が業務上必要とするアプリケーションやリソースを単位としてアクセスを許可します。
たとえば、営業担当者には顧客管理システム、経理担当者には会計システムというように、職務に応じて接続先を限定します。
アクセスの可否は、IDやパスワードだけではなく、次のような情報を組み合わせて判断します。
- 利用者の所属、役職、権限
- 多要素認証の実施状況
- 端末が会社管理下にあるか
- OSやセキュリティソフトが最新か
- アクセス元の国や地域
- 通常と異なる時間帯や操作ではないか
- EDRやMDMが正常に稼働しているか
このように、アクセス時の状況を継続的に検証し、必要最小限の権限だけを与える点がZTNAの特徴です。
NISTのゼロトラスト・アーキテクチャでも、ネットワーク上の位置だけを理由に暗黙の信頼を与えず、アクセス要求ごとに認証・認可する考え方が示されています。
ZTNAはVPNを置き換える単独製品ではない
ZTNAの導入で注意したいのは、「ZTNA製品を契約すればゼロトラスト化できる」と考えないことです。
ゼロトラストは特定の製品名ではなく、アクセスを継続的に検証するためのセキュリティ設計思想です。ZTNAは、その考え方をリモートアクセスに適用するための構成要素の一つです。
ZTNAを有効に機能させるには、次の仕組みとの連携が重要になります。
ID管理とシングルサインオン
誰がアクセスしているのかを正確に判断するには、社員、退職者、取引先、外部委託先などのアカウントを一元管理する必要があります。
シングルサインオンと多要素認証を組み合わせることで、安全性を確保しながら利用者の負担を抑えられます。
MDMやEDRによる端末管理
正しいIDでログインしていても、端末がマルウェアに感染していれば安全とはいえません。
MDMによる端末登録、OSの更新状況、ディスク暗号化、EDRの稼働状況などを確認し、条件を満たさない端末からのアクセスを制限します。
SIEMなどによるログ監視
ZTNAを導入しても、設定が適切でなければ不正アクセスを防げない可能性があります。
認証ログ、端末ログ、アプリケーションログを収集し、異常なアクセスや繰り返される認証失敗を検知できる運用体制が必要です。
CISAのゼロトラスト成熟度モデルも、ゼロトラストを「ID」「デバイス」「ネットワーク」「アプリケーションとワークロード」「データ」という複数の領域で捉えています。ZTNAだけで全領域を完成させるものではありません。
VPNからZTNAへの移行前に確認すること
ZTNAへの移行は、製品選定から始めるのではなく、現在の利用状況を把握することから始めます。
VPNの接続実態をログから把握する
最初に、過去数か月分のVPN接続ログを確認します。
確認したい項目は、利用者数、接続時間帯、接続元、通信量、利用頻度、アクセス先などです。
契約上は多くの利用者が登録されていても、実際には一部の社員しか利用していない場合があります。反対に、把握していない外部委託先や古いアカウントが接続していることもあります。
現在のアクセス実態を把握せずに移行すると、必要なシステムへ接続できない、不要な権限をそのまま移行するといった問題が起こります。
業務アプリケーションを優先度別に分類する
社内で利用しているアプリケーションを洗い出し、重要度と移行難易度で分類します。
- P1：基幹システムや受発注システムなど、停止の影響が大きいもの
- P2：ファイルサーバーや社内ポータルなど、日常的に利用するもの
- P3：利用頻度が低いもの、一時的にしか利用しないもの
最初から基幹システムを移行するのではなく、影響範囲が限定され、検証しやすいアプリケーションから始めることが安全です。
非Webアプリケーションとレガシー環境を確認する
Webブラウザで利用するクラウドサービスは、比較的ZTNAへ移行しやすい傾向があります。
一方、固定IPアドレスや特殊なポートを使用する業務ソフト、CAD、大容量ファイル転送、共有端末、古いOSなどは、製品によって対応状況が異なります。
「ZTNA対応」という製品説明だけで判断せず、自社の通信方式と業務シナリオで動作を確認することが重要です。
VPNからZTNAへ移行する12週間ロードマップ
次の12週間は、移行手順を整理するためのモデルケースです。企業規模や既存システムの複雑さによって、必要な期間は変わります。
Week 1～2：現状把握とアプリケーションの棚卸し
VPNの接続ログを分析し、利用者、接続時間、通信量、アクセス先を整理します。
あわせて、社内で使用しているアプリケーション、ファイルサーバー、データベース、外部委託先の接続などを洗い出します。
各部門へのヒアリングも行い、情報システム部門が把握していないシャドーITや、現場固有の利用方法を確認します。
Week 3～4：ZTNA方式の選定とPoC計画
自社のアプリケーション構成、利用端末、拠点数、クラウド利用状況を基に、ZTNAの導入方式を選定します。
PoCでは、単に「接続できたか」だけではなく、次の評価基準を設定します。
- 認証に要する時間
- 業務アプリケーションの応答速度
- Windows、Mac、スマートフォンでの動作
- 多要素認証の操作性
- MDMやEDRとの連携
- 通信障害時の挙動
- 管理者がログを確認しやすいか
- 非Webアプリケーションへの対応
Week 5～6：IT管理者によるPoC
まずは情報システム担当者の端末へZTNAを導入します。
Webアプリケーションだけでなく、ファイル共有、リモートデスクトップ、SSH、データベース接続など、実際の業務を想定して検証します。
自宅Wi-Fi、モバイル回線、社内LANなど、複数の通信環境で再現性を確認することも重要です。
Week 7～8：代表部門への先行展開
役員や各部門の代表者など、トラブル発生時に情報システム部門と連携しやすい少人数へ先行展開します。
この段階では、認証頻度、スマートフォンでの操作、サインイン手順、アプリケーションの表示速度など、利用者側の負担を確認します。
技術的に安全でも、認証が頻繁すぎて業務を妨げる設計では、現場に定着しません。
Week 9～10：全社展開の準備と社員教育
MDMなどを使い、ZTNAクライアントや必要な設定を業務端末へ配布します。
社員向け説明では、製品の技術仕様よりも「いつから何が変わるのか」「認証に失敗したらどうするのか」「どこへ問い合わせるのか」を明確に伝えます。
接続マニュアル、FAQ、緊急連絡先を用意し、切り替え後に社員が自力で問題を解決できる環境を整えます。
Week 11～12：段階移行とVPN停止判断
重要度の低いアプリケーションや一部の部門から、ZTNA経由へ切り替えます。
全アプリケーションの動作と接続状況が安定していることを確認した後、VPNの利用範囲を段階的に縮小します。
VPNはすぐに撤去せず、一定期間は設定を保存した状態で維持し、重大な問題が発生した場合に切り戻せるようにします。
ZTNA移行で起こりやすい4つの失敗
アクセスポリシーを細かくしすぎる
最小権限を重視するあまり、導入当初から利用者単位で大量のポリシーを作成すると、管理が複雑になります。
まずは営業、経理、管理、開発などの職務グループ単位で設計し、実際の利用ログを確認しながら権限を調整します。
認証を増やしすぎて業務効率を落とす
短時間ごとの再認証や、環境が少し変わるたびに多要素認証を要求する設定は、利用者の集中を妨げます。
健全な管理端末では認証状態を適切に維持し、未登録端末、通常と異なる地域、深夜のアクセスなど、リスクが高い状況で追加認証を求める設計が有効です。
IT担当者だけで全社展開を進める
ZTNAは、認証、端末管理、ネットワーク、アプリケーション、社員教育を横断するプロジェクトです。
担当者が少ない企業では、すべてを自社だけで設計・運用しようとすると、日常業務との両立が難しくなる可能性があります。
社内に不足する領域を明確にし、導入支援会社やセキュリティ事業者の支援範囲を事前に決めることが重要です。
レガシーシステムを一律に移行する
古い業務ソフト、製造現場の専用端末、共有PCなどは、最新の認証方式やZTNAクライアントに対応できないことがあります。
すべてを同じ方式へ統一するのではなく、利用場所、端末、システムの特性に応じて認証方式を分けます。必要であれば、一部のシステムでVPNを継続する判断も現実的です。
VPN停止前に決めておきたいロールバック基準
VPNを停止する前に、「何が起きたらVPNへ戻すのか」を客観的に決めておきます。
即時ロールバックを検討する代表的な条件は、次のとおりです。
- 受発注、会計、工場管理などの重要業務が利用できない
- ZTNAや連携する認証基盤の障害で全社的にサインインできない
- 重大な設定不備や脆弱性が判明した
- ヘルプデスクの対応能力を超える認証障害が発生した
- レガシーシステムの復旧方法を確立できない
切り戻し手順、設定のバックアップ、緊急連絡網、問い合わせ窓口を準備し、担当者が迷わず実行できる状態にしておきます。
ZTNA製品を選ぶときの評価ポイント
ZTNA製品は、機能の多さではなく、自社の業務環境との適合性で評価します。
確認すべきポイントは次のとおりです。
- 現在利用しているID管理基盤と連携できるか
- MDMやEDRの情報をアクセス判断に利用できるか
- Web以外の業務アプリケーションに対応できるか
- 社員所有端末や外部委託先へ安全に提供できるか
- 障害発生時のサポート体制が明確か
- ログを取得・保存・分析できるか
- 契約終了時に設定やログを取り出せるか
- 利用者数や通信量の増加に対応できるか
- VPNとの併用期間を設けられるか
カタログ上の機能比較だけでは、実際の通信速度や操作性までは判断できません。必ず自社の端末、回線、アプリケーションを使ったPoCで確認します。
まとめ
VPNからZTNAへの移行は、通信経路を変更するだけのプロジェクトではありません。
社内ネットワークへの広い接続を許可する方式から、利用者、端末、アクセス状況を確認し、必要なアプリケーションだけを許可する方式への転換です。
成功のポイントは、現在のVPN利用状況とアプリケーションを棚卸しし、小規模なPoCから段階的に展開することです。VPNを一括停止せず、ロールバックできる期間を設けることも欠かせません。
ZTNAは有力な選択肢ですが、導入しただけで安全になるものではありません。ID管理、端末管理、ログ監視、社員教育を含めた運用設計によって、初めてゼロトラスト型アクセスの効果を発揮します。
コメント