企业官网建设流程全解析

1. 项目概述：为什么做 SL 评测认证

工控圈里这两年有个词出现频率越来越高：SL。很多人第一次听到的时候都会愣一下，这跟西门子的 S7、倍福的 TwinCAT 都没关系，它指的是 Security Level，也就是安全等级。当你的 PLC、DCS、SCADA 或者边缘控制器要进某些行业市场时，客户会直接甩过来一句：这个产品做过 SL 评测认证吗？拿得出报告吗？

我做的这个项目，就是把一款典型的工业控制器产品送进基于 GB/T 42456 的 SL 评测认证流程，从标准解读、范围界定、测试执行，到最后拿到符合性结论。整个项目周期大概五周，其中真正的实验室测试和记录工作占了三周多。项目结束后，我最大的感受是：这套评测并不是很多人想的那样“找个机构过来查一遍”，而是一个必须把产品设计、文档体系、测试环境、安全功能全部串起来的系统工程。

这篇文章就围绕这个项目，把我要踩过的坑、总结出的方法、以及评测过程中那些在标准原文里看不到的实操细节，尽量完整地讲出来。适合三类人看：一类是准备送产品去做 SL 评测认证的研发负责人，一类是负责被测系统集成的工程师，还有一类是刚入行工控安全、想弄明白认证这件事到底在做什么的朋友。

先说结论：SL 评测认证不能临时抱佛脚。产品在架构设计阶段就要把安全功能留好位置，否则到了测试执行阶段，你会被现场暴露出来的问题折磨到怀疑人生。下面我从项目整体思路讲起，再逐步拆解每一段实操过程。

2. 评测思路与标准体系拆解

2.1 GB/T 42456 到底在评什么

GB/T 42456 是一份直接面向工业控制系统信息安全的标准，它解决的并不是“这个产品有没有漏洞”这种点状问题，而是把工业控制产品当成一个完整的对象，从身份认证、访问控制、数据保护、通信安全、审计追溯、资源管控等方面去评估它的安全能力。你可以把这份标准理解成一张能力清单，每一条都对应具体的评测项，评测机构依据这些项目来判定产品能够达到哪一级 SL。

项目启动时，我们做的第一件事不是急着去测试，而是把标准里涉及产品范围的条款逐条拉出来做映射。比如我们的被测对象是控制器，那么偏重管理系统、生产管理层的条款就不适用；跟控制设备直接相关的通信鉴权、程序完整性校验、异常报文响应这些条款，才是核心评审项。这个映射过程非常关键，因为它直接决定了后面测试用例的编写范围和权重分配。

有人会问，直接按标准全量测不行吗？答案是效率太低，而且会测出很多没有意义的问题。工业控制设备千差万别，一个用于风电主控的 PLC 和一个用于数控机床的 CNC 系统，它们的暴露面完全不同。评测如果脱离产品实际形态去机械套用每条要求，得到的结果既不准确也无指导价值。所以我们在启动阶段就明确了范围裁剪原则：凡是与“控制设备”身份相关的必测项全量保留，凡是明显只针对上位机、管理平台或云端服务的条款先做标记，进入争议确认流程，最后再由项目组和评测机构一起确认裁剪结果。

2.2 SL 分级背后的逻辑

GB/T 42456 的 SL 等级一般从低到高划分，不同等级对应不同的安全能力要求。最开始我和团队也有个误区，觉得 SL 越高越好，最好一步到位做到最高级。实际上，SL 等级的核心逻辑不是“越高越牛”，而是“匹配你的应用场景”。

举一个很直观的例子：一个部署在物理隔离车间内部、没有外网连接的温控仪，它面对的威胁模型和有公网 IP、支持远程运维的边缘网关完全不同。前者做到 SL1 或 SL2 可能就满足实际风险控制需求；后者如果只做到低等级，那几乎等于裸奔。所以在定级环节，我们花了不少时间做了一件事：结合产品的目标市场、通讯方式和部署环境，梳理出三个典型应用场景，再针对每个场景确定评测目标等级。这样评测出来的结论才有意义，也方便客户将来在项目选型时对号入座。

测试过程中，SL 等级还会反过来影响测试深度。比如低等级可能只要验证“存在身份鉴别机制”，高等级则要求验证“鉴别机制能否抵御暴力破解”“会话令牌是否安全存储”“失败尝试是否触发审计记录”。我们准备送评的设备明显面向中高端市场，所以整个测试方案的深水区都集中在 SL2 到 SL3 这个区间，相关用例占总用例数的六成以上。

2.3 产品级评测与系统级评测的差别

项目里还碰到一个高频混淆点：GB/T 42456 的评测对象可能是产品，也可能是系统，两者差异很大。产品级评测关注的是设备本身固有能力，比如控制器是否支持用户角色划分、是否存在后门账户、通信端口是否可配置；系统级评测关注的是多台设备组成系统后的整体安全能力，比如组网方式是否合理、安全策略是否一致、边界防护是否到位。

我们这次的送评对象是单台控制器，所以属于产品级评测。但测试过程中，周围仍然要搭建一整套包括编程软件、HMI 上位机、工业交换机在内的模拟环境。这里容易犯的错是把环境里的其他设备也当成被测对象，导致问题归属混乱。正确的做法是明确一个原则：外围设备全部视为“可信第三方”，只用来配合触发被测设备的安全行为，评测记录中出现的每一项违规或缺失，都只归因于被测控制器本身。

3. 评测认证全过程实操

3.1 前期准备：比想象中琐碎得多

真正进入测试之前，准备周期比预期长了一倍。首先是资料清单，包括产品说明书、硬件设计文档、软件版本说明、通信协议文档、已知漏洞列表、补丁管理说明、安全配置指南等。很多研发团队一听到要提供这些就头大，尤其是“已知漏洞列表”这一项，总觉得把漏洞写出来不是自己坑自己吗？实际上，评测机构要看的不是有没有漏洞，而是你有没有管理和处置漏洞的流程。写得越坦诚、流程越完整，评测印象分反而越好。

其次是测试环境。我们的被测控制器支持多种工业协议，但 SL 评测不需要把每种协议都拿来测一遍，而是选择代表性协议。我们最终选了 EtherCAT 作为主测协议，原因是该控制器在运动控制场景下大量使用 EtherCAT，而且其报文结构对异常帧注入、时间同步攻击等测试项特别有代表性。为了配合测试，我们用 CODESYS Control RTE SL 搭了一套软 PLC 测试环境，后面第 4 部分会专门讲这块配置。

环境搭建阶段最容易忽略的是时钟同步问题。SL 评测里有一类测试项涉及日志审计，要求审计记录包含可信时间戳。如果测试环境的 PLC 和上位机之间没有做时间同步，评测人员会直接认定该评测项不通过，而没有给你解释的机会。我们第一轮环境自检时就因为 NTP 服务配置不到位，导致审计日志时间戳偏差超过允许范围，后来重新配置了时间同步服务才过关。这类问题在标准里只有半句话，但实际执行时直接影响一项评测结论。

3.2 从安全要求映射到测试用例

标准条款转测试用例，是整个项目技术含量最高的一步。比如说标准里有一条“应对通过通信接口进行访问的主体进行身份鉴别”，这句话如果直接变成测试步骤就太虚了。我们实际拆出来的测试用例如下：

• 通过 EtherCAT 从站向主站发送未鉴权的写请求，验证是否被拒绝；
• 通过编程软件连接控制器，输入错误口令次数达到阈值后，验证是否触发锁定和审计事件；
• 抓取正常通信报文后回放，验证是否存在重放攻击防护；
• 修改固件版本号后尝试在线更新，验证是否触发完整性校验失败告警。

每一条标准要求至少要设计 1 到 3 个正向用例和 1 到 2 个反向用例。正向用例验证“该有的功能有”，反向用例验证“不该放行的行为不放行”。我们这次一共设计了两百多条执行用例，其中约四分之一是反向用例。从实际执行效果来看，反向用例发现的问题数量远高于正向用例，很多产品在功能层面看起来没问题，但一旦遇到畸形报文、越权访问、时间异常这类攻击模拟，弱点就立刻暴露了。

编写测试用例时还要注意可复现性。SL 评测讲究证据链完整，每个用例都要有前置条件、执行步骤、预期结果、实际结果和现场截图。如果某个用例在测试过程中出现了偶发行为，一定要单独标记，并在复测环节连续执行多次，确认是稳定缺陷还是偶发现象。我们项目中遇到过一例偶发的通信断链告警，后来复测了八次，最终确认与网络报文风暴有关，是测试环境问题而不是产品缺陷。

3.3 证据收集与文档输出

测试执行过程大概两周，但真正的体力活在于证据整理。SL 评测的证据不只包括测试记录和截图，还包括配置条目、审计日志、报文抓包文件、异常处理记录等。我们的原则是：凡是被评审人员可能问到的问题，都要能拿出对应的证据；凡是拿不出证据的，一律当作不通过处理。

这里分享一个格式化技巧：我们为每一项评测结论维护了一个证据索引表，分为五列，分别是标准要求编号、测试用例编号、证据文件路径、现场判定结论、复核意见。最后整理出来的证据包光索引表就有三十多页。评测人员看到这种组织方式会非常舒服，因为他们的工作量同样巨大，证据越清晰，沟通成本越低，误判概率也越小。

另外说句实在话：文档输出的质量有时比测试结果本身更能影响最终结论。同样一个评测项，一家公司交上来的是随手截的几张图，另一家交上来的是包含时间、设备、人员、操作步骤、日志关联的完整记录，后者的通过概率明显更高。这不涉及任何暗箱操作，纯粹是评审人员对书面证据的信心问题。

4. 支撑 SL 评测的产品工程实践：CODESYS Control RTE SL 与 EtherCAT 主站配置

4.1 软 PLC 为什么会出现在这个项目里

有人会疑惑，SL 评测不是针对硬件工控产品的吗？为什么还需要专门配置一套 CODESYS Control RTE SL 的软 PLC 测试环境？原因在于，现代控制器的功能边界已经模糊了。我们送评的这款控制器虽然是传统盒式硬件形态，但它内部跑的是虚拟化控制内核，底层能力和 CODESYS 这类软 PLC 运行时高度同源。为了做通信安全测试，我们既要在真实控制器上验证，也需要在一套可灵活调整参数的软 PLC 环境里做破坏性测试，避免把被测硬件设备搞到不可恢复的状态。 CODESYS Control RTE SL 正是承担了这部分“可破坏、可重置”的陪测角色。

CODESYS Control RTE SL 这个名字里也有 SL，但它和我们要评测的 SL 安全等级没有关系。RTE 是 Real-Time Environment 的缩写，SL 在这里是 Single License 的简化标识。把这两件事分开理解，项目沟通能少很多误会。

4.2 EtherCAT 主站配置的实操要点

EtherCAT 主站配置这个需求，最近在工控技术社区里问得特别多。部分原因是 CODESYS Control RTE SL 本身不带 EtherCAT 主站功能，需要额外安装对应扩展包。我们的配置路径如下，供参考：

第一步，确认版本匹配关系。CODESYS Control RTE SL 运行时版本与 EtherCAT Master 扩展包版本必须严格匹配，最稳妥的方式是在 CODESYS 的 Package Manager 里安装同一个发行周期的软件包。随意混搭版本很容易导致设备扫描不到从站，或者主站状态机卡在 OP 之前的 INIT 状态。

第二步，在 Device 视图中添加 EtherCAT Master 设备。添加完成后，不要急着扫描总线，先把主站的周期时间参数按项目需求设好。我们做 SL 评测时把周期设为 1ms，因为被测控制器在运动控制场景下的典型任务周期就是 1ms，这个参数会影响后续异常帧注入测试的时间判断。

第三步，从站扫描和 PDO 映射。CODESYS 的“Scan Devices”功能可以自动识别总线上从站设备的类型和地址，但在测试环境里我们更建议手动添加从站并配置地址。原因很简单：自动扫描出来的过程数据映射不一定完整，尤其是含有安全从站或者复杂分布时钟配置的场合，手动逐个核对更可靠。PDO 映射配置好之后，记得在 Online 视图里确认映射关系有没有真正激活。

第四步，分布时钟配置。EtherCAT 的分布式时钟是实现主从站同步的核心机制。评测过程中有一项是“验证通信中断后系统能否正确识别并恢复”，如果分布时钟配置不对，恢复时间会被拉长，导致该测试项无法通过。我们在配置中去掉了不必要的 DC 偏移补偿选项，让所有从站直接跟随主站时钟，简化了同步链路的复杂度。

下面是我们常用的一个配置检查项清单：

• 主站周期是否与控制器任务周期一致；
• 从站是否全部处于 OP 状态；
• PDO 映射长度是否有误；
• 分布时钟是否使能、参考从站选择是否正确；
• 断线重连时间是否满足测试预期；
• 网卡驱动是否为实时驱动、是否绑定了独立 CPU 核。

这里特别提醒一句：Windows 平台跑 CODESYS Control RTE SL 时，网卡的实时性能是个隐蔽的坑。普通网卡在经历高负载时会产生较大的时间抖动，直接影响 EtherCAT 通信质量。我们在测试机上更换为支持实时驱动的工业级网卡，并把该网卡的中断绑定到独立核心后，通信抖动问题才真正解决。关于中断绑定，实际操作中建议关掉 CPU 节能模式，否则实时任务会被调度到低频率核心上，导致周期性通信波动。

4.3 为评测准备的日志、审计与安全配置

整套 CODESYS 环境搭建完成后，还有一项工作很少被公开提到：为了满足 SL 评测的审计追溯要求，必须提前把软件运行日志、通信日志和系统事件日志的保存策略全部梳理清楚。评测人员会现场要求你调取某段时间的日志，如果日志存得不够、或者时间戳格式不统一，这项评测的结论基本就悬了。

我们在 CODESYS 中启用了详细的通信诊断日志，并把日志导出级别调到可记录 EtherCAT 帧错误等级的程度。这个操作在正常生产环境不建议做，因为日志量会非常庞大，但评测环境下必须这么做，否则无法证明系统在异常帧注入后确实产生了正确响应。

安全配置方面也不要忽视。比如控制器默认开启了哪些服务端口、是否存在默认口令、是否允许匿名访问文件服务，这些在评测里都会逐一检查。我们甚至遇到过一个案例：某设备送测前没有关闭调试用的 Telnet 服务，工程师觉得这是内部测试口，不影响安全性，但评测人员直接据此判定一项重要能力不通过。所以送测前，请花半天时间把自己产品的出厂默认配置从头到尾过一遍，就当自己是黑客，能关的口子全关掉，能取消的共享全取消。

5. 常见问题与排查技巧实录

5.1 典型评测问题速查表

整理一张我们项目中遇到的高频问题速查表：

这个表不是标准答案，但每个问题都来自实际项目，对标 9 月份送测的同类产品也基本都是这些坑，提前做预防总比现场救火强。

5.2 三个容易被忽略的考察点

第一个是固件版本的一致性。产品可能有多个分支版本，测试时用的版本和文档描述不一致，评测人员很可能直接判定“版本可追溯性不符合”。送测前一定要统一固件版本号，明确版本变更记录和代码分支关系，并把签名校验信息一并备好。

第二个是产品的恢复机制。很多测试项会把设备折腾到非正常工作状态，比如通过异常报文冲击通信栈、模拟非法固件刷写、写入越界配置等。如果设备不具备可靠的重启恢复能力，导致多次测试中断，评测人员会认为设备“健壮性不足”。我们在测试前专门写了一套自动化恢复脚本，能够在设备进入异常状态后自动重启并恢复出厂配置，大大提升了测试效率。

第三个是安全功能的默认状态。SL 评测里有一个相当关键的原则：安全功能默认开启才算有效。假如产品提供了访问控制、通信加密等高级安全功能，但出厂默认状态是关闭的，测试人员会合理地认为这个功能“不可用”，因为最终用户不可能人人都是安全专家。这个点特别容易被研发团队忽视，他们觉得“我们有这个功能”就够了，但实际上评测看的是“用户拿到手上的设备是否安全”。

6. 个人经验与踩坑记录

6.1 我在项目中踩过的三个实打实的坑

第一个坑发生在项目第一周。我们拿到被测样品后没有做基线测试就直接进入了正式评测，结果第二天就发现控制器的某个通信端口在生产模式下竟然还能被远程配置。研发同事解释了十分钟为什么“这个端口设计上就是如此”，但评测人员只关心一点：标准要求设备应禁止未授权配置操作。我们不得不停下来修改固件默认策略，整个项目因此延期了两天。从那以后我定了一个规矩：任何产品送评前先在自己实验室按标准要求做一遍基线核查，宁可内部先暴露问题，也不要到正式评测现场再来处理。

第二个坑在外围测试环境的隔离。我们自己搭的陪测上位机为了省事，直接接入了公司办公网络。结果在一次抓包过程中，办公网络的广播流量污染了测试网段，导致被测控制器出现不明原因的周期性通信延迟。排查了一整天后，才发现是交换机 VLAN 划分不合理。解决方案很简单：独立测试网段 + 物理隔离交换机，永久禁用陪测设备连接外部网络。做评测不是做开发，环境的纯净度决定测试结果的置信度。

第三个坑和人员分工有关。连续两周的测试执行阶段，测试工程师三班倒，但文档整理只有一个同事负责，证据积压了一大堆。等要提交材料时才发现很多测试现场没拍照，或者照片上设备状态与记录不符，只能重新排查。后来的办法是每天固定时间强制归档当天的测试记录，再忙也要在当晚下班前完成。项目类工作最忌讳的其实是积压。评测项目尤其如此，因为现场状态是流水账，过了那个节点就再也找不回来了。

从整个项目复盘的角度看，SL 评测认证绝不只是“把产品送过去测一下”那么简单，它既是一次安全能力的体检，也是一次产品工程化水平的审视。文档缺不缺、默认配置乱不乱、恢复机制健不健全，这些平时容易被忽视的细节，到了评测现场都会以最直接的方式暴露出来。希望这篇文章能帮准备走这条路的朋友少走几步弯路。如果你正在做类似的产品认证，欢迎在实际操作中多交流，尤其是 CODESYS 环境配置和异常报文测试这两个方向，我后面还会继续整理更细的材料。