一次燃气事故后的追问,往往是从查不到人开始的:那座门站最后是谁操作的、谁下的远程指令、当时谁在值班——翻系统,只有一堆共用账号;查记录,只有scada-admin;问值班室,谁也不承认。2021 年湖北十堰6·13燃气爆炸重大事故之后,城市燃气的安全与责任可追溯被提到前所未有的高度。而对燃气企业来说,工控安全防护里最便宜、却最容易被忽视的第一道墙,不是买防火墙,而是把人管清楚:《城镇燃气管理条例》(国务院令第 583 号公布、第 666 号修订)把运行、维护、抢修、更新改造的责任压给了燃气经营者,责任要落地到具体的人和操作,身份就得统一、操作就得可追溯;叠加等保 2.0 三级对登录用户两种或两种以上组合鉴别、且至少一种用密码技术的要求,和密评 GB/T 39786 对登录用户身份真实性的要求,身份管理从管理加分项变成了过不过得了关的硬条件。这不是一篇重复讲 UKEY 签名原理的文章(那部分我们在水务篇《水务SCADA密钥管理实战》里已把插 Key 登录的机制拆到芯片层)。这篇换一个坐标系,横向把燃气企业的身份管理看全:一个操作员身份,从建到销走一遍;一张燃气系统的地图,从 SCADA 到远程运维看一遍,落到怎么落地。01 | 先立框架:燃气企业身份为什么会失控燃气企业的作业半径,天然散:燃气企业经营/作业版图(身份视角) 城市燃气企业 ├─ 调度中心:SCADA 调度/监控值班员(白夜倒班,共用账号高发) ├─ 场站群:门站 / 调压站 / 储配站 / LNG·CNG 加气站 │ 每个场站:值班员、PLC 就地操作、站控上位机 ├─ 外勤:巡检、抢修、第三方运维(临时借号、随借随用) └─ 后台:营收客服系统、GIS、办公门户(与工控区还常是两套账号体系) 一个人,在 N 个系统里有 M 个账号,身份信息彼此不通失控有三个结构性原因,这不是管理态度问题:系统散:工控 SCADA 一套账号、办公/营收又一套,调度中心、各场站甚至各写各的值班台账,一个人几个身份没人对得上;人员杂:场站值守有轮班、有外包,抢修运维有临时进场人员。账号借来借去,出事时审计线上只有账号、没有人;责任重:城镇燃气条例对管道燃气经营者的供气设施运行维护、抢修责任是压到底的(管道燃气经营者对其供气范围内的燃气设施承担运行、维护、抢修和更新改造责任),责任链条的末端是谁干的——身份对不上,责任就断在最后一米。失控的代价,用一条典型的复盘链看最清楚(场景示意):某调压站值班员夜班误操作触发异常,调度中心翻 SCADA 日志只看到scada-admin,三个当班的人都说不是自己——没有身份统一,一次本可定位到人的事件,最后只能按管理问题通报,操作者本人反而隐身在共用账号后面。身份对到人,这条链的最后一环才接得上。**一个身份对应一个真实的人,是所有后续动作(双因子、授权、审计)的地基。**地基本来就歪,上层做得再花也没用。这就是为什么身份治理要放在认证前面讲。02 | 第一件事是盘底数:把共用/幽灵/无 Key翻出来身份统一管理的第一步不是买系统,是盘点。先看最常见的四类问题账号,它们几乎在每个燃气企业都能对上号:问题账号长什么样为什么危险共用账号三班倒的几个人共用一个 SCADA 管理员号出问题无法定位到具体某个人幽灵账号归属人已离职/外包已退场,账号却还能登前员工账号是绕开审计的暗门无 Key 账号工控/业务区账号没绑任何第二因子等保密码技术双因子无从谈起休眠账号90 天以上没登录、也没人记得被遗忘的入口,最适合被试探一段可复现的盘点脚本,把账算给你看(输入是身份源导出的账号-人-Key 清单):# -*- coding: utf-8 -*-# 燃气企业账号治理盘点:身份统一管理的第一步,先把底数盘清# 输入:身份源导出的账号-人-Key清单;输出:四类问题账号,逐项给整改依据ROWS[# 账号 归属人(状态) UKEY 最近登录(天){acct:scada-zhang,owners:[(张建国,在职)],ukey:K1001,last:0},{acct:scada-admin,owners:[(李强,在职),(王芳,在职),(赵磊,在职)],ukey:None,last:3},# 三班共用管理员号,且没绑 UKEY{acct:office-li,owners:[(李强,离职)],ukey:K1002,last:12},# 人走了账号没销{acct:scada-legacy,owners:[(系统残留,未知)],ukey:None,last:210},# 无主残留{acct:office-wang,owners:[(王芳,在职)],ukey:K1003,last:5},{acct:gate-zhao,owners:[(赵磊,在职)],ukey:K1004,last:1},# 门站值班专号]defis_all_left(acct):returnall(s离职for_,sinacct[owners])orall(s未知for_,sinacct[owners])shared[aforainROWSiflen(a[owners])1]# 共用:多人在一个号上ghost[aforainROWSifis_all_left(a)anda[last]isnotNone]# 幽灵:归属已走仍可登no2nd[aforainROWSifa[ukey]isNone]# 缺第二因子:没绑任何 Keydormant[aforainROWSifa[last]anda[last]90]# 休眠:90 天以上未用print([① 共用账号] SCADA 区多人共用一个登录号,出事查不到具体是谁)forainshared:print( ,a[acct],-,、.join(nforn,_ina[owners]))print([② 幽灵账号] 归属人已离职/无主,账号仍可登录)forainghost:print( ,a[acct],最后登录,a[last],天前)print([③ 缺第二因子] 燃气工控/业务区账号未绑定 UKEY(等保双因子无从谈起))forainno2nd:print( ,a[acct])print([④ 休眠账号] 90 天以上未登录,疑似被遗忘的入口)foraindormant:print( ,a[acct],最后登录,a[last],天前)print(*40)print(结论:共用,len(shared),个 | 幽灵,len(ghost),个 | 缺二因子,len(no2nd),个 | 休眠,len(dormant),个)print(整改方向:人-UKEY-账号一对一;SCADA 区消灭共用/幽灵号;全量补第二因子)存成d32_account_audit.py直接跑,输出稳定可复现:[① 共用账号] SCADA 区多人共用一个登录号,出事查不到具体是谁 scada-admin - 李强、王芳、赵磊 [② 幽灵账号] 归属人已离职/无主,账号仍可登录 office-li 最后登录 12 天前 scada-legacy 最后登录 210 天前 [③ 缺第二因子] 燃气工控/业务区账号未绑定 UKEY(等保双因子无从谈起) scada-admin scada-legacy [④ 休眠账号] 90 天以上未登录,疑似被遗忘的入口 scada-legacy 最后登录 210 天前 结论:共用 1 个 | 幽灵 2 个 | 缺二因子 2 个 | 休眠 1 个 整改方向:人-UKEY-账号一对一;SCADA 区消灭共用/幽灵号;全量补第二因子盘点数据从哪来,至少要拉五张表对账:①域/业务账号表(办公区) ②SCADA/HMI 用户表 ③VPN/堡垒机账号 ④UKEY 发领记录(谁领了几把 Key) ⑤外包/抢修工单人员名单。五张表各自都有人这个字段,但口径不一对不上——所以盘点不是拉一张表,而是拿人做键把五张表拼起来。这也是为什么单点做审计的系统填不了这个坑:人不在一个统一的身份视角里,账永远对不平。盘出来的问题按顺序处理:先禁幽灵号(风险最高,前员工账号),再拆共用号(一人一号),然后给关键业务账号补发 UKEY(先 SCADA 区),最后归档休眠号并建立周期复盘机制。不要想一次改完,身份治理是先止血、再清创、后重建的过程。验收:跑完能当场报出四类账号的名单和数量,就说明底数盘清了——盘不清,后面所有整改完成都是空话。这类盘点脚本对着一座真实燃气企业的账号导出跑一遍,通常能翻出比预期多得多的残留账号。03 | 立标准:一个人、一个身份、一把 Key底数盘清后立标准。燃气工控区登录的用户,按认证要素给身份定级:登录场景现状常见达标组合说明SCADA/HMI 操作员站口令(或共用账号)口令/账号 UKEY(PIN)你知道你持有,两种组合调度门户/Web 系统口令口令 UKEY/OTPWeb 侧可用第二因子,注意短信不算密码技术网络设备/堡垒机/VPN口令或固定密码账号 UKEY(经 RADIUS)远程运维入口,最该上双因子场站 PLC 就地操作现场口令/钥匙操作留痕 身份绑定就地操作也要到人,不靠脸熟两个口径先对齐,别在测评时才被纠正:等保 2.0 三级(GB/T 22239—2019,安全计算环境·身份鉴别):应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术,且其中一种至少应使用密码技术。UKEY 是含 SM2 密钥对/数字证书的智能密码钥匙,属密码技术这一类,是这条最稳妥的落地载体;密评(GB/T 39786—2021,应用和数据安全层):应采用密码技术对登录用户进行身份鉴别,保证用户身份真实性——实现方式明确包含基于公钥密码算法的数字签名机制。需要特别说破的坑:短信验证码不是密码技术,口令短信满足不了至少一种使用密码技术这条。燃气企业如果要远程运维接入,宁可给运维配 UKEY 也不要图省事用短信码充数。为什么燃气场景更推荐 UKEY 而不是纯 OTP 动态口令?两点务实差异:一是很多燃气场站对手机管控严格(作业区防爆要求、上岗纪律禁带个人手机),依赖手机的软件令牌既不方便也容易被忘在休息室架空;二是 UKEY 里的 SM2 密钥对和证书不只是登录因子——SCADA 上真正关键的操作(远程开阀、切工艺、停气),将来可以要求用同一把 Key 对指令签名,登录因子和指令签名同源,不必再为指令可信另建一套身份体系。立标准的验收:列一张场景 × 登录方式 × 是否满足双因子的对照表,每个登录入口都能勾上两种以上组合、至少一种密码技术,标准就算立住了。这张表本身也是后面测评的自证材料。**认证因子的账也要有人管。**UKEY 不是发下去就完事:每把 Key 的公钥谁签发证书、调岗要不要换 Key、证书到期或吊销怎么通知、离职那把 Key 怎么收回,都要有出处可查。这一层落在密钥管理上——UKEY 证书由密钥管理平台(KSP)的内置 CA 签发与吊销,根密钥存在 HSM 硬件加密机内、永不明文导出;操作员换 Key 即重新发证、旧证即刻作废。登录是认证的事,Key 的来龙去脉是密钥管理的事,两者分开想、但要放进同一张整改表里一起做,测评才交得出账。04 | 收口子:多个系统,一个入口标准立好,难在燃气企业的系统又多又老。操作员要进的系统至少四类:工控 SCADA(C/S 客户端)、调度/办公门户(Web)、VPN/堡垒机(网络设备,常走 RADIUS)、加臭/泄漏监测等专业系统。各自各的登录页,身份就散;散,就管不住。落地前先给每类接入对象选接法,别等实施时才发现某系统协议不对口:接入对象典型系统推荐接法说明Web 应用调度门户、报表、加臭 WebOIDC/OAuth 授权码标准协议,改造量小C/S 工控客户端SCADA/HMI 操作员站本地认证 SDK/中间件(UKEY 签名验签)登录留在本地,验签结果回传服务端网络设备/VPN/堡垒机防火墙、VPN、堡垒机RADIUS网络设备普遍认 RADIUS,统一平台出应答老 B/S 或改不动的系统早期监测平台免改造代理 / 表单代填用户只在统一入口认证一次,后端照样进审计移动/外勤作业抢修 App、移动作业同一身份库 动态口令(OTP)外勤在工控区外,OTP 属密码技术、合规可用;回作业区仍以 UKEY 为准一个容易绕远的误区:不要为了看起来统一强迫所有系统都改造成同一种协议——老系统硬改协议的成本,常常超过它带来的收益。能改造的走标准协议,改不动的用代理/代填兜住,把认证收口到一处就达到了目的。收口的思路是:**人只认一个统一认证入口,入口向后端系统证明这个人是谁,后端系统不必各自维护一套用户库。**三类接入、三种接法:燃气多系统统一认证收口(落地形态) 操作员 / 场站值守 / 外协运维 统一认证(ASP) ┌────────────┐ ┌──────────────────────────┐ │ 插 UKEY │ │ 统一身份库 MFA 会话 │ │ 输账号/PIN │── 认证请求 ───►│ SSO / OIDC · RADIUS · C/S │ └────────────┘ └────────────┬─────────────┘ │ 证明谁(会话/票据/认证应答) ┌───────────────┬───────────────────┼───────────────┬────────────┐ ▼ ▼ ▼ ▼ ▼ SCADA C/S 调度门户 Web VPN/堡垒机 加臭/泄漏 旧系统 (改造走本地 (OIDC 对接) (RADIUS 对接) (免改造代理/ (表单代填 认证 SDK) 代填) /API 改造) 信任底座:KSP 发 UKEY 证书 HSM 存根密钥 全程审计:谁、何时、进哪个系统能改造的系统走标准协议:Web 门户用 OIDC/OAuth 授权码对接,SCADA 这类 C/S 客户端走本地认证中间件(如 UKEY 的 2300 本地服务做签名验签);改不动的旧系统别硬拆:老系统不认 OIDC,就用免改造代理/表单代填/RADIUS 兜住——用户一样只在统一入口认证一次,后端老系统照样被纳入审计;网络设备/VPN 这种非应用入口走 RADIUS:堡垒机、VPN、网络设备认 RADIUS 协议,统一认证平台把账号UKEY 因子翻译成 RADIUS 应答,远程运维入口从此和 SCADA 同一套身份。这一层信任底座是统一的:操作员 UKEY 里的 SM2 证书由密钥管理平台(KSP)的内置 CA 签发、吊销统一在此,根密钥存在 HSM 硬件加密机内永不明文导出。也就是说,身份面(ASP)管认人,密钥面(KSP/HSM)管凭什么认,因子面(UKEY)管人在现场,三层各司其职,不再各系统自建。以一个中等城市燃气集团的整改(场景示意)看收口前后的差别:整改前,SCADA、调度门户、VPN、加臭平台各设各的密码,值班员上岗要先记四套口令,IT 要维护四份用户名单,巡检发现某系统多了个离职账号,还得跨部门确认。整改后,值班员只认一个统一认证入口:登录 SCADA 验 UKEY,切到调度门户自动单点,切 VPN 走同一身份——后端四套系统不再各自为政,IT 只维护一份身份库、一份授权、一份审计。收口的验收:操作员从登录 SCADA到进 VPN 远程处理场站故障,全程只用认一次证、同一个身份、同一把 Key;后端任何一次登录,审计都能对上同一真实的人。05 | 管起来:身份全生命周期,开通即最小、离职即失效收口之后,把身份当作会变的东西来管。燃气企业的人员变动非常频繁:场站值班轮换、抢修外包进场退场、调岗、离职——每个动作都必须在统一平台上有一个明确的状态切换。以最常见的外包抢修人员离场走一遍:开通:外包进场 → 平台建身份,绑定本次工单范围,只给需要的场站和系统最小权限 同时发 UKEY 并绑定,权限最小可用 使用:进场期间,每次登录都要 UKEY 认证,审计记到人 调整:换场站/加作业 → 平台改授权,不另开新账号 退场:工单结束 → 平台吊销 UKEY 证书、停用账号,当场失效,不等想起来再删四个动作四个原则:最小权限(给刚够用的)、一人一号(不借号)、状态联动(调岗/离职即时调整)、撤销即时生效(证书吊销走平台,不用跑每台服务端手删)。在燃气企业,有几个时点最容易漏管,建议做成固定动作:入职:建身份、发 UKEY、按岗位模板授权——给最小权限,不先给全量、以后再说;调岗:场站/系统范围变了,当天改授权,不另开新号;外包进场/退场:权限按工单生效与截止,退场即吊销证书;长期休假/借调:临时停用,人不在岗身份不动;离职:收回 UKEY、吊销证书、停用账号一次做完,系统里不留过渡期幽灵号。“即时失效要做到多快,要分两层看:平台侧的证书吊销/账号停用是即时的,下一次验签就会被拒;但已经登录、还挂在 SCADA 界面上的存量会话不会自己消失——如果平台不下发强制下线/会话失效,会留下人走了、界面还开着的窗口,短则几分钟、长到下次自然超时。整改时把吊销 强制下线一起做,并在制度里写明离职/退场当天的动作清单。这样测评问离职后还能不能登时,答的是吊销即拒、存量会话已断”,而不是应该不能。生命周期验收:随机抽一名近期离职/退场人员,查其账号与 UKEY 证书状态,应当已是停用/吊销;当场用其旧 Key 登录,应当被拒。这条过不了,前面立的标准就是建了没管。06 | 对得上:把审计做成到人的闭环身份统一管理最后一个价值点,是审计到人。燃气企业常见的审计断点是:SCADA 有自己的操作日志,办公系统有自己的登录日志,堡垒机又有自己的录像,出事时没人能拼出这个人今天做了什么。收口后的形态是三类日志汇到一处、能串成一条链:日志记什么回答的问题认证日志(统一平台)谁、何时、从哪、进了哪个系统、验签是否通过身份真实性接入/会话日志登录后操作了 SCADA 哪些画面/指令、堡垒机会话录像具体做了什么异常与撤销日志错 PIN、锁定、证书吊销、权限变更有没有异常与滞后三份日志对得上同一个人 会话,事故复盘就能从是谁登录的一路追到他在哪台操作员站发了哪条指令。这也正好承接城镇燃气条例给经营者压的运维抢修责任——责任链条只要落到人这一环,就是可交代的。让三份日志真正串得起来,有三个落地细节常被忽略:一是统一时间源,SCADA、认证平台、堡垒机先对 NTP,否则日志时间差几分钟就对不上号;二是打通会话 ID,认证平台签发的会话要能一路带到后端系统,后端记录里存同一个会话标识,而不是各记各的;三是人字段归一,所有日志最终都落到统一身份库里那一个 person ID,账号只是它的一个登录名。三个细节做好,追到人才是可操作的,而不是 PPT 上的话。审计验收:挑一次真实的登录,从认证日志、操作记录到会话录像,能用同一个身份 ID 串起来;SCADA 区再没有只认账号不认人的记录。07 | 合规对照与现场自查把整篇收敛成一张对照表,整改和测评都照这张表走:监管要求落到燃气侧的做法现场证据等保 2.0 三级:身份鉴别两种以上组合一种密码技术账号口令 UKEY(SM2),SCADA/门户/VPN 全覆盖场景×登录方式对照表、现场抽测GB/T 39786 密评:登录用户身份真实性(密码技术)UKEY 挑战-应答签名验签,UKEY 证书由平台 CA 签发验签日志、证书/吊销记录城镇燃气条例:运维抢修责任到人身份统一 操作审计到人,不依赖共用账号审计可串到具体人关键信息基础设施保护:运营者安全责任供气等关键业务区身份、密钥、审计集中管控身份/密钥平台与审计台账整改期间可以自测的小动作,三招就能暴露大部分问题:①随机抽 10 个账号,逐个核归属人在不在、有没有绑 Key,共用/幽灵号会立刻现形;②拿一个已离职同事的 UKEY 试登一次,系统若放行,撤销链路就是断的;③自查是否把短信码当成了第二因子——如果某入口只有口令短信,它过不了等保那条,趁早换掉。代码侧自查,一句话跑完上面的盘点脚本:# 四类问题账号全部盘出(命中即通过,输出结论:一行)python3 d32_account_audit.py|grep-E共用 1 个|幽灵 2 个|缺二因子 2 个|休眠 1 个命中即代表脚本逻辑正常;对真实企业,把ROWS换成身份源导出的真实清单,盘点结果就是整改的第一份清单。08 | 边界与后续:人管住了,还有设备和数据把人这一环管住之后,燃气工控安全还有两道延伸,本文先划清边界:设备身份:SCADA 之后还有大量非人的接入者——调压站 PLC、远传终端、智能燃气表。它们也要证明我是合法的表/合法的站,密钥怎么注入、怎么轮换、谁在管,是城市生命线密钥体系的另一章;数据与通道:操作员登录之后,SCADA 下发指令、营收数据落库,还有传输真实性、存储机密性要密码技术兜底。这两道边界,燃气侧最近的延续是《城市生命线密钥安全:智能燃气表密钥分发与关键基础设施密码防护》(D3-3),会同后续的水务密评三级与等保的区别(D4-1)、“智能水表密钥注入”(D4-2)在公共事业线逐篇展开。若要把人-机-账一体的身份与密钥底座往更底层看,可回看同线前篇《水务SCADA密钥管理实战》(D3-1)里拆过的同一套信任源逻辑——身份面收口、密钥面统一,底层是同一套。本文要强调的是:燃气工控安全防护,从先把人管清楚开始——人是一切的起点,也是事故之后唯一能交出答案的那一环。文章作者:安当加密-焱垚