VPNは本当に危ないのか

2026年3月26日
諸角 昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

「VPNは危険だ」という言説が広まっている。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、セキュリティベンダーはこぞって「脱VPN・ゼロトラスト移行」を訴えている。しかし実際のところ、VPNの何が問題で、どこまでが誇張なのか、冷静に整理できている組織は少ないのではないかと考えている。 本ブログでは、VPNをめぐるリスクの構造を三層に分けて整理し、国内の統計データの正確な読み方、よくある意見への答え、そして対策の方向性について考察する。

VPNのリスクは三層構造

VPNのリスクを「危ない」「危なくない」の二項で語ることには無理がある。問題は性質の異なる三つの層に分かれており、それぞれ対策も深刻度も異なる。

第一層:製品脆弱性(CVE)のリスク

Ivanti、Fortinet、Pulse Secure、NetScalerなど主要なVPN製品では、毎年複数の重大な脆弱性が報告されている。パッチが公開される前後の短期間に大規模な攻撃が観測されるケースも多く、このリスクの深刻さは「発生頻度」ではなく「防御困難性」にある。

ゼロデイ段階では組織側に取れる手段があまりない。さらに厄介なのは、パッチを適用した後でも安心できないケースがあることだ。2024年に確認されたCisco ASAへの「ArcaneDoor」攻撃では、攻撃者がファームウェアレベルにバックドアを仕込み、再起動後もアクセスを維持していたことが報告されている。英国NCSCはこの侵害の検出を「信じられないほど難しい」と評している。

国家支援型APTがこうした脆弱性の発見・悪用に多大なリソースを投じていることも、このリスクの性格を際立たせている。目的は金銭ではなく、長期潜伏・情報収集・将来の破壊活動の準備であることが多く、被害が表面化するのが数ヶ月後というケースもある。

第二層:認証情報管理のリスク

VPN経由の侵害としてよく引用されるColonial Pipeline事件(2021年)は、VPN製品の脆弱性が使われたわけではない。MFAが設定されていない休眠アカウントに、別の情報漏洩事案で入手したパスワードを使って侵入したケースであり、本質は「アカウント管理の失敗」である。

この区別は重要で、製品脆弱性への対策とアカウント管理の強化は、必要な対処が全く異なる。VPN経由の侵害を議論する際に両者が混同されると、対策の優先順位を誤ることになる。 認証情報侵害の深刻度が製品脆弱性より「相対的に低い」理由は、防御手段が明確に存在するからである。MFAを適切に実装し、退職者・外部委託先のアカウントを定期的に棚卸しし、パスワードポリシーを徹底するだけで、このリスクは大幅に低減できる。

第三層:設計思想の欠陥

これが最も根本的な問題である。VPNの設計思想には、現代の脅威環境と相容れない構造が二つある。

一つは、VPNアプライアンスが常時インターネットに公開された「公開ポート」を持つ点である。VPNは外部からの接続を受け付けるためにポートを開き続けなければならず、これが攻撃者のスキャン対象となるアタックサーフェスを恒常的に生み出している。後述するZTNAが実現する「ダークIP」、すなわちサーバーをインターネット上から不可視化し攻撃者がスキャンしても存在自体が見えない状態と、根本的に異なっている。公開ポートが存在する限り、脆弱性が発見されるたびに「侵入の入口」が生まれ続けることになる。

もう一つは、「一度認証すれば内部ネットワークを自由に動ける」という暗黙の信頼モデルであることである。侵害後のラテラルムーブメントを止める仕組みがなく、製品脆弱性でも認証情報侵害でも、内部に入られた後の被害拡大を抑制することが難しい。Colonial Pipeline事件で侵入者が約100GBのデータを2時間で窃取できたのも、この構造があったからである。 公開ポートによって「侵入される入口が常に存在する」こと、そして侵入後のラテラルムーブメントを許容してしまう設計が組み合わさることで、VPNは攻撃者にとって突破しやすく、突破後の被害も大きい構造になっている。この二点は、製品をより新しいものに替えたり、パッチを適切に当てたりするだけでは解決できない、アーキテクチャレベルの問題である。

「VPN問題」はVPN固有の問題か

ここで一度立ち止まって、「脱VPN」という議論はVPN特有の問題を論じているのか、それとも別の何かを論じているのかについて考えてみる。

結論から言うと後者の方に近いと言える。問題の本質は、「常時インターネットに公開され、内部ネットワークへの特権的なアクセスを持つ境界機器全般」に共通する構造的リスクである。ファイアウォール、ルーター、リモートデスクトップ、UTMなど、これらはすべて同じ構造を持っている。

2024年に複数の政府機関ネットワークへの侵入に使われた「ArcaneDoor」はCisco ASA(ファイアウォール)が標的だった。中国系APTのVolt Typhoonは、ルーターやファイアウォールを侵害してボットネット化し、他組織への攻撃の中継拠点として再利用するORB(Operational Relay Box)化の手法を用いている。これらはVPNとは別の機器だが、まったく同じ構造的問題を抱えている。 VPNが特に槍玉に挙がっているのは、第一にテレワークの普及でVPN機器の導入が急増し、アタックサーフェスが広がったこと、第二にランサムウェアの初期侵入経路として実績が積み重なり、報道での露出が増えたこと、第三に製品ベンダーが「脱VPN」をZTNA販売のマーケティングに活用していること、であると考えられる。つまり、「脱VPN」は正しい方向だが、VPNだけを替えれば終わりではなく、「境界機器に依存したアーキテクチャからどう脱却するか」が問題である。VPNはその最大かつ最も目立つ例に過ぎない。

国内統計データの正確な読み方

「ランサムウェア被害の63%がVPN機器経由」という数字は、セキュリティの議論で頻繁に引用されている。この数字の出所と正確な意味を確認しておきたい。

一次ソースは警察庁レポート

出所は警察庁「令和5年におけるサイバー空間をめぐる脅威の情勢等について」(2024年3月公表)である。ランサムウェア被害の有効回答115件を分析したもので、VPN機器からの侵入が73件(63%)、リモートデスクトップからが21件(18%)という結果が示されている。 翌年の令和6年上半期版(2024年9月公表)では、VPN機器47%、リモートデスクトップ36%と変化しており、リモートデスクトップ経由の急増が目立っている。これはVPN対策が進む一方で攻撃者が侵入経路をシフトさせていることを示唆しているものと考えられる。

この数字で言えること・言えないこと

言えること:国内ランサムウェア被害において、VPN機器が初期侵入経路として最多であることは事実として裏付けられている。

言えないこと:この数字はVPN経由の侵害が「脆弱性悪用」と「認証情報侵害」のどちらによるものかを分離していない。警察庁レポートでは、「VPN機器のぜい弱性を悪用したり、強度の弱い認証情報等を利用して侵入」と両者を一括して記載している。

参考値として、侵入経路とされた機器のパッチ適用状況を尋ねたアンケートでは、令和5年データで約6割が「未適用のパッチがあった」、約4割が「最新パッチを適用済み」と回答している。後者はゼロデイ攻撃または認証情報侵害の可能性を示唆するが、断定はできない。IIJニュースでも「VPN機器からの侵入はブルートフォースや過去に漏洩したアカウント情報による不正利用が原因であることも多い」と述べており、認証情報侵害の割合も相当程度あると考えられる。

その他の意見

「IPsec VPNにすれば解決するのでは?」

SSL VPNではなくIPsec VPNを使えばよい、という反論はよく出てくる。答えは「実装は改善されるが、設計思想の問題は解決されない」となる。 IPsecにすることで、Ivanti等のSSL VPN製品固有の脆弱性リスクは低減できるが、「公開ポートによるアタックサーフェス」と「認証後のラテラルムーブメントを許容する設計」という第三層の問題は変わらない。IPsecはVPNをより堅牢にするアプローチであり、問題の所在が設計思想にある以上、IPsecへの切り替えは根本的な解にはならない。

「VPNを止めたらレガシーアプリが動かなくなる」

「VPNを止めたらレガシーアプリが動かなくなる」という懸念は、ZTNAの実装方式を選べば多くの場合解決できるが完全ではないと言える。

ZTNAには主に二種類の実装がある。主流の「L7プロキシ型」はHTTP/Sのヘッダーやセッション情報を読んでポリシー評価を行うため、独自TCP/UDPプロトコルに依存するレガシー基幹系・VoIP・映像伝送などは通信の解釈が難しく、対応が困難である。一方「L4トンネル型」(WireGuardベース等)はポート・IP単位で制コントロールするため、RDP・SSH・非HTTP/Sプロトコルにも対応しやすい。L7型と比べてポリシーの粒度は粗くなるが、VPNとは異なり認証後もネットワーク全体へのアクセスを許可するわけではなく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。

ただし実装方式にかかわらず対処できない領域が残る。OT機器・医療機器・産業用PLC等にはエージェントを導入できないため、ZTNAの管理下に置けない。この部分は「動かなくなる」のではなく「ZTNAで管理できない」という問題であり、VPNとのハイブリッド運用か別の手段を検討する必要がある。

結論として、「VPNを止めたらレガシーアプリが動かなくなる」は全体としては正しくなく、L4型ZTNAの選択と移行設計で大半は解決できることになる。残る課題はOT/IoT環境に限定されることになると考えられる。

「VPNを使い続けることは現状維持ではないのか?」

現状維持にもコストとリスクは発生する。アプライアンスのライセンス・運用・パッチコストの増大、侵害時の対応コストなどである。「今すぐ移行できないからVPNを続ける」という判断は、既知のリスクを可視化しないまま保有し続けることを意味する。

ZTNAへの移行は答えになるか

ZTNAがVPNの根本的な代替となりうる理由は、前述した設計思想の欠陥を直接解決するからである。その上で、この問いについて考えてみる。

ZTNAが解決するもの

  • ダークIP:ZTNAゲートウェイ経由でのみアクセスを許可し、サーバーのIPアドレス自体をインターネット上から不可視化する。公開ポートがなくなることでアタックサーフェスが根本から消える。
  • 最小権限アクセス:ネットワーク全体ではなくアプリケーション・リソース単位でアクセスをコントロールする。侵害されてもラテラルムーブメントの被害を局所化できる。
  • 継続的なコンテキスト認証:ユーザーIDだけでなく、デバイスの健全性・接続元・行動パターンをリアルタイムで評価し、リスクに応じてアクセスをコントロールする。
  • 可視性の向上:誰が・何に・どこから・いつアクセスしたかを完全に記録できる。

ZTNAが解決が難しいもの

ZTNAを過信することも危険である。設計思想は優れていても、実装と運用が伴わなければ新たなリスクを生むことになる。

  • ポリシー設計の複雑さ:最小権限ポリシーの設計ミスは直接セキュリティホールに繋がる。VPNの「とりあえずつなぐ」運用から、精緻なポリシー管理への転換が必要である。
  • IdP依存:ZTNAはID基盤との連携が前提であり、IdPが単一障害点になりうる。ID基盤の整備が課題になることも多い。
  • ベンダーロックイン:標準化が未成熟でベンダーごとに実装が異なる。製品選定は長期的な視点が必要である。
  • レガシー環境の限界:ZTNAの主流であるL7プロキシ型はHTTP/Sと相性が良い一方、非HTTP/Sプロトコルへの対応は粒度が粗くなる。L4トンネル型(WireGuardベース等)はRDP・SSHなど非HTTP/Sにも対応しやすく、ラテラルムーブメントの抑制やダークIPの維持といったZTNAの本質的な利点は保たれる。OT機器・PLCなどエージェントを導入できないデバイスについても、SDPアーキテクチャではゲートウェイ側にネットワークコネクタを設置することで保護下に置くことができる。ただしOT環境特有のリアルタイム性・可用性要件への対応は設計段階で十分な検討が必要となる。

AIがVPN問題をどう変えるか

VPNをめぐる脅威環境は、AIの普及によって構造的に変化しつつある。攻撃側・防御側の双方でAIが使われるようになっており、その影響を把握しておくことは今後のセキュリティ戦略に不可欠である。AIは攻撃者にとって、これまで専門知識や時間を要していた作業を自動化・低コスト化するツールになっている。VPNをめぐる文脈で特に影響が大きい点は以下の三つであると考える。

第一は、マルウェアおよびエクスプロイトコードの自動生成である。警察庁は2024年に、生成AIを悪用してランサムウェアと思われる不正プログラムが作成された国内事例を公表している。従来、ランサムウェアの開発には高度な技術力が必要だったが、生成AIの登場でそのハードルが大幅に下がっている。RaaSのエコシステムと組み合わさることで、技術力の低い攻撃者でも洗練された攻撃が可能になりつつある。

第二は、脆弱性スキャンと初期侵入の自動化である。AIを使った自動スキャンツールは、インターネット上に公開されたVPNアプライアンスのバージョン情報や応答パターンから脆弱性の有無を高速に判定し、CVEが公開されたその日のうちに大量のターゲットへ攻撃を試みることができる。VPNの「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AIによる自動スキャンの存在によってさらに深刻化している。かつては人間の攻撃者が手動で探索していた侵入口が、今や24時間自動で探索され続けている。

第三は、フィッシングと認証情報窃取の精度向上である。VPN経由の侵害の相当の割合が認証情報の漏洩を起点とすることは前述の通りであるが、AIを使ったフィッシングメールは文章の自然さ・ターゲティングの精度が飛躍的に向上しており、従来の「日本語が不自然なメール」という見分け方が通用しなくなってきている。また、AIによる音声・動画の偽造(ディープフェイク)を使って経営幹部になりすます攻撃も報告されており、ソーシャルエンジニアリングのリスクが全体的に高まっている。

まとめると、AIの普及は、VPNが持つ三つのリスクをいずれも悪化させる方向に作用する。製品脆弱性はAI自動スキャンによって即日悪用されるリスクが高まり、認証情報侵害はAI精度向上によるフィッシングで窃取しやすくなり、マルウェア展開は自動生成ツールの普及で参入障壁が下がる。「公開ポートが常にアタックサーフェスになる」という設計上の問題は、AI時代においてより高速・大規模に突かれる環境に変わりつつあるといえる。

まとめ

ここまでの内容を踏まえ、IT部門・情報システム担当が今取るべきアクションを、時間軸と優先度で整理してみたい。「脱VPN」は方向性として正しいが、すべてを同時に進める必要はない。重要なのは、リスクを可視化した上で、組織の状況に応じた順序で手を打つことである。

今すぐ着手すべきこと(製品・アーキテクチャを問わない基本対策)

これらはZTNAへの移行の有無にかかわらず、現時点で実施しなければならない最低限の対策である。AIによる攻撃の高度化を考慮すると、後回しにするほどリスクが増大することになる。

  • VPN機器のファームウェア・パッチ適用状況を棚卸しし、未適用のものを即時適用する。サポート終了機器が存在する場合は、更新計画を立てる
  • すべてのVPNアカウントにMFAを設定する。特に退職者・外部委託先・長期未使用のアカウントを優先的に無効化する(ゾンビアカウントの排除)
  • VPN接続ログの監視を強化する。通常と異なる接続元IP・時間帯・通信量の異常をアラートできる仕組みを整備する
  • IPA、JPCERTの脆弱性情報にサブスクライブし、使用中のVPN・ファイアウォール製品に関するCVEを即座に検知できる体制を作る

中期的に進めること(ZTNAへの移行の準備と段階的実施)

ZTNA移行の前提条件を整えながら、リスクの高い部分から順に置き換えていく。完璧な計画を待つより、部分的にでも移行を始めることの方が重要である。

  • ID基盤の整備:ZTNAはIdPとの連携が前提となる。Active Directoryのクラウドへのリフト、Entra ID等の整備を先行させる必要がある
  • 外部委託先・サードパーティのリモートアクセスをVPNからZTNAに置き替える。ゾンビアカウントリスクが最も集中する領域であり、効果が出やすい
  • SaaSアクセスにZTNA/SWGの要素を導入し、クラウドへのバックホール問題を解消しながらゼロトラストの経験を蓄積する
  • VPN機器が担っている機能(拠点間通信等)を棚卸しし、ZTNA、SD-WAN、SASEのどの組み合わせで代替するとかの設計を行う

長期的な目標(アーキテクチャの完全転換)

  • テレワーク、全社員のリモートアクセスをZTNAに完全移行し、物理的なVPNアプライアンスを廃止する
  • 「インターネットに公開されたポートを持つ境界機器」をネットワーク設計から排除し、ダークIPアーキテクチャを実現する
  • 継続的なポスチャ評価(デバイス健全性・コンテキスト認証)を全アクセスに適用し、AIを活用した異常検知と組み合わせる

経営層への説明

IT部門から経営層へのエスカレーションでは、技術的な詳細より「リスクの受容判断を経営として行う必要がある」という点を明示することが重要である。

  • 「VPNを維持することはゼロコストの現状維持ではない。既知のリスクを保有し続けるという意思決定だ」と明示する
  • インシデント発生時の対応コスト(調査・復旧・賠償・事業停止損失)とZTNA移行投資を比較したROI試算を提示する
  • 「今すぐ全廃」ではなく「段階移行ロードマップ」として提示することで、意思決定のハードルを下げる
  • AIによる攻撃の高度化を根拠として、「従来より速いスピードで脆弱性が突かれる環境になっている」という脅威環境の変化を説明する

VPNは問題のない技術ではなく、既知のリスクを抱えたまま動いているインフラである。製品脆弱性・認証情報管理・設計思想の三層すべてに問題があり、AIの普及がその脅威を加速させている。「脱VPN」の方向性は正しく、いつ・どこから始めるかという段階的なアプローチが望ましいと考える。

以上

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*