水务系统的网络攻击不一定会立刻让水泵停转，但这并不意味着风险可以被低估。互联网暴露的 PLC、远程维护通道、老旧工作站和第三方系统集成商，可能共同构成一条通往物理流程的攻击路径。进入 AI 时代后，攻击者获得了更强的自动化能力，水务运营方也需要用更系统的方式建立防守优势。
这类防护不应从“购买一个 AI 安全产品”开始，而应从资产清单、访问控制、网络分段、备份和应急响应等基础工作开始。AI 的价值在于放大有限安全团队的能力，同时把最终决策和安全责任留在人手中。
水务 OT 的真正暴露面
水务组织通常同时运行 IT 和 OT 环境。IT 环境包括办公终端、服务器、身份系统和云服务；OT 环境则包含 PLC、HMI、工程师站、泵站控制设备和工业网络。两者之间并不是完全隔离的，远程运维、供应商接入、历史数据采集和管理系统都会形成连接点。
实践中，深入影响 OT 的入侵，往往会在接触 Purdue 模型 Level 0-1 的物理设备之前，长期停留在普通工作站和服务器上。可以把这一规律概括为“99% 防守面”：大量受感染系统、恶意软件活动、取证线索和检测机会，都出现在商用现成设备上。
这带来一个重要判断：OT 安全并不只是 PLC 安全。保护办公终端、跳板机、身份系统、远程访问平台和日志基础设施，往往能够在攻击接近物理流程前争取到更多检测和阻断机会。
资源有限时，先把基础动作做扎实
水务机构不必一开始就建设复杂的安全运营体系。下面这些动作通常具有较高的投入产出比：
- 盘点资产并评估暴露面：确认哪些 PLC、HMI、工程师站、VPN、远程桌面和管理接口可以从互联网访问。对生产系统进行验证前，应先获得授权，并优先使用配置审查、被动流量分析和供应商文档。
- 清理默认配置：替换默认用户名和密码，关闭不必要的服务，限制防火墙入口，并为暴露的管理面设置明确的来源地址和访问时段。
- 做好备份和备件准备：关键配置、逻辑程序、工程文件和运行数据应遵循 3-2-1 规则，即保留三份副本、使用两种存储介质、至少一份放在异地。备份之外，还要准备关键控制设备的替换件。
- 实施网络分段和强认证：将办公网、OT 管理区、控制区和供应商远程访问区分开。远程访问启用 MFA，能使用只读权限时不要授予完整控制权限。
- 把网络事件纳入现有应急体系：网络攻击应与管道破裂、自然灾害和饮用水安全事件一样，纳入统一的事件指挥和演练流程。
- 审计第三方访问：记录系统集成商和维护承包商的账号、连接入口、授权范围、使用时间和操作日志，并定期回收不再需要的权限。
一个可改造的暴露面盘点示例
下面的 Bash 示例适合在已获授权的管理主机上执行。它不会主动扫描网络，只读取本机已知的资产清单，并标记缺少基本信息的条目。将 assets.csv 替换为组织自己的导出文件后即可改造为定期检查任务。
#!/usr/bin/env bash
set -euo pipefail
input="${1:-assets.csv}"
if [[ ! -f "$input" ]]; then
printf 'asset file not found: %s\n' "$input" >&2
exit 1
fi
printf 'asset_type,asset_name,address,status\n'
while IFS=, read -r asset_type asset_name address owner; do
[[ "$asset_type" == "asset_type" ]] && continue
status="ok"
[[ -z "$asset_name" || -z "$address" ]] && status="missing_name_or_address"
[[ -z "$owner" ]] && status="missing_owner"
printf '%s,%s,%s,%s\n' \
"$asset_type" "$asset_name" "$address" "$status"
done < "$input"
这只是资产治理的起点。生产环境中还应补充“是否互联网暴露”“所属网络区”“远程访问方式”“固件版本”“最后一次备份验证时间”和“业务负责人”等字段。未经授权，不要直接对 PLC 或控制网络进行主动探测；错误的扫描参数可能影响脆弱设备。
用统一治理连接 IT 与 OT
IT 和 OT 团队需要共同维护一套治理框架，而不是各自维护互不相通的安全清单。治理内容至少应覆盖：
- 资产和数据的负责人；
- 远程访问的审批、时限和撤销流程；
- PLC 逻辑、工程文件和配置变更的版本记录；
- 日志留存、告警升级和取证权限；
- 备份恢复、手动接管和安全停机的演练记录；
- 供应商的安全要求、MFA 标准和审计责任。
PLC 通常不在标准软件开发流程中，但围绕 PLC 使用的软件、工程站、脚本、依赖包和配置工具，仍然可以采用安全软件开发的思路。例如，对变更进行评审和签名，限制构建环境权限，保存版本和来源信息，并在投产前验证恢复路径。
合规清单可以帮助组织发现缺口，但不应成为终点。更有价值的指标是领先指标，例如：互联网暴露资产数量、启用 MFA 的远程连接比例、关键备份最近一次恢复验证时间、未关闭高风险供应商账号数量，以及 OT 事件演练后的改进项关闭率。
AI 应该放在哪里
AI 可以成为精简安全团队的力量放大器，适合用于聚合告警、分析身份和网络行为、生成初步调查摘要、识别资产关系，以及帮助运营人员优先处理最可能被利用的暴露面。
但 AI 进入 OT 环境前，需要明确边界。AI 生成的建议不能直接改变 PLC 逻辑、泵站设定值或安全联锁；高影响操作应经过人工确认、双人复核和可回滚的变更流程。任何自动化系统都要持续测试，并记录输入、输出、决策依据和实际执行结果。
可以采用下面这种最小化的人工审批流程：
ai_ot_action:
purpose: "Prioritize suspicious remote-access events"
allowed_actions:
- "correlate_identity_and_network_logs"
- "create_incident_draft"
- "recommend_account_disablement"
prohibited_actions:
- "write_plc_logic"
- "change_pump_setpoint"
- "bypass_safety_interlock"
approval:
required: true
roles:
- "security_operator"
- "ot_process_owner"
audit:
record_prompt: true
record_output: true
record_human_decision: true
retention_days: 365
这份配置是假设性的治理模板，字段需要按实际 AI 平台和事件流程改造。核心原则是把 AI 限制在分析、排序和辅助决策范围内，同时把安全实践嵌入事件响应计划。
一份可执行的落地清单
水务组织可以按以下顺序推进：
- 导出并核对所有 IT、OT 和第三方远程访问资产。
- 优先关闭未经业务证明必要的互联网暴露入口。
- 替换默认凭据，为远程访问启用 MFA，并收紧权限。
- 将办公网络、OT 管理区和控制区分段，建立明确的允许通信关系。
- 备份 PLC 逻辑、配置和工程文件，并完成一次离线恢复验证。
- 将网络攻击场景加入现有事件指挥和工业控制系统演练。
- 用 AI 辅助检测和调查，但禁止未经人工审批的物理流程变更。
- 每月复盘暴露资产、供应商账号、备份恢复和演练改进项。
手动接管和水质检查是重要的安全缓冲，但不能替代数字安全基础。更稳妥的路径，是先压缩攻击者进入 OT 的机会，再用 AI 提升检测和响应速度，并始终让熟悉工艺的人参与关键决策。