IEC 63452 标准前瞻：云网络安全要求解读

原创

薄说安全
薄说安全

薄说安全

2026年7月5日 07:00
北京

在小说阅读器读本章

去阅读

一、IEC 63452 进展：它和现行标准是什么关系？

IEC 63452《Railway applications - Cybersecurity》目前处于 CDV（Committee Draft for Vote，委员会投票草案）阶段。CDV 不是正式出版版本，但已经说明标准文本进入较成熟的国际征询和投票阶段。对轨道交通企业来说，这个阶段值得提前关注，作为一份国际标准，后续可能会转换为国标，对于海外项目，很可能会逐步吸收其中的要求，作为国际项目中网络安全方向的基本标准依据。

从标准定位看，IEC 62443 是工业控制系统环境的通用标准，铁路行业过去也大量借用这套方法；但随着铁路系统数字化、互联化、远程化程度提高，通用工业控制安全框架已经不足以完整覆盖铁路行业的特殊场景。IEC 63452 正是在这个背景下出现的。它受 IEC 62443 和 CLC/TS 50701 影响，把“区域与通道”“风险评估”“基础安全要求”“生命周期管理”等方法进一步铁路化。可以理解为IEC 62443 是基础，CLC/TS 50701 是欧洲铁路场景下的技术规范，IEC 63452 则试图把这些原则整理成面向全球铁路行业的统一标准框架。

IEC 63452指出，铁路网络安全目标是要形成一个可重复、可度量、可审查的网络安全项目体系。这个体系至少包括资产清单、区域与通道建模、风险评估、持续监测、漏洞管理、远程访问控制、事件响应和合规证据。

IEC 63452 要求铁路责任主体识别铁路系统和铁路应用范围，区分信息系统与生产系统，再基于铁路应用生命周期、RAMS 过程、系统移交、运营维护和退役管理，建立网络安全要求和证据链。对于云场景来说，这意味着云平台一旦进入铁路生产系统的运行、维护或安全边界，就需要被纳入 IEC 63452 的系统描述、区域划分、风险评估和运维管理中。

IEC 63452与 IEC 62278、IEC 62279、IEC 62425 这类功能安全标准也不是替代关系。功能安全关注系统在故障条件下能否保持安全；网络安全关注攻击、漏洞、非法访问、配置篡改、供应链风险等威胁是否会破坏铁路应用的机密性、完整性和可用性。二者会在安全相关功能处发生交汇。因此 IEC 63452 特别强调，网络安全活动需要与铁路 RAMS 生命周期协调，并分析了网络安全与功能安全的联系和区别。

二、草案中关于云网络安全提到了什么？

查看草案全文的对云网络安全的内容，在术语定义、系统识别、风险评估、需求分配、区域与通道划分以及附录 K 中均涉及到云网络安全的要求。归纳起来，有以下三个方面：

第一，云平台的网络安全风险评估。

正文 7.5.3.1是最关键的规范性要求，标题是“所考虑系统的分区”。这条要求的核心内容是：项目中按网络安全管理计划指定的组织，应建立所考虑系统（SUC）的区域与通道；资产应根据初始网络安全风险评估结果，或根据资产关键性、运行功能、物理/逻辑位置、访问需求、最小权限原则、责任组织等因素，分组到安全区域，并通过通道连接。

草案进一步列出了资产分区规则：业务资产与控制资产应分入不同区域；安全相关资产应进入专用区域，并与非安全相关资产逻辑或物理分离；临时连接设备应与永久连接设备分区；无线连接设备应与有线设备分区；允许通过外部网络远程连接 SUC 的设备应单独成区；安全设备应部署在区域边界，用于保护区域；属于生产系统云的资产，例如云应用，应分组到一个或多个独立区域。如果因架构约束等原因偏离上述规则，应在风险评估报告中说明理由。

这里的重点是“云在铁路生产系统中属于哪个安全区域”。只要云平台、远程接入、无线接入或临时维护设备进入铁路生产系统场景，就不能再被当作普通网络节点处理，而应纳入架构设计、管理流程、验证证据。

从风险评估角度看，云平台至少会带来四类问题：一是边界变化，云平台可能跨越信息系统、生产系统和外部服务商边界；二是访问变化，远程用户、第三方维护人员、云运维人员可能获得高权限入口；三是数据流变化，监测数据、日志数据、配置数据、控制相关数据可能在不同区域间流动；四是责任变化，运营方、集成商和云厂商之间需要明确风险接受、事件响应、漏洞处置和变更管理责任。

因此，生产系统云资产要进入区域与通道划分；例外情况要在风险评估报告中说明。标准草案附录K中关于云风险管理、云区域、可用区、边缘节点、云服务依赖和业务连续性的内容，则属于资料性指南，用于帮助项目更具体地识别和分析风险。

第二，云平台的网络安全需求规范。

正文 8.3.3 提到，系统集成商应根据网络安全管理计划，把风险评估识别出的网络安全要求分配到子系统和组件层面。这部分虽然不是专门为云写的，但它直接影响云系统落地：网络安全需求不能只停留在总体方案里，而要落到具体子系统、组件、接口和应用上。

草案在解释中明确举例，高层网络安全要求可以根据特性分配为主机要求、应用要求、接口属性要求和附加安全功能要求。其中应用要求可以分配到不同设备类型，包括移动设备、嵌入式设备、网络设备和云。这说明云不是一个笼统平台，而是需求分配对象。

对项目来说，这意味着云侧需求规范至少要回答几类问题：云应用属于哪个安全区域；云与生产系统之间有哪些接口；接口是否需要加密、认证、完整性保护和异常检测；云资源访问是否采用最小权限；密钥、证书和凭据如何管理；日志是否具备统一时间、集中采集和防篡改能力；如果云组件不能满足分配要求，是否需要补偿措施，并重新评估风险。

这部分的规范性要求来自正文 8.3.3：风险评估导出的网络安全要求应分配到子系统和组件层面。至于身份与访问管理（IAM）、多因素认证（MFA）、密钥管理服务（KMS）、公钥基础设施（PKI）、传输层安全协议（TLS）、网络微分段、安全信息与事件管理（SIEM）、安全编排自动化与响应（SOAR）、特权访问工作站等具体控制措施，主要来自附录K，属于资料性参考，但可以作为编写云网络安全需求规范时的重要输入。

第三，云平台安全指南。

草案附录K 标题明确为“informative”，也就是资料性附录。它不是正文强制条款，但系统展开了云安全在铁路应用生命周期中的处理思路。

附录K 的适用范围是直接参与铁路基础设施和车辆控制、监测、运营的云化铁路解决方案、设备、应用、数据、技术资源和数字资产。它特别区分了工业物联网与云连接生产系统：工业物联网更强调数据采集和分析，云连接生产系统则强调通过云扩展、监测、配置甚至控制传统生产系统。

换句话说，安全指南可以理解为“云网络安全要求如何落地”的指南。正文要求项目把生产系统云资产纳入区域与通道、风险评估和需求分配；附录K 则进一步说明，云平台在不同服务模式、不同部署模式、不同生命周期阶段下，应重点考虑哪些安全活动和控制措施。

在云服务模型上，安全指南覆盖 IaaS、PaaS、SaaS 三类模式。IaaS 下，云服务商主要负责物理资源和租户隔离，客户需要负责网络策略、操作系统和应用安全；PaaS 下，云服务商负责硬件、操作系统、网络和平台软件，客户仍要负责服务配置、应用代码和跨应用访问策略；SaaS 下，云服务商承担更多底层责任，但客户仍需要关注使用侧配置、账号权限、数据保护和接口管理。这个划分的价值在于，它把“云厂商负责什么、铁路方负责什么、集成商负责什么”拆得更清楚。

在部署模式上，安全指南同时考虑公有云、私有云和混合云。公有云强调多租户隔离和共享基础设施下的环境安全；私有云强调铁路责任主体对云环境差距的评估和补强；混合云则要求公有云和私有云之间保持一致的安全对策。对于轨道交通项目，私有云尤其值得关注，因为生产系统通常更强调专属资源、边界可控、运维可审计和责任可落实，不能简单套用通用公有云的安全假设。

在生命周期上，安全指南把云安全活动分为规格定义、设计实现、验证、运营维护、退役、业务连续性和灾难恢复几个阶段。规格定义阶段应明确云安全框架、工作范围、SLA、数据隐私、安全条款和事件响应责任；设计实现阶段应考虑网络分段、访问控制、数据保护和加密；验证阶段应关注漏洞扫描、渗透测试和持续监测；运营维护阶段应关注日志、监控、补丁、事件响应和远程接入；退役阶段应确认云资源终止、审计日志保留、数据驻留和数据迁移限制；业务连续性阶段则要评估云服务依赖对铁路应用可用性的影响。

在具体控制措施上，安全指南提供了一套比较完整的参考清单。身份和访问控制方面，包括身份与访问管理（IAM）、最小权限、基于角色的访问控制（RBAC）/基于属性的访问控制（ABAC）、多因素认证（MFA）、账号开通与注销、定期访问评审；凭据和密钥管理方面，包括凭据生命周期管理、密钥不得明文存储、优先使用硬件安全模块（HSM）/可信平台模块（TPM）、密钥管理服务（KMS）、公钥基础设施（PKI）和证书轮换；通信和网络方面，包括云网络安全组、虚拟防火墙、区域间访问控制、网络微分段、必要时采用硬件隔离或单向传输；密码应用方面，强调跨区域通信使用当前先进的加密机制、传输层安全协议（TLS）、前向保密和证书管理。

运营维护方面，安全指南要求关注云资源访问日志、身份联合服务器异常监测、安全编排自动化与响应（SOAR）/安全运营中心（SOC）/安全信息与事件管理（SIEM）对接、漏洞管理、渗透测试、事件响应和远程访问终端安全。对共享网络安全服务，它还提醒要根据数据方向和数据类型选择控制措施：从云实例进入生产系统的控制信号应过滤、认证并监测异常；从生产系统发送到云侧的监测、遥测等非控制数据，宜尽量采用单向传输。

远程接入方面，安全指南没有简单否定 VPN，但提出 VPN 应采用强加密协议并持续更新；RDP 仅应在没有更安全方式时使用；同时建议考虑零信任网络访问（ZTNA），以实现更细粒度、更实时的访问控制。对于管理员访问云资源，附录K 还建议使用特权访问工作站，并进行加固、多因素认证和完整日志记录。

因此，草案正文告诉生产系统云资产必须进入分区与风险管理，并把风险评估导出的要求分配到相关云组件和接口；安全指南则提供可以如何设计、评估和运营云安全的参考方法。项目落地时不能把附录K 逐条机械当成强制要求，但也不能忽视它，因为它很可能成为业主、评估机构或第三方认证机构判断云平台网络安全能力的重要参考。

三、轨道交通云平台系统应如何做？

国内城轨云系统首先应满足等保 2.0 体系要求，以及 GB/T 46739 对城市轨道交通网络信息系统、云计算平台、生产网、管理网、外部服务网、安全管理中心和远程接入等方面的要求。对国内项目来说，这些标准已经构成主要符合性基础，目前城轨云建设也参考IEC62443和IEC63452标准草案的一些要求，但属于两套体系，并没有直接引用。

IEC 63452 更适合放在海外项目中满足网络安全合规性要求分析。对于海外轨道交通项目，如果信号、综合监控、PIS、PA、CCTV、乘客服务、车辆状态监测、运维平台等系统开始采用云架构，项目就不能只证明云平台本身安全，还要证明云平台在铁路生产系统架构中如何被安全使用。

第一，要先判断哪些云化系统进入生产系统边界。PIS、PA、CCTV、综合监控、信号维护平台、车辆状态监测平台，看起来都可能是应用系统，但它们对运营的影响并不相同。PA 可能涉及应急广播，PIS 可能影响乘客疏导，综合监控可能联动环境控制和运营处置，信号维护平台可能影响配置、诊断和软件更新。只要云平台参与运营、监测、维护、配置或控制，就应在 IEC 63452 的系统描述中明确其生产系统属性、功能边界和责任主体。

第二，要建立海外项目的区域与通道模型。云平台不能只画成一个“云”图标，而应根据功能拆分为不同安全区域，例如云应用服务区、数据分析区、日志监控区、远程维护接入区、身份认证与密钥服务区、软件更新与配置管理区、灾备区等。它们与控制中心、车站、车辆、现场设备、维护终端、第三方服务商之间的通信，应明确通道、协议、方向、访问主体、认证方式、加密要求和日志要求。国内项目通常不按 IEC 63452 的“区域与通道”方式建模，而是按等保和 GB/T 46739 中的生产网、管理网、外部服务网、安全区域边界等要求进行划分和控制。这不是安全要求更低，而是国内标准已经用网络安全区域、边界防护、访问控制和安全管理中心等方式约束了系统边界。

第三，要把不同系统的云化风险分开分析。信号系统上云，重点关注安全相关功能边界、本地自治、断连策略、配置变更和软件更新；综合监控上云，重点关注跨专业联动、控制命令过滤、异常操作审计和应急处置；PIS 和 PA 上云，重点关注信息发布权限、内容防篡改、应急广播优先级、错误信息传播和公众影响；CCTV 或乘客服务系统上云，则要关注数据隐私、视频访问权限、跨境数据流动和日志留存。不能用一套“云安全说明”覆盖所有系统。国内项目中，网络安全风险评估更多服务于等级保护定级、测评、整改和安全检查，通常不会按照 IEC 63452 那样围绕一个具体铁路系统对象建立完整的威胁环境、SUC、初始风险评估和详细风险评估流程。风险控制已经被等保测评、密码应用、安全管理制度、运维审计和行业安全要求分解到一组基线控制中。

第四，要把风险评估结果转化为需求规范。网络安全要求不能停留在总体方案里，而要分配到云应用、接口、终端、网关、身份服务、密钥服务、日志服务、远程维护服务和灾备服务。海外项目交付时，应能说明每一个云侧组件承担什么安全要求，哪些要求由云厂商满足，哪些由系统集成商满足，哪些由运营方流程满足。国内项目里，网络安全需求往往由信息安全厂商、等保测评机构、云平台厂商或安全集成单位在安全建设方案中统一考虑，技术系统本身未必形成类似 IEC 63452 中网络安全需求规范（CRS）的专项工程文件。其约束路径主要来自 GB/T 22239、GB/T 46739、密码应用要求、等保测评整改项和安全管理制度，而不是从铁路系统风险评估逐级分配到每个云组件和接口。

第五，要专门设计远程接入和第三方运维。海外项目通常会涉及设备供应商、系统集成商、云厂商、运营方和本地维护单位，多方远程接入不可避免。VPN 可以使用，但不能只写“采用 VPN”就结束。项目应说明访问范围、最小权限、账号生命周期、会话审计、终端安全、临时授权、应急断开和访问复核机制。对于高权限管理操作，应考虑特权访问工作站、堡垒机、多因素认证、细粒度授权，以及零信任网络访问（ZTNA）/安全访问服务边缘（SASE）等更细粒度的访问控制方式。

第六，要把云侧变更纳入铁路系统变更管理。云服务商组件升级、云资源扩缩容、可用区切换、证书轮换、密钥更新、软件发布、配置策略调整，都可能影响铁路应用。海外项目中，这些变化需要提前定义审批、测试、回退、通知和记录机制，不能完全按照普通云平台运维节奏处理。尤其是信号、综合监控、PA 等对运营影响较大的系统，云侧变更应与系统配置管理、回归验证和运营窗口安排保持一致。

第七，要准备可审查的证据链。海外项目面对 IEC 63452 草案或业主网络安全规范时，交付物不能只有等保式的基线符合性材料。至少应准备云系统范围说明、区域与通道图、云资源清单、接口清单、数据流向说明、风险评估报告、网络安全需求分配表、访问控制矩阵、加密与密钥方案、远程接入方案、日志审计方案、漏洞和补丁管理流程、事件响应流程、灾备演练记录、退役和数据清理方案。

结语

IEC 63452 草案对云网络安全的关注，释放了一个清晰信号：轨道交通网络安全正在从“满足基线要求”，走向“建立可持续的网络安全项目体系”。它把铁路系统识别、生产系统边界、区域与通道、风险评估、需求分配、生命周期管理和证据化交付组织在一起。对于云网络安全，正文给出了规范性方向：生产系统云资产要进入区域与通道划分；附录K则提供了云安全设计、验证、运维和退役的实施指南。

这对海外轨道交通项目尤其关键。信号、综合监控、PIS、PA、CCTV、运维平台等系统上云时，真正要回答的不是“能不能上云”，也不是“云厂商是否合规”，而是云上的哪些功能进入生产系统边界，云与地面、车站、车辆、控制中心之间通过哪些通道通信，哪些风险被识别，哪些要求被分配，哪些证据可以证明系统在运营期间持续安全。为满足国际项目的合规性要求，轨道交通云系统出海更应关注标准草案中云网络安全的相关内容。

目前仅为标准草案，后续会持续关注标准的发布和更新，继续做解读工作。