在船舶OT安全改造这条路上我见过太多的方案文档画着漂亮的安全域拓扑但落到“底层怎么实现访问控制”时就开始含糊其辞。这个问题的答案其实非常具体它就是数据面规则、策略模型和身份映射这三件事。今天这篇实践记录就是我基于UR E27规范在一条示范船舶的OT网络里做安全域微隔离底层实现的完整思路包括规范如何拆、域怎么划、策略怎么写、规则怎么下发、坑怎么踩希望能给正在做船舶等保和工控安全的同行一个可以直接参考的样本。1. 项目背景为什么船舶OT必须做微隔离1.1 UR E27规范到底要求了什么UR E27是国际船级社体系里针对船舶网络韧性的统一要求核心逻辑就是让船上的系统按“一旦失效或遭攻击后会带来什么后果”来划分重要程度。规范里把船载系统大致分成几类影响级别影响级别高的系统比如主推进、舵机、电站管理必须放在受控最强的安全区域里影响级别低的系统比如船员娱乐、办公网络则不能与关键系统处在同一个广播域或同一套访问控制策略之下。很多人第一次读UR E27会觉得它只是提了一些安全管理要求比如要区分安全边界、要控制网络访问、要做审计。但真正落地的时候这些词会变成非常具体的工程问题哪些设备属于哪个区域区域之间哪些端口能通同区域内部的主机之间要不要隔离这些问题不解决规范评审那一关就过不去。我参与的这条示范船轮机自动化、电站管理、压载和液位监控分布在传统二层网络里办公网和娱乐网又混在一个物理链路里。船东的要求很明确按照UR E27的结构重新划分安全域并且在网络底层真正实现“区域默认阻断、白名单放行”不能只是换一台防火墙做个NAT就完事。1.2 传统边界防护为什么挡不住横向渗透以前很多船舶网络只有一道边界防护就是在船岸通信网关或者核心交换机上放一个防火墙认为外部进不来就安全了。但真实运营场景里威胁更多是从内部起来的维修工程师带着调试笔记本上船电脑里如果带着恶意软件接入控制网段后可以直接扫描并攻击PLC。船员用U盘拷贝文件不小心把蠕虫带进了办公网办公网又跟机舱监控网有互联。远程诊断服务开通后外部攻击面进一步扩大单纯靠边界ACL很难覆盖所有细粒度通道。边界防火墙管的是“南北向流量”也就是内外网之间的进出。但一旦有一台内部设备失陷攻击者会利用内网互信关系做“东西向”横向移动从办公区一路摸到推进控制系统。微隔离解决的正是这个问题不仅是区域之间有隔离区域内部的每个主机、每个工作负载之间也要有明确的访问关系和最小授权。1.3 船舶环境做微隔离的独特约束跟数据中心里做微隔离相比船舶OT网络有几个非常不一样的地方设备老旧且IP长期固定很多工控机还是Windows XP或老旧嵌入式系统无法安装复杂的代理程序。工控协议多样Modbus/TCP、EtherNet/IP、PROFINET等实时协议对时延很敏感规则检查不能引入太大转发延迟。网络变更是低频事件但每次变更都是关键操作谁也不敢在生产状态下乱动规则。标准要求明确“安全域”“安全边界”这些概念必须能在系统架构图里可追溯。所以我的整体判断是微隔离的底层实现不能照搬数据中心那套“每台虚拟机一个虚拟网卡分布式防火墙”的模式而要更贴近船舶现状走“控制器统一策略 区域边界网关执行 关键主机旁路缓解”的轻量化路线。2. 安全域划分与策略模型先做架构再谈技术2.1 按UR E27的影响分类设计安全区域矩阵安全域怎么划是这次项目第一步也是后面所有规则设计的地基。我的做法是把全船系统先做一次影响等级梳理再映射到网络区域。在这艘示范船上我最终划分了五个安全域安全域名称主要承载系统影响等级参考隔离强度SZ-1 核心推进域主推进控制、舵机、电站管理最高最强默认全隔离仅允许指定HMI访问SZ-2 辅助机械域压载、液位、辅机、燃油监控高强区域内纵向白名单SZ-3 船岸网关域卫星通信、远程诊断、数据采集网关中高隔离等级高只允许协议白名单SZ-4 船员办公域邮件、文件、船舶管理系统中办公网独立严格控制到SZ-1/SZ-2的访问SZ-5 访客娱乐域船员娱乐、乘客网络低完全隔离与生产网物理或逻辑断链区域划分的目的是把“影响等级”变成“网络可达性”。比如推进控制系统是最高影响等级那我就要求它在网络层不出现在任何广播域里甚至连办公网都做不到主动嗅探它。辅助机械域虽然也要跨区域访问但只开放工控协议端口禁止通用文件共享和远程桌面。2.2 用声明式策略模型描述访问关系划分完安全域我习惯先把访问关系写成一份“策略模型”而不是一上来就敲防火墙命令。策略模型是文档也是人和机器之间的共同语言。我用的是一种比较通用的JSON格式每条策略表达“谁在什么条件下可以访问谁”。下面是我在示范船上定义的几条典型策略{ policy_id: P-1001, name: 推进PLC仅接受指定HMI访问, description: 核心推进域内PLC 502端口仅向推进系统的两台HMI开放, source: { zone: SZ-1, hosts: [hmi-prop-01, hmi-prop-02] }, destination: { zone: SZ-1, hosts: [plc-prop-01, plc-prop-03] }, ports: [502], protocol: tcp, action: allow, mode: enforce, log: true }{ policy_id: P-2003, name: 办公网禁止主动访问辅助机械域, source: { zone: SZ-4 }, destination: { zone: SZ-2 }, action: deny, mode: enforce, log: true }这种做法有几个实际好处。第一船东和验船师可以在评审阶段直接看策略模型不用去读几百条ACL。第二策略模型跟具体的底层实现解耦今天用nftables明天换eBPF策略不用重写。第三以后增加新设备只需要在“主机清单”里补一条身份映射不需要碰策略本身的逻辑。2.3 从三张清单到可落地配置真正下沉到实现层策略模型会经过编译变成规则而编译的前提是先维护好三张清单资产清单每台设备所属安全域、IP/MAC、操作系统、承担角色、开放端口。身份映射表主机名、IP、MAC之间的绑定关系这是微隔离识别流量的依据。通信矩阵区域与区域之间、主机与主机之间的允许关系一张二维表格。我会专门强调资产清单的重要性。在一条运营中的船上很多设备的IP是自动获取的甚至存在IP漂移如果规则只认IP很容易把正确的流量挡掉或者放行错误的流量。所以我在资产清单里强制要求绑定MAC对于一些工控设备还会记录它的网卡厂商特征和已知协议指纹以便在规则匹配时多一层校验。3. 微隔离底层实现的技术选型与控制面设计3.1 三条技术路线的比较微隔离的底层实现行业内基本跳不出三条路线。我分别列一下特点路线一纯SDN方案。核心思路是把交换机的转发面交给集中控制器用OpenFlow或者厂商私有协议下发流表。控制粒度可以做到端口级灵活性最高。缺点是船舶现网的交换机大多不支持需要更换核心网络设备工程量极大而且控制器一旦故障全船转发策略都会受影响。路线二主机Agent模式。在每台操作员站、工控机上装代理用本机防火墙或内核钩子实现规则限制。粒度非常细可以做“进程级”隔离。问题是老旧工控机装不上、杀毒软件冲突多、维护成本高而且对PLC这种嵌入式设备完全没有办法。路线三区域边界网关模式。在每个安全域的出入口部署一台策略执行网关由中心控制器统一下发规则网关承担全部东西向流量的过滤和审计。这是我在这个项目里最终采用的路线因为它对现网改动最小控制粒度足够满足UR E27的审查要求又能容纳老旧设备。对比维度SDN方案主机Agent方案区域边界网关方案全网改造量大需更换交换机小但需逐台装软件中只改区域边界控制粒度端口级进程/主机级主机/端口级对老旧系统适配依赖交换机差好策略集中管理强中强运维风险控制器单点Agent与业务冲突网关双机可冗余3.2 控制面与数据面分离的架构我最终落地的架构分成了两层控制面一台微隔离控制器部署在船岸网关域负责设备注册、身份映射、策略模型管理、规则编译和状态监控。数据面每个安全域的边界上部署策略执行节点执行节点是Linux主机运行nftables作为规则执行引擎。核心推进域因为设备数量少、安全要求高额外部署了基于eBPF的观测探针用于采集流量元数据做审计。控制器和数据面之间用管理VLAN传输管理VLAN本身有独立ACL控制器IP只对数据面执行节点和管理终端开放。这里还要求所有执行节点都开启审计日志日志实时回传到控制器上的本地日志模块方便后续排查问题。这里有一个关键设计考量我没有让控制器实时下发每条策略而是采用“规则快照”的方式。控制器把编译好的规则集一次性推给执行节点执行节点加载后就本地生效。这样即使控制器断网各区域依然保持原有的隔离策略不会出现“策略丢失导致解禁”的危险状态。对船舶这种通信链路偶尔不稳定的环境这比强依赖在线控制更可靠。3.3 规则编译从策略模型到底层规则策略模型不是直接扔给nftables执行的中间要经过一个编译过程。我的编译逻辑简单说就是四步身份解析把策略里的主机名、MAC、资产清单转换为IP地址集合。这里会用ARP表、交换机MAC转发表来建立“主机名-IP-MAC”的可靠映射编译前还会做一轮在线探测确认IP没有发生过冲突。规则合并把所有策略按“源IP集合、目标IP集合、目标端口”合并。比如办公域到辅助机械域有十条不同主机策略合并后尽可能减少规则条数而不会让nftables加载几百条冗余线。默认策略生成在每个区域执行节点上生成“默认丢弃”的兜底规则。对所有未命中的流量记录日志后直接丢弃。规则优先级排序nftables按规则链的插入顺序匹配所以放行规则必须放在丢弃规则之前且conntrack状态规则要放在最前面避免已经建立连接的正常流量被误杀。最终生成的nftables规则集大概是这样的结构table inet microseg { chain preresolve { type filter hook prerouting priority 0; policy accept; ct state established,related accept ip saddr 10.20.30.0/24 ip daddr 10.20.40.0/24 tcp dport 502 accept ip saddr 10.20.30.0/24 ip daddr 10.20.40.0/24 tcp dport 44818 accept ip saddr 10.20.30.0/24 ip daddr 10.20.40.0/24 udp dport 2222 accept log prefix MICROSEG-DROP: drop } }上面这段只是示意实际项目里规则会比这多很多特别是一些非标准端口和UDP组播流量。把UDP明确的规则加上去是为了避免工控设备发现协议发出组播后被默认丢弃导致整个区域通信异常。4. 实操过程在示范船网络里落地一套微隔离4.1 现场网络环境假设为了让下面的步骤更具操作性我先把这条示范船的网络环境描述清楚。核心交换机是一台支持VLAN的三层交换机所有区域划分基于VLAN实现。区域出口各挂一台策略执行节点执行节点均运行Linux系统双网卡配置一边接区域内部一边接核心交换侧。SZ-1 核心推进域VLAN 10网段 192.168.10.0/24包含2台HMI、3台PLC、1台变频器网关。SZ-2 辅助机械域VLAN 20网段 192.168.20.0/24包含压载监控、液位监控、辅机控制器、若干远程IO站。SZ-3 船岸网关域VLAN 30网段 192.168.30.0/24包含卫星网关、数据采集服务器、微隔离控制器。SZ-4 区域VLAN 40网段 192.168.40.0/24办公电脑和打印设备。SZ-5 访客域VLAN 50单独物理AP网段 192.168.50.0/24。4.2 实施步骤注册、建模、审核、下发、收敛整个实施流程我按照五个阶段走每个阶段都有明确的产出物和验收标准。第一阶段资产盘点与注册。我带着网络拓扑图到现场逐台核对设备记录设备名称、IP、MAC、端口用途。这里最费时的是访问每台PLC的管理页面确认型号和固件版本。完成后把资产清单导入微隔离控制器。第二阶段策略模型建模。与船东的轮机长、自动化工程师逐条确认通信关系。比如“轮机值班报警能从办公网访问吗”“远程诊断网关能不能读推进PLC数据”这类问题必须由懂业务的人拍板。我把每条确认结果都写成策略模型并编号存档。第三阶段规则审核与模拟。在控制器上编译规则生成“预览模式”规则集。预览模式下执行节点不实际阻断只记录按规则会放行和会丢弃的流量。这个阶段我留了大约一周让船上的自动化系统在正常工况下跑满一个周期收集了真实的通信基线。第四阶段灰度下发。先对SZ-4办公域和SZ-5访客域之间的策略做强制执行再把SZ-2辅助机械域切入强制执行。每个区域切换强制执行后立刻检查该区域内所有工控设备的连接状态和关键报警。第五阶段核心域全量收敛。最后一个切入的是SZ-1核心推进域。因为它的安全等级最高我选择的策略是“除已获批准的HMI和网关任何其他主机都不得访问推进PLC”并且在切换后的48小时里安排专人值守监控报警。4.3 关键配置示例一个安全域边界的完整落地以SZ-2辅助机械域为例我贴一下在现场执行节点上最终生效的核心配置去掉敏感信息后基本可以看懂。# 清空旧规则 nft flush table inet microseg # 定义集合用于维护允许访问的设备 nft add table inet microseg nft add set inet microseg allowed_hmi { type ipv4_addr; flags interval; } nft add element inet microseg allowed_hmi { 192.168.10.10, 192.168.10.11 } nft add chain inet microseg input { type filter hook input priority 0; policy drop; } nft add rule inet microseg input ct state established,related accept nft add rule inet microseg input iif lo accept # 允许来自核心推进域的两台HMI访问本域PLC的502端口 nft add rule inet microseg input ip saddr allowed_hmi ip daddr 192.168.20.42 tcp dport 502 accept nft add rule inet microseg input ip saddr allowed_hmi ip daddr 192.168.20.48 tcp dport 502 accept # 允许数据采集服务器读取本域Modbus寄存器 nft add rule inet microseg input ip saddr 192.168.30.21 ip daddr 192.168.20.0/24 tcp dport 502 accept # 默认丢弃并记录日志 nft add rule inet microseg input log prefix SZ2-DROP: drop这个配置看着简单但有几个细节我得说明。第一我没有在“允许某IP访问某IP”规则里写端口以外的条件因为现场PLC只开放502端口其他端口本来就不监听多写反而增加维护负担。第二组播发现协议我单独放行了特定的UDP目标地址段否则液位监测装置的设备发现会中断。第三允许HMI访问PLC使用的集合是“源IP集合”后续增加新HMI时只要往集合里加IP不用改其他规则。4.4 日志与审计闭环UR E27的审查非常看重可追溯性。所以我要求每个策略执行节点都开启规则日志并回传至控制器。控制器上按策略ID、源IP、目标IP、端口、时间戳做索引形成一张审计表。一旦现场出现“被误杀”的投诉运维人员可以快速查日志判断流量到底是策略拒绝还是主机本身未响应。在微隔离控制器上每个区域的执行节点状态、最近一次规则快照时间、磁盘剩余空间都有面板展示。我特别关注“规则快照失同步”这个指标因为如果某个执行节点长期离线再上线它还可能执行旧的规则集而其他节点已经更新这就破坏了全网策略一致性。5. 部署实录常见问题与排查技巧5.1 默认丢弃导致组播发现协议失效这是我们灰度上线时碰到的第一个真实事故。辅助机械域里的一些远程IO站采用周期性组播方式向监控主机回报状态监控主机通过组播成员关系协议来管理这些IO站。当我给SZ-2执行节点加上默认丢弃策略后IO站发出组播无法穿越执行节点监控主机直接在报警列表里报“设备离线”。排查过程很快抓包发现组播包被drop原因是策略里只考虑了单播。解决方式是先抓一段时间的组播流量把监控主机要接收的组播地址段整理出来在nftables里增加放行规则。这里要特别提醒工控网络里的组播不是可有可无的很多厂商的设备发现、时间同步、状态上报都靠它微隔离规则必须专门评估组播场景。5.2 老旧工控机无法安装补丁与代理示范船上有两台老式液位监视器操作系统很老且长期没有补丁既装不了控制器Agent也无法在本地做安全加固。这种情况下我的处理思路是“隔离加代理防护”把这两台设备单独划到一个逻辑子网执行节点上只对特定监控主机开放端口同时用另一台Linux主机做它们的通信代理代理主机上启用强制访问规则和文件白名单校验。这种“老旧设备代理网关”模式虽然不是最优雅的但至少能保证在最坏情况下设备自身失陷不会直接连累整个辅助机械域。因为代理网关会把它发出的所有流量重新封装PLC侧的访问目标也必须经过代理审核相当于给老设备加了一个对外接口的“安检通道”。5.3 在线变更网络结构导致规则快照过期船上后期加装了一台新的压载泵监控设备工程师把设备IP配置成与旧设备冲突结果微隔离规则按“主机名-IP-MAC”映射匹配时出现了错位新设备流量被错误放行旧设备反而被丢弃。这个问题的根因不在策略本身而在于资产清单没有及时更新。所以我强烈建议在操作规程里加一条硬性要求任何设备新增、IP变更必须先在控制器上进行资产登记确认无误后方可接入区域交换机。热插拔式的设备改动在OT环境里是大忌微隔离的底座就建立在资产身份准确的前提上。5.4 性能优化conntrack表与规则命中顺序船舶网络的设备数量不多但监控协议连接频次很高大量短连接会让conntrack表快速增长。如果执行节点的conntrack上限设置太小新连接会被直接丢弃表现出来就是“监控刷新偶尔断一下”。我把执行节点的conntrack上限从默认值调大同时把UDP超时时间适当缩短避免无状态协议占用太多连接槽位。规则执行性能上因为nftables按链顺序匹配把放行规则写在前面、丢弃规则写在最后可以显著降低匹配延迟。在示范船这种数据包速率下肉眼基本感受不到额外时延。5.5 常见问题速查表问题现象可能原因排查命令/方法解决办法新设备接入后不通资产清单未登记控制器上查身份映射先在资产清单注册再接入组播状态上报中断默认丢弃策略拦截组播tcpdump抓组播包单独放行指定组播地址段周期性连接闪断conntrack表溢出查看执行节点连接数调大上限缩短UDP超时旧设备流量被错误匹配IP冲突或MAC绑定失败查看ARP表冲突升级IP-MAC绑定校验规则下发后部分主机失联规则快照过期对比节点规则版本重新推送全量快照6. 关于技术路线和项目节奏的几点体会再说几句个人经验。第一船舶OT微隔离最怕“一上来就追求全部自动化和最细粒度”。数据中心那套先进理念搬到船上往往会在老旧设备和有限网络条件下碰壁。最稳妥的路径是先做区域级隔离、再做主机级隔离、最后再做应用级隔离每一步都要有明确收益后才能继续推进。第二UR E27规范只是给了安全目标和审查框架它不会规定你必须用哪种底层技术。我在项目里选择nftables作为执行引擎是因为它轻量、稳定、规则文本可读性强而且现场能找到一个熟悉Linux命令的人维护。如果团队更熟悉商业防火墙完全可以用同样的策略模型翻译成防火墙规则。重点是策略模型统一底层执行引擎反而是可以替换的。第三微隔离上线只是开始不是结束。船舶每次进港、每次船东加装新设备、每次自动化系统升级都会产生新的通信需求这些需求如果不回流到策略模型里微隔离体系会慢慢腐朽。我会建议在每次修船或航线调整前专门留一个窗口期做策略复核把存量规则重新梳理一遍清掉那些已经用不到的放行记录。最后想分享一个极小的技巧在所有微隔离执行规则里增加一个“全局置顶日志”链把未命中流量全部记录后丢弃。这样即使现场出了问题你也有足够的审计数据去回溯而不是靠猜或者反复试错。做OT安全留痕比任何花哨的检测技术都更有实际价值。