★ FEATURED ARTICLE 说实话第一次在化工车间做等保整改时我差点被现场工程师赶出去。原因很简单我按办公网的老思路给操作员站装了一款企业版杀毒软件结果它把DCS组态软件的运行进程当成恶意进程给杀了中控台屏幕上报警信息瞬间刷屏。那次之后我才彻底明白工业控制系统的等保建设和IT系统完全是两个物种。这几年网络安全等级保护2.0在工控领域落地得越来越深电力、石化、冶金、轨道交通、汽车制造这些行业基本都把工控系统当成“高压线”在管理。等保不再只是一张证而是直接关系到生产安全和合规红线。很多企业以为买几台防火墙、装几套审计系统就能过测结果测评机构一进场问题清单拉出来几十页。问题的根源在于工控系统的安全防护技术体系不是堆设备而是要围绕“生产优先、可用性第一、分区隔离、协议可控”这一套底层逻辑来做整体设计。这篇文章就围绕网络安全等级保护工业控制系统安全防护技术体系设计这条主线把定级备案、区域划分、纵深防御、集中管控、落地案例、避坑经验全部讲透。不管你是等保测评机构的工程师还是工业企业里负责信息安全的IT主管或者是刚入门工控安全方向的学生这篇文章都能给你一套可以直接抄作业的设计思路。1. 等保2.0落在工控系统上到底难在哪很多人第一次接触等保2.0里的“工业控制系统安全扩展要求”时第一反应是这不就是通用要求在工控场景下加了几条备注吗还真不是。等保2.0的核心标准GB/T 22239-2019把工业控制系统作为独立的新兴应用场景单列出来在通用安全要求之外增加了扩展要求覆盖物理环境、通信网络、区域边界、计算环境、安全管理中心、建设管理和运维管理七个层面。这些扩展要求背后是工业控制系统和传统信息系统本质上的差异。1.1 通用要求与工控扩展要求的关系我接触过不少企业以为工控等保就是把原来的等保方案改个标题把“服务器”改成“工程师站”“操作员站”把“防火墙”改成“工业防火墙”就完事了。这种换汤不换药的做法测评老师一眼就能看出来因为工控扩展要求的测评项非常具体比如“是否对工业控制协议进行深度检测”“是否对工程组态软件和控制器固件进行版本管理”“是否对USB等外部设备接入进行管控”等每一个都是冲着工控场景的实际风险去的。通用要求解决的是信息系统普遍存在的安全风险强调保密性、完整性、可用性三者的平衡而工控扩展要求在第一优先级上明确把“可用性”摆在了最前面这是整个设计逻辑的分水岭。工业控制系统里一条PLC控制指令如果被延迟几百毫秒产线上的机械臂可能就撞了一台操作员站如果蓝屏整个中控室的操作员可能就失去了对现场设备的监视能力。所以工控等保的技术措施必须做到能防护、但绝不能妨碍正常生产控制。1.2 工控安全与IT安全的三个本质矛盾设计工控安全防护体系前先得认清三个矛盾否则后面做的所有策略都会“水土不服”。第一可用性优先还是保密性优先。办公网里数据泄露是头等大事防火墙策略可以做得极严断了业务最多是员工抱怨。但工控网里网络安全设备一旦误杀业务报文导致的直接后果就是产线停摆、设备停机损失以分钟计算。所以在工控网络里安全策略的默认姿态是“白名单按需放行”而不是“黑名单阻断”。第二确定性优先还是检测优先。IT系统追求对未知威胁的实时检测和响应杀毒软件天天更新病毒库。但工控系统特点是业务通信高度确定谁和谁通信、跑什么协议、用哪个端口、流量多大基本是固定的。正因为确定最好的防护模式就是基线白名单而不是天天靠特征库去猜什么是恶意流量。第三设备生命周期长还是安全迭代快。一台办公电脑用三年就淘汰了但一套DCS控制系统可能运行十五年甚至更久用的操作系统很可能是Windows 7甚至Windows XP漏洞一堆却没法打补丁因为补丁可能和组态软件冲突。这个现实决定了工控安全防护不能依赖“先有漏洞库才能防护”的传统思路而要靠白名单、网络隔离、协议过滤这些不依赖补丁的机制来兜底。1.3 “一个中心、三重防护”的工控化改造等保2.0的整体框架是“一个中心、三重防护”也就是以安全管理中心为大脑对计算环境、区域边界、通信网络进行纵深防御。放到工控场景里这套框架一样适用但具体落地有了明显变化。计算环境防护从“装杀毒软件”变成了“应用白名单加固”区域边界防护从“防火墙控制端口”变成了“工业防火墙控制协议功能码”通信网络防护从“局域网VLAN划分”变成了“生产控制大区与管理信息大区隔离、控制子网间基于Purdue层级做访问控制”。安全管理中心则从“装一堆孤立管理工具”变成“集中收集日志、统一配置策略、统一展现安全态势”这既是等保三级测评的硬性要求也是日常运营真正能落地的基础。所以工控等保技术体系设计的本质是把“一个中心、三重防护”这个通用框架按工控场景的可用性优先级和协议特征做一次“换芯”重组。2. 体系设计第一步定级备案与安全域划分任何等保项目的起点都不是买设备而是定级备案。定级定错了后面所有工作可能都白做。工控系统的定级比普通信息系统更讲究因为一个大型工厂里往往有DCS、PLC、SCADA、SIS安全仪表系统、MES、ERP等各种系统业务关系复杂而且同类系统在不同行业的重要性差异也很大。2.1 定级对象怎么拆才合理我见过有的企业图省事把整个工厂的工控网络和办公网络打包成一个定级对象结果测评范围大得离谱边界模糊连测评机构都不知道该从哪下手。这种做法不可取。定级对象拆分的原则是“系统功能相对独立、安全责任能够明确划分、管理边界清晰”。在工控场景里常见的拆分方式是管理信息大区ERP、OA、邮件等单独作为一个定级对象生产控制大区作为一个定级对象如果一个企业有多个互不相通的车间控制网且分属不同业务单元可以分别定级。SIS安全仪表系统因为涉及生命安全保护建议独立定级而且级别不能低。还有一种常见情况是同一个生产控制大区内有多个安全域但整体仍作为一个定级对象来测评内部安全域通过扩展要求中的区域隔离要求来约束。之所以强调这些是因为定级对象直接决定了后面的测评成本和安全建设范围。定级对象拆得越清楚防护体系设计越有针对性也不会出现“为了一台MES服务器把整条产线的PLC全部纳入重保范围”这种边界失控的情况。2.2 定级要素与建议级别等级保护定级看两个维度业务信息被破坏时的受侵害客体国家安全、社会秩序、公共利益、公民及法人合法权益以及受侵害的程度一般损害、严重损害、特别严重损害。工控系统一旦被破坏往往直接导致生产安全事故影响面从企业内部扩散到社会面比如城市供水SCADA系统瘫痪、电网调度异常、化工装置失控这些已经触及公共利益甚至国家安全层面。实际操作中我给出的参考建议是直接影响生产安全、涉及危险工艺、属于关键信息基础设施的工控系统定级不应低于第三级中小型离散制造业的MES、车间控制网络如果仅影响本企业生产定第二级是常见做法涉及供电、供水、供气、交通信号、石油天然气长输管道等公共服务的SCADA系统基本都要往第三级甚至第四级定。定级完成后要按要求备案三级及以上系统每年开展一次等级测评这是硬性规定。二级和三级的安全要求差距非常明显直接关系到项目预算。我做了一个简单对比对比项第二级第三级测评频率每两年不少于一次每年不少于一次集中管控有基本要求必须建立统一安全管理中心策略统一、审计集中访问控制自主访问控制等基本要求强制要求安全区域边界、细化协议级访问控制安全审计主要设备和服务器审计网络、主机、应用、安全设备全面审计留存不少于六个月数据备份本地备份本地备份异地备份身份鉴别口令密码等基本要求双因素认证、堡垒机管理运维操作这张表里的每一项都会直接映射到技术防护体系里具体要部署什么、做到什么程度。2.3 基于Purdue模型的安全域划分定级备案完成后技术体系设计的第一步是划安全域。工控领域最经典、也最适用的参考模型是Purdue模型它把工控网络从下到上分成L0到L5六个层级。L0是现场设备层包括传感器、变送器、执行器、变频器等L1是基本控制层即PLC、DCS控制站、RTUL2是过程监控层包含HMI人机界面、操作员站、实时数据库L3是生产管理层涵盖MES、历史数据库、工程师站、报表服务器L4和L5属于企业网络层是ERP、OA、邮件等管理信息系统。安全域划分的核心逻辑是同层级之间按需互通跨层级必须经过受控边界安全级别不同的区域之间必须做强隔离。比如L2操作员站要访问L1的PLC这是正常业务需求但必须控制只能访问本生产线的PLC且只允许Modbus TCP、S7comm这类工控协议源和目的都要明确到IP。再比如L4办公网想访问L3历史数据库做报表分析就必须通过工业防火墙或网闸做单向数据摆渡而不是直接在核心交换机上打通路由。我习惯把这种划分称为“楼层思维”楼上楼下可以串门但必须走门禁不能从窗户随便翻。安全域划分不是纯技术设计它直接影响后续每一台设备策略的颗粒度所以这一步一定要和企业工艺部门、自动化部门反复确认把边界数据流彻底盘清楚再动手。3. 纵深防御的技术体系拆解安全域划好之后就进入真正落地设备的环节。工控等保技术体系我用一句话总结边界做隔离流量做白名单主机做加固行为做审计运维走堡垒机全局统一管理。下面按层次拆开讲。3.1 边界与通信网络防护从网络隔离到协议级过滤边界防护是工控安全体系里投入最大、见效最快的一层但也是最容易出事故的一层。我反复跟团队强调一个原则工控边界设备不能只当网络层防火墙用必须支持工控协议深度解析。先看网络隔离。生产控制大区和管理信息大区之间原则上应该部署工业网闸或工业防火墙。网闸适合数据单向同步场景比如生产区数据要单向发给办公区展示大屏办公区不允许回连生产区用单向网闸最合适。工业防火墙则适合双向业务仍有必要、但必须要做精细化控制的场景它比传统防火墙多出来的是“看得懂PLC协议”的能力。具体到策略设计工业防火墙要能识别并过滤Modbus TCP、S7comm、OPC UA/DA、IEC 104、DNP3这些常见工控协议。以Modbus TCP为例普通防火墙只能看到源IP、目的IP、源端口、目的端口但工业防火墙还能解析到功能码和寄存器地址。这样就可以做到“只允许某个HMI读取1号PLC的保持寄存器禁止写线圈”这种颗粒度对于防止误操作和恶意指令灌入非常关键。我贴一个实际项目中Modbus TCP白名单策略的简化示例方便你理解配置思路# 策略示例仅允许中控室操作员站访问1号PLC 源192.168.10.10操作员站 目的192.168.20.51号PLC 协议Modbus TCP 功能码0x01 读线圈、0x02 读离散输入、0x03 读保持寄存器、0x04 读输入寄存器 禁止功能码0x05 写单线圈、0x06 写单寄存器、0x0F 写多线圈、0x10 写多寄存器很多企业的痛点在于产线正常运行时没人说得清哪些功能码是日常需要的哪些是组态时才用的。稳妥的做法是先用工业防火墙的“观察模式”跑一到两周记录正常业务流量基线再根据基线生成白名单策略最后才切换成阻断模式这个流程后面我会在避坑部分详细展开。通信网络层面还有一个容易忽略的点是远程运维。许多工控厂商为了远程诊断会开放Modbus、S7等端口到办公网甚至互联网这是测评里最典型的高风险项。正确做法是部署堡垒机加加密隧道所有远程运维必须经过身份认证、操作审计账期到期自动失效杜绝裸奔式的远程访问。3.2 计算环境防护主机白名单是工控主机安全的核心计算环境在工控场景里主要指操作员站、工程师站、历史服务器、应用服务器和接口机。这些主机的共性是配置固定、用途单一、运行软件版本长期不升级恰恰又最容易成为攻击跳板。针对这些主机我给你一套“三步走”的技术方案。第一步应用白名单。工控主机上运行的合法程序是有限的比如操作员站就是操作员客户端加组态运行库工程师站就是组态软件、驱动、编译器。用白名单机制把允许运行的可执行文件、脚本、DLL全部锁死其他一律禁止执行这是工控主机防勒索、防植入最有效的手段。实施时先进入学习模式观察积累一周的合法进程快照生成基线后再收紧。第二步主机加固。包括禁用默认共享、关闭445等高危端口、禁用Guest账户、加强口令策略、开启本地安全日志。这里要注意不能照搬办公网加固清单比如OPC通信依赖DCOM的135端口如果你不分青红皂白全部封死组态软件直接连不上PLC所以加固前必须和自动化厂商核对端口清单。第三步外设管控。工控现场最头疼的是U盘病毒和笔记本乱接。要通过组策略或终端管理系统彻底禁用USB存储设备自动运行只允许经过杀毒的专用U盘并做好外联管控禁止生产网主机私接互联网。光这一点就能挡掉大量因巡检人员“顺手插U盘”导致的中毒事件。3.3 审计与集中管控让安全可视、可管、可追溯光有防护不审计等于闭着眼睛开车。等保三级对安全审计有硬性要求日志留存不少于六个月要对网络日志、主机日志、安全设备日志进行集中收集和关联分析。工控系统的审计有自己的特殊性普通审计平台解析不了PLC协议所以必须部署工控专用的流量审计系统。工控流量审计一般通过交换机镜像口旁路部署不影响业务。它的核心价值有两个一是还原工控协议会话记录谁在什么时间访问了哪台PLC执行了什么功能码操作二是基于基线做异常检测比如半夜三点突然有大量写寄存器操作或者从未见过的设备尝试连接控制站系统立刻产生告警这个能力在溯源取证时非常管用。再来看集中管控平台。我把它比作整个安全体系的“作战指挥室”工业防火墙、网闸、审计系统、主机白名单、堡垒机的策略和告警要全部汇聚到一个平台上做统一管理。三级等保测评时专家如果看到每个设备都在单打独斗没有一个统一安全管理中心往往直接判定不满足集中管控要求。这个平台还要提供整体安全态势展示、策略统一下发、告警闭环处置能力方便安全团队的日常运营。堡垒机则负责运维入口的收敛。生产网内所有网络设备、服务器、工控主机的运维操作都要经过堡垒机人员登录必须双因素认证操作过程录屏审计权限最小化分配。这样即使第三方DCS厂商工程师进场调试也能留痕可查不担心里面做了什么非法操作说不清。4. 实例复盘某制造企业的三级等保工控防护体系前面讲了一大堆理论可能有朋友觉得不够直观。下面我复盘一个最近完成的汽车零部件工厂三级等保整改项目把整体思路、设备清单、策略设计和落地效果完整过一遍方便你直接参考。4.1 项目背景与现状这家工厂有两条焊接生产线和一条总装线每条产线都有独立的PLC控制柜和HMI触摸屏中控室有6台操作员站和2台工程师站另有一台历史数据库服务器采集产线数据。生产管理区有MES服务器办公区有ERP、OA、文件服务器。项目启动前的网络状态可以用“裸奔”来形容办公网和生产网共用核心交换机没有任何隔离办公网电脑可以ping通PLC操作员站全是Windows 7系统只有一个盗版杀软工程师站存在大量弱口令账户现场巡检人员经常插U盘拷贝历史数据。这家企业要做三级等保测评的原因也很现实它是某主机厂的Tier 1供应商主机厂在供应链安全审计中要求所有核心供应商的生产系统必须通过网络安全等级保护三级测评否则取消新项目定点资格。这是标准合规驱动的整改项目。4.2 安全域规划与部署方案我们按照Purdue模型把整个网络重新划分为四个安全边界清晰的区域办公管理域、生产管理域、过程监控域、现场控制域。办公管理域与生产管理域之间部署工业网闸和工业防火墙双链路办公区的报表系统只能单向读取生产数据生产管理域内的MES服务器访问过程监控域的历史数据库必须经过工业防火墙白名单过程监控域的操作员站、工程师站访问现场控制域的PLC精确到IP和协议功能码。设备部署清单如下设备类型数量部署位置主要作用工业防火墙2台办公网与生产管理域边界、生产管理域与监控域边界协议白名单、访问控制工业网闸1台办公网与生产管理域单向数据摆渡生产数据单向发布工控流量审计系统1套生产管理域核心交换机镜像口工控协议审计、异常检测主机白名单终端系统30点操作员站、工程师站、历史服务器、MES服务器应用白名单、外设管控堡垒机1台运维管理区集中运维入口、操作审计日志审计系统1套安全管理中心日志集中收集、六个月内存储集中管控平台1套安全管理中心统一策略管理、告警聚合这里我特别提一句工控流量审计系统的探针一定要接在能同时看到过程监控层和控制层流量交换的位置很多项目为了图省事直接接在核心交换机上结果各控制子网的流量全在二层交换机上就消化掉了审计系统根本看不到PLC通信细节。4.3 安全策略设计示例网络划分之后策略设计的核心就两个字收敛。原则是“默认拒绝显式放行”。办公管理域到生产管理域的访问控制我们只放行了MES服务器与ERP服务器之间的接口机IP和端口以及报表系统到历史数据库的只读连接其余全部拒绝。生产管理域到过程监控域放行MES服务器访问历史数据库、工程师站访问各PLC组态端口其他禁止。过程监控域到现场控制域按产线一对一定制白名单。以焊接线为例工程师站需要在线修改PLC程序我们开放的通信关系是这样的工程师站 192.168.30.10 焊接线PLC 1号 192.168.40.11 焊接线PLC 2号 192.168.40.12 协议S7comm TCP 102 允许方向工程师站 → PLC组态下载、在线监控 同时方向PLC → 工程师站状态回传 操作员站 192.168.30.11 放行对PLC的S7comm只读监控禁止下载主机白名单方面我们在每台操作员站上锁定了组态软件客户端、OPC客户端、系统关键进程等10类进程测试期学习了两周后切到强制模式。现场的外设管控同时启用所有USB存储设备必须插一次专用杀毒终端完成查杀才能在中控室使用且操作记录留痕。远程运维通道我们全走堡垒机加加密隧道DCS厂商工程师从外地登录必须先在堡垒机申请临时账号审批通过后建立加密远程会话全过程录屏并留存六个月以上到期自动销号。这块设计从根本上解决了过去“厂商一个电话就打洞进生产网”的问题。4.4 落地效果与整改项整个项目从方案设计到测评通过历时三个月。整改前测评机构出的初测报告里高风险项有11项中风险19项整改后复测高风险项清零中风险项压到3项以内顺利拿到三级测评通过报告。直观的变化体现在几个方面办公网再也不能直连PLC所有跨区域数据流动都有设备守门U盘随意插拔的情况被技术手段卡死巡检人员必须走登记流程历史库被盗链读数的问题通过协议白名单完全堵住安全团队可以从集中管控平台上一屏看到全网安全告警和工控协议会话记录再也不是“出了事只能翻交换机日志”。实际上部署完成两个月后平台就捕获到一次内部工程师违规从操作员站拉取产线工艺参数到办公网的行为这在以前根本无法追溯现在直接定位到人和时间点。5. 常见问题与避坑指南做了这么多工控等保项目踩过的坑两只手数不过来。这里挑最典型的几类问题整理成指南帮你少走弯路。5.1 上线即“翻车”安全策略影响控制通信这几乎是每个工控安全项目都要经历的一道坎。最典型的现象是工业防火墙切换到阻断模式不到半小时操作员站大面积掉线PLC通信中断报警此起彼伏。原因是上线前没有做好流量基线学习策略只写了端口却把PLC之间正常的组播心跳包给拦截了。我的处理经验是任何边界策略和设备在正式阻断前至少要跑两周“影子模式”或“观察模式”记录所有异常流量和正常基线策略切换必须分级灰度比如先只过滤办公网到生产网方向再处理生产网内部方向每条策略都要标注业务用途和责任人避免三个月后没人说得清这条策略是谁加的、为什么加。5.2 扫描工具引发的生产事故很多刚接触工控等保的服务商喜欢拿传统漏洞扫描器对着工控网扫一遍结果发现扫描过程中PLC的CPU利用率飙到高峰甚至直接导致控制器看门狗重启。这不是设备垃圾而是工控协议对非预期流量太敏感。老版本的S7Comm、Modbus TCP在收到异常格式报文时固件处理逻辑并不健壮容易被异常报文干扰。正确做法是首选被动流量分析和工控专用的无损漏洞评估工具用镜像口抓包方式做识别不向控制器发送主动探测报文如果必须做主动扫描也要先做离线仿真环境验证扫描策略限制并发数和深度避开生产时段。工控环境里“扫一下”可能真会让一条产线停下来这一条必须刻在脑子里。5.3 白名单与业务变更冲突应用白名单上线后维护人员改一次组态可能就被拦一次工程师会觉得这东西是来添乱的。根源在于变更流程没设计好。白名单不能是一成不变的死规则它必须配合一套变更管理流程。我的建议是日常业务变更走“申请→审批→临时放行→复核→恢复强制”闭环流程白名单平台要能快速生成临时放行窗口比如允许某台工程师站在下周一上午九点到十一点执行组态下载操作时间到自动回收权限。这样既满足安全基线又不妨碍正常的产线维护。如果操作太繁琐你就要反思这个过程是不是哪里可以自动化安全工具最终应该让人感觉“有用”而不是“添乱”。5.4 测评不通过的常见原因结合多次等保测评经验工控系统最容易挂的不仅有技术项管理项也是重灾区。我在测评现场见过不少企业技术设备买得挺全最后还是被判定整改不通过问题往往出在这些地方机房和机柜间没有门禁和视频监控或者监控录像留存不足三个月物理安全项直接不满足。生产网和办公网存在未受控的隐蔽链路比如某台工程师站同事接了办公网WiFi这种旁路连接是网络安全设备防不住的。日志留存不足六个月部分工控主机根本不开启日志采集审计平台形同虚设。第三方运维供应商和厂商远程维护过程没有记录没有签署保密协议和操作审批单。集中管控平台缺失安全设备和主机安全各自独立运行无法体现统一管理。每一条看起来都不难解决但在实际项目里因为赶工期、省预算而把这些“软环节”砍掉的情况实在太多了。等保测评不是只看设备更看体系化建设和证据链留存。5.5 我的五条独家经验最后分享几条我自己压箱底的经验也不算独家但都是真金白银踩出来的。第一条梳理资产盘点一定要比采购设备早一步。很多企业连自己有多少台PLC、装了什么版本的固件、哪些端口对外开放都说不清就开始买防火墙结果设备到了没有策略可配。资产清单是安全体系的底座这个懒不能偷。第二条安全域边界规划要拉上自动化部门一起开评审会。IT部门画出来的拓扑往往和现场实际走线对不上。只有真正懂产线工艺的人才能告诉你哪条链路是冗余的、哪条是临时拉的、哪个端口是为了设备厂商远程调试才留的口子。第三条只要预算允许优先选支持观察模式的双模部署设备。无论是工业防火墙还是主机白名单一定要有影子模式先在非阻断状态下积累基线再真正收紧规则这是减少业务冲突最有效的手段。第四条工控协议白名单的初始规则不要拍脑袋写。我会找一个生产最平稳、负荷最低的时间段用流量审计系统连续采集两周数据把正常通信模型摸清楚再转成防火墙策略。这样做出来的策略业务误伤率极低。第五条也是我认为最重要的一条文档同步更新一定要跟上。等保测评会要制度文件、操作记录、变更记录、应急预案、演练报告任何一次策略变更、设备配置变更都必须留痕。很多项目技术干得很漂亮最后却因为文档缺失被打回整改这笔账太亏了。在我做过的所有工控等保项目里凡是能把“合规”当成“安全建设抓手”的企业最后收获的都不只是一张测评通过证书而是一套真正看得见、管得住、能追溯的生产网络安全体系。设备可以靠预算堆但体系的灵魂在于理解工控业务、尊重现场工程师的每一次操作。你能把安全策略设计得既严丝合缝又不打扰生产这套体系才算是合格了。
阅读完成 · 觉得有帮助？
