はじめに――政府共通基盤GSSで何が起きたのか
2026年9月11日、デジタル庁は、同庁が運用する政府共通の業務実施環境「GSS（Government Solution Service）」に対する不正アクセスについて、調査結果を公表しました。
GSSは、各府省庁の職員が利用するネットワークや業務環境を共通化し、政府全体のデジタル基盤を支える重要なシステムです。
今回の事案では、GSSを利用する行政機関の職員などに関する情報を中心に、約24万6,000件の個人情報が外部へ流出した可能性があるとされています。
ただし、今回の事件で私が最も注目したのは、流出した可能性のある情報の件数ではありません。
デジタル庁が公表した、二つの事実です。
一つは、攻撃者がネットワーク接続機器（VPN）の脆弱性を悪用してGSSへ侵入したこと。
そしてもう一つは、「保守運用担当者のアカウント」が利用されていたことです。
デジタル庁によれば、6月25日、保守運用担当者のアカウントを利用した大量のファイルアクセスが検知されています。
その後の調査によって、7月9日、第三者がネットワーク接続機器（VPN）の脆弱性を悪用してシステムへ侵入し、不正アクセスを行っていたことが判明したとしています。
さらに松本尚デジタル大臣は9月11日の記者会見で、攻撃に悪用されたVPNの脆弱性について、事件発生以前から把握していた「既知の脆弱性」であったことを明らかにしました。
デジタル庁は、その脆弱性を把握していました。
しかし、他の脆弱性との優先順位を判断する中で対応前の状態にあり、その間に攻撃者によって悪用されたとしています。
ここまでが、現時点でデジタル庁から明らかにされている事件の大きな輪郭です。
しかし、この説明を時系列に並べてみると、一つの大きな空白が存在することに気付きます。
VPNの脆弱性を悪用した侵入
と、
保守運用担当者のアカウントを利用した大量のファイルアクセス
の間です。
攻撃者は、VPNを突破した後、どのようにして保守運用担当者のアカウントを利用できる状態になったのでしょうか？
VPNへの侵入後に、そのアカウントの認証情報を窃取したのでしょうか。
それとも、攻撃者はVPNを突破する以前から、何らかの方法で保守運用担当者の認証情報、あるいは認証に必要となる別の情報を取得していたのでしょうか。
現時点で、その答えは公表されていません。
そして、この「空白」こそが、今回のGSS侵害事件の全容を理解するための重要な鍵になるのではないかと私は考えています。
GSSは「VPNを突破すれば終わり」のシステムなのか
もう一つ、この事件を考えるうえで無視できないものがあります。
GSSがゼロトラストの考え方を取り入れて構築された政府共通基盤であることです。
従来型の境界防御では、「VPNによって内部ネットワークへ入った利用者」を一定程度信頼する設計が存在しました。
しかし、ゼロトラストの基本的な考え方は異なります。
ネットワークの内側にいるという理由だけで利用者や端末を信用せず、アクセスしようとする主体のIdentity（アイデンティティ）、端末、権限、アクセス対象などを確認しながら、必要なアクセスだけを許可します。
したがって、GSSのゼロトラストが設計どおり機能していたのであれば、
VPNを突破した＝GSS内部を自由に移動できるとは考えにくいのです。
VPNという第一の境界を突破した先には、さらに認証・認可という壁が存在していたはずです。
ところが今回、攻撃者はその先で「保守運用担当者のアカウント」を利用しています。
ここに、私は強い違和感を覚えました。
攻撃者はVPNを突破した後、ゼロトラスト環境の中で保守運用担当者の認証情報を探し出し、それを窃取したのでしょうか？
もちろん技術的な可能性として否定することはできません。
しかし、それだけで説明してよいのでしょうか。
むしろ攻撃者がVPNへの侵入とは別に、事前の偵察や他の侵害活動によって、保守運用担当者に紐づく認証情報や認証手段をあらかじめ取得していた可能性についても検討する必要があると考えます。
ここから先は、デジタル庁が現時点で公表していない領域へ入ります。
本記事では「事実」と「推察」を分けて考える
ここで、本記事の調査方針を明確にしておきたいと思います。
今回のGSS侵害について、デジタル庁から公表されている情報は、事件の全容を再現できるほど詳細なものではありません。
VPN製品の名称は公表されていません。
悪用された具体的な脆弱性も公表されていません。
「保守運用担当者のアカウント」が、どの組織に所属する担当者のものだったのかも明らかになっていません。
その認証情報を攻撃者がいつ、どこで、どのような方法によって入手したのかも分かっていません。
したがって、現時点で事件の全容を断定することはできません。
一方で、何も分からないわけでもありません。
デジタル庁が公表した情報だけでなく、GSSに関する政府調達資料、システム構成に関する公開資料、運用・保守契約、過去に世界各地で発生したVPN機器への攻撃事例などを組み合わせることで、考えられる攻撃経路を絞り込むことはできます。
そこで本記事では、
【確認済み】
デジタル庁、政府機関、調達資料、関係機関などの公開情報によって確認できる事項。
【分析・推察】
確認済みの事実と技術資料、過去の攻撃事例などを組み合わせ、ネット探検ラボが合理的と考える仮説。
【未確認】
現時点では公開情報による裏付けがなく、今後の情報開示や追加調査を待つ必要がある事項。
この三つを可能な限り区別しながら、事件を追っていきます。
現時点でデジタル庁の情報開示そのものを批判することはしない
今回の公表内容について、「情報が足りない」と感じる部分があることは事実です。
しかし、本記事では現時点で、そのこと自体をデジタル庁への批判材料とはしません。
重大なサイバーインシデントでは、攻撃経路の特定、ログ解析、端末やサーバーのフォレンジック、認証情報の利用状況、関係事業者への調査など、多くの確認作業が必要になります。
調査途中の段階で、十分な裏付けのない企業名や侵害経路を公表することが適切とは限りません。
特に今回、「保守運用担当者のアカウント」が利用されたことが確認されている以上、そのアカウントの管理主体や認証情報の取得経路についても、当然ながら重要な調査対象になっていると考えられます。
ただし、これはネット探検ラボによる推察です。
デジタル庁が現在、委託事業者や再委託事業者への侵害可能性を調査していると確認されたわけではありません。
だからこそ、現時点では結論を急ぎません。
新しい情報が公表されれば、それまで推察として扱っていた部分を改めて検証します。
裏付けられた仮説は「確認済み」へ移します。
否定された仮説は棄却します。
そして、新しい事実によって別の可能性が浮上すれば、改めて事件像を書き換えます。
本記事の目的は、限られた情報から犯人や責任主体を決めつけることではありません。
公開された事実を一つずつ積み上げながら、「今回のGSS侵害で実際に何が起きたのか」を追い続けることです。
まず次に、デジタル庁が公表した情報を時系列に並べてみたいと思います。
すると、今回の事件で「分かっていること」と「まだ分かっていないこと」の境界が、よりはっきりと見えてきます。
まず、確認された事実を時系列に並べてみる
ここから、今回の事件をもう少し細かく見ていきます。
2026年6月25日、デジタル庁は「保守運用担当者のアカウント」を利用した、サーバー上の大量のファイルへのアクセスを検知しました。
この時点でデジタル庁が直接観測したのは、VPNへの侵入そのものではありません。
保守運用担当者のアカウントによる異常なファイルアクセスでした。
その後、外部専門事業者の協力も得ながら調査を進め、7月9日になって、第三者がネットワーク接続機器（VPN）の脆弱性を利用してシステムへ侵入していたことが判明しました。
同日、問題となった保守運用担当者のアカウントを停止するとともに、侵害された機器と外部との通信を遮断しています。
さらに7月15日には個人情報保護委員会へ報告。その後も影響範囲や漏えいした可能性のある情報を調査し、9月11日に事件を公表しました。
ここで注意しなければならないことがあります。
「検知された順序」と「攻撃者が行動した順序」は同じとは限らないということです。
デジタル庁が最初に発見したのは保守運用担当者アカウントによる大量アクセスです。
VPNへの侵入は、その後の調査によって遡及的に確認されました。
したがって、
VPNを突破した
↓
その先で保守運用担当者アカウントを奪取した
↓
大量のファイルへアクセスした
という一連の攻撃経路まで、デジタル庁が公表したわけではありません。
現時点で確認できるのは、VPNの脆弱性が悪用されたこと
そして、
保守運用担当者のアカウントが利用されたことです。
この二つをつなぐ部分は、まだ公表されていません。
攻撃に使われたのは「既知の脆弱性」だった
今回、もう一つ重要な事実が明らかになっています。
悪用されたVPNの脆弱性は、攻撃が確認される以前から公表されていた「既知の脆弱性」でした。
デジタル庁によれば、当初公表されていた評価はCVSSで「Medium」でした。
デジタル庁も脆弱性を把握し、一般的な対応より早く対処を進めていたと説明しています。
しかし、結果として修正プログラムを適用する前に攻撃者に悪用されてしまいました。
ここで私は、単純に「パッチを当てるのが遅かった」と批判するつもりはありません。
脆弱性は日々大量に報告されます。
すべての脆弱性に対して、発表された瞬間に本番システムを停止してパッチを適用することは現実的ではありません。
問題は、その優先順位を何によって判断するかです。
インターネットに接続されたVPNは、組織内部へ入るための入口です。
しかも今回対象となったのは、政府共通基盤であるGSSです。
CVSSの数字だけではなく…
- 「その機器がどこに置かれているのか」
- 「侵害された場合、どこまで到達できるのか」
- 「どのような権限や情報へ接続しているのか」
という実際のシステム環境を含めてリスクを判断する必要があります。
興味深いことに、デジタル庁自身も今回の事件を受け、今後は「政府情報システムの重要性を考慮し、より実質的なリスクに基づいて迅速かつ先行的な対応」を行えるよう脆弱性管理を強化するとしています。
つまり今回の教訓は、「Mediumだったから仕方がなかった」で終わるものではありません。
VPNを突破したら、その先へ自由に進めるのか
ここで一度、VPNへの攻撃が何を意味するのかを整理しておきます。
VPNの脆弱性を利用して侵入に成功したからといって、攻撃者が組織内部のすべてのサーバーやファイルへ自由にアクセスできるようになるとは限りません。
分かりやすく建物に例えてみます。
VPNが建物へ入るための「玄関」だったとします。
攻撃者は玄関の鍵の欠陥を見つけ、建物の中へ入ることに成功しました。
しかし、建物の中にはさらに扉があります。
- 経理部の部屋
- 人事部の部屋
- サーバールーム
- 重要書類が保管された金庫
玄関を突破したからといって、これらの扉がすべて開くわけではありません。
コンピューターシステムも基本的には同じです。
別のサーバーへ接続しようとすれば、そのサーバーで利用できるアカウントが必要になる場合があります。
管理機能を利用しようとすれば、管理権限を持つアカウントが必要になります。
ファイルへアクセスしようとすれば、そのファイルを読む権限が必要になります。
つまり攻撃者にとってVPNの突破は、「入口を突破した」ことに過ぎない場合があります。
その先へ進むためには、「次の扉を開ける鍵」が必要になるのです。
だから攻撃者は「次の鍵」を探す
では、VPNを突破した攻撃者は何をするのでしょうか。
一つの重要な行動が、「この先へ進むために使える認証情報を探すこと」です。
- IDとパスワードだけとは限りません
- 認証済みのセッション
- Cookie
- 認証トークン
- 証明書
- サービスアカウント
- 管理者アカウント
こうした「正規利用者であることを証明するもの」が攻撃対象になります。
攻撃者がそれを入手すると、本来は職員やシステム管理者しか利用できない機能へ、正規利用者になりすましてアクセスできる場合があります。
ここで初めて「横展開」という言葉が登場します。
横展開とは、最初に侵害した機器を足掛かりとして、別の端末やサーバーへ侵害範囲を広げていくことです。
しかし、横展開も魔法のように自由に行えるわけではありません。
別のシステムへ移るたびに、「そこへアクセスする権限を持っているか」が問題になります。
だからこそ、認証情報の奪取が重要になるのです。
実際のVPN攻撃でも「認証情報」が狙われている
実例を一つだけ見てみます。
2023年末から2024年にかけて、Ivanti Connect SecureというVPN製品に対する大規模な攻撃が確認されました。
攻撃者はVPN機器の脆弱性を利用して侵入しました。
しかし、そこで終わってはいません。
セキュリティ企業Volexityの調査では、攻撃者は侵害したVPN機器を足掛かりに内部を調査し、さらに認証情報を窃取して別のシステムへ侵害範囲を広げていました。
非常に単純化すると…
VPNの脆弱性を利用する
↓
VPNという入口を突破する
↓
内部へ到達する
↓
その先へ進むための認証情報を探す
↓
取得した正規の認証情報を利用する
↓
別のサーバーや端末へ進む
…という流れです。
つまり、VPNを突破したから横展開できたのではありません。
より正確には、VPNを突破して「次の鍵を探せる場所」へ到達し、その鍵を取得することで、さらに先へ進んだと考えた方が分かりやすいでしょう。
では、今回のGSSでは「次の鍵」は何だったのか
ここまで理解すると、今回デジタル庁が公表した一つの情報が非常に重要に見えてきます。
「保守運用担当者のアカウント」です。
今回確認されている事実を、先ほどの建物の例に当てはめてみます。
攻撃者はVPNの脆弱性を利用しました。
つまり、「玄関」を突破しました。
しかし、その先へ進むには別の認証が必要だった可能性があります。
そして実際に、攻撃者による大量のファイルアクセスで利用されていたのが、
保守運用担当者のアカウントでした。
ここで初めて、今回の事件で追うべき問いがはっきりします。
攻撃者は、この「次の鍵」をどこで手に入れたのか？という点です。
VPNを突破した後に、保守アカウントを奪ったのか
まず考えられるのは、先ほど紹介したIvantiの事例と同じような攻撃です。
VPNを突破
↓
認証情報を探索
↓
保守運用担当者の認証情報を発見・窃取
↓
そのアカウントを利用
↓
サーバーへアクセス
技術的には考えられる経路です。
しかし、今回のGSSでは、ここで一つ大きな条件を考えなければなりません。
GSSはゼロトラストを採用したシステムだったということです。
ゼロトラストなら、「玄関を突破した人」を信用しない
先ほどの建物の例をもう少しだけ続けます。
従来型のシステムでは、「玄関を正しく通った人なのだから、建物内部ではある程度信用しよう」という考え方がありました。
ゼロトラストは違います。
玄関を通過していても信用しません。
別の部屋へ入ろうとすれば…
- 「あなたは誰ですか」
- 「その部屋へ入る権限がありますか」
- 「いつも使っている端末ですか」
といった確認を繰り返します。
つまり、VPNという玄関を突破したことと、その先のシステムから認証されたことは別問題です。
ここが今回のGSS侵害を考えるうえで極めて重要です。
そこで生じる一つの疑問
もしGSSのゼロトラストが想定どおり機能していたのであれば、VPNを突破しただけでは、その先にあるシステムへのアクセス権限まで得たことにはなりません。
その状態で、保守運用担当者の認証情報をどこから取得したのか。
という疑問が生じます。
もちろん、VPN機器を侵害した後、その機器や到達可能になった領域から、認証情報、認証済みセッション、トークンなどを窃取した可能性はあります。
その場合には、VPN突破後に保守アカウントを取得したという説明が成立します。
しかし、もう一つ考えなければならない可能性があると考えています。
「次の鍵」は、玄関を突破する前から持っていたのではないか
攻撃者がVPNを攻撃する以前に、保守運用担当者に紐づく認証情報をすでに取得していたという可能性です。
ここからは【分析・推察】になります。
もし攻撃者が事前にGSSについて偵察していたとすれば…
- GSSを誰が構築しているのか
- 誰が運用しているのか
- 誰がネットワーク機器を保守しているのか
- どの企業の技術者がGSSへ接続する必要があるのか
…こうした情報も調査対象になり得ます。
そして、保守事業者やその担当者側の端末などを別の方法で侵害できれば、GSSへ接続するためのIdentityを取得できる可能性があります。
ここでいうIdentityとは、単純なIDとパスワードだけではありません。
- MFAに関係する情報
- 認証トークン
- 証明書
- 認証済みセッション
- あるいは、正規の保守端末そのもの
…こうしたものまで含まれます。
仮に攻撃者がそれらを事前に取得していたのであれば、今回の攻撃は非常に違った姿に見えてきます。
攻撃者は「二つの鍵」を用意していたのか
一つ目は、VPNという入口を突破する鍵。
今回確認されている既知のVPN脆弱性です。
そして二つ目は、その先で正規利用者として認証される鍵。
今回利用された「保守運用担当者のアカウント」です。
つまり…
VPN脆弱性
＝ ネットワークへ到達するための鍵
保守Identity
＝ その先のシステムへアクセスするための鍵
という二段構えだった可能性があります。
もちろん、これはまだ確認された事実ではありません。
攻撃者がVPN侵害後に保守アカウントを取得した可能性も残っています。
だから現時点では、
仮説A：VPN突破後に保守Identityを取得した
仮説B：VPN突破以前に保守Identityを取得していた
仮説C：VPNと保守Identityを別々に攻略し、最後に組み合わせた
という複数の可能性を残しておく必要がありますが・・・。
一方で、GSSがゼロトラストを採用していたという条件を考慮すると、
「保守運用担当者のアカウントは、いつ、どこで攻撃者の手に渡ったのか」
という問いを避けて、今回の事件を理解することはできなくなります。
そして、この問いから次の調査対象が見えてきます。
そもそも、その「保守運用担当者」とは誰だったのか？ということです。
では、「保守運用担当者」とは誰だったのか
ここから、今回の事件のもう一つの核心へ入ります。
デジタル庁は、問題となったアカウントについて「保守運用担当者のアカウント」と公表しています。
しかし、その担当者がデジタル庁職員だったのか、GSSの運用・保守を受託する事業者の担当者だったのか、あるいは再委託先の担当者だったのかについては、現時点で明らかにしていません。
そこでGSSの調達資料を確認しました。
「令和7年度ガバメントソリューションサービスの運用一式」の契約相手方は、日本電気株式会社（NEC）です。
契約金額は231億1,666万2,386円。
さらにGSSでは、機器構築・保守についても別途大規模な調達が行われています。
そして重要なのは、その業務内容です。
GSSの運用に関する調達資料には、
「重大な脆弱性への対応等（NW機器の設定変更作業）」
まで業務として明記されています。
SOCサービスに関する資料を確認すると、脆弱性情報を収集し、危険性を評価して対策を検討する仕組みが存在し、パッチ適用やバージョンアップなどの実際の対処については、GSS運用・保守事業者側の責任範囲として整理されています。
もちろん、GSS全体の管理責任がデジタル庁から民間企業へ移るという意味ではありません。
デジタル庁側にも、判断基準の承認や必要な指示を行う役割があります。
しかし少なくとも、
GSSのネットワーク機器を専門的に運用・保守する実務に、外部事業者が深く関与する構造だった
ことは、公開された調達資料から確認できます。
保守アカウントも外部事業者のものだったのか
ここからは【分析・推察】です。
この運用体制を考えれば、今回利用された「保守運用担当者のアカウント」が、GSSの運用・保守を担う外部事業者側に付与されたものであった可能性は高いと考えています。
ただし、ここで、「NECのアカウントだった」と断定することはできません。
GSSの調達資料では再委託を前提とした管理項目も確認できます。
巨大な政府システムですから、ネットワーク、機器、監視、保守などを複数の専門事業者が分担していたとしても不思議ではありません。
だからこそ、今後確認したいのは単に「元請はどこか」ではありません。
問題となったVPN機器を、実際に誰が保守していたのか…です。
- 誰が機器を納入したのか
- 誰が設定したのか
- 誰が日常的に保守していたのか
- 誰がベンダーから脆弱性情報を受け取っていたのか
- 誰がGSSへの影響を評価したのか
- 誰がパッチ適用作業を担当することになっていたのか
そして、その作業を行う担当者にどのような保守アカウントが与えられていたのか。
この関係を一本につなぐ必要があります。
今回の事件には「二つの管理経路」がある
ここまで調べてくると、今回の事件には二つの重要な経路が見えてきます。
一つは、Identityの管理経路です。
- 誰に保守アカウントを発行したのか
- どの端末から利用できたのか
- どの程度の権限を持っていたのか
- MFAなどはどのように管理されていたのか
- そして攻撃者は、そのIdentityをどこで取得したのか
もう一つは、脆弱性情報の管理経路です。
- VPN製品の脆弱性を誰が把握したのか。
- 誰が危険性を評価したのか。
- 誰が対応順位を決めたのか。
- 誰がパッチを適用することになっていたのか。
この二つは、一見すると別の問題です。
しかし、今回の事件では同じ「運用・保守」という場所で交差している可能性があります。
攻撃者が利用したのは、保守運用担当者のアカウント。
攻撃者が入口として利用したのは、保守対象でもあるVPN機器の既知脆弱性。
この二つが偶然同時に登場しただけなのか。
それとも、GSSの運用・保守体制そのものを攻撃者が理解した上で狙った結果なのか。
ここは今後、慎重に確認する必要があります。
「Mediumだった」で終わらせてはいけない
もう一つ、今回の事件で重要なのが脆弱性情報の更新です。
デジタル庁は、今回悪用された脆弱性について、
「当初公表されていた脆弱性評価ではMediumだった」と説明しています。
注目したいのは「当初」という言葉です。
脆弱性の危険度は、最初に公表された評価のまま固定されるわけではありません。
- 新しい解析結果が出る
- 実際の攻撃が観測される
- 攻撃手法が広まる
- ベンダーが評価を変更する
- 各国の政府機関が緊急の注意喚起を出す
こうして脆弱性を取り巻く状況は変化していきます。
したがって本当に確認すべきなのは、「なぜMediumを後回しにしたのか」
だけではありません。
「Medium」から「High」へ――脆弱性情報は更新されていた
ここで、今回の事件を考えるうえで見逃せない問題があります。
デジタル庁は、悪用されたVPNの脆弱性について、当初公表されていた評価は「Medium」だったと説明しています。
しかし、脆弱性情報は最初に公表された内容のまま固定されるものではありません。
- 新たな解析結果が出る
- 実際の攻撃が確認される
- 攻撃手法が公開される
- ベンダーが危険度を変更する
- 各国の政府機関が緊急対応を求める
こうした情報が追加されれば、それまでの対応優先順位も見直さなければなりません。
そして今回、GSSで悪用された可能性がある脆弱性として、一つのCVEがセキュリティ関係者から注目されています。
Palo Alto NetworksのGlobalProtectに存在した認証回避の脆弱性、
CVE-2026-0257です。
ただし、最初に明確にしておきます。
デジタル庁は、今回悪用されたVPN製品やCVE番号を公表していません。
したがって、CVE-2026-0257が今回の侵入口だったと断定することはできません。
ここからは【分析・推察】として読んでください。
候補CVEでは、わずか16日間で状況が大きく変わった
CVE-2026-0257は、2026年5月13日にPalo Alto Networksから公表されました。
当初のCVSS v4スコアは、
4.7――Medium
でした。
ところが、その後の展開が重要です。
Rapid7によれば、少なくとも5月17日には実際の悪用が観測されています。
つまり、脆弱性の公開からわずか4日後には、
「理論上悪用できる脆弱性」から「現実に攻撃者が悪用している脆弱性」へ状況が変化していたことになります。
さらに5月29日、CVE-2026-0257は米国CISAのKnown Exploited Vulnerabilities（KEV）Catalogへ追加されました。
KEVは、単に危険そうな脆弱性を並べたリストではありません。
実際の悪用が確認された脆弱性を収録するものです。
そして同じ5月29日、Palo Alto Networksも脆弱性情報を更新。
CVSS v4スコアは、
4.7 Medium
↓
7.8 High
へ変更されました。
現在のPalo Alto Networksのアドバイザリでは、深刻度は「HIGH」、対応の緊急度は「HIGHEST」、Exploit Maturityは「ATTACKED」とされています。
つまり、この脆弱性については、
5月13日 公開――Medium（4.7）
↓
5月17日 実際の悪用を観測
↓
5月29日 CISA KEVへ追加
↓
5月29日 High（7.8）へ評価変更
という情報更新が起きていました。
問題は「最初にMediumだったこと」ではない
ここで、今回のGSS事件を見る視点が変わります。
仮に、今回悪用されたVPN脆弱性がCVE-2026-0257だったとすれば、
「Mediumの脆弱性だったため、より危険な脆弱性から優先して対応していた」
という初期判断だけを検証しても意味がありません。
5月17日には実悪用が観測されています。
5月29日にはKEVへ追加されています。
そして同日、ベンダー自身がHighへ評価を引き上げています。
ならば確認しなければならないのは、その更新情報をGSSの脆弱性管理側が、いつ把握したのか…です。
さらに、把握した時点で対応優先順位を変更したのか。
ここまで確認する必要があります。
脆弱性管理で重要なのは「情報を追い続けること」
脆弱性管理は…
「CVEが公開された」
↓
「CVSSは4.7だった」
↓
「Mediumとして登録した」
…で終了する仕事ではありません。むしろ、そこからが始まりです。
特にインターネットへ露出したVPNのような境界機器では、実悪用が始まったという情報は極めて重要です。
CVSSが何点なのかとは別に、「攻撃者がすでに使っている」という事実そのものが、リスクを大きく変化させます。
今回の候補CVEでは、その後さらにKEVへの追加とHighへの変更まで行われています。
それにもかかわらず、最初に取得した「Medium」という情報のまま対応順位が維持されていたのだとすれば、問題はパッチ作業が遅れたことだけではありません。
脆弱性情報を継続的に追跡し、変化した脅威をリスク評価へ反映する仕組みが機能していたのか
という、より根本的な問題になります。
だから確認したいのは「誰が更新情報を見ていたのか」
ここで、先ほど確認したGSSの運用・保守体制が再び重要になります。
GSSには、脆弱性情報を収集し、危険性を評価し、対策を検討し、パッチ適用などを実施する仕組みがありました。
では今回…
- 誰がベンダーの脆弱性情報を継続監視していたのか
- 誰が実悪用情報を確認する担当だったのか
- 誰がCISA KEVなどの外部脅威情報を確認していたのか
- 誰が評価変更をGSSのリスク評価へ反映する責任を持っていたのか
そして誰が…
「これはもうMediumとして扱うべき脆弱性ではない。緊急対応へ切り替えるべきだ」と判断する立場だったのでしょうか。
ここまで追って初めて、今回の脆弱性管理のどこに問題があったのかを評価できます。
そして、この時間軸は侵入時期とも重なる可能性がある
さらに重要なのが攻撃時期です。
今回のGSSへの侵入活動については、5月下旬から始まっていた可能性も報じられています。
仮にCVE-2026-0257が今回の脆弱性だった場合…
脆弱性公開
↓
実悪用確認
↓
評価更新
↓
攻撃者によるGSSへの侵入
…という出来事が、非常に短い期間に集中していた可能性があります。
これはまだ仮説です。
しかし、だからこそVPN製品とCVE番号の公表が重要になります。
それが明らかになれば…
- ベンダーがいつ警告したのか
- 世界でいつ攻撃が始まったのか
- GSS側がいつ把握したのか
- いつ対応を決めたのか
- そして攻撃者はいつ先に入ったのか
…これらを同じ時間軸上で検証できるからです。
今回の事件で問われるべきなのは、「Mediumの脆弱性への対応が遅れたのか」ではありません。
より正確には、「変化し続ける脅威情報を、政府共通基盤の防御判断へどれだけ速く反映できていたのか」だと考えます。
多層委託で考えるべきなのは「責任」だけではない
政府の巨大システムを民間事業者へ委託すること自体を問題視するつもりはありません。
高度な専門知識を必要とするシステムでは、むしろ専門企業の力を利用することは合理的です。
再委託についても同様です。
問題は、参加する組織が増えるほど、管理しなければならないTrust Boundary（信頼境界）が増えることです。
仮に…
デジタル庁
↓
元請事業者
↓
専門事業者
↓
機器保守事業者
↓
保守担当者
…という構造だったとします。
この場合、サイバーセキュリティ上確認しなければならないのは契約上の責任だけではありません。
- 誰にアカウントを発行するのか
- どこまで権限を与えるのか
- どの端末からアクセスできるのか
- 保守端末を誰が管理するのか
- 脆弱性情報を誰が受け取るのか
- 誰が再評価するのか
- 誰が緊急パッチ適用を決定できるのか
そして、一つの企業や端末が侵害された場合、どこまで影響が波及するのか。
こうした「信頼の連鎖」を管理する必要があります。
ゼロトラストを採用するのであれば、この考え方はGSS内部だけで終わらせるべきではありません。
GSSへ接続する運用・保守サプライチェーンまで含めて、Trustを検証する必要があります。
現時点で見えているもの、まだ見えていないもの
ここで今回の事件を、もう一度だけ整理します。
確認されていることがあります。
- VPNの既知脆弱性が悪用された。
- 保守運用担当者のアカウントが利用された。
- そのアカウントから大量のファイルへアクセスされた。
- 個人情報を含むファイルが外部へ漏えいした可能性がある。
一方、まだ見えていない部分があります。
- 攻撃者が保守Identityをいつ、どこで取得したのか。
- VPNを突破した後、どのようにGSSの認証・認可を通過したのか。
- 保守アカウントが誰に付与されていたのか。
- 実際にVPNを保守していた事業者は誰だったのか。
- 既知脆弱性に関する更新情報が、どこまで把握・再評価されていたのか。
私は、この見えていない部分にこそ、今回の事件から得るべき重要な教訓が隠れていると考えています。
デジタル庁の続報を待つ
なお、本記事では現時点でデジタル庁の情報開示そのものを強く批判することはしません。
デジタル庁は現在も調査を継続しており、セキュリティ対策上、公表を差し控えている事項があるとしています。
フォレンジック調査が続いているのであれば、攻撃経路を確定できていない可能性があります。
関係する事業者や端末、認証履歴などについて確認が続いている可能性も考えられます。
ただし、それらは現時点では推察です。
そして続報が出たとき、この記事で示した仮説と照合したいと思います。
最後に――攻撃者は「外」から何を見ていたのか
今回の事件を追っていて、最後に一つ気になることがあります。
私たちは通常、サイバーセキュリティを組織の内側から考えます。
- VPNにパッチは当たっているか。
- アカウントは適切に管理されているか。
- ログを監視しているか。
- ゼロトラストは機能しているか。
- もちろん、どれも重要です。
しかし、攻撃者は外側から見ています。
- どのVPN製品を使っているのか。
- どの脆弱性が残っているのか。
- 誰がシステムを構築しているのか。
- 誰が運用しているのか。
- 誰が保守しているのか。
- どの企業の担当者が、そのシステムへ入る権限を持っているのか。
攻撃者がそこまで調べていたとすれば、守る側も同じ視野を持たなければなりません。
今回のGSS侵害で、攻撃者がそこまで事前偵察していたという証拠は、現時点ではありません。
しかし、
VPNという「技術的な入口」と、保守運用担当者という「人・Identityの入口」が同じ事件に登場した。
この事実は重いと思います。
政府共通基盤を守るのであれば、自分たちのネットワーク内部だけを監視していては足りません。
- 自分たちが外部からどう見えているのか。
- 自分たちへつながる企業や保守経路がどう見えているのか。
- どこが攻撃者にとって最も入りやすい入口になっているのか。
そこまで観測範囲を広げる必要があります。
今回の事件でデジタル庁が実際にどこまで攻撃者から観察されていたのかは、まだ分かりません。
確認された事実と、そこから導いた仮説を残しておきたいと思います。
今後デジタル庁から新しい情報が公表されれば、推察だった部分を再検証します。
正しかった仮説は確認された事実へ。
誤っていた仮説は棄却します。
そうやって、少しずつ事件の実像へ近づいていきたいと思います。
サイバー攻撃で本当に見るべきなのは、侵入口だけではありません。
攻撃者がその入口を選ぶまでに、私たちの何を見ていたのか。
今回のGSS侵害事件について、ネット探検ラボでは今後も追跡を続けていきたいと思います。
コメント