【自来水企业】随着《网络安全应对能力强化法》的施行,安全事件应对将发生如下变化

    2026年7月20日

    本文的作者

    董事长兼首席执行官

    金筑 敬晃

    2025年5月通过的所谓“网络应对能力强化法(解说文章)”(正式名称:《关于防止因针对重要电子计算机的非法行为而造成损害的法律》)中关于官民合作的部分,将于2026年10月开始实施。自来水行业与电力、燃气、通信等行业一同被纳入适用范围,获得指定的自来水运营商将依法承担申报系统资产以及向政府报告网络安全事件的义务。

    “我们属于封闭网络,所以与我们无关”、“监控与控制系统向来是独立的”——这些话在基础产业的一线经常能听到,但若将本法与国土交通省于2025年3月制定的《关于确保供水领域信息安全的安全指南》结合起来阅读,就会发现这一前提本身已迫切需要重新审视。本文将根据法律、省令和指南这三个方面,梳理自来水运营商在实际工作中需要采取哪些事件应对措施。

    法律规定的义务:申报与事件报告

    该强化法的直接适用对象是依据《经济安全保障推进法》指定的15个关键基础设施领域的经营者,截至2025年7月,共计有257家被指定。自来水行业是这15个领域之一。被指定的经营者必须就其与核心业务相关的信息系统中属于“特定重要计算机”的设备,向政府申报供应商名称及产品信息等;此外,在遭受网络攻击时,还必须提交事件报告。

    关于报告的内容,内阁府专家会议提出的《关于实施的思路(草案)》中,提出了如下框架。

    首先,报告分为两个阶段:一旦发现安全事件,应立即发布“速报”,并在30天内提交“详报”。两份报告均只需报告当时已掌握的情况,并不要求在初期阶段就进行完美的原因分析。报告对象不仅包括非法访问等“特定违规行为”的痕迹,还包括与此相关的各类事件。也就是说,该机制的设计并非“在确认遭到入侵后才进行报告”,而是从出现征兆的阶段起,报告义务即已生效。

    关于云服务使用情况的处理方式,在草案阶段已作明确规定。对于SaaS以及(涉及中间件和操作系统)的PaaS,一旦收到云服务提供商的通知,即视为“已知悉”。将计费、收费及账簿类系统迁移至云端的运营商,必须预先确定接收供应商故障或安全事件通知的对接窗口,以及将其纳入报告流程的具体步骤。

    处罚规定也不容忽视。法规规定,违反申报义务且不遵守主管部门整改命令的,将处以200万日元以下的罚款;不配合提交资料等要求的,将处以30万日元以下的罚款。

    此外,虽然直接被指定的仅限于大型企业,但未被指定的企业也并非完全无关。有观点指出,受托运营特定重要计算机的IT供应商及集团子公司,以及根据系统架构不同,受托方持有的设备也可能被纳入监管范围。在正推进服务整合、区域化及综合委托的水务领域,各组织应意识到自身可能作为“受托方”被牵涉其中的可能性。

    根据省令“已经”成为义务的事项

    虽然容易被忽视,但供水领域实际上已经存在关于网络安全的强制性标准。《关于规定供水设施技术标准的省令》第1条第11项之2规定,对于管理设施运行的计算机,必须采取必要措施确保网络安全,以避免对供水造成严重影响。该规定是在令和元年对省令进行修订时设立的,并已于令和2年4月起施行。

    具体应采取哪些措施,已在科长通知的“注意事项”中予以说明,并配合《安全指南》第一版的制定,于令和7年2月进行了修订。其中列举了针对控制系统计算机的主体认证功能、安装防病毒软件并保持其最新状态等内容。准确来说,当前的情况是:即使不等到《强化法》正式施行,拥有监控控制系统的经营者也已承担了法定义务。

    指南所描绘的“事件响应实务”

     虽然国土交通省的安全指南(2025年3月制定·第一版)并非强制性规定,而是建议性标准,但可以认为,在《强化法》框架下履行报告义务所需的实务基础,基本上都载于该指南之中。若梳理与事件应对相关的要素,大致可归纳为以下流程:

    平时:建立体制和制定计划。 该指南要求建立负责处理安全事件的CSIRT等机构,并事先与相关部门就职责分工达成一致。由于CSIRT既可以是常设机构,也可以仅在发生安全事件时临时设立,因此即使是难以确保专职人员的中小型企业,也能进行相应设计。此外,还提到了在意识到重要基础设施服务故障发生(或可能发生)后,预先规定初步应对措施的应急预案,以及BCP和IT-BCP的完善。为了满足《强化法》中“发现后迅速通报”的要求,在该初步应对计划中具体明确从现场发现异常到信息传达到管理层及报告窗口的流程,实际上是必不可少的先决条件。

    检测:从征兆阶段就采取行动
    该指南在危机管理一章中提到了对网络攻击“征兆”的应对措施,这与《强化法》中报告对象涵盖“可能导致特定不正当行为的事件”的规定相一致。若采取“静观其变”的运营方式,直至侵害行为得到确认,则无法达到法律的要求标准。

    应对与恢复:将手动运行的局限性纳入考量
    自来水系统的优势在于,即使监控控制系统停止运行,原则上仍可通过人工替代运行来维持,但正如指南中所指出的,替代运行时作业效率会下降,预计会对供水服务造成影响。不应抱有“最坏情况下也能手动运行,所以没问题”的想法,而应将切换至手动运行的判断标准、流程及人员配置等内容,一并纳入应急预案中。

    信息共享:CEPTOAR的运用
    作为共享安全事件信息和攻击征兆信息的框架,自来水领域设有CEPTOAR系统,其事务局由日本自来水协会负责。在《强化法》施行后,向政府提交法定报告与行业内部信息共享这两条途径将并行运作,因此,若能事先明确哪些信息应通过哪条途径提交、由谁来决定提交对象,将有助于减少混乱。

    图片来源:厚生劳动省《供水领域网络安全对策调查报告》第37页

    训练:让计划“付诸行动”。 指南将演习和训练列为独立的实施项目。仅通过一次桌面演练,就能发现报告格式和联络网络中的漏洞。实际撰写速报草稿的训练,作为实施前的准备工作,可说是具有很高的成本效益。

    “因为是封闭网络所以安全”这一说法为何站不住脚

    该指南用相当大的篇幅警告人们不要过度信赖封闭网络。根据该指南的定义,仅通过防火墙或路由器限制通信的架构,以及可通过互联网VPN(SSL-VPN、IPsec-VPN)访问的架构,均不属于封闭网络。即使通过专线构建了封闭网络,只要连接目标网络中的任意一点与互联网相连,物理隔离便会失效。

    文中还列举了实际案例。2010年,伊朗的一处核燃料设施中,原本与互联网物理隔离的控制系统因通过插入U盘等方式感染了恶意软件,导致离心机停机。2015年,乌克兰某电力公司中,原本通过防火墙(FW)和虚拟专用网络(VPN)实现逻辑隔离的控制系统,因攻击者利用通过业务终端窃取的合法认证信息,通过VPN进行非法操作,最终导致了大规模停电。就供水系统而言,事务系统与控制系统之间的连接点,以及具备互联网连接协议的现场传感器和平板电脑,都可能成为类似的入侵入口。

    从事件响应的角度来看,这一问题之所以重要,是因为如果在风险评估中因“这是封闭网络”而忽视了风险,就可能导致既没有设计检测机制,也没有设计报告触发机制。强化法规定的报告义务始于“发现”。如果没有发现的手段,就无法履行这一义务。

    在施行之前应做些什么

    考虑到该法规将于2026年10月实施,指定对象(或候选对象)的企业应采取的措施将逐渐明确。

    首先是资产清点。这是一项旨在梳理可能属于申报范围的特定重要计算机及外围设备的工作,许多相关企业已着手开展。不仅包括监控系统、泵站运行、供水管理等控制系统,还涵盖了一旦遭受攻击会导致设备停机或功能下降的外围设备。

    其次,是完善报告流程。将“认知”的定义(包括云端通知)、速报的起草人和审批流程,以及30天内提交详细报告的调查机制纳入应急预案。同时,还应在此阶段对《个人信息保护法》规定的泄露报告等现有报告制度进行梳理,避免重复。

    第三,是管理层的参与。该指南明确规定,若因网络安全体制不完善导致组织遭受损失,参与体制决策的管理层可能被追究损害赔偿责任。我们希望在法规施行前,作为组织明确认识到:事件应对不仅是信息系统负责人的工作,更是经营风险管理本身。

    法律的具体细节仍有部分需在施行前通过政省令及实施细则予以明确,因此本文中标注为“草案”的事项今后可能会发生变化。最新信息请参阅内阁府(网络安全事务负责部门)和国土交通省自来水事业课公布的资料。

    于是便来到了Incident Lake

    正如前文所述,在应对《强化法》的过程中,真正带来负担的,与其说是平时制定规则,不如说是“事件发生当下的实际应对工作”。考虑到需要整理已确认的事实并迅速发布快报,在应对的同时记录经过,在30天内汇总详细报告,并在事件结束后为防止再次发生及开展培训而进行回顾,坦率地说,仅靠有限的人员和人力来完成这一切,并不现实。

    Incident Lake 是一款支撑这一系列流程的事件管理平台。它将事件发生时的报告、恢复处理以及报告的编制与管理等环节实现自动化,使负责人能够将时间用于本应专注的“解决眼前的故障”上。正值速报、详报等有时限的报告制度开始正式实施之际,我们建议您将报告和记录机制转变为不再依赖人工努力的形式。


    参考资料

    本文的作者

    董事长兼首席执行官

    金筑 敬晃

    SIGQ股份有限公司 代表董事

    毕业于筑波大学研究生院,专业为数据库与分布式系统。
    在AI时代不可或缺的、负责处理运营数据(即非结构化、实时信息)的工程师。
    应届毕业后加入Money Forward股份有限公司。曾外派至越南分部,在包括海外在内的开发一线从事管理和开发工作。
    2022年加入Plaid股份有限公司,负责平台工程(Platform Engineering)工作,参与大规模分布式数据系统的开发。
    2024年创立SIGQ株式会社。

    分享这篇文章

    Facebook分享按钮X分享按钮
    keyboard_backspace

    实用文章一览