こんにちは、株式会社TIMEWELLの濱本です。2026年9月11日、デジタル庁は、同庁が運用する政府共通の業務環境「ガバメントソリューションサービス（GSS）」への不正アクセスにより、各府省庁の職員等の個人情報約24.6万件が漏えいした可能性があると公表しました1。侵入経路として示されたのは、ネットワーク接続機器、つまりVPN機器の脆弱性です。しかもその脆弱性は攻撃前に公表されていた既知のもので、当初の深刻度評価はCVSSで「中」だったとされています2。
この記事は、デジタル庁の落ち度を数え上げるためのものではありません。同庁は同日中にQ&Aを公開し、脆弱性が既知だったこと、深刻度が「中」だったこと、修正プログラムの適用前に悪用されたことを自ら明かしています。都合の悪い事実を含めて公表した姿勢は、私は率直に評価しています。ただ、この事案には、日本のあらゆる法人にそのまま当てはまる構造上の問題が含まれています。深刻度の点数順に脆弱性を直していく運用が、なぜ間に合わなかったのか。ゼロトラストを掲げたシステムが、なぜVPN機器の穴から破られたのか。そして自社は明日から何を変えればよいのか。この3点を、公表された事実と公的な統計だけを材料に考えていきます。
なお、悪用された脆弱性の具体的な内容、機器のベンダー名、攻撃者については公表されていません。その空白を憶測で埋めることはしません。
何が起きたのか。公表された事実を時系列で整理する
まず事実関係を、デジタル庁の報道発表とQ&Aに沿って並べます12。
起点は2026年6月25日です。保守運用担当者のアカウントを使って、サーバ上の大量のファイルへアクセスが行われたことを検知し、調査が始まりました。ここでの検知の主語が「保守運用担当者のアカウント」である点は、後で立ち返ります。7月9日、第三者がVPN機器の脆弱性を利用してシステムに侵入していたことが判明し、同日中に当該アカウントの停止と、侵害された機器と外部との通信遮断が行われました。その後、外部の専門事業者とともに調査を進め、個人情報が外部へ漏えいした可能性を確認して、9月11日の公表に至っています。検知から公表までは78日、侵入経路の特定から公表までは64日です。
漏えいした可能性がある情報は約24.6万件で、内訳はGSSを利用する府省庁等の職員と、その業務に携わった公務員等（独立行政法人の職員を含む）が約18.9万件、業務に携わった事業者と個人が約5.7万件です。属性は重複を含めて、氏名が約23.6万件、メールアドレスが約23.1万件、電話番号が約9.4万件、住所が約0.1万件。Q&Aによれば、電話番号や住所の多くは個人のものではなく、庁舎の所在地や公務用の連絡先が大半とのことでした。マイナンバー、金融機関の口座情報、年金番号は含まれておらず、一般の国民の個人情報も含まれていません。9月11日時点で、なりすましメールなどの二次被害は確認されていないとされています2。
GSSがどういうものかも押さえておきましょう。デジタル庁の説明では、GSSは「政府共通の標準的な業務実施環境（業務用PCやネットワーク環境）を提供するサービス」で、ゼロトラストアーキテクチャに基づくネットワークへ各府省庁を統合していく計画の中核です3。2025年2月時点で13機関、接続ユーザー4.2万人が利用しており4、2026年7月の重点政策一覧では、令和12年度末までに利用者を27万人以上へ広げる目標が掲げられています5。国家公務員の業務端末とネットワークの土台になりつつあるシステムだと理解すれば、影響の重さが分かります。
公表までの78日については、Q&Aで「検知当初の段階では、不正アクセスの有無や影響範囲が判明しておらず、侵入経路の分析や漏えいした可能性のある情報の特定、対象者の確認などに相当の時間を要した」と説明されています2。この説明は、フォレンジック調査の実務を知っている人ほど納得しやすいものです。一方で、対象者から見れば、フィッシングに悪用されうるメールアドレスと氏名が2か月半のあいだ手元から離れていたことになります。個人情報保護法は行政機関等にも委員会への報告を義務づけており、民間では速報が概ね3〜5日、確報が30日または60日という目安があります6。委員会への報告と一般への公表は別の判断ですが、「公表は事実確認が終わってから」という設計が、対象者の自衛の機会をどこまで奪うのか。この点は、自社の公表方針を考える際の論点として持ち帰りたいところです。自社の初動や公表判断が組織として整っているかを項目で確かめたい方は、AIリテラシー診断のような棚卸しから入るのも一つの方法です。
「中」の脆弱性が突かれた。深刻度の点数順に直す運用の限界
この事案の核心は、Q&Aの次の一節にあります。「今回の事案で悪用された脆弱性は、当初公表されていた脆弱性評価においては、中（CVSS値 Mediumレベル）のものでした」。そして「公表された際の脆弱性の深刻度評価に応じた一般的対応よりも早く対処を進めました。結果として、修正プログラムの適用前に当該脆弱性が悪用される事態となった」2。大臣会見でも、緊急度の高い他の脆弱性から順に対応している最中に悪用された、と説明されています7。
つまりデジタル庁は、脆弱性を放置していたわけではありません。深刻度に応じて優先順位をつけ、一般的な目安より早いペースで処理していました。それでも間に合わなかったのです。ここに、多くの法人が同じ構造で抱えている問題があります。CVSS（共通脆弱性評価システム）は、その脆弱性が悪用されたときにどれだけ深刻かを評価する指標であって、実際に攻撃者がそれを使うかどうかを予測する指標ではありません。攻撃者は点数が高い脆弱性から順に攻めるわけではなく、「いま自分が持っている攻撃コードで、いま届く機器に効く脆弱性」を使います。深刻度「中」でも、攻撃コードが出回り、インターネットに露出したVPN機器に効くなら、それは攻撃者にとって最優先の入口です。
この考え方を制度にしたのが、米国CISAの拘束的運用指令BOD 22-01です。CISAは「実際の攻撃で使われることのないかもしれない何千もの脆弱性に各機関が注力するのではなく、能動的な脅威となっている脆弱性へ焦点を移す」と説明し、悪用が確認された脆弱性のカタログ（KEV）に載ったものは、2021年以降のCVEであれば2週間以内に修正することを連邦機関に義務づけました8。点数ではなく「悪用されているか」で期限を切る発想です。私はこれが、今回の事案から法人が持ち帰るべき最大の教訓だと考えています。
ただし、現実の修正スピードは逆方向に動いています。Verizonの2026年版データ侵害調査報告書（DBIR）によると、脆弱性の悪用は侵害の初期侵入経路の31%を占め、前年の20%から伸びて、初めて認証情報の悪用を抜いて首位になりました。悪用が確認された脆弱性を修正するまでの中央値は43日で、前年の32日から2週間近く延び、完全に修正できた割合は26%と前年の38%から下がっています9。一方、JPCERT/CCのアナリストは、ゼロデイ攻撃が発覚して脆弱性が公表されると、間を置かずに広範囲なNデイ攻撃が始まると指摘しています10。攻撃側は公表から数日で動き、守る側は中央値で43日かかります。この差の中に、今回のGSSも落ちました。
正直なところ、「うちは深刻度が高いものから順に、月次のメンテナンス枠で当てています」という運用は、数年前まで模範解答でした。しかしインターネットに露出した機器については、その順番の付け方自体を変える必要があります。点数が「中」であっても、悪用が確認されているか、攻撃コードが公開されているか、そしてその機器が外から見えているか。この3つが揃ったら、深刻度に関係なく最上位に上げます。デジタル庁がQ&Aで「実質的なリスクに基づいて、一層迅速かつ先行的な対応を行う」と述べているのは2、まさにこの転換のことです。
AIセキュリティ研修を、本気で
OWASP・NIST・ISO 42001・経産省ガイドライン全準拠の2日間集中講座。経営層と現場で分けて受講できます。
VPN機器は「守りの箱」から「いちばん狙われる入口」になった
今回の侵入口がVPN機器だったことは、偶然ではありません。数字を見れば、むしろ典型例です。
警察庁が公表した「令和7年におけるサイバー空間をめぐる脅威の情勢等について」によると、2025年のランサムウェア被害報告は226件で、感染経路について有効回答があった92件のうち61件、66.3%がVPN機器からの侵入でした。リモートデスクトップが19件で続き、不審メールはわずか2件です。過去5年の累計でも485件中293件がVPN機器で、6割を超えています11。同報告書は、攻撃者は「未修正のぜい弱性、漏えいした認証情報や簡易なパスワード、設定不備等を悪用して組織のネットワークへ侵入する」と整理しています。かつて主流だった標的型メールは、いまや脇役です。
海外の統計も同じ方向を示します。Verizonの2025年版DBIRでは、脆弱性の悪用による侵害のうちエッジデバイスとVPNが標的となった割合は22%で、前年の3%から約8倍に跳ね上がりました。しかも、それらの脆弱性を年内に完全修正できた組織は約54%にとどまり、修正までの中央値は32日でした12。
なぜVPN機器がこれほど狙われるのか。JPCERT/CCがInternet Week 2025で示した分析が、実務者の目線で分かりやすく説明しています10。第一に、ファイアウォールやSSL-VPN機器、ロードバランサーといったエッジデバイスは、インターネットに直接面しているのに、EDRのようなホスト型の監視製品を入れられないことが多く、監視が弱いという点です。第二に、侵害されると認証情報が窃取されやすく、多要素認証まで突破される恐れがあります。エッジデバイスの侵害が、高権限アカウントの認証情報窃取につながった事例もあると同資料は述べています。第三に、パッチを当てる前に窃取された認証情報や設置されたバックドアは、後から別の攻撃グループに融通されて悪用されうるという点。だから「パッチを当てたから終わり」とはいかず、パッチ適用時点ですでに侵害されていないかを調べるところまでが一区切りになります。JPCERT/CCは2025年だけで、Ivanti、Fortinet、SonicWall、Citrix、Cisco、WatchGuardなど、エッジデバイス関連の注意喚起とCyberNewsFlashを11件出しています10。
ここで一つ、はっきり言っておきたいことがあります。VPNは「安全にする道具」として導入されます。しかし攻撃者から見ると、VPN機器は「社内ネットワークへの正規の入口が、認証さえ通れば開く場所」であり、そこに脆弱性があれば認証すら要りません。守りの箱だったものが、いちばん割りやすいガラスになっているのです。この認識の転換が、法人のIT部門と経営層の両方に必要だと私は考えています。
ゼロトラストを採用していたのに、なぜ破られたのか
GSSは、ゼロトラストアーキテクチャを採用したシステムとして整備されてきました3。だからこそ「ゼロトラストなのに、なぜ」という疑問が出るのは自然です。Q&Aでもこの問いが立てられ、「ゼロトラストアーキテクチャを採用しておりましたが、結果として不正アクセス及び情報漏えいの可能性が生じたことを重く受け止めております」と答えられています2。大臣会見では「ゼロトラストであってもどこかに穴が開いている可能性がある」という言葉もありました7。
この問いに答えるには、ゼロトラストとは何かに戻る必要があります。デジタル庁自身が2022年に定めた「ゼロトラストアーキテクチャ適用方針」（DS-210）は、ゼロトラストを「境界の内部が侵害されることも想定したうえで、情報システムおよびサービスの要求ごとに適切かつ必要最小の権限でのアクセス制御を行う」概念と定義し、「特定の実装やソリューションを指すものではない」と明記しています。さらに、ゼロトラストアーキテクチャは「境界型セキュリティとネットワークベースのセキュリティ対策を否定するものではない」とも書かれています13。
つまり、ゼロトラストを採用したからといってVPN機器が消えるわけではありません。むしろ多くの組織では、VPN機器やそれに相当するゲートウェイが、ゼロトラストの入口として残ります。そしてその機器そのものに脆弱性があれば、アクセス制御のルールを評価する以前の段階で侵入されてしまいます。ゼロトラストは「入った後に自由に動かせない」ための設計であって、「入口の箱に穴がない」ことを保証する設計ではないのです。ゼロトラストという言葉に安心を求めてきた組織ほど、この区別を曖昧にしたまま進んでいないでしょうか。
もう一つ、見落としてはいけない点。検知の起点となったのが「保守運用担当者のアカウントを利用した大量のファイルアクセス」だったことです1。攻撃者はVPN機器の脆弱性から入り、その後、保守運用の権限を持つアカウントを使って動いていたと読めます。Q&Aによると、VPN機器はGSSの一部としてデジタル庁が責任を持って管理し、「場合によっては外部事業者に委託して」運用されています2。エッジデバイスの侵害が高権限アカウントの認証情報窃取につながるというJPCERT/CCの指摘10と、まさに重なる構図です。
ここは公平に書きます。大量のファイルアクセスという異常を検知できたこと自体は、GSSの監視が機能した証拠です。この検知がなければ、漏えいの範囲も、そもそも侵入されていた事実も、もっと長く把握されなかったかもしれません。同時に、保守運用という「業務上、大量のファイルに触れても不自然ではない」権限が奪われると、検知がどれだけ難しくなるかも示しています。デジタル庁の2026年7月の重点政策一覧には、端末管理やヘルプデスクなど定型的な運用業務の外部委託拡充を令和8年度に検討する方針が書かれています5。運用を外に出すこと自体は現実的な選択ですが、そのときに保守運用アカウントの権限をどう最小化し、どう監視するかは、今回の事案が突きつけた宿題だと私は受け取っています。
法人が今週から変えられること。点数ではなく「露出」と「悪用」で動く
ここからは自社の話です。デジタル庁と同じ構造の穴は、規模の大小を問わず、VPN機器やファイアウォールを外に向けて置いているすべての法人にあります。私が優先順位の高いと考える順に並べます。
最初にやるべきなのは、インターネットに露出している資産の棚卸し。VPN、ファイアウォール、ロードバランサー、リモートデスクトップのゲートウェイ、そして忘れられがちな拠点の小型ルーター。これらの機器名、ファームウェアの版、管理画面がどこから見えるか、誰が保守しているかを一枚の表にします。JPCERT/CCの資料が「組織内に対策漏れのホストが生じないよう注意が必要」と締めているのは10、実際にサポート切れの旧版が攻撃された事例があったからです。表にない機器は守れません。
次に、エッジデバイスだけは、脆弱性対応の期限を別枠で決めます。社内サーバの月次パッチと同じ枠に入れないことが肝心です。私が実務で推す基準は明快で、「悪用が確認された、または攻撃コードが公開された脆弱性は、CVSSの点数に関係なく、インターネットに露出した機器では原則72時間以内に修正または代替策を完了する」というものです。CISAが連邦機関に2週間を課しているのは8あくまで上限であり、Nデイ攻撃が公表直後に始まる現実10を踏まえれば、露出した機器についてはもっと短くすべきでしょう。JPCERT/CCの注意喚起、ベンダーのアドバイザリ、CISAのKEVカタログ。この3つの購読を、担当者個人のメールではなく組織の当番制に載せてください。
三つ目は、修正が間に合わないときの代替策を、あらかじめ決めておくことです。パッチ適用に検証やベンダー調整が要るなら、その間に管理画面をインターネットから見えなくする、使っていないSSL-VPNのWebモードや不要なポータル機能を止める、接続元を業務上必要な国や拠点のアドレスに絞る、といった手を先に打ちます。「パッチが出るまで何もできない」という状態を作らないこと。それが期限を守る現実的な方法でしょう。
四つ目は、保守運用アカウントの扱い。今回の事案が示したとおり、攻撃者はいったん入った後、大量のファイルに触れても不自然でない権限を探します。保守用の高権限アカウントは常時有効にせず、作業のたびに期限付きで払い出す。委託先の担当者ごとにアカウントを分け、共有IDをなくす。そして「保守アカウントが通常の作業時間外に大量のファイルへアクセスした」といった振る舞いを検知の条件に入れます。GSSがこの検知で事案を把握できたことは、同じ仕組みが自社でも機能するという裏返しでもあります。
五つ目は、ログを機器の外に出しておくことです。JPCERT/CCは、エッジデバイスのログが機器内部にしか保存されておらず、攻撃者に消されて調査ができなかった事例を挙げています10。ログを外部のログ基盤へ転送しておくだけで、侵害の有無を確かめられるかどうかが変わります。そしてパッチを当てた後には、「その前に入られていないか」を確認する手順を組み込んでください。パッチ適用前に窃取された認証情報は、パッチでは無効になりません。当てたら認証情報も変えます。この一手間が、二度目の侵入を防ぎます。
こうした設計と運用の話は、技術者だけで完結しません。予算の優先順位、委託契約の条項、公表の判断は経営の仕事です。当社が提供しているWARP SECURITYでは、攻撃手法の解説よりも、こうした平時の設計と意思決定に時間を割いています。以前にさくらインターネットの不正アクセスから法人が持ち帰るべき点を整理した記事でも書きましたが、事業者やシステムが破られる前提で、自社に残る責任と手順を先に決めておくことが、結局いちばん効きます。組織的な管理体制を認証の形で整えたい場合は、ISMS（ISO/IEC 27001）の入門記事も参考にしてください。
まとめ。「中」でも狙われる。だから順番の付け方を変える
今回の事案を一文にすると、「既知で深刻度『中』のVPN脆弱性が、深刻度順の対応が届く前に突かれ、保守運用アカウントを経由して約24.6万件の個人情報が漏えいした可能性がある」となります。デジタル庁は事実を含めて公表し、脆弱性管理を「実質的なリスクに基づいて迅速かつ先行的に」見直すと述べています2。この方向は正しいと私は思います。そして同じ見直しは、国よりもむしろ、専任のセキュリティ担当がいない法人にこそ必要です。
持ち帰っていただきたいのは次の点です。CVSSの点数は「悪用されたらどれだけ痛いか」であって「悪用されるか」ではないこと。インターネットに露出したVPN機器は、警察庁の統計で6割超の侵入口になっている、いちばん狙われる箱であること。ゼロトラストは入った後の被害を抑える設計であり、入口の箱の穴を塞ぐのは別の仕事であること。そして、パッチは当てるだけでなく、当てる前に入られていないかを確かめて初めて終わること。
まずは今週、自社で外から見えている機器を一枚の表にすることから始めてみてください。それだけで、次の注意喚起が出たときに「うちは該当するのか」を数分で判断できるようになります。エッジデバイスの期限設計や保守アカウントの管理、経営層を巻き込んだ公表方針づくりについて相談したい方は、個別相談からお声がけください。状況を伺ったうえで、一緒に優先順位を考えます。
参考
本記事の事実関係は、以下の公表資料に基づいています。悪用された脆弱性の詳細、機器のベンダー、攻撃者は2026年9月11日時点で公表されていません。
Footnotes
-
ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について — デジタル庁 — 2026年9月11日 ↩ ↩2 ↩3
-
「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A — デジタル庁 — 2026年9月11日 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
ガバメントソリューションサービス（GSS）について（政策評価・行政事業レビュー有識者会議資料） — デジタル庁 — 2024年5月29日 ↩ ↩2
-
重点政策一覧（１－１ GSSへの移行、１－２ GSSにおけるセキュリティの高度化と耐災害性の強化） — デジタル庁 — 2026年7月21日 ↩ ↩2
-
松本デジタル相、24.6万件漏えい可能性について説明 「既知の脆弱性を対応前に悪用」（報道・補助的参照。会見要旨はデジタル庁に後日掲載予定） — ITmedia NEWS — 2026年9月11日 ↩ ↩2
-
BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities — CISA — 2021年11月3日 ↩ ↩2
-
2026 Data Breach Investigations Report — Verizon（数値の補助的参照: Verizon DBIR: Vulnerability exploitation is the dominant initial access vector — Help Net Security — 2026年5月20日） ↩
-
狙われ続けるエッジデバイス ～JPCERT/CC目線で見たサイバー攻撃～ — JPCERTコーディネーションセンター 久下達也（Internet Week 2025講演資料、JPNIC掲載） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
ゼロトラストアーキテクチャ適用方針（標準ガイドライン群ID DS-210） — デジタル庁 — 2022年6月30日 ↩
