文章总结： 日本数字厅披露GSS平台数据泄露事件，约24.6万条个人信息外泄。攻击利用已发布补丁的中危VPN漏洞，配合权限过大的运维账号，通过行为异常被发现，检测到披露隔78天。事件暴露补丁管理流程未闭合、零信任架构不解决入口安全、共享基础设施爆炸半径大等问题。建议将边界设备补丁管理设为有SLA的工程，强化运维账号认证与审计，建立文件访问行为基线告警，并对共享基础设施做爆炸半径评估。 综合评分： 88 文章分类： 应急响应,漏洞分析,安全建设,安全意识,解决方案

---

补丁早就发布了：日本政府 GSS 事件完整技术复盘

浩凯信安 浩凯信安

浩凯信安

2026年9月16日 13:42 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

2026 年 9 月 11 日，日本数字厅披露了一起数据泄露事件：约 24.6 万条个人信息可能外泄。

但真正值得安全从业者停下来看的，不是这个数字。是另外三个事实。

第一，被利用的漏洞不是 0day，危害评级只有中危，而且攻击者动手的时候，补丁已经发布了。

第二，这套系统已经采用了零信任架构（Zero Trust Architecture）。

第三，出事的 GSS 平台，连接着日本 23 个省厅。打一个点，理论上同时暴露 23 个机构。

再加上一个时间上的刺：6 月 25 日就检测到异常，9 月 11 日才对外披露，中间隔了 78 天。

这篇文章，我把公开信息拼成一条完整链路，拆开给你看。因为这三条里随便哪一条，都可能正躺在你自己的环境里。

一、事故回放：78 天里到底发生了什么

按数字厅公布的信息，整件事的时间线是这样的：

| | | | — | — | | 时间 | 发生了什么 | | 2026-06-25 | 检测到异常——有人正在用一个「维护运维人员账号」，在服务器上大量访问文件。数字厅启动调查 | | 2026-07-09 | 查明真相：第三方利用了联网 VPN 设备的漏洞侵入系统，取得未授权访问。同一天，停用该维护账号、切断受损设备与外部世界的一切通信 | | 2026-07-15 | 向日本个人信息保护委员会报告 | | 2026-09-11 | 对外公开披露 |

有两条细节值得单独拎出来。

第一，发现异常靠的是「行为」而不是「告警」。 触发调查的，是「某个账号访问了大量文件」这个模式——不是 IPS 报了什么，不是 EDR 拦了什么。也就是说，漏洞被利用的那一刻，没有拦住；是攻击者开始翻文件之后，行为层面才露出马脚。

第二，从确认入侵方式到对外披露，隔了 63 天。 数字厅给的解释是：追溯入侵路径、确定受影响数据的范围、逐一识别受影响的人，这套流程很复杂。这个解释在技术上是成立的——但也说明一件事：出事的系统，平时并没有把「谁碰了哪些数据」这件事记录到可以快速回溯的粒度。不然不需要 63 天。

图：GSS 事件时间线：检测到披露隔了 78 天

二、数据到底泄了什么

先把数字拆干净。

约 24.6 万条，按主体分：

| | | | — | — | | 主体 | 数量 | | GSS 用户机构的职员，以及参与其业务的公职人员（含独立行政法人职员） | 约 18.9 万 | | 参与 GSS 用户机构业务的事业者及个人 | 约 5.7 万 |

按属性分（数字之间有重叠，同一个人可能被多个字段计数）：

| | | | — | — | | 字段 | 数量 | | 姓名 | 约 23.6 万 | | 邮箱地址 | 约 23.1 万 | | 电话号码 | 约 9.4 万 | | 地址 | 约 1000 |

没泄的，和泄了一样重要。 数字厅明确说明：不含 My Number（个人编号）、不含金融机构账户信息、不含年金编号；也不含普通民众的个人信息。

泄漏数据的来源也交代得很清楚：使用 GSS 必须先提交用户登记申请表，表里要填代表人姓名、公务用电话号码、办公场所地址。泄的就是这批登记信息。

数字厅还补了一句很关键的说明：很多电话和地址并不是个人的，而是各省厅政府建筑所在地和公务联络方式。

这一句其实降低了实际危害等级。但同时也暴露了另一个问题：这批数据的采集本身就没有做用途和敏感度的分层——个人联系方式、公务场所地址、代表人信息，全都躺在同一张表里，一起被打包带走。

三、攻击链拆解：为什么「中危」就够了

数字厅没有公布 VPN 设备的型号，也没有公布具体漏洞。但公开信息已经足够把攻击链画出来。

第一步：从公网入口进。

攻击者利用的是 GSS 网络所使用的一台联网 VPN 设备上的漏洞。对照 MITRE ATT&CK，这一步同时命中两个技术点：T1190 利用面向公网的应用程序 和 T1133 外部远程服务。

VPN 网关天生就是这类目标——它必须在公网上可达，它是所有远程流量的解密终点，而且一旦拿下它，攻击者就站在了内网的门口。这也是为什么最近的 Check Point VPN 漏洞会让荷兰 NCSC 直接警告「利用即将发生」，让厂商紧急发热修。

第二步：拿一个有效账号。

这一步是整条链里最值得琢磨的。攻击者并没有自己造一个账号，而是使用了「维护运维人员账号」进入系统——对应 T1078 有效账号。

维护运维账号的特点是什么？

· 权限大：它要能改配置、能重启服务、能排查故障，所以通常有较高的系统权限。

· 长时间存在：这类账号往往一开就是几年，很少清理。

· 登录位置灵活：运维本来就是远程干活，所以「从非常规位置登录」很难被当成异常。

· 认证方式弱：很多环境里，它还是「账号密码 + 一张静态证书」，不做强绑定。

VPN 漏洞负责「进得来」，维护账号负责「进得深」。 两者叠在一起，杀伤力远大于各自单看。

第三步：找数据。

进来之后，攻击者的行为很朴素：大量访问服务器上的文件——T1005 本地系统数据、T1213 信息仓库数据。

没有花哨的横向移动，没有提权链，没有内核利用。就是翻文件、挑数据、带走。

这恰恰是最难防的一步：在你有权限访问的数据里，合法读取和恶意读取在网络层看起来是一样的。

第四步：外传。

数据被带出。数字厅在事后调查中确认「存在个人信息可能已外泄到外部的可能性」，但没有公布外传的具体通道与数据量。

整条链看下来，注意一件事：没有一步需要「高危漏洞」或者「0day」。 一个中危的 VPN 漏洞 + 一个权限过大的长期账号 + 一次没人及时看的异常文件访问，24.6 万条数据就这么出去了。

图：GSS 事件攻击链四步拆解

四、三个最扎心的点

4.1 补丁早就发布了，但没装上

这是整个事件里最不应该发生的一点。

数字厅自己的说法是：被利用的漏洞不是零日漏洞，评级为中危；而且据媒体报道，攻击者利用它的时候，补丁已经可用了。

那问题就变成了：一个已知的、有补丁的中危漏洞，为什么还留在 23 个省厅共用的基础设施上？

数字厅在 Q&A 里描述了他们的漏洞管理流程：持续收集和评估漏洞情报、核对厂商发布的漏洞信息与各类预警、评估影响、采取必要措施。

流程是有的。 但他们同时承认：这次漏洞仍然被攻击者利用了，因此将「重新审视从识别漏洞信息，到评估、实施对策的整个流程」。

这句话翻译过来就是——流程存在 ≠ 流程闭合。中间那一段从「我们知道有这个漏洞」到「补丁真的装到这台设备上」的路，断了。

4.2 采用了零信任架构，然后被打穿了

这一条我认为是本事件最有信息量的部分。

记者问得很直接：GSS 不是已经上了零信任架构吗？为什么还是不安全？

数字厅的回答原话大意是：

我们采用了零信任架构，但结果上，仍然发生了非法访问和信息泄露的可能性，我们对此非常重视。

这是一个非常诚实的回答，也是一个值得所有正在做零信任改造的团队抄在备忘录上的回答。

零信任解决的是「信任边界」问题——不再默认内网可信、每个访问都要验证。它不解决「被利用的设备」问题。

如果你的 VPN 网关本身就是零信任架构里的一个组件，攻击者拿下了这个组件，那么他就是从一个「已经被信任的组件」往外发起的访问。零信任不会跳出来说「你不对劲」，因为从它的视角看，请求来自一条合法的隧道、一个合法的账号。

架构决定的是「攻击者进来之后能走多远」，而不是「攻击者进不进得来」。 入口的问题，永远要靠补丁、收敛暴露面、强认证去解。

4.3 23 个省厅，共用一套基础设施

GSS 全称 Government Solution Service，由数字厅运营，连接日本 23 个省厅，是典型的共享 IT 基础设施。

共享基础设施的收益很明确：省钱、统一标准、集中运维、统一安全策略。

但它的代价同样明确：爆炸半径是共享的。

打一个平台，理论上同时暴露 23 个机构的数据。这次事件里，18.9 万政府人员 + 5.7 万外部合作者，全部出自同一批登记表。

而且共享基础设施还有一个隐性风险：它会把「最弱的那一环」变成所有人的短板。 23 个机构里，只要有一台 VPN 设备的补丁没跟上、只要有一个运维账号的权限没收紧，所有人一起承担后果。

数字厅事后表示「影响仅限于该系统本身，未确认其他系统有类似损害」。这是在说横向没有扩散——但数据层面的影响已经发生了。

五、给防守方的清单

复盘的价值，在于能带走什么。下面这几条，我认为是从这起事件里最该抄走的。

1）把「补丁管理」当成一个有 SLA 的工程，而不是一个流程文档。

这次事件的根因不是「不知道」，是「知道了没装完」。建议做法：

· 对面向公网的边界设备（VPN 网关、防火墙、负载均衡、堡垒机）单独建一张台账，它们是优先级最高的一档；

· 给每一档设定明确的修复时限，并且把时限做成可考核的指标，而不是一句「尽快」；

· 关键点：修复的完成标准是「验证已生效」，不是「工单已关闭」。

2）把运维账号当成攻击者的首选目标来设计。

这次攻击者没有造账号，用的是现成的运维账号。所以：

· 运维账号强制短时凭据（比如按次签发的证书、SSH 证书、动态令牌），用完即失效；

· 运维登录绑定来源：固定跳板机、固定出口 IP、固定时间窗；

· 运维操作全程录屏或命令级留痕，并且这些日志要离开运维自己的权限范围存放——不然攻击者拿到账号后第一件事就是清日志；

· 长期不用的运维账号自动回收。

3）把「大量文件访问」做成一条能自动告警的规则。

这是本次唯一真正起作用的检测手段。它的逻辑很简单，但价值极高：

同一个主体，在短时间内，访问的数据量或文件数，显著偏离它的历史基线。

这条规则不依赖任何特征库，不依赖漏洞是否已知，也不依赖攻击者用的是什么手法。它检的是行为本身不合理。

落地时要盯住三类主体：运维账号、服务账号、以及任何具有批量读取权限的账号。它们平时的行为模式很稳定，一旦偏离，信噪比非常高。

4）对「共享基础设施」单独做一次爆炸半径评估。

如果你的环境里有那种「一套系统支撑多个业务线 / 多个子公司 / 多个部门」的组件，问自己三个问题：

· 拿下这一台，能看到多少数据？

· 这些数据里，有没有本来不该放在一起的（个人联系方式 + 组织架构 + 业务关系）？

· 数据采集的时候，有没有做用途分层和敏感度分级？还是全都躺在一张申请表里？

第三问尤其重要。这次泄露的数据全部来自用户登记表——如果当初按敏感度分了层，即使被打穿，一次也拿不走这么整齐的一批。

5）零信任要做，但不要把它当成入口安全的替代品。

零信任该做，它确实能显著压缩横向移动的空间。但它管不了「你的 VPN 设备本身有漏洞」这件事。

正确的姿势是两条线同时推进：入口侧收敛暴露面、快速修补、强认证；内部侧做零信任、最小权限、行为检测。缺任何一条，另一条的价值都会大打折扣。

写在最后

把这件事压缩成一句话：

它不是一个被攻破的系统，它是一个没有被及时修好的系统。

没有 0day，没有 APT 级的手法，没有内存破坏。只有一个已知的、中危的、有补丁的漏洞，一个权限过大的长期账号，和一个 78 天之后才被公众知道的下午。

这也是它最值得警惕的地方——大多数真实事故，长得就是这副样子。 不惊悚，不高级，全是「本来可以」。

日本公共部门的这起事件也不是孤例。NISC 在 2023 年披露过邮件系统被入侵，JAXA 在 2024 年报告过未授权访问。把这几件事摆在一起看，指向的不是某一次技术失误，而是补丁管理与访问控制在公共部门基础设施上的系统性挑战。

对国内的安全团队来说，这次事件至少有两条直接的镜鉴：

第一，边界设备的补丁，值得单独拉一条流水线。 它们暴露在公网、承载全部远程流量、一旦被拿下就等于站在内网门口。别让它们和内部业务系统排在同一个补丁队列里。

第二，你要能回答一个问题：如果今天有人用了一个合法的运维账号在翻文件，你要多久才会知道？

如果你的答案是「不知道」，那么这次事件里最值钱的教训，你还没拿到。

参 考

· 日本数字厅官方说明与 Q&A（2026-09-11）—— digital.go.jp

· Zero Day News / BleepingComputer / TechNadu 相关报道（2026-09）

· Enigma Global Threat Intelligence Report（2026-09-15）

说明：本文所有事实均来自日本数字厅官方披露与公开报道，未披露的细节（VPN 设备型号、具体漏洞编号、外传通道）本文不做推测。文中攻击链映射使用 MITRE ATT&CK 框架，目的是帮助防守方对照自身环境，不构成任何攻击方法指引。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：浩凯信安 浩凯信安 浩凯信安《补丁早就发布了：日本政府 GSS 事件完整技术复盘》