典型场景：机舱监控系统送审

这是一个示意性的典型场景（非某具体项目）：一台机舱监控 / 报警系统要满足 E27，从头走一遍流程。具体定级与通过与否以船级社为准。

机舱报警监控系统（AMS/ERAMS）是船舶不可或缺的安全子系统，负责持续监视主辅机、锅炉、燃油、润滑油、冷却水、舱底 / 压载水、废气温度、曲轴箱压力及值班员死人报警等参数。典型系统由 PLC 采集模块（可达每台模块 64 路模拟量输入）、15 英寸触控 HMI、驾驶台与驾控室远程 LED 指示板以及 Modbus RTU-TCP / CANBus / 以太网通信链路组成，并需满足正常与应急双路供电冗余。所有报警信号须在机舱及持续值守控制站（如驾控室、驾驶台）可见可听，以满足 SOLAS 第 II-1 章及 UMS（无人机舱）船级符号要求。正是因为这套系统深度嵌入船舶运营数据流，近年来也成为 E27 审查的典型对象。

① 确认范围与类别

机舱监控属船载计算机系统（CBS），在 E27 范围内。按 UR E22 的失效后果看，监控报警类常落在 Cat II（可能逐渐导致危险），需要文档、FAT 见证与系统证书——不是 Cat I 那种「通常不验证」。

首先需要澄清两个范围问题。第一，E27 对 CBS 的定义是「处理、存储或传输信息的可编程电子装置或装置集合」。凡含有 PLC、固件控制器或网络 HMI，并通过以太网、USB 或串行接口进行数据交换的系统，均满足触发条件——即使系统与外部网络完全隔离，只要物理服务端口未被永久封堵，E27 要求依然适用。第二，E27 于 2022 年 4 月首次发布，2023 年 9 月发布 Rev.1；对于建造合同签订日期在 2024 年 7 月 1 日及之后的新建船舶，本要求为强制性要求。对于更早的新建项目，也可能按建造合同或船东 / 船厂约定纳入范围，务必在项目早期确认适用日期。

确定系统在 E27 范围内之后，下一步是按 UR E22 Rev.3 对系统进行类别判定。E22 将 CBS 分为三类：Cat I 为「失效不会导致危险」，通常无需验证；Cat III 为「失效可能立即导致危险或灾难」；而机舱监控报警系统属于维持船舶正常运营和适居条件所必需的监控与控制功能，按 E22 原文，此类系统的失效「可能逐渐导致对人员安全、船舶安全和 / 或环境的危险」，即 Cat II。Cat II 的审查要求包括：文件提交、工厂验收测试（FAT）见证及系统证书颁发。这意味着机舱监控系统不能以「参考设计」或「内部检验」的方式绕过船级社审查。

② 差距评估

对照 E27 的能力族逐项过。机舱监控最常见的两个缺口：一是没有安全审计日志（按 IEC 62443 的 FR 分类，对应事件响应与日志、使用控制等功能域——以下 FR 标记均为 IEC 62443 框架分类，非 E27 印刷标签，以船级社解释为准）；二是厂家直连远程维护没有审批与边界（使用控制 + 受限数据流的缺口）。

在正式走差距评估之前，需要建立两份基础文件：**系统资产清单**和**拓扑图**。资产清单要精确到版本级别，列明 PLC 型号与固件版本、HMI 操作系统版本、所有第三方库和通信协议栈；拓扑图则需呈现物理与逻辑两个层面的数据流、协议类型及所有对外连接——包括厂家远程诊断接口。这两份文件本身也是 E27 文件包的核心提交件，提前建立意味着差距评估与文件准备同步推进，避免后期返工。

有了资产清单和拓扑图，差距评估才能做到「有凭有据」。E27 要求 CBS 满足至少 30 项核心安全能力；若系统通过不受信任网络进行通信（如接受厂家 VPN 远程维护、向岸基平台推送数据），则额外须满足 11 项能力，合计 41 项。能力范围覆盖：身份标识与鉴权、软件真实性验证、备份与回滚、网络安全事件日志、流量监控与控制、访问控制、加密通信、恶意软件检测、安全更新机制和漏洞披露。机舱监控系统在这 30 至 41 项能力中，通常存在以下五类典型缺口，每一类都在行业公开技术文章中被反复印证。

缺口（a）审计日志缺失是最为普遍的单项缺口。E27 明确要求：系统须对每项关键操作（登录、修改设定值、更新固件）生成带可靠时间戳的日志记录，日志须存储于防篡改文件中，且在安全功能失效时须向船员发出告警。ABS 在其 E27 常见问答中强调「CBS 须为审计记录加盖时间戳」。许多机舱监控系统的早期版本固件仅记录工艺报警，不记录用户操作，这在传统功能设计阶段完全合理，但在 E27 合规框架下构成明显缺口。

缺口（b）厂家远程通道，被海事 OT 安全咨询机构 OTWarden 定性为「最高网络风险向量之一」。典型情形是：OEM 在系统调试阶段开通了一条 VPN 隧道用于远程参数调整，此后该隧道长期维持连接，既未写入拓扑图，也无逐次审批机制。E27 对连接不受信任网络的系统额外要求：使用带端点鉴权、完整性保护和传输层加密的安全隧道；在授予服务笔记本电脑或远程访问前须获得本船明确授权；会话须逐次授权，完成后立即终止；建议在物理层面提供可拔除插头等强制断开手段。Pen Test Partners 亦指出，许多船上实际安装的断开机制并不总是有效或显而易见。

③ 整改

差距评估完成后，整改工作按缺口类型分别推进，复杂度和所需时间差异显著。整改过程中需同步更新文件，以便最终提交材料与实际系统状态一致。若某项能力在技术或架构层面确实无法完全满足，E27 允许采用补偿性对策，但补偿措施须证明：针对相同威胁提供同等保护，且不引入更高安全风险——此类主张需在安全能力描述文件中详细论证，供船级社审查。

• 一人一账号 + 强口令，替换共享登录
• 启用安全审计日志，带可靠时间戳
• 部署远程维护安全网关：审批、会话审计、边界隔离
• 关闭无用端口与服务，按最小功能裁剪
• 定期备份配置并实测恢复流程

**日志缺口整改**通常通过固件 / 软件升级实现，属于整改难度较低的一类：升级固件以启用操作日志、配置远程时间同步（NTP）以确保时间戳可靠性、将日志写入防篡改存储（只追加文件或外部安全日志服务器）、更新测试程序并重新测试。整改后须能演示：登录操作产生日志、修改设定值产生日志、日志无法被普通用户删除。

**远程通道整改**复杂度明显更高，通常需要在监控系统与外部网络之间插入受管交换机或防火墙，并配置逐次授权流程：本船人员通过本地控制台批准 OEM 发起的维护请求，会话全程审计录制，完成后自动或手动终止并记录终止时间。若原有拓扑中已存在以太网路径但未被记录，则须重新绘制拓扑图、标注所有数据流和协议类型，并就该路径的安全控制措施单独论证。值得注意的是，E27 不要求提交实际软件代码或专有功能细节——ABS 在其常见问答中明确指出，船级社不要求提交实际代码——需要提交的是安全能力映射、演示安全功能有效运行的测试程序，以及架构文档。

**SBOM 整改**在技术层面并不复杂，但通常耗时较长：厂家需枚举系统内所有组件（操作系统及版本、第三方库及版本、固件层次及版本），形成活文件并约定后续 CVE 通报和补丁 SLA 的维护责任。SBOM 既是 E27 文件包的提交件，也是后续运营阶段漏洞披露与补丁管理的基础——对于船东而言，这意味着在采购阶段即应要求厂家提供 SBOM 和漏洞披露政策，以及产品生命周期终止日期，作为合同条款的一部分。

④ 取证与送审

整改完成后，进入文件包准备与送审阶段。E27 要求厂商提交的文件包含五大核心文件：（1）CBS 资产清单——硬件与软件组件列表，精确到版本；（2）CBS 拓扑图——物理与逻辑网络架构，标注数据流、协议和所有连接；（3）安全能力描述——系统功能与 30 余项强制安全要求之间的逐项映射；（4）安全能力测试程序——逐项测试的测试步骤，可重复执行；（5）安全配置指南（加固手册）——默认值、配置加固说明。此外，还须提交三份生命周期文件：安全开发生命周期（SDL）文档、维护与验证计划，以及支持船东事件响应与恢复计划的信息文件。

船级社在收到文件包后，审查员将重点核查以下几个维度：**文件完整性**——五大核心文件是否齐全，资产清单是否达到版本级粒度；**拓扑准确性**——物理拓扑图是否标注了所有数据流、协议（Modbus、以太网、RS-485）和外部连接，远程访问通道是否可见；**能力映射质量**——安全能力描述是否将 30 项能力逐一映射到系统中的具体功能，对于存在差距的项目，补偿性对策的论证是否充分；**测试程序质量**——是否对每项要求设有独立章节，测试是否可重复，是否经过见证；**加固指南充分性**——是否提供可操作的安全配置指导，而非仅列出出厂默认值。

在 FAT（工厂验收测试）阶段，若走逐船审批路线（非型式认可），船级社验船师须亲赴厂家设施现场见证网络安全能力测试。验船师通常会重点验证两个环节：一是审计日志演示——实际触发登录、设定值修改和固件更新操作，验证日志被生成并证明日志无法被普通用户删除；二是远程访问控制演示——验证厂家无法在未经本地明确授权的情况下建立远程连接，并验证会话终止机制有效。

⑤ 型式认可与逐船审批：选哪条路？

E27 提供两条认证路径。**路径 A（型式认可）**：厂家在船级社进行一次性审查，包含完整文件审核与工厂见证 FAT；取得型式认可证书后（有效期通常约为 5 年，以实际船级社条款为准），后续每艘船的安装可提交精简版船级文件包。截至 2024 年 11 月，全球已获得型式认可的 CBS 数量合计约 24 套（约 4 套来自日本船级社 ClassNK，约 20 套来自挪威船级社 DNV），数量仍然有限。以发动机控制领域为例，WinGD 于 2022 年 11 月 30 日获得 DNV SP1 型式认可，这是业内第一家获此认可的船用发动机设计商，认可范围涵盖身份鉴权、软件真实性验证、备份与回滚、网络安全事件日志及流量监控控制等能力。报警系统领域的类似案例是 Zenitel 的 EXIGO IP 广播 / 通用报警（PAGA）系统，其型式认可流程包含「详细文件评估及基于 IACS UR E27 标准的严格测试」，并借助威胁与风险评估（TRA）优先处理漏洞。需要注意的是，Zenitel 的型式认可仅适用于从其挪威总部交付、由经培训人员安装的新交付系统，既有安装不在认可范围内，无法通过现场升级纳入。

**路径 B（逐船审批）**：针对每艘船提交完整文件包，验船师须亲赴厂家或船厂现场见证 FAT。Pen Test Partners 指出，未获型式认可的系统所需文件量「与取得型式认可所需文件量相当」，因此船厂越来越倾向于在采购合同中要求厂家提供型式认可证书，以规避逐船审批带来的成本和验船师档期依赖风险。对于机舱监控系统厂家而言，实现型式认可虽需前期投入，但长远来看可显著降低每艘船的合规摩擦，并形成市场竞争优势。

⑥ 厂家与船厂的责任分工

E27（对 CBS 产品合规）与 E26（对船舶系统集成合规）在责任主体上有清晰分工，对于参与机舱监控系统供应链的各方都至关重要。厂家作为 E27 义务主体，需负责：型式认可证据或逐船审批文件包、SBOM 与 CVE 日志及补丁 SLA、安全配置指南（加固手册）、SDL 开发生命周期文件、漏洞披露政策和产品生命周期终止日期公示。船厂 / 系统集成商作为 E26 义务主体，需负责：区域与导管图、船级资产清单、网络安全设计描述、船舶弹性测试程序，并在建造过程中持续维护更新资产清单。

两者之间的**交接点**是 E27 CBS 认可证书加加固指南。船厂以厂家提供的认可配置作为安全基线，在此之上叠加船级层面的控制措施——包括网络分区和区域策略。以机舱监控场景为例：集成商需确保 AMS/ERAMS 被置于适当的安全区域（通常是 OT 区域），其 Modbus / 以太网连接被记录在导管图中，任何维护 VPN 通道均通过防火墙和访问控制进行管理，并在船舶级网络安全设计描述中引用厂家的加固指南。若机舱监控系统通过云端能量管理模块向岸基平台推送数据，该连接路径须被特别识别——Pen Test Partners 指出，此类「云连接能量监控系统极为普遍」，且往往是「记录不完整或不安全」的高风险连接；应在设计阶段将其纳入审查范围，而非在审计时发现。

项目周期因船而异，本场景只示意步骤次序、不代表时长；最终定级与通过以船级社审查为准。DNV SP1 型式认可以 IEC 62443-3-3 安全等级 1（SL1）为技术基础，SL1 针对的是对「随机或偶然的」未授权访问的防护，而非定向攻击；这与机舱监控场景中的威胁模型基本匹配。具有 IEC 62443-4-2 SL1 组件认证的厂家，在通向 E27 型式认可的文件准备方面拥有更扎实的起点。