SSL-VPN(SSL/TLS を利用したリモートアクセス VPN)を狙った攻撃が相次いでいます。FortiOS・Ivanti Connect Secure・Pulse Connect Secure といった主要な製品で、認証を回避されたり、遠隔から任意のコードを実行されたりする深刻な脆弱性が繰り返し公表されています。こうした脆弱性は、ランサムウェアの侵入口としても報告が続いています。
自社で使っている SSL-VPN 機器に脆弱性があると知っても、「何から手をつければよいのか」「このまま使い続けてよいのか、それとも移行すべきか」で判断に迷う担当者は少なくありません。専任のセキュリティ人材がいない企業であれば、なおさらです。
本記事では、SSL-VPN に脆弱性が多い構造上の理由を整理したうえで、近年の重大な脆弱性(CVE)の実例、今すぐ取るべき当面の対策、そして「使い続けるか・移行するか」の判断材料を解説します。
目次
一括ダウンロードする
SSL-VPNの脆弱性はなぜ多いのか
SSL-VPN は、ブラウザや専用クライアントから社内のネットワークやアプリケーションへ安全に接続できる仕組みで、導入のしやすさからテレワークで広く使われてきました。その SSL-VPN で脆弱性が繰り返し見つかるのは、担当者の運用が悪いからというより、製品の構造そのものに起因する面が大きいといえます。主な理由は次の4点です。

- インターネットに公開される入口である: 社外から接続を受け付けるため、常にインターネット側に露出しています。攻撃者から見れば社内ネットワークへの入口であり、探索と攻撃の標的になりやすい性質を持ちます。
- ベンダーごとに機能を独自実装している: 認証・ポータル・ポリシー配布などを各ベンダーが独自に作り込むため、実装の過程で欠陥が入り込みやすくなります。
- 大規模なソフトウェアライブラリに依存している: SSL/TLS の処理には OpenSSL などの大規模で複雑なライブラリが使われます。VPN で使わない機能まで含む複雑さが、考慮漏れや予期しない脆弱性を生みやすくします。
- 認証・暗号化・ポータルを1台に集約している: Web UI・認証・暗号化・ポータルを1つの機器に詰め込む設計は、攻撃対象となる面が広く、1か所の欠陥が機器全体の乗っ取りにつながりやすい構造です。
これらは特定のベンダーに限った話ではありません。SSL-VPN を廃止する方針を打ち出した Fortinet も、同趣旨の課題として「脆弱性の恒常的多発」「ソフトウェアライブラリの複雑性」「広すぎるアクセス権限」を挙げています。後者2つは上で挙げたライブラリへの依存や機能の1台集約と重なり、ベンダー自身の説明からも、製品の構造に根ざした課題であることが裏づけられます。
加えて、SSL-VPN は導入している企業が多いため、攻撃者に狙われやすく、結果として脆弱性が見つかり報告される機会も多くなります。利用の広さそのものが、脆弱性の表面化しやすさにつながっている面もあります。
出典・参考資料(2件)
近年の重大なSSL-VPN脆弱性と被害の実例
ここからは、脅威が実在することを具体的な脆弱性(CVE)で確認します。CVE とは、公表された脆弱性に世界共通で付けられる識別番号です。CVSS は深刻度を 0〜10 で表す指標で、9.0 以上が「緊急」に相当します。
自社で使っている製品・バージョンが該当しないか、照らし合わせてみてください。以下は代表的な例で、ここに載っていない製品でも、各ベンダーの公開情報や JPCERT/CC・IPA の注意喚起をたどれば同じように確認できます。
主な重大脆弱性の一覧(2021年以降)
SSL-VPN 製品の重大な脆弱性は、特定の年に集中したものではなく、2021年以降も製品・ベンダーをまたいで継続的に公表されています。いずれも認証の回避や遠隔からのコード実行につながるもので、実際に攻撃へ悪用された例も含まれます。
| CVE番号 | 対象製品(影響を受けるバージョン) | 脆弱性の内容 | CVSS | 公表時期 |
|---|---|---|---|---|
| CVE-2021-22893 | Pulse Connect Secure(9.0R3・9.1R1 以降が影響) | 認証バイパス。未認証の攻撃者による遠隔コード実行。悪用が確認済み | 10.0(緊急) | 2021年4月 |
| CVE-2022-40684 | FortiOS・FortiProxy・FortiSwitchManager | 認証バイパス。未認証の攻撃者が管理インターフェースを操作可能 | 9.8(緊急) | 2022年10月 |
| CVE-2022-42475 | FortiOS SSL-VPN・FortiProxy SSL-VPN | ヒープベースのバッファオーバーフロー。未認証の遠隔コード実行。悪用が確認済み | 9.8(緊急) | 2022年12月 |
| CVE-2023-4966 | Citrix NetScaler ADC・NetScaler Gateway(Gateway 構成時) | 機密情報の漏えい(通称 CitrixBleed)。セッション情報の窃取に悪用された | 9.4(緊急) | 2023年10月 |
| CVE-2023-46805 | Ivanti Connect Secure(9.x・22.x)・Policy Secure | 認証バイパス。制御チェックを回避し制限リソースへアクセス | 8.2(重要) | 2024年1月 |
| CVE-2024-21887 | Ivanti Connect Secure(9.x・22.x)・Policy Secure | コマンドインジェクション。細工したリクエストで任意コマンド実行 | 9.1(緊急) | 2024年1月 |
| CVE-2024-21762 | FortiOS SSL-VPN・FortiProxy(6.0〜7.4系) | 境界外書き込み。未認証の遠隔コード実行のおそれ。悪用が確認済み | 9.8(緊急) | 2024年2月 |
※CVE番号・対象製品・影響バージョン・CVSS・公表時期は、各出典の公式情報に基づきます。CVSS は NVD(NIST)の v3.1 基本値です(CVE-2023-4966 のみ Citrix 提供の v3.1 評価値 9.4。NVD の基本値は 7.5)。
出典・参考資料(8件)
ランサムウェア被害の侵入口になっている現実
これらの脆弱性が危険なのは、単に機器が乗っ取られるだけでなく、社内ネットワークへの侵入口として悪用される点にあります。認証を回避されて VPN を通過されると、そこを起点に内部へ侵入され、権限の奪取や横方向への移動を経て、ランサムウェアの展開やデータの持ち出しにつながります。
この危険は統計にも表れています。警察庁の調査では、2024年(令和6年)中に報告されたランサムウェア被害のうち、感染経路が特定できた有効回答100件中55件(55.0%)が VPN 機器からの侵入でした。リモートデスクトップからの31件(31.0%)を上回り、VPN 機器が最も多い侵入口となっています。
脆弱性を抱えた SSL-VPN が、現実に侵入の起点になっていることがうかがえます。
出典・参考資料(1件)
Ivanti Connect Secure の2つの脆弱性(CVE-2023-46805 と CVE-2024-21887)は、認証回避とコマンドインジェクションを組み合わせることで、認証なしに任意のコマンドを実行できる状態を生みました。この2つは実際に悪用されています。認証情報が外部で売買されるケースもあり、脆弱性を放置した機器が侵害の起点になりやすいことがうかがえます。
ランサムウェアは SSL-VPN に限らず、メールや持ち込み端末などさまざまな経路から侵入します。侵入口をふさぐだけでなく、予防・バックアップ・感染時の対応まで含めて自社の備えを体系的に見直したい方は、次の記事もあわせてご覧ください。
今すぐやるべき当面の対策(優先度順の手順)
ここからは、SSL-VPN を使い続ける前提で、今すぐ取るべき当面の対策を優先度の高い順に整理します。いずれも特定の製品に限らず当てはまる内容です。取引先の大企業からセキュリティ対応を求められている下請け・協力会社の立場でも、まず押さえるべき基本となります。

1. 修正プログラム(パッチ)の運用を整える
最優先は、公開された修正プログラムを速やかに適用することです。まず今日できることとして、自社が使っている機器の製品名とバージョンを確認し、ベンダーから新しい修正プログラムが出ていないか・自社が未適用のまま放置していないかを確かめましょう。脆弱性が公表されると、攻撃側は未対応の機器を探し始めます。IPA も CVE-2022-42475 への対策として、固定版への更新を第一に挙げています。
その場しのぎの更新で終わらせず、次の流れを運用として回せるようにしておくと、次の脆弱性にも対応しやすくなります。
- 情報収集: ベンダーのセキュリティ情報や JPCERT/CC・IPA の注意喚起を定期的に確認し、自社機器に関わる脆弱性を把握する
- 対象の特定: 影響を受けるバージョンに自社の機器が該当するかを確認する
- 検証と適用: 深刻度(CVSS)に応じて適用期限を決め、可能な範囲で動作を確認してから適用する
- 記録: 適用した日時・バージョンを記録し、対応状況を追えるようにする
2. 多要素認証・証明書認証を導入する
ID とパスワードだけの認証は、認証情報が漏れると容易に突破されます。近年の脆弱性には認証を回避するものが目立ち、万一認証情報が流出しても、もう一段の確認で侵入を防げる仕組みが重要です。そこで、多要素認証や、許可した端末だけに接続を限定する証明書認証(デバイス証明書)の導入が有効です。NSA・CISA も、リモートアクセス VPN の要塞化策としてクライアント証明書による認証を推奨しています。
ただし、認証そのものを回避してしまう脆弱性(認証バイパス)には多要素認証だけでは対抗できず、修正プログラムの適用が前提になる点には注意が必要です。
あわせて、漏えいした認証情報の棚卸しも欠かせません。脆弱性の種類によっては、修正プログラムを適用する前に ID・パスワードや証明書が外部に抜き取られていることがあり、SSL-VPN 機器の認証情報が窃取・転売される例も確認されています。こうして盗まれた認証情報は、パッチを適用して脆弱性をふさいだ後も有効なままで、正規の認証情報を使った侵入までは防げません。
そのため、パッチ適用とあわせて、VPN 利用者のパスワードや証明書、ローカル管理者アカウントなどを棚卸しし、漏えいの可能性があるものは失効・再発行しておきましょう。
出典・参考資料(1件)
多要素認証は、SMS・認証アプリ・生体認証・物理キーなど方式によって安全性が大きく変わり、二段階認証との違いも混同されがちです。仕組みや認証の3要素、方式ごとの選び方を基礎から確認したい場合は、次の記事が参考になります。
3. ログを確認し、異常を検知できるようにする
すでに侵害を受けていないかを確認することも、当面の対策に含まれます。IPA は推奨対応として、機器のログに悪用を示す記録がないか、不審なファイルが置かれていないか、不審な通信先への接続がないかを調べるよう示しています。あわせて、大量のログイン失敗や不審な時間帯のアクセスなどを継続的に監視し、異常に気づける状態にしておくと、侵入の兆候を早期に捉えられます。
確認のときは、ログが古いものから上書きされて消える前に保全しておくことが大切です。点検は直近だけでなく、対象の脆弱性が公表された時期までさかのぼって行います。また、ベンダーが機器の改ざんや侵害の有無を調べる専用ツールを提供している場合は、それを使って点検すると確実です。
4. 不要な機能を無効化し、公開範囲を絞る
攻撃を受ける面は、小さいほど安全です。使っていない機能や、外部に公開する必要のない管理インターフェースは無効化し、接続元を必要な範囲に限定します。IPA は CVE-2022-42475 の暫定的な回避策として、修正が間に合わない場合に SSL-VPN 機能そのものを無効化する選択肢も示しています。
具体的には、管理画面(管理インターフェース)をインターネットに公開しない、接続元をあらかじめ許可した IP アドレスの範囲に限定する、使っていないポータルや機能を停止する、といった設定を見直します。
5. 自社に当てはめる対策チェックリスト(優先度順)
何から着手すればよいか迷う場合は、次の各項目に自社が「できている/いない」で答えてみてください。上から優先度の高い順に並べているので、「いいえ」が付いた項目のうち最も上のものから着手すると、迷わず進められます。
- 使っている SSL-VPN 機器の製品名とバージョンを把握しているか
- 最新の修正プログラムが適用されているか/未適用なら適用予定を決めているか
- ベンダーや JPCERT/CC・IPA の脆弱性情報を定期的に確認する担当・仕組みがあるか
- VPN 接続と管理画面に多要素認証(または証明書認証)を設定しているか
- 漏えいの可能性がある認証情報(VPN 利用者のパスワード・証明書・ローカル管理者アカウント)を棚卸しし、失効・再発行したか
- ログを保全し、異常なアクセスに気づける状態になっているか
- 不要な機能を無効化し、接続元・公開範囲を絞っているか
出典・参考資料(2件)
一括ダウンロードする
このまま使い続けるか、移行すべきか
当面の対策を講じたうえで、多くの担当者が次に迷うのが「SSL-VPN を使い続けてよいのか」という判断です。ここでは、外部の事実(公的機関の推奨とベンダーの動き)を確認したうえで、自社の判断軸と移行先の違いを整理します。移行が常に正解とも、使い続けて問題ないとも断定せず、判断材料を示します。
公的機関が示す推奨(NSA・CISA・NIST)
米国の NSA・CISA は、リモートアクセス VPN に関する共同の情報シート(2021年9月公表)で、可能であれば VPN を IKE/IPsec で構成し、SSL/TLS VPN の機能とフォールバックを無効化することを推奨しています。標準化された方式を優先するという考え方です。
NIST も、ガイド文書「SP 800-77 Rev.1」で IPsec を「IP ネットワーク上の通信を保護するためのオープンな標準に基づくフレームワーク」と位置づけています。
これらは「SSL-VPN は直ちに危険だから全廃せよ」という趣旨ではなく、長期的には標準化された方式(IPsec)やゼロトラストへ軸足を移すことを促すものと読めます。
出典・参考資料(2件)
Fortinetの廃止スケジュール
ベンダー側の動きとして代表的なのが Fortinet です。FortiOS 7.6.3 以降では、SSL-VPN の「トンネルモード」が IPsec VPN に置き換えられ、GUI・CLI から利用できなくなりました。公式のリリースノートには次のように記載されています。
SSL VPN tunnel mode replaced with IPsec VPN. Starting in FortiOS 7.6.3, the SSL VPN tunnel mode feature is replaced with IPsec VPN, SSL VPN tunnel mode is no longer available in the GUI and CLI.
出典:FortiOS 7.6.3 Release Notes|Fortinet Document Library
ここで削除されたのは SSL-VPN の「トンネルモード」であり、ブラウザから使う Web モード(Agentless VPN)は継続します。SSL-VPN の全機能が一度になくなるわけではなく、段階的な移行措置である点に注意が必要です。
Fortinet は、トンネルモードの廃止に伴う IPsec VPN への移行を完了させる目安を2027年5月上旬としています。また、広く使われている FortiOS 7.4 系は、セキュリティパッチを含むサポートの終了(EOS)が2028年11月11日に設定されています。
出典・参考資料(2件)
使い続けてよい条件と、移行を考えるサイン
これらの事実を踏まえ、自社が今すぐ移行すべきか、当面は使い続けられるかを判断する目安を整理します。次の条件を満たせているうちは、適切に運用しながら使い続ける選択肢もあります。

- ベンダーのサポートと修正プログラムの提供が継続している
- 公開された脆弱性に速やかにパッチを適用できる体制がある
- 多要素認証・ログ監視など、当面の対策を講じられている
一方で、次のようなサインが見られる場合は、移行の検討を本格化させるタイミングです。
- 使っている機器やバージョンがサポート終了(EOS)を迎える、または近づいている
- パッチ適用が追いつかず、脆弱性が公表されても対応に時間がかかっている
- ベンダーが当該機能の廃止・縮小方針を示している
移行先の違い(IPsec・ZTNA・SASE)
移行を検討する場合、主な選択肢は次の3つです。どれが向くかは、拠点間の常時接続が中心か、クラウドやリモート利用が多いか、ネットワークとセキュリティをまとめて見直したいかで変わります。
- IPsec VPN: 標準化された方式に基づく VPN で、公的機関が推奨する移行先です。拠点間の常時接続が中心の企業に向きます。一方で設定はやや複雑で、リモートの個人端末を多数つなぐ用途では運用負荷が上がりやすい面があります。
- ZTNA(ゼロトラストネットワークアクセス): 「社内ネットワークに入れる」のではなく、ユーザーと端末を検証したうえで必要なアプリケーションにだけ最小権限でアクセスさせる考え方です。クラウドや SaaS の利用が多く、リモートワーク主体の企業に向き、侵入後の横移動を抑えやすいのが特徴です。
- SASE(Secure Access Service Edge): ネットワークとセキュリティの機能をクラウドから統合提供する枠組みで、ZTNA を含みます。拠点・リモート・クラウド利用をまとめて見直したい企業に向きますが、対象範囲が広い分、段階的な移行計画が必要になります。
脆弱性対応を仕組みで支える選択肢
ここまで見てきた当面の対策は、人手の運用だけで回そうとすると負担が大きく、専任のセキュリティ人材がいない企業では続けにくい面があります。移行を見据える場合でも、移行が完了するまでは当面の対策が欠かせません。そこで、脆弱性の発見・アクセスの制御・侵入後の検知といった当面の対策を、仕組みで肩代わりするサービスを紹介します。
ここで取り上げるのは当面の対策を支えるサービスで、IPsec・ZTNA・SASE といった移行先そのものの比較ではありません。移行先を含めた全体像は、社内セキュリティソリューションの比較記事もあわせてご覧ください。
| サービス名 | CloudGate UNO | Network Blackbox | KATABAMI |
|---|---|---|---|
| 提供会社 | 株式会社インターナショナルシステムリサーチ | 株式会社クワッドマイナージャパン | 株式会社SYNCHRO |
| 脆弱性対応で担う役割 | アクセス制御・多要素認証の強化 (入口の認証を固める) | 侵入後の通信の検知・事後調査 (NDR) | 継続的な脆弱性診断+復旧・補償 |
| アクセス制御・多要素認証 | ◎ | × | × |
| 侵入後の通信検知・事後調査 | × | ◎ | × |
| 継続的な脆弱性診断 | × | × | ◎ |
| 対応する主な対策 | 多要素認証・証明書認証の導入 | ログ確認・異常検知 | 脆弱性の継続的な把握 (パッチ運用の前提) |
| 初期費用 | 要問い合わせ | 要問い合わせ | 要問い合わせ |
| 月額費用 | 400〜600円/ユーザー(税抜) | 要問い合わせ | 1台1,250円/月〜 |
| 詳細情報 | 公式資料を見る | 公式資料を見る | オンライン相談を予約 |
※料金は2026年11月時点の各社公式情報に基づきます。プラン・課金単位により異なるため、最新の条件は各社の公式情報をご確認ください。
1. CloudGate UNO(株式会社インターナショナルシステムリサーチ)

CloudGate UNO は、ISR(インターナショナルシステムリサーチ)が自社開発するクラウド型の ID 基盤(IDaaS)です。シングルサインオン(SSO)に加え、多要素認証やパスキー(FIDO2)によるパスワードレス認証、IP アドレスや端末によるアクセス制限を提供します。公式では「ゼロトラスト時代の認証・アクセス制御」を担うプラットフォームと位置づけています。
SSL-VPN の対策で課題になりがちな「ID・パスワードだけの認証からの脱却」を担うサービスです。クライアント証明書・デバイス証明書による端末制限も提供し、許可した端末だけにアクセスを限定できます。多要素認証の強化という当面の対策から、ZTNA を見据えたアクセス制御の見直しまで、同じ基盤で扱えます。
ただし、VPN 機器側のログインに多要素認証を組み合わせられるかは、機器が SAML や RADIUS 連携に対応しているかなど構成によります。導入時に自社環境との連携可否を確認しておくと安心です。
一口に多要素認証といっても、方式によって攻撃への強さは異なります。この点について、開発元の ISR はインタビューで次のように説明しています。

当社が採用しているパスキーのパスワードレス認証は、フィッシング攻撃に対して非常に強い耐性を持ちます。SMS認証やワンタイムパスワードなどの一般的な多要素認証を突破する攻撃手法が顕在化する中、より安全な認証環境を提供します。
2. Network Blackbox(株式会社クワッドマイナージャパン)

ネットワークを流れる全パケットを収集・分析し、脅威を検知・対応する NDR(Network Detection and Response)製品が Network Blackbox です。フルパケットキャプチャを基盤に、収集・検知・ハンティング・フォレンジック・対応の5つの機能を1つの製品で提供します。
SSL-VPN の脆弱性が悪用され、万一侵入を許した場合でも、通信そのものを記録しているため、内部での不審な動きや横方向への移動を検知し、事後にパケット単位で経路をたどる調査(フォレンジック)が可能です。「ログ確認と異常検知」を仕組みで支える選択肢として、侵入後の可視化に強みがあります。
3. KATABAMI サイバーセキュリティ対策パッケージ(株式会社SYNCHRO)

KATABAMI は、サイバー攻撃対策を「予防・復旧・補償」の3本柱で提供するパッケージ型サービスです。予防にあたる脆弱性診断では、ネットワーク内部から毎月(年12回)脆弱性を検出し、改善策を定期的に提示します。
ネットワーク内部の機器を継続的に見張り、脆弱性の把握を仕組み化したい場合に役立つサービスです。診断は内部から行うため、外部に公開した SSL-VPN 機器そのものをどこまで対象にできるかは構成によりますが、社内機器を毎月点検し続ける運用を省力化できます。
公式サイトでは「設置10分」「最短2週間で利用開始」といった短期間・省工数での導入のしやすさが訴求されており、専任のセキュリティ担当者を置けない企業でも、脆弱性の発見と改善提案を仕組みとして回しやすい設計です。
あわせて、データのバックアップによる復旧と、サイバー保険による補償も組み合わせられます。
そもそも、ネットワーク内部の脆弱性診断が「継続的に」行いにくかった背景について、提供元の SYNCHRO はインタビューで従来型の診断の実情をこう語っています。

このようなオフィス内の脆弱性を調べるために、従来はお客様先まで足を運び、中に入って席を借りて調査する必要がありました。専門家が2人で出向いて期間中拘束されるため、どうしてもコストが高くなり、頻繁にはお願いしづらいのが実情です。結果として、年に1回程度の実施が一般的でした。一方で、新しい脆弱性は日々生まれており、生成AIの登場でそのスピードもさらに上がっています。
ここで取り上げた3つは、SSL-VPN の脆弱性対応に関わる代表的なサービスですが、社内セキュリティの打ち手は端末・ネットワーク・ID・データ・監視運用と幅広くあります。守る対象ごとにどんなタイプのサービスがあるかをまとめて見比べ、自社に足りない対策から検討したい方は、次の記事をご覧ください。
社内セキュリティソリューション比較|守る対象別のタイプ・代表サービスと選び方
社内のセキュリティを強化したいものの、端末の保護から不正アクセス対策、情報漏えいの防止まで課題が広く、何から手をつければよいか判断がつかないという声は少なくありません。テレワークやクラウド利用が定着し、社外に持ち出される端末やIDが増えたこ…
まとめ
SSL-VPN に脆弱性が多いのは、インターネットに公開される入口であること、ベンダーごとの独自実装、大規模ライブラリへの依存、機能の1台集約という構造上の理由によるものです。運用の問題というより、製品の性質に根ざした課題だと捉えるのが出発点になります。
まず取り組むべきは、修正プログラムの運用・多要素認証・ログ確認・不要機能の無効化という当面の対策です。そのうえで、ベンダーのサポート状況やパッチ適用の体制を見ながら、使い続けるか、IPsec・ZTNA・SASE へ移行するかを判断します。公的機関の推奨やベンダーの廃止方針は、どちらかに決めつけるためではなく、自社の状況に照らして判断するための材料として活用してください。
これらの対策を人手だけで続けるのが難しい場合は、継続的な脆弱性診断・アクセス制御の強化・侵入後の通信検知といった仕組みで支える選択肢もあります。自社の体制に合わせて、無理なく続けられる形を検討してみてください。
一括ダウンロードする
よくある質問(FAQ)
Q. SSL-VPNとは何ですか?
A. SSL-VPNとは、SSL/TLS という暗号化技術を使って、社外から社内のネットワークやアプリケーションへ安全に接続できるようにするリモートアクセスの仕組みです。ブラウザや専用クライアントから手軽に使えるため、テレワークの普及とともに広く導入されました。
一方で、インターネット側に公開される入口であり、認証・暗号化・ポータルを1台に集約する構造から攻撃の標的になりやすく、脆弱性が繰り返し報告されています。
Q. SSL-VPNは脆弱性があっても使い続けて大丈夫ですか?
A. SSL-VPNは、ベンダーのサポートと修正プログラムの提供が続いており、脆弱性の公表後すぐにパッチを適用できる体制と、多要素認証・ログ監視を整えられているなら、適切に運用しながら使い続ける選択肢もあります。「脆弱性があるから即廃止」と決めつける必要はありません。
ただし、使っている機器やバージョンがサポート終了(EOS)に近づいている、パッチ適用が追いつかない、ベンダーが当該機能の廃止・縮小方針を示しているといったサインが見られる場合は、移行の検討を本格化させるタイミングです。
Q. 自社のSSL-VPN機器が脆弱性の対象かどうか、どう確認すればよいですか?
A. 自社のSSL-VPN機器が対象かは、まず使っている製品名とバージョンを把握し、ベンダーのセキュリティ情報や JPCERT/CC・IPA の注意喚起で公表された「影響を受けるバージョン」と照らし合わせることで確認できます。CVE 番号や CVSS の深刻度もあわせて確認し、該当する場合は深刻度に応じて適用期限を決めて修正プログラムを当てます。
あわせて、機器のログに悪用を示す記録がないか、見覚えのないファイルが置かれていないか、不審な通信先への接続がないかも調べ、すでに侵害を受けていないかを確認しておくと安心です。
Q. SSL-VPNとIPsec VPNではどちらが安全ですか?
A. SSL-VPNとIPsec VPNのどちらが安全かは一概に優劣をつけられませんが、公的機関はより標準化された方式である IPsec を推奨しており、長期的な移行先として位置づけられています。NSA・CISA はリモートアクセス VPN を IKE/IPsec で構成し、SSL/TLS VPN の機能を無効化することを推奨し、NIST も IPsec をオープンな標準として位置づけています。
ただし IPsec は設定がやや複雑になりがちで、用途によっては ZTNA(ゼロトラストネットワークアクセス)や SASE のほうが適する場合もあります。安全性だけでなく、自社の規模・用途・運用体制に合わせて選ぶことが大切です。
Q. SSL-VPNに多要素認証を導入すれば、脆弱性があっても安全ですか?
A. SSL-VPNに多要素認証を入れても、それだけで脆弱性のリスクがなくなるわけではありません。多要素認証は、認証情報が漏れても侵入されにくくする有効な対策です。ただし、認証そのものを回避する脆弱性や、遠隔から任意のコードを実行される脆弱性は、修正プログラムの適用でしか根本的にはふさげません。多要素認証・ログ監視・不要機能の無効化といった対策は、パッチ運用と組み合わせて初めて効果を発揮します。
Q. 専任のセキュリティ担当者がいない中小企業は、SSL-VPNの脆弱性対策を何から始めればよいですか?
A. 専任担当者がいない企業でも、まずは使っているSSL-VPN機器の製品名とバージョンを把握して最新の修正プログラムを適用し、VPN接続と管理画面に多要素認証を設定することから始めるのが現実的です。これらは優先度が高く、特別な人員がいなくても着手できる基本の対策です。
これらを人手だけで継続するのが難しい場合は、継続的な脆弱性診断・アクセス制御の強化・侵入後の通信検知といった仕組みで支えるサービスを組み合わせる方法もあります。自社の体制に合わせて、無理なく続けられる形を選ぶとよいでしょう。
社内セキュリティソリューションの料金・資料を一括チェック
MCB FinTechカタログでは、脆弱性診断・アクセス制御・ネットワーク監視など、社内セキュリティに関わるサービスの最新資料を無料で一括請求できます。機能・料金・サポート体制を見比べて、自社に合うサービスを効率よく選べます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか?
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。

マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。


















