こんにちは、ひろかずです。
政府共通の業務環境GSSへの不正アクセスにより、個人情報漏えいが発生した可能性が公表されました。ゼロトラストアーキテクチャを採用していた環境の侵害は事例として珍しいので、何が起きて、なにをすべきなのかの整理を共有します。
忙しい人向けの要約
- デジタル庁は2026年9月11日、政府共通の業務環境GSSへの不正アクセスにより、約24.6万件の個人情報（職員・公務員等 約18.9万件、GSS利用機関の業務に携わった事業者・個人 約5.7万件）が漏えいした可能性を公表しました。
- 侵入経路は、攻撃前に公表済みだったVPN機器の脆弱性（当初評価はCVSS Medium）で、修正プログラムの適用前に悪用されました。6月25日に保守運用担当者アカウントによる大量ファイルアクセスを検知し、7月9日に第三者の侵入と判明しています。
- デジタル庁はQ&Aで「ゼロトラストアーキテクチャを採用しておりました」と明言しています。自社に持ち帰るべき問いは、外部接続に使うVPN機器の脆弱性対応をどの優先度で回すか、そこを通る保守用アカウントをどう統制するか、の2つです。
- 実務では、残存VPNの目的別台帳化、保守運用アカウントの棚卸しと行動監視、大量ファイルアクセス検知の閾値設計の3点を先に確認すべきです。
- 検知から公表まで約2か月半を要した経緯は、自社のインシデント調査体制（ログ保持・フォレンジック・報告手順）を見直す材料になります。
何が起きているの？
デジタル庁が公開したQ&Aにある一文
「ゼロトラストアーキテクチャを採用しておりましたが、結果として不正アクセス及び情報漏えいの可能性が生じたことを重く受け止めております」。ゼロトラストを採用している政府共通基盤が、VPNの脆弱性から破られました。
事実関係を時系列で確認します。
| 日付 | 出来事 | 出典区分 |
|---|---|---|
| 2026年5月下旬ごろ | 第三者がVPN機器の脆弱性を悪用して侵入を開始したとみられる | 二次（日本経済新聞・時事通信・日経クロステックの報道。デジタル庁の公式発表・Q&A・大臣会見録には記載なし） |
| 2026年6月25日 | 保守運用担当者のアカウントを利用したサーバ上の大量ファイルへのアクセスを検知し、調査を開始 | 一次（デジタル庁 公式発表） |
| 2026年7月9日 | 第三者がネットワーク接続機器（VPN）の脆弱性を利用して侵入していたことが判明 | 一次（デジタル庁 Q&A） |
| 2026年7月15日 | 個人情報保護委員会へ報告 | 一次（デジタル庁 Q&A） |
| 2026年9月11日 | 不正アクセスと個人情報漏えいの可能性を公表 | 一次（デジタル庁 公式発表） |
デジタル庁のQ&Aと公式発表で公開されている内容を整理します。
| 区分 | 公開されている内容 |
|---|---|
| 漏えいの可能性がある情報・数量 | 合計約24.6万件（GSS利用機関の職員および業務に携わった公務員等 約18.9万件、事業者および個人 約5.7万件） |
| 漏えいの可能性がある属性 | 氏名、メールアドレス、電話番号、住所等 |
| 含まれていない情報 | マイナンバー、金融機関口座情報、年金番号等。一般の方の個人情報も含まれない |
| 初動対応（封じ込め） | 7月9日に当該保守運用担当者アカウントを停止し、侵害された機器と外部との通信を遮断。その後、修正プログラムの適用と関係アカウントの認証情報変更 |
| 再発防止策 | 脆弱性管理方法の見直し、外部からの接続方法の改善、侵入された場合でも影響を最小限とする対策の強化、監視体制・アクセス管理の点検（9月15日の大臣会見） |
| 報告・公表 | 2026年7月15日に個人情報保護委員会へ報告、9月11日に公表 |
公表されていないことも多い事案です。デジタル庁はQ&Aで、具体的な脆弱性の内容について「今後のセキュリティ確保に支障を及ぼすおそれがある」として回答を差し控えています。
| 未公表の項目 | 実務上の意味 |
|---|---|
| 侵入に使われた VPN機器の製品名・ベンダ名 | 同一製品の利用有無による自社影響の判定ができない |
| 悪用された脆弱性の識別番号（CVE等） | 自社機器の該当パッチ適用状況を照合できない |
| 修正プログラムの適用が間に合わなかった具体的な経緯 | どの段階で対応が遅れたかを自社の運用と比べられない |
| 多要素認証の適用状況 | MFAで防げた事案だったかを評価できない |
| 侵入開始日の確定値 | 「5月下旬ごろ」は報道ベースの情報で、デジタル庁の公表資料には記載がない |
脆弱性が既知だったかどうか
- Q&Aによると、悪用された脆弱性は攻撃が確認される前に公表済みで、当初の評価はCVSSで中（Medium）でした。
- デジタル庁は深刻度評価に応じた一般的な対応より早く対処を進めていたものの、修正プログラムの適用前に悪用されたと説明しています。
- 松本大臣も9月11日の会見で、緊急度の高くない脆弱性として順番にパッチを当てている間に侵入されたという認識を示しました。
本件は、ゼロデイ攻撃でも単純な放置でもなく、Medium評価の既知脆弱性が修正の順番待ちの間に突かれた事案です。読み取るべきは、外部接続機器の脆弱性をどの優先度で処理しているか、そこを通る保守用アカウントを誰がどう管理しているかという点です。
なぜ情報システム・セキュリティ担当者に関係するの？
ゼロトラスト移行を進めている企業ほど、この事案への関心は高いでしょう。移行が進んだ組織のネットワークには、たいてい「最後まで残ったVPN」があります。サーバ発のPush型通信、運用管理ツールのパッチ配布、レガシープロトコル、委託先ベンダーの保守回線。ZTNAへ寄せきれない通信要件が理由で、VPNとのハイブリッド構成が長期化するケースは多くの企業で散見されます。
ここで情シスやセキュリティ担当者が自分事として考えたいのは、「残っているVPN装置を、移行後も同じ水準で管理し続けられているか」という点です。リモートアクセスの主経路をZTNAに寄せると、残ったVPNは日々の運用で意識される頻度が下がります。台帳上の記述が移行前のままになる、ファームウェアの更新確認の間隔が長くなる、接続元制限やアカウントの見直しが後回しになる。こうした変化は管理の良し悪しでなく、構造的に起きやすいものです。
保守業者が利用できるリモートアクセスの仕組みが限られ、クライアントVPNやサイト間VPNを残さざるを得ないケースは、実際のゼロトラストアーキテクチャを目指したシステム更改の現場でも見受けられます。
GSS事案で悪用されたのは、保守運用担当者のアカウントでした（権限の範囲は公表されていません）。外部接続機器と、そこを通る保守用・高権限のアカウントは、最優先の管理対象として扱うべきです。
よくある誤解
「ゼロトラストを導入済みだからVPNリスクは解消した」
ゼロトラストアーキテクチャとは、ネットワーク上の位置に基づく暗黙の信頼を排除し、すべてのアクセス要求を検証する設計思想です。設計思想である以上、構成要素の一部にVPNが残っていれば、その部分には旧来のリスクがそのまま残ります。GSSの具体的な構成は公表されていませんが、侵入口はVPN機器の既知脆弱性でした。報道では、外部からの保守運用に利用していたVPN機器とされています（ITmedia ビジネスオンライン）。ゼロトラストを掲げた環境でも、外部に露出した機器の脆弱性対応が遅れれば、そこが入口になり得ると読むのが妥当です。
「検知できたのだから問題ない」
本事案では6月25日の検知が調査の起点になりましたが、侵入判明までに約2週間、公表までに約2か月半を要しています。松本大臣は9月15日の会見で、6月25日の時点では大量アクセスが正規の業務なのか第三者の不正利用なのかを直ちに判断できず、確認に時間がかかったと説明しています。正規アカウントが悪用されると、検知しても判断に時間がかかります。検知は被害の確定を防ぐ第一歩にすぎません。検知後に「いつから」「どこまで」を特定できるかは、ログの保持期間と調査体制で決まります。
「パッチを当てれば終わり」
外部接続機器にパッチを適用しても、適用前に侵入済みでないことの確認にはなりません。封じ込めの範囲は、侵入痕跡の調査と、窃取された可能性のある認証情報の失効まで含みます。
実務で問題になりやすいポイント
残存VPNの「所有者不在」
ZTNA移行後に残ったVPNは、移行プロジェクトの管理対象から外れ、保守契約の一部として委託先任せになりがちです。パッチ適用のSLA、脆弱性情報の受領経路、適用判断の責任者が文書化されていない状態は、見落とされやすいポイントです。
保守運用アカウントの統制
委託先が使う高権限アカウントは、人事システムと連動せず、MFAの適用対象からも漏れやすいです。休眠していても削除されず、行動ログの監視対象にも入っていません。退職・契約終了時の棚卸しが効かない「放置されがちな、人ではないが人が使うID」として、多くの企業で見落とされやすい領域です。
大量アクセス検知の閾値
GSS事案では大量ファイルアクセスの検知が機能しました。自社で同じ検知ができるか。保守アカウントの「平常時の挙動」を定義し、モニタリングしていなければ、異常の検知もできません。
CVSSだけで決める修正の優先度
GSS事案で悪用されたのは、当初CVSSでMediumと評価された既知の脆弱性でした。深刻度スコアだけで順番を決めると、インターネットに露出したVPN機器の中程度の脆弱性が後回しになります。外部から到達できるか、悪用が観測されているか（CISAのKEVへの登録など）、その機器を通るアカウントの権限がどれだけ大きいかを加味して、優先度を決める運用にしておくべきです。
技術的・運用的な確認ポイント
確認すべき対象は3層に分かれます。
| 層 | 確認対象 | 確認する項目 | 判断の基準 |
|---|---|---|---|
| 機器の層 | インターネットに露出しているVPN・リモートアクセス機器（全数列挙） | 用途（例：一般リモートワーク／委託先による保守／拠点間接続／機器メンテナンス） ファームウェアバージョン パッチ適用の責任者 パッチ適用までの標準日数 | 「ZTNA移行済みなので対象なし」と即答できない機器が1台でもあれば、その機器の取扱い（廃止か継続利用か）と担当者を決めた上で、継続的に確認する必要がある |
| アカウントの層 | VPN経由で認証できるアカウントのうち、委託先・保守用・共有利用のもの | MFAの適用状況 認証情報のローテーション周期 最終利用日 | 侵害を想定し、平時から認証情報をローテーションできる状態か（GSS事案の初動でも「関係アカウントの認証情報の変更」が封じ込め措置に含まれています） |
| 検知の層 | 保守アカウントの挙動と、VPN機器自体のログ | ファイルアクセス数・アクセス時間帯・接続元の平常値 逸脱時のアラート設計 認証ログ・設定変更ログの保持期間 | 侵入開始が検知の1か月前だった場合にログを遡れるか |
対応方針の比較表
| 方針 | 概要 | 効果 | 残るリスク | 向いている状況 |
|---|---|---|---|---|
| 残存VPNの完全廃止（ZTNA化） | 保守経路含め全アクセスをZTNAへ移行 | 攻撃面の構造的削減 | 委託先の契約改定・レガシー通信の非対応 | レガシーシステムや保守契約更新期を迎える組織 |
| 残存VPNの統制強化 | 台帳化・接続元制限・MFA・パッチSLA明文化 | 短期間で実行可能 | 機器の露出自体は継続 | 廃止が困難、または廃止まで時間がかかる組織 |
| 保守アカウントのJIT化 | 保守時のみ時限的に有効化・都度承認 | 休眠アカウント悪用の抑止 | 運用手順の整備コスト | 委託先が多い組織 |
| 検知強化のみ | 大量アクセス・異常挙動のアラート設計 | 被害確定前の発見可能性向上 | 侵入自体は防げない | 上記と必ず併用すべき（単独採用は非推奨） |
導入・見直し時のチェックリスト
- インターネット露出のVPN・リモートアクセス機器を全数台帳化した
- 各機器の用途・パッチ責任者・適用標準日数を文書化した
- VPN機器の脆弱性の優先度を、CVSSに加えて外部露出と悪用実績で判断する基準がある
- 委託先・保守用アカウントを全件抽出し、MFA適用状況を確認した
- 保守アカウントの認証情報ローテーション手順が存在する
- 保守アカウントの大量ファイルアクセスを検知するアラートがある
- VPN機器の認証ログ・設定変更ログの保持期間が調査要件を満たす
- 侵害判明時の封じ込め手順（アカウント停止・通信遮断・認証情報変更）が文書化されている
- 個人情報保護委員会への報告要否を判断する社内フローがある
経営層・監査部門への説明ポイント
経営層への説明ポイント
「政府共通基盤ですら破られた」という恐怖訴求ではなく、何が起き、自社はどうなっているのかという事実を順に示して説明すべきです。説明の骨子は3点です。
- ゼロトラスト投資は完了ではなく移行途中であり、移行しきれていない経路が残っていること。
- その経路（残存VPNと保守アカウント）の統制状況を今回棚卸しし、結果がこうであったこと。
- 廃止または統制強化に必要な予算と期間はこれだけであること。
GSS事案は「検知から公表まで約2か月半」という調査期間の実例でもあり、自社で同種事案が起きた場合の開示・報告スケジュール感を経営層と共有する材料になります。
監査部門への説明ポイント
監査部門が見るのは方針でなく、統制が設計どおりに運用されている証明
残存VPNと保守アカウントについては、以下の資料を提示できる状態にしておくと、指摘を受けてから探す事態を避けられます。
- 外部接続機器の台帳（用途・責任者・ファームウェアと適用履歴）
- 委託先・保守用アカウントの棚卸し記録と、MFA適用状況の一覧
- 認証情報のローテーションやアカウント停止を、規定どおりの周期で実施した記録
- 大量アクセス検知のアラート設定値と、検知時の対応記録
- VPN機器ログの保持期間の設定値と、実際に遡れたことを示せる証跡
- 侵害判明時の封じ込め手順と、外部への報告要否を判断する社内フロー
監査でよく問われるのは「認識していたか」でなく「いつ、誰が、何を実施したか」
- 残存VPNのような「廃止途上の設備」はこの記録が欠けやすいため、台帳に次回点検日を入れ、定期的な確認の記録を残す運用にするといいでしょう。
報告期限の評価も感覚でなく法令を基準にする
- 個人情報保護委員会の報告の期限は、速報が発覚日からおおむね3〜5日以内、確報が30日以内（不正な目的で行われたおそれがある場合は60日以内）です。
- 不正アクセスによる漏えいは後者に当たります。
- GSS事案では、7月9日に不正アクセスが判明して漏えいのおそれを確認し、6日後の7月15日に報告しています。この報告が速報か確報かは公表されていません。
監査に示すべきは以下2点
- 発覚から3〜5日で速報を出せる体制（報告要否の判断者と提出担当の事前指定）
- 30日・60日内に漏えい範囲と対象者数を特定できるログ保持と調査体制
実務担当者が次に取るべき対応ステップ
- 今週中：インターネット露出のVPN機器の全数把握と、未適用パッチの有無確認
- 今週中：委託先・保守用アカウントの一覧化と、休眠アカウントの停止
- 2週間以内：保守アカウントの大量アクセス検知アラートの設計・有効化
- 1か月以内：VPN機器ログの保持期間確認と、不足時の延長・外部保管
- 四半期内：残存VPNごとの廃止可否判断と、廃止不可のものの統制強化計画（JIT化・接続元制限・MFA）の策定
- 次回契約更新時：委託先保守契約へのリモートアクセス要件（ZTNA経由・監査ログ提供）の明記
まとめ
「ゼロトラストアーキテクチャを採用しておりましたが侵害されてしまいました」。この言葉を言う日が来るとすれば、その原因のひとつはおそらく、移行の主役だったZTNAの外側、たとえば脇に残ったVPNの脆弱性対応と、そこを通る保守アカウントの管理です。
今日やるべきことは明確です。残存VPNの台帳を開き、なければ作り、保守アカウントの一覧と突き合わせる。その台帳に「所有者不明」の行が1つでもあれば、その行の担当者を決め、廃止するか継続的な統制の下に置くかを今期中に判断してください。
この記事が誰かの助けになれば幸いです。
FAQ
Q1. デジタル庁GSS事案の侵入経路は何でしたか？
ネットワーク接続機器（VPN）の脆弱性です。第三者がこれを利用してシステムに侵入し、保守運用担当者のアカウントを利用してサーバ上の大量のファイルにアクセスしていました。悪用された脆弱性は攻撃前に公表済みで、当初の評価はCVSSでMediumでしたが、修正プログラムの適用前に悪用されました。VPNの製品名や脆弱性の識別番号は公表されていません。
Q2. 漏えいした可能性がある情報の規模は？
約24.6万件です。内訳は職員・公務員等が約18.9万件、GSS利用機関の業務に携わった事業者・個人が約5.7万件で、氏名、メールアドレス、電話番号、住所等が対象です。マイナンバーや口座情報は含まれていません。
Q3. ゼロトラストを導入していれば防げたのでは？
GSSはゼロトラストアーキテクチャを採用していたとデジタル庁が明言しています。構成の詳細は公表されていませんが、侵入口はVPN機器の既知脆弱性で、修正プログラムの適用前に悪用されました。ゼロトラストを採用していても、外部に露出した機器の脆弱性対応が遅れれば入口になり得ます。
Q4. 自社でまず何を確認すべきですか？
インターネットに露出しているVPN機器の全数把握、委託先・保守用アカウントの棚卸し、保守アカウントの大量アクセス検知の3点です。
Q5. VPNをすぐ廃止できない場合はどうすべきですか？
台帳化・接続元制限・MFA・パッチ適用SLAの明文化による統制強化と、保守アカウントの時限有効化（JIT化）を先行させ、契約更新時にZTNA化を進める二段構えを推奨します。
Q6. 検知から公表まで約2か月半かかったのはなぜですか？
デジタル庁は、侵入経路の分析、漏えいした可能性のある情報と対象者の特定に相当の時間を要したと説明しています。自社でも同様の調査には時間がかかるため、ログ保持と調査体制の事前整備が公表・報告の速度を左右します。
Q7. 保守運用アカウントはなぜ狙われやすいのですか？
高権限でありながら人事連動の棚卸し対象から漏れやすく、MFAや行動監視の適用も後回しになりがちなためです。委託先が利用する場合は自社の統制が届きにくく、休眠状態でも残存しやすい特性があります。
