デジタル庁のGSSへの不正アクセス。問われているのはVPN一台のパッチ管理ではない。既知の脆弱性をどう順位付けし、パッチが間に合わない時間をどう守り、侵入後をどこで止めるのか。そして、いつ社会に知らせるのか。
2026年9月11日、デジタル庁が政府共通の業務基盤「ガバメントソリューションサービス（GSS）」への不正アクセスを公表した。
漏えいした可能性がある個人情報は約24万6千件。GSS利用機関の職員や、その業務に携わった公務員等が約18万9千件、事業者や個人が約5万7千件とされている。重複を含む数字で、人数そのものではない。
氏名約23万6千件、メールアドレス約23万1千件、電話番号約9万4千件、住所約1千件などが対象となった可能性がある。一般の国民の個人情報、マイナンバー、金融機関の口座情報、年金番号などは含まれていないという。
現時点で個人情報の悪用などの二次被害は確認されていない。GSSを利用した政府業務にも明確な影響は確認されていない。
ここだけなら、「VPNの脆弱性を突かれたが、検知して止めた」という事故にも見える。
しかし、発表と会見を時系列で追うと、それほど単純ではない。今回問われているのは、VPN一台のパッチ管理だけではない。入られる可能性を前提に設計されたはずのGSSで、一つ目の壁を破られたあと、次の壁はどこまで機能したのか。そこだと思う。
GSSは単なるVPNではない。
各府省庁が個別に持ってきた庁内LANや業務用PC、ネットワーク環境などを統合していく政府共通の業務実施環境で、設計にはゼロトラストの考え方も取り入れられている。端末や通信を継続的に確認し、一度認証したからといって無条件に信用し続けないことが前提になる。
だから、VPNを破られた。それだけなら、まだ一つ目の壁の話だ。本当に見るべきなのは、そのあとである。
今回悪用されたVPNの脆弱性は、デジタル庁が事案発生前から把握していた。
会見では、複数の脆弱性について緊急度の高いものから順番に対応していたところ、今回の脆弱性を先に悪用されたと説明している。CVSS上の重要度は「中（Medium）」程度だった。修正プログラムやパッチを適用する前に攻撃を受けたという。
つまりこれは、「知らない穴を突然突かれた」という話ではない。知っていた穴の中で、どれを先に直すかという判断で攻撃者に先を越された。
ここは重要だ。
「Mediumだったから後回しにした」とだけ読むのも早い。実際には、他にどんな脆弱性を抱えていたのか、それぞれの緊急度、変更作業の難易度など、外からは分からない。
だが、再発防止策として「脆弱性管理を見直す」というなら、今後何を変えるのかは知りたい。CVSSだけを見るのか。インターネットから直接到達できる機器なのか。認証の入口なのか。突破された場合、どこまで影響が広がるのか。実際に攻撃が観測されているのか。そうした条件をどう重ねて、優先順位を変えるのか。
製品名やCVE番号は公表されていない。一部では特定のVPN製品の脆弱性を候補として挙げる分析もあるが、本稿では特定しない。問題は製品当てではない。次に同じようなMediumが出たとき、何を根拠に「これは今すぐ直す」に変えるのか。その仕組みの方が重要だ。
この点でもう一つ興味深いことがある。
今回の侵入が起きていた時期、政府はちょうど「Project YATA-Shield」を進めていた。6月16日の会見で松本デジタル相は、利用可能なフロンティアAIを使いながら、脆弱性のチェックやパッチ適用を進めると説明している。6月26日には、複数のフロンティアAIを重層的に利用して脆弱性チェックを進める方針も示した。さらに6月12日、大臣は政府のセキュリティ対応について、重要な脆弱性なら場合によっては情報システムを一時停止してでも対応する必要があるという趣旨を述べている。
これは今回の事案を考える上でかなり重要だ。
政府はすでに、脆弱性をもっと早く見つける、AIも使う、重要ならシステムを止めてでも直す、という方向に進んでいた。
しかし今回悪用されたのは、少なくとも発表上は「見つけられていなかった脆弱性」ではない。すでに把握していた脆弱性だった。
だとすれば、今回問われているのは、AIで穴を見つける能力だけではない。見つけた後、どれを先に直すのか。どれだけ速く直せるのか。そこだ。
「脆弱性管理を見直します」と言うのは簡単だ。しかし、優先順位を変えれば、本当に対応速度まで上がるのだろうか。
パッチには検証がいる。影響確認がいる。冗長系の切り替えがいる場合もある。委託先との調整や変更承認もある。止められないシステムなら、適用できる時間帯も限られる。
今回どの工程に時間を要していたのかは公表されていない。判断基準の問題だったのか。検証能力だったのか。変更作業に必要な体制だったのか。要員や委託先との調整だったのか。それとも別の理由なのか。
ここを明らかにしないまま、「次から優先順位を見直す」だけでは、本当に速くなるのか分からない。
そして、もっと重要なのはここだ。
どれだけAIを使っても、優先順位を改善しても、すべての脆弱性に攻撃者より先にパッチを当てることはできない。
だからゼロトラストや多層防御がある。
パッチ適用までの間は、インターネットからの到達範囲を絞る。接続元や端末を限定する。必要なら脆弱な機能そのものを止める。IPSなどで一時的に悪用を遮断する。権限を最小限にする。ネットワークを分ける。一つの機器を突破されても、その先へ簡単には進ませない。
パッチが間に合わなかったことは起こり得る。問題は、そのとき次の壁で止まるかだ。
デジタル庁の説明では、攻撃者はVPNの脆弱性を悪用して内部ネットワークへ侵入した後、保守運用に用いていたアカウント情報を取得し、そのアカウントを悪用した。そして、サーバ上の大量のファイルへアクセスした。
流れにすると、VPNの脆弱性 → 内部へ侵入 → 保守運用アカウント情報を取得 → 正規アカウントを悪用 → 大量のファイルへアクセス、となる。
どの府省庁、どの内部領域が最初に侵害されたのかは公表されていない。だから「ある省庁から別の省庁へ横展開された」とまでは言えない。
ただし、一つ目の入口を越えた後に、別の認証情報を取得し、その資格情報を利用してさらに内部資源へ進んだことは確認されている。一般的に言えば、侵入後の横展開を考える上で非常に重要な動きだ。
GSSが「入られることも前提」にしているなら、まさにここを止めるための仕組みがあったはずだ。
7月9日、デジタル庁は悪用された保守運用アカウントを停止し、侵害された機器と外部との通信を遮断した。
これは当然必要な対応だ。しかし、それで終わりではない。
もっと知りたいのは、なぜ、その認証情報を取得されたのか。端末上の資格情報だったのか。設定やファイルから取られたのか。セッションやトークンだったのか。別の認証基盤へ到達されたのか。公表資料からは分からない。取材でも、侵害に至った詳しい経緯や原因は調査中とされている。
ここは非常に大きな空白だと思う。
アカウントを停止すれば、その鍵は使えなくなる。しかし、鍵を盗めた原因を潰していなければ、別の鍵をまた盗まれる可能性が残る。
原因は特定されたのか。その取得経路は排除されたのか。同じ条件を持つ他の保守アカウントは横断的に確認したのか。ここまでが再発防止だと思う。
もう一つ重要なのが検知の位置だ。
6月25日に異常を把握したきっかけとして公表されているのは、保守運用担当者のアカウントを利用してサーバ上の大量のファイルへアクセスしたことだった。
つまり、公表されている検知の起点は、VPNを突破した時ではない。内部へ入った時でもない。認証情報を取得された時でもない。盗まれた正規アカウントで、大量のファイルへアクセスした段階だ。
もちろん、それ以前にもアラートや記録が存在し、後から調査で結び付けられた可能性はある。公表されていないので、「それ以前は何も検知していなかった」とは言えない。
だからこそ説明してほしい。VPN突破から大量ファイルアクセスまでの間に、何を検知できていたのか。何を検知できなかったのか。次回は、資格情報を取られた時点で気づけるのか。盗まれたIDが通常とは違う場所、端末、時間帯、通信経路から利用されたら止められるのか。普段アクセスしないリソースへ向かえば再認証や遮断が入るのか。
「正規のアカウントだから信用する」なら、ゼロトラストではない。
約24万6千件の情報について、デジタル庁の表現は一貫して、「外部に漏えいした可能性」である。
大量のファイルにアクセスされたことは分かっている。影響を受けた可能性のある情報も、氏名、メールアドレス、電話番号、住所などに分類している。しかし、実際にどのファイルが外部へ持ち出されたのかは確定していない。
私は最初、この事案を見て「出口のログが不足していたのではないか」と考えた。だが、それも今の情報からは断定できない。実際、デジタル庁は侵入開始時期、VPN経由の侵入、認証情報の取得、正規アカウントの悪用、大量ファイルアクセスまで、かなりの範囲を再構成している。記録がなかったわけではない。
だから問いは、「ログがあったか」ではなく、どこまで事実を確定できるだけの記録が残っていたか、だと思う。
なぜ「ファイルへアクセスされた」までは言えて、「外へ出た」は確定できないのか。何が分からないのか。通信の記録なのか。保存期間なのか。暗号化された通信なのか。それとも別の技術的理由なのか。そこまで説明されて初めて、次に何を直すべきかが分かる。
今回、公開DNSと証明書透明性ログも確認した。侵入に使われたVPN製品やCVEそのものを、外から特定することはできなかった。
一方で、7月から8月にかけて、GSS関連の複数の系統で証明書の発行・更新が続いていることは確認できる。名称上east／westに分かれた系統でも、8月4日と8月19日に新しい証明書が発行されている。約2週間の時間差がある。
ただし、ここから理由は分からない。今回の事故を受けた段階的な更改なのか。以前から予定されていた作業なのか。単なる証明書更新日の違いなのか。変更作業の時間なのか。外からは確認できない。
だから、これを「侵害されたVPNを作り直した証拠」とはしない。言えるのは、7月9日の封じ込め以降、公表前の7月から8月にもGSS外形上で複数の変更・更新が観測できる、そこまでだ。
対策を進めていた時間軸とは矛盾しない。むしろ気になるのは、その内側で何を変えたかだ。VPNだけではなく、認証情報の保護、権限分離、内部のアクセス制御、横展開の抑止、検知、ログ。そこまで手を入れたのか。
今回もう一つ納得しにくいのが、公表までの時間である。
異常を検知したのは6月25日。7月9日にはVPNを経由した侵入を特定し、アカウント停止と通信遮断を行った。報道によれば7月中旬には個人情報保護委員会へ報告している。一般への公表は9月11日だった。検知から約2か月半である。
松本大臣は、侵入経路や影響範囲、漏えいした可能性のある情報の特定など、調査に時間を要したと説明している。それは理解できる。24万件規模の対象を調べ、影響範囲を確定していく作業に時間がかかるのは当然だろう。
しかし、調査に時間がかかることと、第一報を出さないことは同じではない。
個人情報保護委員会の行政機関向け事務対応ガイドでは、本人への通知について、概要、対象情報、原因などのすべてが判明するまで待つ必要はなく、状況に応じて速やかに通知する考え方が明記されている。
もちろん、これは社会一般への公表義務そのものを定めたものではない。また、事案がほとんど分からず、通知しても本人が対策できない、あるいはかえって被害を広げるような場合は、直ちに通知しない合理的な場合も示されている。
それでも、7月9日の時点では、GSSへの不正アクセスがあった、VPNが侵入経路だった、保守運用アカウントが悪用された、侵害された機器を遮断した、影響範囲は調査中、というところまで分かっていた。
ならば、「政府共通基盤GSSへの不正アクセスを確認した。封じ込めを実施した。個人情報への影響は調査中である」という第一報を出す選択肢はなかったのだろうか。
数字が確定している必要はない。製品名やCVEを明かす必要もない。分からないことは「調査中」でいい。
まず止める。分かった範囲で知らせる。調査を続ける。新しい事実が分かれば更新する。行政機関のインシデント対応として、その方が信頼を維持できたのではないかと思う。
公表前から、この事案について外部で言及が見られ、「なぜ公表されないのか」という疑念も出ていた。だからといって、「デジタル庁が隠蔽した」と断定する材料はない。そこは分ける。
ただ、公表が約2か月半後になったことで、そう疑われる余地を自ら作ってしまったとは思う。
デジタル庁は民間企業ではない。政府の共通基盤を税金で運営し、行政のデジタル化とセキュリティを主導する立場にある。
今回は、一般国民の個人情報は漏えい対象ではないと発表されている。そこは正確に書かなければならない。しかし政府全体は、日常的に国民から大量の情報を預かっている。その政府の共通基盤でインシデントが起きた時、何をいつ説明するかは、直接被害を受けた人だけの問題ではない。行政を信頼して情報を預けられるかという問題でもある。
「よく分からなかったから調査していた」は、調査を続ける理由になる。しかし、7月9日以降も第一報を出さなかった理由として、それだけで十分なのか。ここは、もう少し説明してほしい。
今回の事案を「VPNにパッチを当てましょう」で終わらせてはいけないと思う。知りたいのは、その先だ。
脆弱性の優先順位を、今後どう変えるのか。CVSSだけでなく、実悪用、インターネット露出、認証境界、資産の重要性をどう評価するのか。優先度を上げた脆弱性を、どれだけ速く検証し、適用できる体制にするのか。そして、それでもパッチが間に合わない期間を、何で守るのか。
VPNを突破された後、なぜ保守運用アカウント情報まで取得されたのか。その原因は特定されたのか。その取得経路は排除されたのか。他の同種アカウントも確認したのか。
次回は、資格情報を盗まれた時点で検知できるのか。盗まれた正規アカウントを使われても、大量ファイルアクセスまで進ませないために何を変えるのか。
そして最後に、実際にデータが外へ出たかどうかを、後から確定できるだけの記録をどう残すのか。さらに、インシデントが起きた時、すべてが判明するまで待たず、どの段階で社会に知らせるのか。
ここまで答えて初めて、今回の事故を受けてGSSをどう強くするのかが見えてくると思う。
ゼロトラストを導入していたのに侵入された。だからゼロトラストは失敗だった。そういう話ではない。
ゼロトラストは「絶対に入られない」という約束ではない。むしろ、侵入される、資格情報も盗まれる、正規アカウントも悪用される、その前提で、一つの壁を破られても次で止める。そのための考え方だ。
松本大臣も今回の会見で、ゼロトラストでも探せば穴がある可能性があり、対策を繰り返し見直す必要があるという趣旨の説明をしている。その考え方には同意する。考えながら守っていく。その通りだと思う。
だからこそ、何が今回うまくいかなかったのか。そこも明らかにしてほしい。
AIを使って脆弱性を見つける。それも必要だ。だが今回問われているのは、その先だ。見つけた穴をどう順位付けするのか。どれだけ速く直すのか。間に合わない時間をどう守るのか。入られた後をどこで止めるのか。そして何が起きたかを後から確実に説明できるのか。
GSSは政府全体の仕事を支える共通基盤だ。だから求めたいのは、「二度と侵入されません」という約束ではない。
入られても止める。一つ目で止まらなければ、次で止める。止められなければ、できるだけ早く見つける。何が起きたのかを記録から再構成する。そして、分かった事実を必要な時点で知らせる。
そこまで含めて、強い政府共通基盤になってほしい。しっかりお願いしたい、と一利用者として思う。
参照
Aikido Community Japan
公開日: 2026/9/11
最終更新: 2026/9/12
セキュリティの最新情報をお届けします。