4. 工业网关资产识别与访问关系梳理
工业网关远程访问安全治理的第一步，不是急着配防火墙或改密码，而是把“谁在网里、谁在连谁、谁被允许连谁”这三件事说清楚。资产识别回答的是“有哪些网关、它们长什么样”；访问关系梳理回答的是“这些网关与远程用户、运维终端、云平台之间形成了怎样的连接与授权关系”。两者合起来，才构成后续策略下发、审计和最小权限收敛的基础数据模型。
一、网关设备清单：先建立可追踪的资产台账
工业网关通常分布在厂区机房、配电室、现场控制柜甚至无人值守站点，型号杂、来源多、责任人不清是常态。资产台账不能只记“IP 和位置”，而要覆盖能支撑安全判断的关键字段。建议至少包含：资产唯一编号、设备名称、厂商与型号、序列号、部署位置（厂区/车间/机柜）、管理 IP 与业务 IP、固件版本、硬件版本、所属业务系统、责任人、上线时间、是否允许远程访问、最近一次固件核查时间。
其中“管理 IP 与业务 IP 分离”是工业网关常见的部署方式：管理口用于本地配置和远程运维，业务口承载 PLC、仪表等现场数据。台账中若把两者混为一谈，后续做访问控制时极易误封业务流量。示例参数（合理假设）：某厂 3 号能源站网关，管理 IP 为 10.20.30.11/24，业务 IP 为 192.168.50.1/24，固件版本 V2.4.1，硬件版本 HW-B，责任人张工，允许远程访问为“是（仅限运维 VPN 段）”。
二、固件版本：把“版本差异”变成风险差异
固件版本不是简单的版本号记录，而是漏洞暴露面和功能边界的直接映射。同一型号网关，V2.3.x 与 V2.4.x 可能在 Web 管理界面认证方式、SSH 是否默认开启、是否支持双因子登录上存在明显差异。梳理时应把“型号—固件版本—已知风险—是否可升级”关联起来，而不是孤立地记录版本号。
实际操作中，可先通过网关管理界面或命令行读取版本信息，再与厂商安全公告比对。例如通过 SSH 登录后执行：
show version
# 输出示例（合理假设）：
# Model: GW-300
# Firmware: V2.3.7
# Hardware: HW-B
# Build: 2023-08-14若厂商公告指出 V2.3.7 存在未授权访问风险、修复版本为 V2.4.1，则该资产应标记为“高风险待升级”。对于无法立即升级的网关，必须在访问关系模型中先收紧其远程访问路径，例如仅允许特定运维跳板机访问，禁止直接暴露管理端口。
三、开放端口：从“端口清单”到“服务暴露面”
开放端口本身不是问题，问题是“谁可以从哪里访问这些端口”。梳理时建议按“端口—协议—服务—监听地址—访问来源—是否必要”六列记录。工业网关常见端口包括：443（Web 管理）、22（SSH 运维）、502（Modbus TCP 业务）、102（S7 通信）、1883/8883（MQTT 上云）、161（SNMP 监控）等。
关键判断依据是监听地址：若管理端口监听在 0.0.0.0，意味着所有可达网络都能尝试连接；若仅监听内网管理地址，则暴露面显著缩小。示例（合理假设）：某网关开放 443、22、502，其中 443 与 22 监听 0.0.0.0，502 监听业务网段。此时应优先确认 443/22 是否真的需要对外，若远程运维统一走 VPN，则应在边界设备上限制来源，而不是依赖网关自身认证。
四、远程用户与权限关系建模
访问关系建模的核心，是把“用户—角色—权限—目标资产—访问路径—认证方式”串成一条可审计的链路。工业场景中常见角色包括：本地运维、远程运维、系统集成商、厂商支持、只读监控账号。不同角色的权限边界应明确到“能登录哪台网关、能操作哪些功能、是否可改配置、是否可下发固件”。
建模时建议采用“主体—客体—权限—条件”四元组表达。例如：主体“远程运维账号 ops_zhang”，客体“GW-300（3 号能源站）”，权限“SSH 登录 + 查看状态”，条件“仅通过运维 VPN 段 10.8.0.0/24，且需双因子认证”。这样一条关系，比单纯写“张工有权限”要可执行得多。
五、从清单到模型：一次可执行的梳理流程
把上述四类信息整合起来，可按以下顺序推进：第一步，通过扫描与人工核对形成网关设备清单，补齐型号、固件、IP、责任人；第二步，对每台网关执行端口与服务核查，记录监听地址和访问来源；第三步，导出或整理远程用户列表，明确每个账号的角色与权限；第四步，用“主体—客体—权限—条件”四元组把用户与网关关联起来；第五步，对照固件风险与端口暴露面，标记高风险关系并制定收敛动作。
判断梳理是否到位，可以看三个信号：能否在 5 分钟内回答“某台网关被哪些远程账号访问、走什么路径”；能否明确指出哪些端口不必要开放；能否对每个远程账号说清其权限边界和认证条件。若做不到，说明资产与访问关系模型还停留在“有记录”而非“可治理”的阶段。