VPNは危険って本当？SASE・ZTNAとの違いは「トンネル」ではなく設計にある

「VPNはもう危険」「これからはゼロトラスト」。そんな言葉をよく目にします。一方で、こんな疑問も浮かびます。

• VPNという技術そのものが危ないのか？
• SASEやZTNAは、VPNと何がどう違うのか？
• 中小企業は、VPNをやめないといけないのか？

先に結論をお伝えします。危ないのは**VPNという技術そのものではなく、古い「設計」と「運用」**です。そして、SASEやZTNAも、接続には暗号化された経路（トンネル型の接続）を使うことがあります。つまり両者を分けるのは「トンネルの有無」ではなく、設計の考え方です。ひとことで言えば、見るべきは「トンネルの有無」ではなく、誰が・どこまで入れるかの設計です。この記事では、その違いを専門用語ぬきで整理します。

この記事でわかること

• 「VPNは危険」がどこまで本当か
• SASE・ZTNAとVPNの、本当の違い（＝設計）
• 中小企業が現実的に取るべき方向

「VPNは危険」はどこまで本当か

VPN機器を狙った攻撃は実際に多く、警察庁「ランサムウェア被害防止対策」でも、VPN機器やリモートデスクトップのぜい弱性が悪用される事例が多数確認されていると説明されています。ただ、その中身を見ると、危険の正体は「VPNという技術」ではなく、次のような古い設計・運用にあります。

• 脆弱性の放置：修正プログラムを当てず、サポート終了（EOL）機器を使い続ける
• パスワードだけの認証：流出・使い回しで突破される
• 接続後にフルアクセス：つながれば社内LAN全体が見える状態

脆弱性が放置されやすい背景には、JPCERT/CC「なぜ、SSL-VPN製品の脆弱性は放置されるのか」が指摘するように、メーカーから利用者へ情報が届きにくい商流の問題もあります。いずれにせよ、問題は技術そのものより設計・運用の古さだ、という視点が大切です。

とはいえ、古いVPN機器の脆弱性・保守切れ・パスワードだけの認証は、現実に攻撃者から狙われています。「技術のせいではない」からといって、古い構成を放置してよいわけではありません。VPNの危険性の詳しい点検は脱VPNの記事でも扱っています。

「トンネルの有無」で安全・危険は決まらない

ここでよくある誤解が、「SASE／ZTNAはトンネルを使わないから安全、VPNはトンネルだから危険」というものです。

実際には、SASEやZTNAでも、端末とサービスの間や、拠点とクラウド基盤の間で、暗号化通信やトンネル型の接続を使う場合があります。暗号化された経路を使う点だけ見れば、従来のVPNと重なる部分もあります。つまり「トンネルがあるから危険」「トンネルがないから安全」とは言えません。

「安全か危険か」を分けているのは、トンネルを張るかどうかではなく、そのアクセスを、誰に・どこまで・どう許すかという設計です。

SASEとZTNAの違いを整理する

「VPN・ZTNA・SASE」は、しばしば同列で語られますが、指しているものの粒度が違います。用語の整理は用語集でも行っています。

本当の違いは「設計」にある

鍵になるのが「ゼロトラスト」という考え方です。NIST（米国国立標準技術研究所）の「SP 800-207（ゼロトラストアーキテクチャ）」では、ネットワーク上の場所だけで信頼しないこと、リソース単位で保護すること、アクセスをセッション単位で判断し利用者・端末・状況などに応じたポリシーを適用すること、最小権限を適用することが示されています。

日本でも、デジタル庁「ゼロトラストアーキテクチャ適用方針」で、政府情報システムにこの考え方を適用していく方針が示されています。

古い境界型のVPNと、ZTNA／SASE的な設計の違いを並べると、次のようになります。

ポイントは、これは製品名の話ではなく、設計の話だということです。同じ「暗号化された経路を使う」でも、設計が古いままなら危うく、設計を現代化すれば安全側に寄せられます。

よくある「古い設計」のサイン

自社の構成が、古い設計のままになっていないか点検してみてください。

当てはまる項目が多いほど、「VPNをやめる」より先に、設計の見直しが効きます。

中小企業が現実的に取るべき方向

ここまでをまとめると、中小企業の現実解は「VPNをやめる」ことではなく、設計を現代化することです。いきなり大規模なSASEを全面導入しなくても、設計の考え方は近づけられます。

• 接続後の到達範囲を絞る（社内LAN全体を開放しない）
• 利用者ごとに必要な宛先だけを許可する（最小権限）
• 共有IDをやめ、認証情報の管理を徹底する
• 脆弱性対応・更新の担当と頻度を決める

たとえばForceLinkは、ゼロトラストの考え方のうち「接続後も社内LAN全体を開放しない」「利用者ごとに必要な社内リソースだけ許可する」という部分を、中小企業向けリモートアクセスに取り入れた一例です。機能名として社内リソース・ルート制御（接続後も社内LAN全体を開放せず、利用者ごとに必要な宛先だけ許可する機能）を提供していますが、現時点で多要素認証（MFA）には未対応のため、MFAを必須要件とする場合は、要件に合う構成を別途ご確認ください。方式ごとの違いは比較ページ、設計の考え方はセキュリティのページでも整理しています。

まとめ：押さえるべき3点

1. 危ないのはVPNという技術そのものではなく、古い設計・運用
2. SASE・ZTNAも暗号化通信・トンネル型の接続を使うことがある。違いは「トンネルの有無」ではなく設計
3. 中小企業の現実解は「やめる」より、接続後の範囲を絞り、最小権限にする設計の現代化

自社の構成が古い設計のままになっていないかは、比較ページで方式を、脱VPNの記事で点検の観点を確認しつつ、あわせて料金ページとFAQで確認してください。中小企業が現実的に始める手順は中小企業のゼロトラスト入門で解説しています。UTM・ファイアウォールとの役割の違いはこちらの記事も参考にしてください。

参考・出典

• 警察庁「ランサムウェア被害防止対策」
• JPCERT/CC「なぜ、SSL-VPN製品の脆弱性は放置されるのか」（2022年）
• NIST「SP 800-207 Zero Trust Architecture」（2020年）
• デジタル庁「ゼロトラストアーキテクチャ適用方針」（2022年6月）