はじめに:VPNへの誤解

20251211

ここ数年、ランサムウェア被害のニュースをきっかけに、「VPNは危険だ」「VPNはもう限界だ」「これからはゼロトラストだ」という論調の記事が一気に増えました。

国内の調査でも、ランサムウェア被害の侵入経路として VPN 機器や RDP の脆弱性が大きな割合を占めると指摘されています。警察庁「令和6年上半期におけるサイバー空間をめぐる脅威の情勢等について」によれば、感染経路のうち、VPN機器またはリモートデスクトップ(RDP)を経由したものが約83%を占めており、侵入経路となった機器の約5割はセキュリティパッチが未適用の状態でした。

海外でも同様の傾向が見られます。Zscaler ThreatLabz 2024 VPN Risk Report によると、56%の組織が過去12ヶ月間に「VPNの脆弱性を悪用したサイバー攻撃」を少なくとも1回経験しており、これは前年の45%から11ポイントの増加です。また、91%の回答者が「VPNが自社のITセキュリティ環境を危険にさらす可能性がある」と懸念を示しています。

こうした数字だけを見ると、

「VPNは時代遅れだ」

「VPNこそ諸悪の根源だ」

「ゼロトラストに移行すれば安全になる」

という結論に飛びつきたくなります。

しかし、本当にそうでしょうか?

・VPNそのものが危険なのか?

・VPNの「設計思想」自体が古くなっているのか?

・それとも、運用や組み合わせ方の問題なのか?

そもそも VPN は、なぜ生まれ、なぜ今も使われ続けているのか。

単に「社内ネットワークに入るためのトンネル」なら、他の技術でも代替はできます。それでもなお、VPN が重要な役割を果たし続けている理由はどこにあるのか。

実は VPN には、他の技術では決して代替できない「本質」があります。

そして、その本質を見失ったまま「脱VPN」だけが語られていることこそ、いま最も危険な状況だと感じています。

本稿では、

・VPNがなぜ生まれたのか

・VPNの本当の目的とは何か

・ゼロトラストの理想と現実

・そして、今本当に考えるべき「信頼」と「検証」とは何か

を整理しながら、「VPNは悪者か?」という問いに、少し違う角度から答えてみたいと思います。

第1章:VPNの歴史 ― なぜ生まれたのか

VPN の起源を理解するには、「そもそもインターネットはどんな前提で作られたのか」を軽く振り返る必要があります。

インターネットの黎明期(1960年代〜1980年代)

1960年代、ARPANET から始まり、1980年代には TCP/IP プロトコルが確立され、現在のインターネットの基盤が出来上がりました。

当時のネットワークは、「とりあえずつながればいい」という設計が中心でした。

・データは基本的に平文

・経路は信頼された研究機関・軍事ネットワーク

・攻撃者が一般ユーザーとして大量参加する世界は想定されていない

つまり、

・盗聴

・なりすまし

・中間者攻撃

といったリスクは、設計当初ほとんど考慮されていませんでした。

暗号化とトンネリングへの挑戦(1990年代)

1990年代に入り、インターネットが一般社会に広がるにつれ、「公共のネットワークを使いながら、安全に通信したい」というニーズが急速に高まります。

そこで研究されたのが、

・IPパケット自体を暗号化する仕組み(IPsec)

・既存のインターネットの上に仮想的な専用線を作るトンネリング

という発想でした。

背景にあった現実は極めてシンプルです。

・拠点間専用線は安全だが高価すぎる

・インターネットは安価だが危険すぎる

「安価なインターネットの上に、専用線と同等の安全な仮想ネットワークを作れないか?」

この問いに対する答えが、VPN(Virtual Private Network)でした。

VPN の目的は最初から明確でした。

・インターネットの上に

・特定の組織だけが利用できる

・閉じた、安全な仮想ネットワークを作ること

つまり VPN とは、

「自分たちが管理するネットワーク同士を、公共ネットワークを経由しながら安全につなぐ技術」

として生まれたものなのです。

企業から個人へ、そして「本質の忘却」へ

その後 VPN は、

・拠点間通信

・リモートワーク

・管理者の遠隔運用

といった用途で広く普及しました。

2000年代後半以降は、

・個人向けVPNサービス

・プライバシー保護ツール

・地域制限回避手段

としても認知されるようになり、「VPN=IPを隠すもの」「VPN=動画を見るためのもの」というイメージも広がります。

この過程で、VPN本来の役割――

「自分たちが作り、自分たちが管理する安全な空間に、遠隔から安全に入るための技術」

という本質が、少しずつ意識されなくなっていきました。

第2章:VPNの本当の目的(本質的3要素)

VPN が 30 年近く使われ続けてきた理由は、「社内ネットワークに入れるから」ではありません。

VPN には、他の技術では代替できない 3 つの本質的価値が存在します。

1. 経路保証(Path Authenticity)

― 暗号境界を自分で固定できる価値

VPN の最大の価値は、通信が”どこで暗号化され、どこで復号されるか”という論理的経路(トラストバウンダリ)を、利用者自身が固定できることです。

この「論理経路の固定」こそが、多くの人が見落としている VPN の核心です。

インターネット通信では、BGPルーティングの変動により経路が常に変化します。どの国・どのネットワークを経由するかは制御できず、途中経路での盗聴・改ざんを検知することも困難です。

しかし VPN は、

・暗号トンネルの始点と終点(Security Association)を自分で指定できる

・復号地点は”VPNゲートウェイ以外では絶対に発生しない”

・途中の物理経路がどう変動しても安全性に影響しない

という、インターネットには本来存在しない「論理経路の固定」を実現します。

つまり、到達先のIPが同じでも、VPNではそこに至るまでの経路をすべて”安全に無視できる”。

これはプロキシや SASE が提供する「中継点としてのIP」とは、まったく次元が異なる価値です。

インターネットの不確実性を排除し、”安全性が自分で定義できる経路”を作る技術が VPN である。

これが「経路保証」の本質です。

 

2. 接続相手の真正性保証(Mutual Authentication)

― 双方向で「本物」を確認できる価値

通常の TLS 通信は、クライアント → サーバの一方向認証が基本です。

VPN は初期設計から、

・クライアント → VPNサーバ

・VPNサーバ → クライアント

という相互認証(Mutual Authentication)を前提としています。

これにより、

・接続している相手が本当に正当な VPN ゲートウェイである

・接続してきたクライアントも正当な利用者である

・認証が成功した双方の間に、第三者が入り込む余地がない

という構造が成立します。

ZTNA も似た認証概念を持ちますが、「相互認証 × 暗号境界の自主管理」が合わさる点は VPN にしか存在しません。

 

3. 盗聴・改ざん防止(Confidentiality & Integrity)

― 道と内容の両方を守る価値

通信経路には、多層の攻撃ポイントが存在します。

・ARPスプーフィング

・DNSポイズニング

・中継ルータの書き換え

・BGPハイジャック

・偽アクセスポイント

・ISPレベルのインターセプト

プロキシや ZTNA が守れるのは「内容」だけであり、入り口までの経路は依然として攻撃可能領域のままです。

VPN が強い理由は、「どこで暗号化され、どこで復号されるか」という”道”の保証と、内容の保護がセットで成立している点にあります。

特に DNS については、

・公開DNSを使っても政府・ISPのリダイレクトは回避できない

・DoH/DoT でもブロック・ハイジャックされ得る

一方 VPN は、DNSクエリすらトンネル内部で完結できるため、攻撃面を大幅に縮小できます。

 

◆ 本質まとめ

この順序には明確な意味があります。

1. 経路保証 ― 道を守る(暗号境界の自主管理)

2. 接続相手の真正性保証 ― 誰と繋がるかを守る

3. 盗聴・改ざん防止 ― 通信の内容を守る

VPN は「内容を守る技術」ではなく、”道と相手と過程”を守る技術です。

この本質を理解しないまま VPN を評価すると、

・「暗号化なら TLS で良い」

・「認証なら ZTNA で良い」

という、根本的に間違った結論に至ります。

第3章:VPNを評価する正しい観点

VPN の本当の価値は、

「安全な相手との専用トンネルを確立し、その間に誰もいないことを保証する」

という一点に集約されます。

では、なぜ VPN が「攻撃されやすい」と言われるようになったのでしょうか。

実際に被害の多くを占めているのは、次のようなケースです。

・脆弱なファームウェアを放置した機器

・ID・パスワードのみの認証

・パッチが適用されていない運用

・VPN接続後の社内LANがフラットで無制限に移動できる構成

つまり、

「VPNという技術そのもの」ではなく、

「VPNを万能トンネルとして雑に扱った設計と運用」

こそが、攻撃対象になってきたのです。

玄関(VPN)が悪かったのではなく、

鍵管理と家の中の構造が危険だった、という構図です。

第4章:ゼロトラストの理想と現実

ゼロトラストの思想は、本来とても健全です。

・誰も信じない

・すべて検証する

という考え方は、境界型防御の限界を超える重要な発想です。

SASE や ZTNA は、その思想を実装する技術として急速に普及しました。

しかし、ここで一つ重要な問いが残ります。

「その検証基盤は、誰が管理し、どこで動いているのか?」

多くのゼロトラスト環境では、

・クラウド上の認証基盤

・クラウド上のゲートウェイ

・クラウド上の検査エンジン

を必ず経由して通信が成立します。

これは、

「最も重要な入口と判断ロジックを、自分たちでは検証できない空間に預けている」

という構造でもあります。

SASE / ZTNA の盲点

ここで、次の問いに明確に答えられるでしょうか。

・そのサーバのメモリは暗号化されているか?

・他社と物理的に分離されていると証明できるか?

・運用者や管理者が見ていないと検証できるか?

・国家レベルの介入に対して、利用者自身が検証できるか?

多くの場合、これらは

「ベンダーを信じる」

以外に、確認手段が存在しません。

ゼロトラストは「誰も信じない」という思想で始まりました。

 

しかし現実には、クラウド基盤の中身については「信じるしかない」という構造が残っています。

これはベンダーの問題ではなく、現在のアーキテクチャが抱える構造的な課題となっています。

第5章:データの3つの状態と、見落とされている領域

データの保護は、次の3つに分けて考えられます。

  • Data at Rest(保存中)
  • Data in Transit(通信中)
  • Data in Use(処理中)

 

VPN は Data in Transit を守る技術です。
ストレージ暗号化は Data at Rest を守ります。

しかし、Data in Use――処理中のメモリ上のデータについては、
依然として十分な検証手段を持たない環境が大半を占めています。

ゼロトラストは入口を厳格に管理するものの、

  • 処理中のデータが誰にも見られていないか
  • 実行中のデータが盗まれていないか

といった点を、利用者自身が独立して確かめる仕組みは、多くの環境で確立されていません。

近年では、Intel SGX や AMD SEV、AWS Nitro Enclaves など、Confidential Computing によって Data in Use を保護しようとする技術も登場しています。

ただしこれらは、

  • 対応サービスが限られている
  • アプリケーション側の大幅な改修が必要
  • 運用の複雑さがネックになる

といった課題が残っており、
「利用者自身が検証可能なモデル」という観点では、まだ一般的な選択肢とは言えません。

結論:統合という選択 ― VPNとゼロトラストは対立しない

本稿は、「VPNか、ゼロトラストか」という二項対立を作るためのものではありません。

VPNには、

・通信経路を固定し、検証可能にする

・通信相手の真正性を双方向で確定する

・通信経路に第三者が存在しないことを保証する

という、今なお失われていない本質的価値があります。

ゼロトラストには、

・境界に依存しない

・すべてを継続的に検証する

という、現代に不可欠な思想があります。

本当に必要なのは、

VPNを捨てることでも、

ゼロトラストを否定することでもなく、

「それぞれの目的を見失わないまま、統合されたセキュリティモデルを再構築すること」

ではないでしょうか。

VPNの目的を忘れたゼロトラストも、

ゼロトラストの思想を欠いたVPN運用も、

どちらも新たな”無意識の信頼”を生み出してしまいます。

真のゼロトラストとは、単なる製品の置き換えではありません。

・何を信じているのか

・どこまでを検証できているのか

・どこから先を「信じるしかない領域」として受け入れているのか

これらを利用者自身が正しく理解し、その上で設計することこそが、本当の意味でのゼロトラストです。

自分が借りたサーバで、自分たちのセキュアな空間を作る。

その安全性を、自分たち自身で検証できる構造を持つ。

安全は「検証できること」でしか成立しません。

検証できない安心は、保証のない期待にすぎません。

VPNの本質を見失わず、

ゼロトラストの思想を形骸化させず、

矛盾を排除するのではなく、

矛盾を統合した次のモデルへ。

いま私たちに必要なのは、そのための冷静な再設計ではないでしょうか。

(本稿は、VPNの本質的価値とゼロトラストの思想を「対立」ではなく「検証可能性」という軸で再統合することを目的としています)