デジタル庁 GSS(ガバメントソリューションサービス)への不正アクセス、問題は「侵入されたこと」だけではない　保守運用アカウントの権限とゼロトラスト設計を検証

デジタル庁のガバメントソリューションサービス（GSS）への不正アクセスでは、VPNの脆弱性を利用した侵入だけでなく、侵入後に保守運用担当者のアカウントを利用してサーバ上の大量のファイルへアクセスされた点を検証する必要があります。

デジタル庁は2026年9月11日、GSSへの不正アクセスにより、職員や業務関係者の個人情報約24.6万件が外部へ漏えいした可能性があると公表しました。9月12日に更新したQ&Aでは、攻撃に悪用されたVPN機器の脆弱性について、当初公表されていたCVSS評価は「Medium」だったことも明らかにしています。

具体的なCVE番号は、セキュリティ確保への影響を理由に公表されていません。このため、当該脆弱性がCISAのKnown Exploited Vulnerabilities（KEV）Catalogに掲載されているかなど、個別CVE単位の確認はできません。

今回の事案は、CVSSの数値だけでパッチ適用順を決めることの限界も示しています。米CISAは、既に悪用が確認された脆弱性をKEV Catalogで管理し、連邦政府機関に期限を定めた修正を求めています。CISAの脆弱性優先順位付けではCVSSだけでなく、実際の悪用状況、技術的影響、組織のミッションへの影響なども判断材料にしています。

GSSは、各府省庁の業務用PCやネットワーク環境を政府共通基盤へ統合し、セキュリティを底上げ・均質化することを目的としています。ゼロトラストアーキテクチャを採用し、「境界内に侵入されることもありき」で端末や通信を監視し、異常時には遮断して横展開を防ぐ考え方も示していました。

その前提に照らすと、今回の論点は「VPNに脆弱性があった」という入口の問題だけではありません。

保守運用アカウントにどの範囲までアクセス権が与えられていたのか。複数機関にまたがる情報へのアクセスをどこまで分離できていたのか。大量アクセスを検知した後、アカウントやセッションをどのように制御する設計だったのか。政府共通基盤を拡大する際、管理権限の集中による被害半径をどう抑えるのか。

加えて、CVSSがMediumであっても、インターネットから到達可能なVPN機器や共通基盤への入口であれば、組織側の実質的なリスクは高くなる場合があります。

今回の事案は、共通基盤における「特権アクセスの設計」「ゼロトラストの実装」「実悪用を前提とした脆弱性管理」を検証する材料になっています。

今回事案で問われる6つの問題

論点	公表資料から確認できる事実	問われる点
脆弱性の優先順位	悪用されたVPN脆弱性の当初評価はCVSS Medium	CVSSの高さだけで対応期限を決めていなかったか
保守運用アカウントの権限	保守運用担当者アカウントを利用し、サーバ上の大量ファイルへアクセス	1つの管理系IDが侵害された場合の被害半径
複数機関への影響	GSS利用機関の職員や業務関係者など、複数機関に関係する情報が対象	組織・システム単位の権限分離とデータ分離
ゼロトラストとの整合	GSSは継続的監視と異常時の遮断による横展開防止を説明	認証後の行動監視とアクセス制御
検知後の対応	6月25日に大量アクセスを検知。デジタル庁は検知直後から被害拡大防止措置を実施し、7月9日に侵入経路を特定してアカウント停止・外部通信遮断	調査と封じ込めを並行できる運用設計
共通基盤の集中リスク	GSSは各府省庁の環境を統合する政府共通基盤	管理権限や運用経路まで集中した場合の最大影響範囲

CVSS「Medium」でも実際の攻撃に悪用された

9月12日にデジタル庁が更新したQ&Aでは、今回悪用されたVPN機器の脆弱性について、当初公表されていた脆弱性評価がCVSSの「Medium」だったことが明らかになりました。

脆弱性自体は攻撃が確認される前に公表されており、デジタル庁も一般的な対応より早く対処を進めていたと説明しています。しかし、修正プログラムを適用する前に脆弱性が悪用されました。

ここで注意したいのは、CVSSが低い、または中程度だから「攻撃されにくい」とは限らないことです。

CVSS Base Scoreは、その脆弱性が持つ技術的な深刻度を共通尺度で示すものです。CVSSを管理するFIRSTも、CVSS v4.0のガイドで、Base Scoreはseverity（深刻度）を測るものであり、単独でrisk（リスク）を評価するためのものではないと説明しています。

実際の組織リスクは、脆弱性そのものの技術的性質だけでなく、

• インターネットから到達できる機器か
• VPN、ファイアウォール、認証基盤など侵入の入口になる機器か
• 攻撃コードや具体的な悪用情報が出回っているか
• 実際の攻撃で利用されているか
• 侵害後に得られる権限が大きいか
• その機器から重要システムへ到達できるか
• 対象システムが行政、医療、製造など重要業務を支えているか

によって変わります。

今回のGSS事案では、CVSS MediumだったVPN機器の脆弱性が、政府共通基盤への侵入経路として実際に利用されました。

「CriticalとHighを先に対応し、Mediumは通常サイクルで処理する」という一律の運用では、同様の事案を取りこぼす可能性があります。

米CISAはCVSSだけではなく「実際に悪用されているか」を優先する

米国の政府機関では、CVSSだけを基準に脆弱性対応の優先順位を決める考え方から、実際の攻撃状況を重視する方式へ移行しています。

CISAは2021年、Binding Operational Directive 22-01を発出し、Known Exploited Vulnerabilities（KEV）Catalogを運用しています。

KEVは、実際の攻撃で悪用されていることを確認した脆弱性を収録するカタログです。米連邦文民行政機関（FCEB）は、KEVに掲載された脆弱性をCISAが指定する期限までに修正する必要があります。

BOD 22-01の説明資料では、それまでCVSSを中心に脆弱性を優先していた方式から、既知のエクスプロイトが存在し、攻撃者による悪用が確認されている脆弱性を優先する戦略へ変更したと説明しています。

CISAは同資料で、実際に悪用されている脆弱性の中には、CVSS上「Medium」や「Low」と評価されるものもあると指摘しています。

つまり、米政府の考え方は、

「CVSSが何点か」

だけではなく、

「今、攻撃者が使っているか」

を脆弱性管理の優先順位に直接反映するものです。

今回GSSで悪用された脆弱性のCVE番号は公表されていないため、KEV掲載の有無を確認することはできません。ただし、「Medium評価だった脆弱性がパッチ適用前に実際に悪用された」という事実は、CISAがKEVを重視する理由と重なります。

CISAのSSVCは「組織にとっての影響」まで評価する

CISAは、KEVとは別にStakeholder-Specific Vulnerability Categorization（SSVC）という脆弱性の優先順位付け手法も提供しています。

SSVCは単純な点数順ではなく、脆弱性ごとに判断木を用いて、Track、Track*、Attend、Actの4段階に分類します。

CISAが判断に利用する主な要素には、

• Exploitation：悪用状況
• Technical Impact：技術的影響
• Mission Prevalence：組織のミッションに対する対象システムの重要度・広がり
• Public Well-Being Impact：安全や社会への影響

などがあります。

「Act」と判定された脆弱性について、CISAは可能な限り早く対応することを推奨しています。

この考え方をGSS事案へ当てはめると、VPN機器の脆弱性のCVSSがMediumであっても、政府共通基盤の外部接続点であり、侵害後に保守運用アカウントの悪用へつながる可能性があるなら、組織固有の優先度を引き上げる余地があります。

脆弱性管理では「脆弱性のスコア」と「その脆弱性が自社で悪用された場合の結果」を分けて評価する必要があります。

NISTも2026年、KEVや政府利用ソフトウェアを優先する運用へ

米国立標準技術研究所（NIST）も2026年4月、National Vulnerability Database（NVD）のCVE情報拡充について、新しい優先順位を公表しました。

NISTは2026年4月15日以降、CVEのエンリッチメントを優先する対象として、

1. CISA KEV Catalogに掲載されたCVE
2. 米連邦政府で利用されているソフトウェアのCVE
3. Executive Order 14028で定義されるCritical SoftwareのCVE

を挙げています。

これは、公開されたすべてのCVEをCVSS順に処理する考え方ではありません。

「実悪用されているか」「政府環境で利用されているか」「重要ソフトウェアか」という、運用環境と脅威情報を優先順位へ反映しています。

NIST SP 800-40 Rev.4も、パッチ管理を単なる更新作業ではなく、組織のリスクを低減するための予防保守として位置付けています。

GSSのような政府共通基盤だけでなく、企業でも脆弱性の対応期限を決める際は、CVSSと資産の重要度、外部公開状況、実悪用情報を組み合わせる必要があります。

最大の論点は「1つの保守運用IDが侵害された場合の被害半径」

今回の事案で脆弱性管理と並んで検証すべきなのが、侵入後に利用された保守運用担当者アカウントの権限です。

デジタル庁は6月25日、保守運用担当者のアカウントを利用してサーバ上の大量のファイルへアクセスする動きを検知しました。

その後の調査では、GSS利用機関の職員、公務員等、GSS利用機関の業務に携わった事業者や個人など、複数機関に関係する情報を含むファイルが影響範囲に入っています。

ここで確認したいのは、攻撃者が正規の保守運用IDを利用できる状態になった後、どの程度まで内部リソースへ到達できたかです。

共通基盤の保守担当者には、障害対応や設定変更のため、一般利用者より強い権限が必要になる場合があります。しかし、その権限が複数組織のシステムやデータへ横断的に及ぶ場合、1つのIDが侵害されたときの被害も大きくなります。

セキュリティ設計では、管理者アカウントを「侵害されない前提」で扱うのではなく、侵害された場合でも被害範囲を限定できるようにします。

システム単位、組織単位、作業単位で管理権限を分ける。恒常的な広範囲権限を避ける。通常は特権を無効化し、作業時だけ必要な範囲で有効化する。こうした最小権限の設計が、共通基盤ほど必要になります。

NISTのゼロトラストアーキテクチャも、ネットワークの内外ではなく、個別リソースへのアクセスを都度判断する考え方を示しています。CISAのZero Trust Maturity Modelでは、成熟した状態のアクセス管理としてJust-in-Time（JIT）やJust-Enough Accessによる動的な最小権限を挙げています。

今回問われるのは、「保守担当者だから広い権限が必要だった」で終わらせず、その権限が常時必要だったのか、侵害時にどこまで影響を限定できる設計だったのかという点です。

GSSでは共有IDを禁止　問題は「誰が使ったか」より「何ができたか」

GSSの運用要件を確認すると、今回の問題を「共有アカウントの管理不備」と捉えるのは適切ではありません。

2025年度のGSS運用調達に関するデジタル庁の回答では、運用作業者は「個人に紐づけられたID」とGSS専用端末を利用することが必須であり、IDと端末の共有利用は禁止との認識について、デジタル庁が「ご認識のとおり」と回答しています。

つまり、GSSは少なくとも運用要件上、誰が操作したのかを追跡できる個人単位のID利用を前提にしています。

それでも今回、保守運用担当者アカウントが第三者に利用され、大量のファイルアクセスに至りました。

この事実から見るべきなのは、「IDを個人に割り当てていたか」だけではなく、そのIDが認証された後に何ができる設計だったかです。

個人ID化は操作の追跡には有効ですが、権限の広さを制限するものではありません。

個別IDであっても、1つのIDが複数機関のサーバやデータへ広くアクセスできれば、認証情報を悪用された際の影響は大きくなります。

ID管理とアクセス権管理は別の問題です。

「ゼロトラスト採用」だけでは不十分　認証後の権限制御が焦点

デジタル庁はGSSについて、ゼロトラストアーキテクチャを採用した政府共通の業務環境と説明しています。

2026年2月のデジタル庁資料では、GSSのゼロトラストセキュリティについて、

• 境界内に侵入されることもありきで対策
• 端末や通信の挙動を常に監視
• 即時の遮断等によって横展開を防ぐ

という考え方を示しています。

2024年のデジタル庁ニュースでも、ユーザーや端末へIDを割り当て、アクセスを継続的に監視・確認すると説明していました。

今回も、大量のファイルアクセスそのものは検知されています。その意味では「監視が全く機能しなかった」というわけではありません。

問題は、その後に攻撃者が利用できる権限とデータの範囲をどこまで限定できるかです。

ゼロトラストでは、一度認証を通過したIDだからといって、その後の操作を無条件に信用する考え方を取りません。

どのリソースへアクセスしようとしているのか。通常とは異なる量のデータへアクセスしていないか。接続元の端末や通信経路に異常がないか。操作内容がその担当者の通常業務から外れていないか。

こうした情報をもとに、認証後もアクセス可否を継続的に判断します。

今回の事案は、ゼロトラストを「VPNの代替」や「ログイン時の認証強化」としてではなく、認証後の権限範囲と行動制御まで含めて実装できているかを問い直すケースです。

「横展開を防ぐ」という設計思想と複数機関への影響

GSSのゼロトラスト資料では、「即時の遮断等→横展開を防ぐ」という説明があります。

今回の公表では、保守運用担当者のアカウントを利用した大量アクセスが発生し、複数のGSS利用機関に関係する情報が影響範囲となりました。

ネットワーク上の「横展開」と、管理アカウントを使った正規経路からのデータアクセスは同一ではありません。

しかし、ゼロトラストが目指すのは、攻撃者が一度内部へ入った後に広範囲へアクセスできる状態を避けることです。

その観点では、ネットワークセグメントだけではなく、

• 機関ごとのデータ分離
• アプリケーションごとのアクセス制御
• 管理者権限の分割
• 管理プレーンと業務データの分離
• セッション単位の認可
• 大量アクセス時のポリシー変更

まで含めて検証する必要があります。

GSSが利用機関・利用者を増やすのであれば、「1つの保守運用IDが侵害された場合、最大で何機関・何システム・何件の情報へ到達できるのか」を設計指標として管理する考え方があります。

検知から封じ込めまで、調査と制御を並行できるか

今回の時系列では、6月25日に保守運用担当者アカウントを利用した大量ファイルアクセスを検知し、調査を開始しています。

デジタル庁は9月12日更新のQ&Aで、検知直後から被害拡大防止措置を講じたと説明しています。

その後、7月9日に第三者がVPN機器の脆弱性を利用して侵入していたことが判明し、同日、当該アカウントを停止するとともに、侵害された機器と外部との通信を遮断しました。

このため、「6月25日の検知から7月9日まで何も封じ込めをしなかった」と評価することはできません。

一方、具体的に6月25日から7月9日までどのような暫定措置を行ったのかは公表されていません。

実務上の論点は、調査が完了するまで全面的な権限を維持するのではなく、リスクに応じて段階的にアクセスを制御できるかです。

例えば、

• 対象セッションだけを失効する
• 一時的に管理権限を縮小する
• 特定サーバへのアクセスを止める
• 通常を超える大量取得を制限する
• 管理端末を隔離する

といった選択肢を事前に用意しておけば、「全面停止」か「継続利用」かの二択を避けられます。

検知能力と封じ込め能力は別に評価する必要があります。

共通基盤はセキュリティを均質化する一方、管理権限の集中リスクを持つ

GSSは、各府省庁が個別に構築していた業務用PCやネットワーク環境を共通化する取り組みです。

デジタル庁は、GSSによって情報セキュリティを底上げ・均質化し、政府全体のネットワークを効率化できると説明しています。

個別の府省庁がそれぞれネットワークやセキュリティ製品を管理するより、共通基盤で脆弱性管理、監視、端末管理、認証を統一した方が管理水準を揃えやすくなります。

一方、統合されるのは利用環境だけではありません。

運用管理、ネットワーク設定、監視、保守作業も一元化されるほど、管理系のアカウントや運用経路は攻撃者にとって価値の高い標的になります。

共通基盤では、通常の利用者数だけでリスクを測ることはできません。

確認したいのは、「1つの管理アカウントが侵害されたとき、どこまで届くか」です。

利用機関を増やすほど、この最大影響範囲を小さくするための権限分割やセグメンテーションも同時に強化する必要があります。

VPNのパッチ管理は「CVSS順」から「実質リスク順」へ

デジタル庁は今回の事案を受け、VPNへの修正プログラム適用に加え、脆弱性管理方法の見直しと外部からの接続方法の改善を進めています。

9月12日のQ&Aでは、今後について「政府情報システムの重要性を考慮し、より実質的なリスクに基づいて迅速かつ先行的な対応」を行えるよう脆弱性管理を強化すると説明しています。

この方向性は、CISAやNISTが採用しているリスクベースの考え方とも重なります。

企業の脆弱性管理でも、単に、

• Critical：即時
• High：○日以内
• Medium：次回定例
• Low：余裕があれば対応

とCVSSだけで機械的に期限を決めるのではなく、少なくとも次の情報を組み合わせます。

判断材料	確認内容
CVSS	技術的な深刻度
CISA KEV	実際の攻撃で悪用が確認されているか
ベンダー情報	悪用確認、PoC、攻撃観測、緩和策の有無
外部公開状況	インターネットから到達できるか
資産の役割	VPN、FW、IdP、AD、バックアップなど侵害時の影響が大きい機器か
権限・到達範囲	侵害後に重要システムや管理ネットワークへ到達できるか
業務影響	停止・漏えい時に事業や行政サービスへどの程度影響するか
EPSS等	悪用可能性を補助的に評価できる情報があるか

特にVPN、ファイアウォール、認証基盤、リモート管理機器のようなインターネット境界の製品は、CVSS Mediumでも「通常のMedium」と同じ期限で扱わないルールを設ける方法があります。

情報システム部門が確認したい脆弱性管理と管理ID

今回の事案を企業へ置き換えると、脆弱性管理と管理アカウント管理を別々の運用にしないことがポイントになります。

確認項目は次のとおりです。

• CVSSだけでパッチ適用の優先順位を決めていないか
• CISA KEVを脆弱性管理の判断材料として取り込んでいるか
• ベンダーが「悪用確認」「攻撃観測」を公表した場合、CVSSに関係なく優先度を上げられるか
• VPN、FW、IdPなど外部公開機器のMedium脆弱性について別のSLAを設定しているか
• インターネットから到達可能な機器を資産台帳から抽出できるか
• パッチ未適用期間中にアクセス制限、機能停止、ACL変更などの緩和策を適用できるか
• 1つの管理IDでアクセスできる会社・部署・システムを一覧化できるか
• 管理権限を業務単位・システム単位に分割しているか
• 通常時は特権を無効にし、作業時だけ付与できるか
• 管理IDで大量データへアクセスした場合に検知できるか
• 異常時に対象セッションだけを停止できるか
• 管理端末から到達できるネットワーク範囲を限定しているか
• 子会社や部門をまたぐデータアクセスを必要最小限にしているか
• 管理ID侵害時の最大影響範囲を定期的にレビューしているか

ゼロトラストの導入状況を評価する場合も、「製品を導入しているか」ではなく、管理IDを奪われた場合の最大到達範囲をどこまで縮小できているかを見る方が実態を把握できます。

同様に脆弱性管理も、「Criticalを何日以内に直したか」だけでは不十分です。

CVSS Mediumでも、実悪用が確認された、外部公開されている、重要な認証経路になっている、侵害時の到達範囲が広いといった条件が重なれば、CriticalやHighより先に修正する判断が必要になる場合があります。

今回のGSS事案から得られる論点は、VPN製品や攻撃手法の特殊性ではありません。

脆弱性のスコアだけでは実際の攻撃リスクを表せないこと、正規の保守運用アカウントを第三者に使われた場合の被害半径を事前に制限しておくこと、検知後に調査と封じ込めを並行できることです。

政府共通基盤でも企業グループの共通IT基盤でも、「脆弱性の深刻度」「実際の悪用状況」「資産の重要度」「侵害後の到達範囲」を組み合わせて優先順位を決める必要があります。

ゼロトラストの基本原則については「ゼロトラストとは？概念や今までのセキュリティとの違いを解説」でも整理しています。

出典

• ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について – デジタル庁
• 「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A – デジタル庁
• ガバメントソリューションサービス – デジタル庁
• 事務局説明資料（第1回デジタル・サイバーセキュリティWG） – デジタル庁
• 令和7年度ガバメントソリューションサービスの運用一式 調達仕様書等の意見招請に対する回答 – デジタル庁
• 行政の働き方改革のリアルを「人事院×GSS導入」で徹底解説 – デジタル庁ニュース
• Zero Trust Architecture（SP 800-207） – NIST
• Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology（SP 800-40 Rev.4） – NIST
• NIST Updates NVD Operations to Address Record CVE Growth – NIST
• Known Exploited Vulnerabilities Catalog – CISA
• Reducing the Significant Risk of Known Exploited Vulnerabilities / BOD 22-01 Fact Sheet – CISA
• Stakeholder-Specific Vulnerability Categorization（SSVC）Guide – CISA
• CVSS v4.0 User Guide – FIRST