日曜日, 9月 13, 2026

ゼロトラストの政府基盤はなぜ抜かれたのか ― デジタル庁GSS不正アクセス24.6万件の全体像

2026年9月11日、デジタル庁は、各府省庁向けに運用している政府共通の業務実施環境「ガバメントソリューションサービス(GSS)」が外部から不正アクセスを受け、約24.6万件の個人情報が漏えいした可能性があると公表しました。侵入の入口は、外部からの保守運用に使っていたVPN機器の脆弱性です。

この事案が技術者にとって重いのは、件数そのものよりも入口の性質のほうです。悪用されたのはゼロデイではなく、攻撃が観測される前に公表されていた既知の脆弱性でした。しかも当初の深刻度評価は「中(Medium)」。デジタル庁は「公表された際の深刻度評価に応じた一般的対応よりも早く対処を進めた」と説明していますが、修正プログラムの適用が間に合いませんでした。ゼロトラストアーキテクチャを採用した政府共通基盤が、CVSS「中」の穴から抜かれた、という構図です。

本稿の見立てを先に書いておきます。この事案の教訓は「パッチを早く当てろ」ではありません。CVSSの静的スコアを起点にパッチの順番を決める運用そのものが、すでに攻撃側の速度に追いついていないということです。米国CISAは同じ問題意識から2026年6月にパッチ優先順位の指令を作り替えています。以下、公表事実を整理したうえで、そこまでを順に見ていきます。

本稿は2026年9月13日時点で公開されている情報に基づきます。デジタル庁は調査を継続中であり、セキュリティ上の理由から公表を差し控えている事項があるとしています。特に、悪用されたVPN機器の製品名、脆弱性のCVE番号、攻撃者に関する情報はいずれも非公表です。本文中でCVEに言及する箇所は、公表事実ではなく第三者による推測であることを明示しています。

1. 何が起きたのか

GSSは、各府省庁が個別に構築・調達していた業務用PC、ネットワーク、セキュリティ対策を、標準的な業務実施環境として統合する政府共通基盤です。2021年度にデジタル庁での利用が始まり、報道ベースでは2026年7月末時点で独立行政法人などを含む23機関・約15.4万人が利用しています。

発端は2026年6月25日、保守運用担当者のアカウントを使ってサーバ上の大量のファイルにアクセスが行われたことを検知したことでした。日経クロステックの報道によれば、このアクセスは5月下旬ごろから行われていたとされます。外部の専門事業者の協力を得た調査の結果、7月9日に、第三者がVPN機器の脆弱性を利用してシステムに侵入していたことが判明。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断しました。

日付 出来事 補足
2026年5月下旬ごろ 保守運用担当者のアカウントによるサーバ上の大量ファイルへのアクセスが始まる 時期は報道ベース。侵入の起点となった経緯は調査中とされる
6月25日 大量ファイルアクセスを検知し、調査を開始 この時点では不正アクセスの有無・影響範囲とも不明
7月9日 VPN機器の脆弱性を利用した第三者の侵入と判明。アカウント停止・外部通信遮断 公表資料の概要図では、初動対応としてVPNへのパッチ適用も実施
7月15日 個人情報保護委員会へ報告 この事実は9月12日のQ&A更新で追記された
9月11日 公表。閣議後会見で松本尚デジタル相が説明 検知から78日、侵入経路判明から約2か月
9月12日 デジタル庁がQ&Aを公開・更新 個人情報保護委員会への報告日を追記

封じ込め後は、新たな不正アクセスや不審な通信は確認されていないとされています。GSSを利用する政府の業務にも支障は生じていません。二次被害も9月11日時点では確認されていませんが、なりすましメールやフィッシングに悪用される可能性があるとして、デジタル庁は注意を呼びかけ、専用のフリーダイヤル(0120-360-036)と問い合わせメールアドレスを設けています。対象者には、連絡先が特定できた人から順次、個別に連絡する方針です。

2. 漏えいした可能性のある情報の中身

数字を扱ううえで最初に押さえるべきは、約24.6万件が「漏えいが確定した件数」でも「被害人数」でもないことです。デジタル庁はQ&Aで、不正アクセスの痕跡が確認された情報について「漏えいした可能性が否定できないものも含めて対象としている」と説明しています。対象者の保護を優先して広めに取った数字だ、ということです。

区分 規模 備考
GSS利用機関の職員および業務に携わった公務員等(独立行政法人の職員を含む) 約18.9万人 公式Q&Aはこの内訳を「人」で表記している
GSS利用機関の業務に携わった事業者および個人 約5.7万人 企業の従業員、個人事業主、WEB会議の参加者などを含む
氏名 約23.6万件 属性別の数字は重複を含む
メールアドレス 約23.1万件 公務用・業務用のもの
電話番号 約9.4万件 多くは個人のものではなく公務用の連絡先
住所 約0.1万件 多くは各府省庁の庁舎所在地や事業所所在地

情報の出どころは、システムの利用者登録の申請書です。代表者の氏名、業務に使う電話番号、勤務先の住所を記載する必要があり、それが漏えいした可能性がある、という構造になっています。マイナンバー、金融機関口座情報、年金番号は含まれていないことが確認されており、一般の国民の個人情報も含まれません。

ただし「機微な情報がないから軽い」とは言えません。各府省庁の職員と、その業務に携わった事業者担当者の氏名・所属・連絡先が組になったリストは、標的型攻撃の下ごしらえとしては上等な材料です。マイナンバーが漏れなかったことと、この名簿が漏れた可能性があることは、別々に評価すべき事柄でしょう。

3. 入口は「CVSS中」の既知脆弱性だった

この事案でもっとも議論に値するのは、ここです。デジタル庁はQ&Aで次のように説明しています。悪用された脆弱性は、当初公表されていた評価では中(CVSS値 Mediumレベル)のものだった。攻撃が確認される前に公表されていた既知の脆弱性だった。公表時の深刻度評価に応じた一般的対応よりも早く対処を進めていたが、修正プログラムの適用前に悪用された——。

松本デジタル相も9月11日の会見で、脆弱性の存在を事案発生前から把握しており、緊急度の高い他の脆弱性から順に対応を進めていた最中に悪用された、と説明しています。つまり脆弱性管理のプロセスは動いていた。動いていたが、キューの順番が攻撃者の到着より遅かったということです。

脆弱性情報の収集・評価は継続的に実施しており、ベンダーの公表情報や注意喚起を確認して影響を評価したうえで対策を講じる運用だった、ともQ&Aは述べています。デジタル庁自身、「脆弱性情報の把握から評価・対策実施までのプロセスを改めて点検し、より迅速かつ確実に対応できるよう運用の強化を進める」「実質的なリスクに基づいて、一層迅速かつ先行的な対応を行う」としており、優先順位付けの基準そのものが論点だという認識は共有されています。

4. 非公表のCVEをめぐる推測をどう扱うか

VPN機器の製品名も、悪用されたCVE番号も公表されていません。この状況で、セキュリティ研究者のpiyokango氏は、大臣が説明した内容などから、Palo Alto Networksが公表したCVE-2026-0257に該当する可能性があると推測しています。これは第三者の推測であり、デジタル庁が認めた事実ではありません。この点は動かしようがないので、まず明記しておきます。

そのうえで、この脆弱性の経緯自体は、本稿の主題と正面から重なるので見ておく価値があります。CVE-2026-0257はPAN-OSのGlobalProtectポータル/ゲートウェイにおける認証回避の脆弱性で、2026年5月13日にアドバイザリが公開されました。認証オーバーライド用のCookieを有効にしており、かつ特定の証明書構成が存在する場合に、リモートの未認証攻撃者がCookieを偽造して不正なVPN接続を確立できます。

問題は評価の推移です。公開当初のCVSS v4.0スコアは4.7、深刻度は中でした。ところが5月29日にRapid7が技術解析と実証コードを公開したことを受け、Palo Alto Networksはスコアを7.8(高)へ改定します。同日、CISAはこのCVEをKEVカタログに追加し、連邦民間行政機関に6月1日までの対処を命じました。実際の悪用は5月17日ごろから観測されていたと報告されています。

GSSの脆弱性がこれと同一であるかは確認できません。ただ、少なくとも一般論として言えることがあります。「公開時のCVSSスコア」は、対処の順番を決める根拠としては賞味期限が短い。同じCVEが2週間で4.7から7.8に化けるのであれば、公開時点のスコアで並べたキューは、その時点で古くなり始めています。

5. 「ゼロトラストだったのに」をどう読むか

GSSはゼロトラストネットワークアーキテクチャを活用した環境として設計されています。デジタル庁はQ&Aで、ゼロトラストアーキテクチャを採用していたが結果として不正アクセスと情報漏えいの可能性が生じたことを重く受け止めている、と述べる一方、具体的なセキュリティ対策の内容やシステム構成は「攻撃者を利する」として非公表としました。松本大臣も会見で「ゼロトラストとはいえ、探しても探してもどこかに穴が空いている可能性がある」と述べています。

ここは慎重に読む必要があります。公開情報からわかるのは、外部からの保守運用にVPNという境界型の経路が使われていたこと、そこを突かれて内部に入られたこと、侵入後に保守運用アカウントの情報が取得・悪用されたこと(デジタル庁は侵害に至った経緯・原因を調査中としています)、そして異常検知が「大量ファイルアクセス」という振る舞いで働いたことです。ゼロトラスト制御の設計そのものに不備があったのか、それとも制御は存在したが保守経路が例外として残っていたのかは、公開情報からは判断できません。

なお、VPN機器の管理体制についてデジタル庁は、GSSのシステムの一部としてデジタル庁が責任を持って管理しており、マニュアル等を整備したうえで職員が、場合によっては外部事業者に委託して管理している、と説明しています。責任の所在は明確にされている一方、外部保守という運用形態が境界を作っていた構図は残ります。

6. デジタル庁のこれまでの個人情報事案

今回のGSS事案は、デジタル庁が直接運用するシステムに関する公表事案としては、漏えいの可能性がある件数が最大のものです。それ以前の事案は、性格がかなり異なります。

時期 事案 性格 規模
2021年11月24日 報道機関向けプレスリリース送信で、BCCに入れるべきアドレスをCCに記載 人的ミス 約400件
2022年4月1日 ワクチン接種証明書アプリの問い合わせ回答メールで、BCCに入れるべきアドレスをTOに記載 人的ミス 少数
2022年4月6日 e-Govサポートデスクの運用受託事業者が回答メールの送付先を誤り、問い合わせ者のアドレスが流出 委託先の人的ミス 少数
2023年5〜6月 自治体窓口の共用端末でログアウトされず、他人のアカウントに公金受取口座が誤登録。マイナポータルで口座情報が閲覧可能な状態に 制度・運用 後述
2023年9月20日 個人情報保護委員会が、マイナンバー法33条・個人情報保護法157条に基づきデジタル庁を指導 監督上の措置
2026年9月11日 GSSへの不正アクセス サイバー攻撃 約24.6万件

公金受取口座の件は、デジタル庁が約5,400万件の全口座を総点検し、2023年6月7日時点で他人の口座への誤登録の可能性が高いもの748件を確認、マイナポータルからの閲覧を不可としました。その後、個人情報保護委員会が整理した同年6月22日時点の数字としては、誤登録のおそれがある事例940件、家族名義などとみられるもの約14万件が挙げられています。再発防止として、デジタル庁は2023年6月23日、登録操作の完了時に再度マイナンバーカードを読み取り、操作開始時のカードとの同一性を確認する仕様変更を実施しました。同年11月には検知モデルの高度化により追加の疑い口座を確認し、閲覧を停止しています。不正利用の被害は確認されていません。

2023年9月20日の措置について、一点だけ用語を整理しておきます。これは「行政指導」であって「行政処分」ではありません。個人情報保護法では、行政機関等に対する「指導及び助言」と「勧告」は別の条文に置かれた監視・監督手段であり、民間事業者に対する「勧告に従わなければ命令」という段階構造とは仕組みが違います。行政機関への指導が必ず勧告の前段階になるわけでもありません。同日、国税庁も指導を受けています。デジタル庁が指導を受けたのはこのときが初めてでした。

なお、政府機関の情報漏えいには、府省庁が利用するベンダー側のサービスやシステムを起点とするものもあります(2021年のProjectWEB事案、2023年のNISCのメール関連システムの事案など)。ただしこれらはデジタル庁の所管システムの事案ではないため、本稿では切り分けて扱います。

7. マイナ関連の件数はなぜ混乱するのか

2023年のマイナンバー関連トラブルは、報道でも数字が錯綜しました。混乱の原因は単純で、集計の範囲と時点が違う数字が、同じ「件」という単位で並べられていることです。健康保険証の紐付け誤りは保険者側の登録に起因するもので、デジタル庁の直接事案ではありませんが、政府全体のマイナンバー情報総点検を通じて一体で語られたため、混同されやすくなっています。

数字 何を指すか 注意点
7,372件 2023年5月22日までに把握されていた健康保険証の紐付け誤り この時点での累計であり、最終数字ではない
1,069件 その後の自己点検で追加判明した紐付け誤り 7,372件と合わせて計8,441件
5件 追加分1,069件のうち、アクセスログの確認が完了した771件で確認された、他人による薬剤情報等の閲覧 7,372件全体に対する数字ではない。従来分と合わせた閲覧事例は計15件と報じられた
8,351件 マイナンバー情報総点検(対象約8,208万件)で新たに確認された紐付け誤り 対象件数に対する割合は0.01%。累積の判明数ではない
約1万5,907件 総点検前から判明していた事案・自己点検・個別データ点検などを含む累積の判明数 報道ベースの集計。8,351件と足し合わせてはいけない
748件/940件 公金受取口座の他人誤登録。前者は2023年6月7日時点、後者は個人情報保護委員会が整理した同年6月22日時点 別々の事案ではなく、同じ問題の時点違いの数字

この手の数字を引用するときは、「いつ時点の」「どの範囲を数えた」数字なのかをセットで書かないと、意味が変わります。特に「7,372件のうち5件が閲覧された」という書き方は、閲覧の確認母数がまったく違うので成立しません。

8. 行政機関の漏えい報告は増え続けている

個人情報保護委員会は2026年7月7日、個人情報保護法168条に基づく2025年度の年次報告を国会に報告し、その概要を公表しました。2025年度の漏えい等報告は1万9,417件で、内訳は民間の個人情報取扱事業者等が17,139件、行政機関等が2,278件です。前年度は合計21,007件(民間19,056件、行政機関等1,951件)でした。

全体としては前年度を下回った一方、行政機関等の報告は1,951件から2,278件へと約17%増え、過去最高を記録しています。日本経済新聞によれば、行政機関の報告のうち資料の誤交付や誤送付といった人為的ミスが要因となったものが1,536件で、全体の67%を占めました。

ここも数字の性格に注意が必要です。1万9,417件は漏えい等事案に関する報告の処理件数であって、漏えいした人数でも個人情報レコード数でもありません。「2万件近くの個人情報が漏れた」と読むのは誤りです。

9. 何が問われているのか

ここからは筆者の見立てです。公表事実からの推論であり、デジタル庁の見解ではありません。

第一に、優先順位付けの基準です。「CVSSスコアの高い順に対応する」という運用は、直感的で説明もしやすいのですが、スコアは静的な技術特性から算出されるもので、実際に悪用されているかどうかを直接反映しません。CVE-2026-0257が公開時4.7から7.8へ改定された経緯は、その限界をよく示しています。

参照点になるのが、米国CISAが2026年6月10日に発出した拘束的運用指令BOD 26-04「Prioritizing Security Updates Based on Risk」です。この指令はBOD 19-02とBOD 22-01を失効させ、①資産が公開露出しているか、②KEVカタログに掲載されているか、③攻撃を自動化できるか、④技術的影響はどうか、という4つの判断基準で修正の期限を決める方式に切り替えました。4条件すべてに該当する最優先の脆弱性は3日以内の修正が求められます。BOD 19-02の失効により、連邦民間行政機関では脆弱性の優先順位付けにCVSSを使うことが必須ではなくなりました。AIによって脆弱性の発見から武器化までの時間が圧縮されている、という認識が背景にあります。

GSS事案で悪用された脆弱性が、仮に悪用実績の公表されていたものだったとすれば、「CVSSは中だが実際に悪用されている外部公開機器」という、まさにBOD 26-04が最優先に置く類型に当てはまります。日本の政府情報システムにおける脆弱性管理の期限設定を、悪用実績に紐づける方向へどこまで踏み込むかは、再発防止策の実質を測る指標になるはずです。デジタル庁自身が「実質的なリスクに基づいて」と表現しているのは、この方向を意識したものと読めます。

第二に、外部保守経路の扱いです。ゼロトラストを掲げる環境でも、外部からの保守運用のためにVPNという境界を残せば、そこが単一障害点になり得ます。パッチ適用が間に合わないと判断した時点で当該経路を一時的に閉じる、という選択肢を運用上取れるようにしておくことは、パッチ適用の速度を上げるのと同じくらい重要です。

第三に、パッチ適用は侵害の排除ではない、という点です。BOD 26-04がフォレンジック・トリアージを併せて要求しているのは、パッチを当てても既に入り込んだ攻撃者は出ていかないからです。GSS事案でも、侵入後に保守運用アカウントの情報が取得・悪用されています。境界の穴を塞ぐことと、内部に残された足跡を洗うことは別作業です。

第四に、検知から公表までの78日をどう評価するかです。デジタル庁は、影響範囲・侵入経路の分析・対象者の確認に相当の時間を要したと説明しており、7月9日には外部通信を遮断しているため、この期間ずっとデータが流出し続けていたわけではありません。個人情報保護委員会への報告は7月15日に済んでいます。ただ、漏えいの可能性がある対象者が公務員と事業者担当者である以上、彼らがフィッシングの標的になり得る期間でもありました。全体像の確定を待つことと、対象者への注意喚起を先行させることは、本来は別のタイムラインで動かせるはずです。

10. まとめ

デジタル庁のGSS事案は、規模の割に「派手さ」がありません。ゼロデイでもなく、ランサムウェアでもなく、マイナンバーが漏れたわけでもない。だからこそ、脆弱性管理を実際に回している立場からは、これ以上ないほど身につまされる事案です。脆弱性情報は収集していた。評価もしていた。優先順位もつけていた。それでも、順番待ちの列に並んでいる間に抜かれた。

スコアの高い順に潰すという運用は、キューの長さと攻撃者の速度が釣り合っている間しか成立しません。その前提が崩れているのなら、並べ替えの基準そのものを変えるしかない。CISAがCVSS必須をやめて悪用実績と公開露出を軸に据えたのは、その判断です。

調査はまだ続いており、VPN製品名も、CVE番号も、攻撃者の情報も明らかにされていません。再発防止策の具体的な内容も、システム防御に関わるとして非公表とされました。何をもって「脆弱性管理の強化」が達成されたと判断するのか——その基準がどこかの時点で示されるかどうかを、引き続き見ておきたいと思います。

0 件のコメント: