企业官网建设流程全解析

一次燃气事故后的追问,往往是从"查不到人"开始的:那座门站最后是谁操作的、谁下的远程指令、当时谁在值班——翻系统,只有一堆共用账号;查记录,只有"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"翻出来

身份统一管理的第一步不是买系统,是盘点。先看最常见的四类问题账号,它们几乎在每个燃气企业都能对上号:

一段可复现的盘点脚本,把"账"算给你看(输入是身份源导出的账号-人-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

底数盘清后立标准。燃气工控区登录的用户,按"认证要素"给身份定级:

两个口径先对齐,别在测评时才被纠正:

• 等保 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)、加臭/泄漏监测等专业系统。各自各的登录页,身份就散;散,就管不住。

落地前先给每类接入对象选接法,别等实施时才发现某系统协议不对口:

一个容易绕远的误区:不要为了"看起来统一"强迫所有系统都改造成同一种协议——老系统硬改协议的成本,常常超过它带来的收益。能改造的走标准协议,改不动的用代理/代填兜住,把"认证"收口到一处就达到了目的。

收口的思路是:**人只认一个统一认证入口,入口向后端系统证明"这个人是谁",后端系统不必各自维护一套用户库。**三类接入、三种接法:

燃气多系统统一认证收口(落地形态) 操作员 / 场站值守 / 外协运维 统一认证(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、认证平台、堡垒机先对 NTP,否则日志时间差几分钟就对不上号;二是打通会话 ID,认证平台签发的会话要能一路带到后端系统,后端记录里存同一个会话标识,而不是各记各的;三是人字段归一,所有日志最终都落到统一身份库里那一个 person ID,账号只是它的一个登录名。三个细节做好,"追到人"才是可操作的,而不是 PPT 上的话。

审计验收:挑一次真实的登录,从认证日志、操作记录到会话录像,能用同一个身份 ID 串起来;SCADA 区再没有只认账号不认人的记录。

07 | 合规对照与现场自查

把整篇收敛成一张对照表,整改和测评都照这张表走:

整改期间可以自测的小动作,三招就能暴露大部分问题:①随机抽 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)里拆过的同一套信任源逻辑——身份面收口、密钥面统一,底层是同一套。本文要强调的是:燃气工控安全防护,从"先把人管清楚"开始——人是一切的起点,也是事故之后唯一能交出答案的那一环。

文章作者:安当加密-焱垚