跳到正文
>_ITDITDWeb 安全平台

安全指南

组织的安全底线在哪里?从 2026 年日本的真实事故倒推的 6 个优先事项

组织最低限度该做的安全对策,从 2026 年日本公布的大型事故(KDDI、Aflac、日本数字厅、樱花互联网、Gyazo 等)的官方公告倒推:面向互联网的设备、外包与维护账号、流量监控、日志保存期限、不该保留的数据、重新排定优先级。

发布于 2026-06-11 更新于 2026-09-27 3 分钟阅读

适合谁读:有员工和外包方参与、需要决定安全“底线”放在哪里的企业与组织。个人开发者和小规模运营者请看 个人开发与小规模运营的安全底线。本文把本站根据各组织自身的官方公告分析过的 2026 年日本事故,重新倒推为组织层面的对策。不涉及攻击步骤。

事故暴露出的 6 个漏洞

以下都是本站根据各组织官方公告解读过的事件(日文与英文版有详细解说)。

公布的事实暴露的漏洞组织的底线
日本数字厅:经由 VPN 设备的漏洞入侵;记者会上说明当时正在按顺序打补丁面向互联网的设备的更新在“排队”① 按期限封堵入口设备
日本数字厅:检测到通过维护运营人员账号对服务器上大量文件的访问非本公司员工账号的权限与监控② 收窄维护、外包、离职人员的账号
Aflac:攻击与正常使用形式相同而未能立即检测;缺少对短时间大量查询的监控与控制功能每一次都“合法”的访问的数量③ 监视数量与时间
樱花互联网:对销售管理系统的非法访问发生在 2023 年 4 月至 2026 年 3 月;再发防止措施包括重新审视日志的采集范围与保存期限发现时已无法回溯④ 日志保留到能回溯的期限
Gyazo:泄露的元数据主要是 2019 年 1 月以前的不再需要的数据仍被保留⑤ 不保留不再需要的数据
Adobe Commerce:8 月 11 日发布修复,44 天后确认被利用(列入 KEV),公告仍写着“优先级 2、未发现被利用”相信发布时的优先级而推迟⑥ 用 KEV 重新排定优先级

怎么读这张表:不是用来指责,而是用来自查

各组织在被入侵后进行调查,并公布了原因和再发防止措施。本站把这些报告不当作别人的事,而当作“我们是否也有同样的漏洞”的检查表。这些漏洞没有一个只属于特别粗心的组织。KDDI 的事件中,入口是连厂商自己都不知道的漏洞,所以“入口能被完美封堵”的前提并不成立。正因如此,②到⑤这些“被入侵后不让它扩散”的一侧也属于底线。

6 项底线,以及各自的“第一步”

1

① 按期限封堵面向互联网的设备

VPN 设备、远程桌面入口、防火墙管理界面——把能从互联网直接访问的设备列成清单,写上型号、版本和负责更新的人。日本警察厅的统计中,勒索软件感染途径的 92 个有效回答里,61 个是 VPN 设备。

第一步:给清单上的每台设备定一个数字——漏洞被确认利用(KEV)后,允许多少天内封堵。“按顺序打补丁”的做法,与数字厅事件是同一种结构。

2

② 收窄维护、外包、离职人员的账号,并放到看得见的地方

每个组织都有不属于员工的人的账号——维护商、外包方、已经离职的人。它们往往为了方便被赋予宽泛权限,而且归谁管并不清楚。

第一步:列出所有非员工账号,给每个账号指定内部负责人和有效期。然后依次做到:只在使用时启用、限制来源地址、强制使用抗钓鱼的双因素认证。把账号停用写进与入职相同的表单里。

3

③ 监视“数量”与“时间”

在 Aflac 的事件中,攻击看起来与正常使用一样。如果每一次查询都是合法的,逐次检查是拦不住的。剩下的线索是每小时有多少条数据流出,以及深夜和休息日的活动。

第一步:在返回客户数据最多的那个功能上,加上每个账号每小时的上限和达到上限 80% 时通知到具体负责人的告警。在文件服务器和云存储上,为数倍于平常的批量下载设置告警。

4

④ 日志保留到“发现时能回溯”的期限

在樱花互联网的事件中,非法访问从约三年前就开始了。如果没有那段时间的日志,既说不清发生了什么,也说不清没发生什么。

第一步:认证(成功与失败)、数据查询与导出、管理操作这三类至少保留 12 个月(以支付卡行业标准 PCI DSS 为参考)。存储不够时,先保住这三类,再考虑 Web 访问日志。

5

⑤ 不保留不再需要的数据

在 Gyazo 的事件中,泄露的元数据主要是多年前上传的图片所附带的信息。泄露的规模取决于当时持有多少数据。没有持有的数据就不会泄露。

第一步:为每一类客户数据写一行:用途是什么、保留到何时。写不出来的,就是删除或匿名化的候选。同时检查已注销用户的数据是否还残留着(樱花互联网的事件中,除非另行办理退会,解约后会员信息仍被保留)。

6

⑥ 用 KEV 而不是发布时的评级重新排定优先级

Adobe Commerce 发布修复时公告写着“优先级 2、未发现被利用”,44 天后 CISA 确认了被利用。WordPress 本体的漏洞则只用了 3 天。

第一步:为自己使用的产品准备一个在其被加入 KEV 时收到通知的机制,并规定一旦被加入就重新排列修补顺序。判断方法见 用 CVSS、EPSS、KEV 决定优先级。

收窄入口

① 按期限封堵面向互联网的设备 / ⑥ 用 KEV 重新排定优先级

被入侵也不让其走远

② 维护、外包、离职人员的账号 / ⑤ 不保留不需要的数据

发现入侵,并能回溯

③ 监视数量与时间 / ④ 日志保留足够长

6 项底线分为“入口”和“被入侵之后”两层。以入口无法被完美封堵为前提,给后面几层同样的分量。

个人与组织,变的是什么

组织会积累的东西(事故从这里开始)

  • 不属于自己的账号(维护商、外包方、离职人员)
  • 没人记得的设备(安装商搭的 VPN、旧的测试环境)
  • 多年累积的数据(已解约的会员、旧的元数据)
  • “总会有人在看”的监控(工具有,负责人没有)

组织的底线要做的事

  • 给一切指定内部负责人和期限
  • 面向互联网的设备用清单和修补期限管理
  • 写下数据为什么保留、保留多久,说不出理由的就删除
  • 告警要定好数字和接收人,并测试它真的能送达

本站观点:底线就是决定“谁、看哪个数字、何时发现”

把事故报告排在一起看,最显眼的是很多组织其实已经有安全产品。Aflac 具备检测和阻断非法访问的功能,在上线前也做过设计评审和渗透测试。仍然没能拦住,是因为攻击不是它们预想的形态。

所以本站建议,衡量组织的底线不是看“部署了什么”,而是看“是否决定了谁、在超过哪个数字时、何时发现”。部署工具的清单对审计有用;而在事故发生的那个夜晚,能让电话响起来的,只有定好了阈值和接收人的告警。确认告警没有还发往离职人员的邮箱——这本身就是第一步。

人与治理——让 6 项持续运转

6 项底线不是做一次就结束。人员会调动,设备会增加,数据会累积。为了持续运转,至少要具备以下几点。

  • 定一名负责人:6 项各自的清单和期限由谁掌握。
  • 每季度一次盘点:更新设备、非员工账号、数据的清单(思路见 资产盘点清单)。
  • 教育从“如何核实联系”开始:任何事故之后,冒充组织的便乘联系都会增加。让员工和客户都养成从官方网站核实的习惯。
  • 在与供应商的合同里写明账号和日志的处理方式:维护和外包的通道,如果合同里不写明由谁管理,就没人管理。

接下来阅读

FAQ

Q组织的安全对策应该从哪里开始?
A

从真实事故被突破的地方开始最可靠。日本 2026 年的大型事故公开了:VPN 设备的漏洞(日本数字厅)、通过维护人员账号大量访问服务器文件(同一事件)、无法阻止短时间内的大量查询(Aflac)、长达约三年未被察觉的非法访问(樱花互联网)等。本站据此把面向互联网的设备、维护与外包账号、流量监控、日志保存期限、不保留的数据、重新排定优先级这 6 项定为底线。

Q和个人开发者的清单有什么不同?
A

组织里会积累不属于自己的账号(外包、维护商、离职人员)、没人记得的设备,以及多年累积的数据。多数事故正是从这些“归属不明的东西”开始的。个人版讲的是守住自己的钥匙和秘密,组织版讲的是给没有主人的东西指定主人。

Q买了 EDR 或 SIEM 就够了吗?
A

产品是手段,不是底线。Aflac 公布称其具备检测和阻断非法访问的功能,但由于访问形式与正常使用相同,未能立即检测到。关键是决定“超过多少、通知谁、何时通知”,并确认通知真的能送达。

Q中小企业也要做同样的事吗?
A

这 6 个思路与规模无关。预算和人手有限时,先从三件事开始:列出 VPN 等面向互联网的设备并定下修补期限;盘点维护与外包账号;给返回数据最多的一个功能加上每小时上限和通知。