大量の認証情報が攻撃者に ～FortiBleedから考えるVPN依存のリスク～
投稿者：山本仁一
こんにちは、セキュリティエバンジェリストの山本です。
ネットワーク境界デバイスを狙う大規模侵害「FortiBleed」が世界を震撼させています。本記事では、この事象の技術的背景にある「認証情報と運用の負債」を紐解き、2027年5月のSSL-VPN終了の節目を見据えた、SASE/ZTNAへの現実的な移行アプローチを解説します。
目次
1. FortiBleedとは何か？
1.1. 大規模に報告されたVPN機器の認証情報露出
独立系セキュリティリサーチャーであるVolodymyr “Bob” Diachenko氏の発信を皮切りに発見されたこの大規模キャンペーンは、各種脅威インテリジェンス機関によって「FortiBleed」と命名されました。
複数の脅威インテリジェンス企業やセキュリティリサーチャーから報告されている影響規模には差がありますが、shodanで確認可能な全公開デバイスの約50%になる約7万台から7万5,000台規模Fortinet機器が対象になった可能性が指摘されています(CyberAngelより)。また、影響範囲は特定の国や業種に限定されず、グローバルに広がっているようです。
ここまでの大規模侵害をどうやって許したのかというメカニズムについて説明しますと、３つの主要要因が複合的に絡んでいることがわかりました。
まずFortinetは2025年初頭に、管理者パスワードの保存方法を解読が容易な「Salt付きSHA-256」から、より計算量が多く強固な「PBKDF2」アルゴリズムへと移行するセキュリティ強化を実施しました。しかし、ファームウェアをアップグレードしただけでは、既存のパスワードハッシュは自動的にPBKDF2に変換されず、「アップグレード後に当該管理者がシステムに一度ログインする」必要がありました。このアクションを怠った、あるいは使用頻度の低い管理者アカウントのパスワードは、構成ファイル内のold-passwordフィールド等に古いSHA-256形式のまま残存し続けました。
また攻撃者は、過去のVPNの脆弱性（CVE-2018-13379等）や構成ファイルのエクスポート機能の悪用、あるいはエンドポイントで感染したInfostealerから、FortiGateなどの構成ファイルやSSL-VPNの認証ハッシュを大量に入手し、GPUクラスターを使用して大規模に認証情報を復元したと報じられています(CyberAngelより)。
こうやってクラックした認証情報を用いつつ、攻撃者はブルートフォースやパスワードスプレー攻撃により大量のデバイスを侵害します。さらに侵害したデバイスは次に監視拠点として利用します。つまりSSL-VPNトラフィックを監視して、通過する追加の認証情報を収集します。収集されたパスワードは、さらに多くのデバイスを侵害するためにスキャナーにフィードバックされ、自己増殖的に機能し続けます。
つまりFortiBleedは、単なる局所的なインシデントではなく、インターネットに公開されたリモートアクセス基盤を狙う大規模な脅威として受け止めるべき事象です。
1.2. 漏えい件数を押し上げた「認証情報」と「運用負債」
FortiBleedの最大の脅威は前述のとおり、「新しいゼロデイ脆弱性が発見され、それだけで一気に侵害が広がった」という単純な話ではありません。
現時点の公開情報を見る限り、FortiBleedの中心にあるのは、過去に窃取された認証情報、情報窃取マルウェアによって漏えいしたID・パスワード、古い設定ファイルに残された認証情報などが複合的に悪用された可能性があり、単一の脆弱性だけで説明できる事象ではなく、VPN運用の中に蓄積された「認証情報の負債」や「設定の負債」が、漏えい件数を押し上げた要因となっています。
多くの企業では、VPN装置は一度導入されると、長期間にわたり使い続けられると思われます。その間に、管理者が異動したり、外部委託先向けのアカウントが残ったり、過去に作成された接続設定やバックアップファイルが十分に管理されないまま残ったりすることがあります。
こうした一つひとつは、日常運用の中では見過ごされがちな小さな問題です。しかし、それらが積み重なると攻撃者にとっては価値の高い侵入材料になることが今回明らかになりました。
特に、VPN装置の設定ファイルには、ユーザー情報、接続ポリシー、ネットワーク構成、認証方式など、攻撃者が社内侵入の準備に利用できる情報が含まれる場合があります。仮に装置そのものを最新化していても、過去の設定情報や古い認証情報がどこかに残っていれば、それが攻撃の足がかりになるのが今回の侵害で明らかになりました。
この意味で、FortiBleedは「いま存在している脆弱性」だけでなく、「過去から持ち越された運用負債」が現在のリスクとして表面化した事象といえます。
2. SSL-VPN依存のリスク
2.1. インターネットに公開される境界デバイスという宿命
今回の大規模侵害であるFortiBleedは、その名称からFortinet社の製品固有の問題と受け止める方もいるかもしれません。前述の通り局所的なインシデントではないことはお伝えしましたが、もっというと、近年の攻撃者がFortinet製品に限らず、Ivanti Connect Secure、SonicWall、CiscoなどのVPN、ファイアウォール、リモートアクセス装置、ルーターといった、企業ネットワークの境界に置かれた機器を集中的に狙っているという点を忘れてはなりません。
SSL-VPNは、社外のユーザーがインターネット経由で社内システムにアクセスするための仕組みです。利便性が高く、多くの企業で導入されてきました。
一方で、その仕組み上、SSL-VPN装置はインターネットから接続を受け付ける必要があります。この「インターネット上に見える」という特性は、非常に大きなリスクです。実際、攻撃者は世界中のIPアドレスを継続的にスキャンし、どの企業がどのVPN装置を利用しているか、どのバージョンを使っているか、既知の脆弱性が残っていないかを調査しています。
こういった装置に脆弱性が公開されると、攻撃者は短時間で探索と攻撃を自動化します。防御側がパッチ適用や設定変更を進める前に、攻撃者が先にスキャンし、侵害を試みるケースも珍しくありません。
これは、インターネットに公開された境界デバイスが持つ宿命的なリスクです。VPNを適切に運用するためには、教科書的には、パッチ適用、MFA、アクセス制限、ログ監視、アカウント棚卸しなどが重要な作業です。しかし、外部に公開され、つねに攻撃者にチェックされているこれらをすべて継続的に、かつ漏れなく実施し続けることが運用負荷になることは容易に想像できます。
2.2. 正規認証情報を悪用されると検知が難しい
さらに、FortiBleedのように攻撃者が正規の認証情報を入手しログインしてくると、ログインそのものは正規の認証として記録される可能性があります。過去に漏えいしたID・パスワード、情報窃取マルウェアで盗まれた認証情報、退職者や委託先の不要アカウントなどが悪用されると、攻撃者は「侵入した」のではなく、「ログインした」ように見える点が、セキュリティ監視として課題となってきます。
もちろん、接続元IPアドレス、時間帯、国・地域、端末情報、ログイン後の操作内容などを詳細に分析すれば、不審な兆候を検知できる可能性はあります。それには、他のデバイスから例えば認証ログ、エンドポイントログ、ネットワークログ、クラウドサービスログなどさまざまなログを横断的に分析する仕組みが必要です。この領域にはSIEMやSOAR、EDR/XDR、近年ではITDRという言葉も出てきましたが、ID基盤との重要な連携ログ管理分析機能が必要になります。
2.3. VPNは侵入後の横展開の起点になり得る
VPNのもう一つの大きな課題は、認証後のアクセス範囲です。従来型のVPNでは、ユーザーが一度認証されると、ネットワークの一部または広範なセグメントへアクセスできる設計になっていることがあります。このような環境で攻撃者がVPN認証情報を悪用して社内へ入った場合、次に狙うのは横展開です。Active Directory環境の探索、ファイルサーバーや業務サーバーへのアクセス、追加の認証情報の窃取などを通じて、より深い権限や重要情報へ到達しようとします。
つまり、VPNは単なるリモートアクセス手段ではなく、攻撃者にとっては社内ネットワークへ踏み込むための起点になり得るのです。
この課題の背景にあるのは、「入口で認証した後は、一定範囲を信頼する」という考え方です。この考え方は、かつての社内ネットワーク中心の時代には合理的でした。しかし、クラウド利用、リモートワーク、委託先接続、グローバル拠点連携が当たり前になった現在では、ネットワークの内側だから安全とは言い切れません。
これが、数年前から提唱されてきたゼロトラストの考え方が求められる背景です。ゼロトラストでは、「一度認証されたから信頼する」のではなく、ユーザー、デバイス、アクセス先、場所、時間、リスク状態などを継続的に確認し、必要最小限のアクセスだけを許可する、という概念です。
3. なぜ今、VPN撤廃を検討すべきなのか
3.1. VPNを”より強く守る”発想の限界
これまで多くの企業は、VPNを前提としてリモートアクセス環境を構築してきました。VPN装置を導入し、利用者を登録し、認証を強化し、必要に応じてMFAやアクセス制御を追加する。これは、長年にわたり現実的な選択肢でした。しかし前述したように、VPN装置をより強く守る発想には限界があることが明らかになってきました。
繰り返しますが、VPN装置はインターネット上に公開され、攻撃者から常に観測される状況下で、脆弱性が公表されれば短時間で狙われ、認証情報が漏えいすれば正規ログインとして悪用される可能性があります。さらに、管理者アカウントや設定ファイルの管理に不備があれば、過去の運用負債が現在の侵入口になります。
とはいえ、現在利用中のVPNを今すぐすべて停止できる企業は多くはないと思います。業務システム、レガシーアプリケーション、委託先接続、拠点間通信など、VPNに依存している業務は数多く存在します。
これからの時代で重要なのは、VPNを前提とした防御を続けるのではなく、VPN依存を段階的に減らす方針を持つことです。VPNを守る努力は必要ですが、それと同時に、VPNを使わなくても安全に業務アプリケーションへアクセスできる設計へ移行する必要があります。
3.2. FortiGate SSL-VPN終了の流れと企業への影響
VPN撤廃を検討すべき理由は、製品ライフサイクルの観点からも発生しています。
Fortinet社は、FortiGateにおけるSSL-VPNからの移行を進めています。公開情報では、FortiOSのバージョンによってSSL-VPN機能の扱いが変わっており、2027年5月という１つの節目が設定されており、今後のバージョンやサポート期限を踏まえると、従来のSSL-VPNをそのまま使い続ける前提で長期計画を立てることは難しくなっています。
さらにサポート終了や機能変更は、単なる技術部門の課題ではなく、在宅勤務、保守作業、外部委託先との連携、海外拠点からの接続など、企業活動そのものを支える基盤となっている環境では、移行計画が遅れれば、セキュリティリスクだけでなく、業務継続、監査対応、委託先管理、インシデント発生時の説明責任にも影響します。
特に、2027年5月という節目を意識すると、いまから移行対象を棚卸しし、代替方式を検討し、PoCや段階導入を進める必要があります。リモートアクセス基盤の刷新は、数週間で完了するものではありません。利用者、接続先システム、認証方式、端末管理、運用体制、サポート窓口まで含めて設計し直す必要があります。
3.3. 境界型防御からゼロトラストへの転換
VPN撤廃を考えるうえで避けて通れないのが、境界型防御からゼロトラストへの発想転換です。
従来の境界型防御は、社内と社外の境界を明確に分け、社外から社内へ入る入口を制御する考え方でした。この考え方は、社内システムがデータセンターに集約され、ユーザーも社内ネットワークからアクセスする時代には有効でした。しかし現在は、業務システムがクラウドやSaaSに分散し、ユーザーは自宅、外出先、海外拠点、委託先などからアクセスします。端末も会社支給PCだけでなく、モバイル端末や仮想デスクトップなど多様化しています。もはや「社内ネットワークの内側だから安全」と考えることはできません。
前出のゼロトラストは、この前提を見直す考え方です。 ”すべてを疑う”という極端な意味で捉えると、仕組みも大掛かりになりそうで、そのような仕組みへの移行は大掛かりに感じてしまいますが、アクセスのたびにユーザー、デバイス、接続先、リスク状態を確認し、必要最小限の権限だけを与えること、これがゼロトラストの基本です。
VPN中心の設計では、一度接続した後のアクセス範囲が広くなりがちです。一方、ゼロトラストネットワークアーキテクチャ（ZTNA）やそれらを実現する概念であるセキュアアクセスサービスエッジ（SASE）を活用すれば、ネットワーク全体ではなく、業務アプリケーション単位でアクセスを制御できます。この概念は、侵害された場合の影響範囲を小さくするという点でも非常に有用です。
3.4.全廃ではなく、段階的な縮小・置き換えから始める
リモートアクセス環境をゼロトラストへ切り替える際に、もう一つ重要な点としては、すべてのVPNを一気に廃止するのではなく、段階的に置き換えから始める点です。
多くの企業では、VPNが複数の業務に深く組み込まれています。基幹システムへの接続、保守ベンダーからのアクセス、海外拠点との通信、緊急時の管理接続など、簡単には置き換えられない用途もあります。
そのため、最初にVPNの利用実態を可視化することをおすすめします。どのユーザーが、どの端末から、どのアプリケーションへ、どの頻度でアクセスしているのかを把握し、移行しやすい業務から順に置き換えていくことが現実的です。
たとえば、WebアプリケーションやSaaSへのアクセスはZTNAやSASEへ移行しやすい領域です。一方、特殊なプロトコルを使う業務システムや、拠点間接続に近い用途は、別途設計が必要になる場合があります。
以上のように、VPNを残すか廃止するかという二択で考えずに、事業影響を抑えながらVPN依存度を下げ、最終的に外部公開面と認証情報リスクを縮小していく。この段階的な移行こそが、現実的なVPN撤廃の進め方です。
4. SASE/ZTNAへの移行で何が変わるのか
4.1. ネットワーク単位ではなくアプリケーション単位で守る
SASEやZTNAへの移行によって最も大きく変わるのは、アクセス制御の単位です。
従来型のVPNでは、前述したようにユーザーがVPNに接続すると、多くの環境ではネットワークの一部に入る形になります。一方、ZTNAでは、ユーザーをネットワークに入れるのではなく、認可されたアプリケーションにだけ接続させるという考え方を取ります。たとえば、営業部門のユーザーには営業支援システムと販売管理システムのみ許可し、技術営業のユーザーには、営業支援システムと開発・検証環境にアクセスさせる、しかし販売管理システムにはアクセスさせない、といった形です。
これは、万が一アカウントが侵害された場合の被害範囲を小さくするうえで重要です。攻撃者が認証情報を入手しても、アクセスできるアプリケーションが限定されていれば、横展開の余地を抑えられます。
VPNが「社内ネットワークへの入口」を提供する仕組みだとすれば、ZTNAは「必要なアプリケーションへの最小限の通路」を提供する仕組みです。この違いは、セキュリティ運用において非常に大きな意味を持ちます。
4.2. アイデンティティとデバイス状態を継続的に確認する
もう１つ、SASE/ZTNAの大きな特徴は、アイデンティティとデバイス状態を継続的に確認する点です。従来型のVPNでは、ログイン時の認証が重視されます。一度接続が確立されると、そのセッション中は一定の信頼が継続する設計になっていることが多くあります。
一方、ゼロトラストの考え方では、ユーザーが誰か、端末が管理対象か、セキュリティパッチが適用されているか、EDRが稼働しているか、通常とは異なる場所からアクセスしていないかといった状態を確認しながら、アクセス可否を判断することが可能になります。
たとえば、同じユーザーであっても、会社管理端末からのアクセスと、未知の端末からのアクセスでは扱いを変えるべきです。また、通常は日本からアクセスしているユーザーが、短時間のうちに海外から接続しているように見える場合には、追加認証やブロックを検討すべきです。
このように、SASE/ZTNAでは、ID、端末、場所、時間、リスク状態を組み合わせて判断できるのが、認証情報だけでアクセス制御を行うVPN中心の設計との大きな違いです。
5. まとめ：VPNを守る時代からVPNに依存しない時代へ
FortiBleedは、インターネット境界に位置する認証情報における最大規模の露出事案として大きく注目されています。しかし本質は、インターネットに公開されたVPN装置が、認証情報、設定情報、過去の運用負債と結びついたとき、企業ネットワークへの強力な侵入口になり得る。これこそが、FortiBleedから学ぶべき最大の教訓です。
いま企業に求められているのは、VPNを“より強く守る”ことだけではなく、VPNに依存しないリモートアクセス設計へ段階的に移行することです。SASEやZTNAは、そのための現実的な選択肢です。そのため、FortiGate SSL-VPNをご利用中の企業では、今後のサポートや機能変更の流れを踏まえ、移行計画を早めに検討する必要があります。2027年5月という節目を見据えると、現状把握、対象業務の分類、PoC、段階導入、運用設計までを逆算して進めることが重要です。
セキュリティは「コスト」ではなく「事業継続のための投資」です。
まずは、自社がどの業務でVPNに依存しているのか、どの接続をSASE/ZTNAへ移行できるのか、そしてサポート終了までにどの順番で対応すべきかを整理するところから始めてみてはいかがでしょうか。
そのような企業に向けて、移行検討のポイントをまとめたガイドをご用意しています。具体的な確認項目や移行の進め方を把握したい方は、以下のバナーから詳細をご確認ください。
