VPN vs ZTNA ― テレワーク時代のネットワーク接続の選び方
テレワーク環境のネットワーク接続は、従来の「VPNで社内に入る」方式から「ZTNAでクラウドに直接アクセスする」方式へ移行が進んでいます。
背景にあるのは働き方の変化です。業務のほとんどがMicrosoft 365やSaaS上で完結するようになると、わざわざ社内を経由してからインターネットに出る構成が、遠回りかつ非効率になります。加えて、VPN装置そのものが攻撃対象になっている実情も、移行を後押ししています。
VPNの仕組みとメリット・デメリット
仕組み： 社外のPCからインターネット経由で暗号化トンネルを張り、社内ネットワークに接続。社内のファイルサーバーや基幹システムにアクセスできる。
メリット： オンプレミスの社内リソースにアクセスできる。既存のネットワーク構成を大きく変えずに導入可能。
デメリット： VPN装置がボトルネックになりやすい（同時接続数の制限、帯域の逼迫）。VPN接続後は社内ネットワーク全体にアクセスできてしまう（攻撃者がVPN経由で侵入すると横展開が容易）。VPN装置自体が脆弱性を突かれた攻撃事例が多発。
VPNの構造的な弱点は「一度入れば何でもできる」こと
技術的な性能の話以上に重要なのが、VPNの認可モデルです。VPNは「社内ネットワークへの入場券」を配る仕組みで、入った後に何にアクセスできるかは細かく制御されません。
つまり、1つのVPNアカウントが乗っ取られた時点で、攻撃者は社員と同じ位置に立ちます。そこからファイルサーバーを探索し、他の端末へ横移動していくのが、近年のランサムウェア被害の典型的な流れです。
さらに、いわゆるヘアピン問題もあります。全通信をVPN経由にする構成（フルトンネル）では、自宅からMicrosoft 365を使うだけの通信も、いったん本社を経由してからインターネットに出ます。回線とVPN装置の両方に無駄な負荷がかかり、Web会議の品質低下として表面化します。
ZTNAの仕組みとメリット・デメリット
仕組み： ユーザーはVPNを使わず、クラウドサービス（M365、SaaS）にインターネット経由で直接アクセス。アクセスのたびにID、デバイスの状態、場所などを検証し、必要最小限のリソースにのみアクセスを許可。
メリット： VPN装置が不要（クラウドのみで業務が完結する場合）。アプリ単位でアクセスを制御でき、社内ネットワーク全体へのアクセスを与えない。条件付きアクセスやIntuneと連携したきめ細かい制御。
デメリット： オンプレミスのリソース（ファイルサーバー、基幹システム）にはアクセスできない。クラウド移行が前提。
「境界」から「ID」へ守る対象が変わる
ZTNAの本質は、信頼の基準をネットワークの位置からIDと端末の状態に移すことです。「社内ネットワークにいるから信頼する」のをやめ、アクセスのたびに次を検証します。
- 誰が（ID・多要素認証の結果）
- どの端末から（管理された端末か、暗号化されているか、更新は適用されているか）
- どこから（国・IPアドレス・普段と異なる場所でないか）
- 何にアクセスしようとしているか（アプリ単位）
この結果、侵害されたときの被害範囲が限定されます。1つのアカウントが乗っ取られても、そのアカウントに許可されたアプリにしか到達できません。
中小企業の現実的な選択
| 業務環境 | 推奨方式 |
|---|---|
| M365＋SaaSで業務完結 | ZTNA（VPN不要） |
| オンプレミスのファイルサーバーが残っている | VPN＋ZTNA（ハイブリッド） |
| オンプレミスの基幹システム（ERP等）を利用 | VPN必須＋クラウドはZTNA |
M365を中心に業務が行われている中小企業では、条件付きアクセス＋Intune＋MFAの組み合わせで、VPNなしのZTNA型テレワーク環境を構築できます。オンプレミスが残っている場合は、VPNをオンプレミスアクセス専用に限定し、クラウドへのアクセスはZTNA型にするハイブリッド構成が合理的です。
まず「VPNで何をしているか」を調べる
移行を検討する際、いきなり製品選定に入ると失敗します。VPN経由で実際に何にアクセスされているかを先に把握してください。
VPN装置のログから、接続元・接続先・利用時間帯を集計します。よくあるのは次のパターンです。
- VPNを使っているが、実際はM365にしかアクセスしていない → VPNは不要。条件付きアクセスへ寄せられる
- 特定のファイルサーバーへのアクセスだけが残っている → そのサーバーをSharePoint/Driveに移せばVPNを廃止できる
- 基幹システムへのアクセスが業務の中心 → VPNは残す。ただし用途を限定し、フルトンネルは避ける
「なんとなく全員にVPNを配っている」状態から、用途を特定して必要な人にだけ残すだけでも、装置の負荷と攻撃面は下がります。
段階的な移行の進め方
一度に切り替える必要はありません。次の順序が現実的です。
- MFAを全ユーザーに適用する — ZTNAの前提。ここが未実施ならまずこれから
- 条件付きアクセスでクラウド側を制御する — M365へのアクセスに、端末とIDの条件を付ける
- フルトンネルをやめる — クラウド向け通信はVPNを経由させない（スプリットトンネル化）。これだけで回線負荷が大きく下がる
- オンプレミスの棚卸し — 残っているリソースをクラウドへ移せるか検討する
- VPNを用途限定にする、または廃止する
3の時点で体感速度が改善するため、社内の理解も得やすくなります。
移行時に見落とされやすい点
- プリンタ・複合機への印刷 — 在宅から社内プリンタに出力する運用があると、VPN廃止で止まります
- ライセンス認証サーバー — 一部の業務ソフトは社内のライセンスサーバーへの到達が必要です
- IP制限をかけている外部サービス — 「社内IPからのみアクセス可」という取引先システムがあると、VPN（固定IP）が必要になります。この場合はクラウドプロキシで固定IPを得る方法もあります
- 監査・ログ要件 — 誰がいつ何にアクセスしたかの記録要件がある場合、ZTNA側で同等のログが取得できるか確認します
VPNを残す場合の最低条件
すぐに移行できない場合でも、次は必ず実施してください。VPN装置の脆弱性を突いた侵入は、実際に多発しています。
- ファームウェアを最新に保つ — 緊急度の高い脆弱性は計画外でも適用する
- MFAを必須にする — ID・パスワードだけの認証は突破される前提で考える
- 退職者アカウントを確実に停止する — 人事とIT部門の連携フローがないと必ず残る
- 管理画面をインターネットに公開しない — 設定用のポートが外部から到達可能な状態は避ける
- 接続ログを定期的に確認する — 深夜や海外からの見慣れない接続に気づける状態にする
まとめ
- VPNの構造的な弱点は性能ではなく、「一度入れば社内全体に到達できる」認可モデルにある
- ZTNAは信頼の基準をネットワークの位置からIDと端末の状態に移す。侵害時の被害範囲が限定される
- 移行検討は製品選定からではなく、VPNログで「実際に何にアクセスしているか」の把握から始める
- 「VPNを使っているが実態はM365だけ」なら、条件付きアクセスへ寄せてVPNを廃止できる
- 段階的に進める。MFA → 条件付きアクセス → フルトンネル廃止 → オンプレ棚卸し → VPN縮小の順
- フルトンネルをやめるだけで体感速度が改善し、社内の理解を得やすくなる
- 見落としやすいのは社内プリンタ・ライセンスサーバー・IP制限のある取引先システム
- VPNを残す場合も、ファームウェア更新・MFA・退職者アカウント停止は必須
→ テレワーク環境構築 完全ガイド → 条件付きアクセスの解説
情シス365では、テレワーク環境のネットワーク設計を支援しています。現状のVPN構成を見直したい場合は無料相談からご相談ください。設計方針の相談はIT顧問プラン、構築と運用は運用支援（月額12万円〜）で対応します。