工业互联网等保合规指南：工信部分类分级+等保2.0三级落地
工业互联网等保合规这件事，被很多制造企业当成"买几台安全设备、填几张测评表"就能过关。真实情况相反：等保测评追的是一条证据链，从设备怎么证明自己是谁，到数据怎么加密落库，再到日志能不能证明没被改过，任何一环拿不出可核查的材料，测评就卡在那里。某汽车零部件工厂在分级评估后，整改了四个月才把三级的测评项补齐。
坐标先立：工业互联网的合规可以按"安全计算环境、安全区域边界、安全通信网络、安全管理中心"四块来拆，这是国内网络安全等级保护相关标准的通用框架。工控场景的特殊性在于，它的"计算环境"里大量是 PLC、SCADA、边缘网关这类工业设备，不是普通服务器；它的"边界"是 IT 与 OT 交汇的地方。本文切入的是最容易被做浅的一块：制造企业怎么把工业互联网等保合规从纸面要求，落到可提交、可复现、可追溯的密码与身份证据上。
01 | 工业互联网等保合规的这件事，难在哪儿
工业互联网等保合规的复杂度，不在算法，而在"设备杂、协议旧、边界糊、证据散"。具体难在下面五处。
首要难点在设备身份没有统一锚点。 一条产线上的 PLC、工业机器人、边缘网关、SCADA 服务器，往往来自不同厂商、不同年代，有的根本不支持现代身份协议。等保测评要求"身份鉴别"，但很多设备的"身份"只是一个写死在配置文件里的 IP 或用户名，谁拿着这个配置都能接入。要补齐这一项，就得给每台设备签发可验证的凭据，而不是继续依赖共享口令。
其次，数据保密的要求落不到 OT 侧。 工艺参数、配方、设备状态这些高敏感数据，大多直接在 PLC 与 SCADA 之间明文流转，落库时也是明文。等保测评会追到"数据保密性"这一项，要求对重要数据做加密保护。但 OT 侧的设备很多不能承受重改造，这就卡住了：要么改不动，要么改完影响生产节拍。
再有一处难点在完整性无人兜底。 下发给设备的控制指令、设备的配置变更、运维的审计日志，这三样如果只靠明文传输和本地文件保存，一旦被篡改根本发现不了。测评里的"数据完整性"和"审计完整性"两项，要的是"能证明没被改过"，而不是"我们相信没被改过"。
还有一处难点在密钥管理散落各处。 设备有设备密钥，应用有应用密钥，数据库有数据库密钥，很多制造企业这三套密钥各管各的，没有统一的派生与轮换规则。等保和密码应用测评会一起追问：根密钥在哪里生成、怎么存储、多久轮换一次、历史数据怎么解密。散落的密钥体系，回答不了这些问题。
最后一处难点在证据无法串联。 身份做了、加密做了、签名做了，但三件事用的是三套系统、三份台账，测评时只能分别交材料，拼不出一条完整的证据链。测评人员要的是"这台设备用这张凭据接入、这条数据用这把密钥加密、这条日志用这个签名防篡改"能串起来，而不是三个孤立的事实。
把这五处难点串起来看，这套合规的核心矛盾是：测评看的是证据链，而企业交付的是孤岛式的安全动作。
02 | 机制拆解：工业互联网等保合规的三道关
先把三道关各自的职责划清楚，再看它们怎么拼成证据链。
| 关 | 对应测评维度 | 要解决的事 | 典型手段 | 缺了会怎样 |
|---|---|---|---|---|
| 身份鉴别关 | 安全计算环境·身份鉴别 | 设备与操作员怎么证明自己是谁 | 设备凭据 + 签名验签 + 多因素 | 任何人拿配置就能接入 |
| 数据保密关 | 安全计算环境·数据保密性 | 重要数据怎么加密保护 | 透明加密 + 分域密钥 + HSM 根密钥 | 配方与参数明文泄露 |
| 完整性关 | 安全计算环境·数据完整性 | 指令与日志被篡改能否发现 | 指令签名 + 日志签名 + 审计 | 篡改指令、造假日志无感知 |
这三道关的边界要讲清楚：身份鉴别关只解决"这台设备是不是它说的那台"，不解决"它的数据是否加密"；数据保密关只解决"数据落盘是不是密文"，它依赖身份鉴别关给出的可信身份；完整性关不直接参与接入，但它决定前两关产生的凭据、密钥、日志是否以可验证形态留存。很多工厂把这三件事分别交给三家厂商、三个立项，最后三份材料拼不出一条证据链。
工业互联网等保合规里的身份鉴别关
身份鉴别关的落点是"每台设备一把可验证的凭据"。设备用私钥对接入请求签名，平台只认公钥验签；操作员登录设备维护终端时叠加多因素。凭据的私钥必须留在设备侧的安全载体里，不能落配置文件。这样测评时交付的是"设备身份由签名验签保证、私钥不出设备"的闭环，而不是"我们设了强口令"的口头说明。
工业互联网等保合规里的数据保密关
数据保密关的落点是"重要数据按域加密、密钥分域派生"。工艺参数、配方这类高敏感字段，写入时自动加密、读取时自动解密，业务不需要改代码；加密所用的会话密钥，由主密钥按"产线 + 设备"这类因子派生，每台设备各不相同。这样即使某一个应用的数据密钥泄露，也不会连带影响其他设备或产线。
工业互联网等保合规里的完整性关
完整性关的落点是"指令和日志都要带签名"。下发给设备的控制指令，由授权方签名，设备侧验签通过才执行，被篡改的指令直接拒绝；设备的审计日志条目也逐条签名，事后任何改动都能被验签发现。这一关让"数据完整性"和"审计完整性"两项从承诺变成可核查的事实。
下面这张图说明三道关在一次设备接入与运维里的位置关系：
text
[边缘网关] --签名接入请求--> [工业身份平台] --验签--> 放行/拒绝
| |
| 身份锚点: 设备SM2凭据 | 根密钥: 硬件密码机(HSM), 永不明文导出
v v
[PLC/SCADA] --指令签名--> [执行侧验签] --篡改指令拒绝--> 执行
|
| 数据落库: 透明加密 + 会话密钥(按产线+设备派生)
v
[审计日志] --逐条签名--> [审计系统] --篡改日志发现--> 告警03 | 先跑通：工业互联网等保合规的四个环节
下面这段演示把三道关跑成一条完整链路：先由设备用私钥对接入请求签名，平台侧演示验签通过、篡改被拒、冒名被拒；再演示生产线密钥按"产线 + 设备"派生、不同设备彼此不同、主密钥轮换后派生值变化；接着演示工艺参数用派生密钥做 SM4 加密落库并可还原；最后演示下发指令与审计日志的签名验签，被篡改的指令和日志都被拒绝。
python
# -*- coding: utf-8 -*-
"""
账号3 Day3 #1 演示：工业互联网等保合规（工控设备身份鉴别 + 生产线密钥注入 + 数据加密 + 指令/日志完整性）
覆盖五件事：
1) 设备身份鉴别 ------ 设备用 SM2 私钥对接入请求签名，平台验签通过；篡改/冒名被拒
2) 生产线密钥注入烧录 ------ 主密钥按「产线 + 设备」派生会话密钥，每台设备各不相同
3) 产线数据加密落库 ------ SM4-CBC 加密工艺参数，可解密还原
4) 下发指令完整性 ------ 控制指令签名验签，被篡改的指令被拒
5) 审计日志防篡改 ------ 日志条目签名，篡改后验签失败
演示用固定私钥，且固定 K（同一私钥+同一K会泄露私钥，仅演示用）。
断言统一 print(f"[{t}] = {'True' if ok else 'False'}")，全部为 True。
"""
from gmssl import sm2, sm4, sm3, func
# ---- 固定私钥（已过 xxcsdn_keycheck.py 三关预检） ----
DEV_PRIV = "6a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c46a3a91c4" # 产线设备
FAKE_PRIV = "5b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d0" # 冒名设备
FIXED_K = "0101010101010101010101010101010101010101010101010101010101010101"
def pub_of(priv: str) -> str:
"""P = d * G；gmssl 不会从私钥派生公钥，必须显式算出再传入"""
return sm2.CryptSM2(private_key=priv, public_key="")._kg(
int(priv, 16), sm2.default_ecc_table["g"])
DEV_PUB = pub_of(DEV_PRIV)
FAKE_PUB = pub_of(FAKE_PRIV)
def sm3_hex(data: bytes) -> str:
return sm3.sm3_hash(func.bytes_to_list(data))
# ---- 手写 SM4-CBC：gmssl 的 crypt_cbc 有缺陷，one_round 是 16 进 16 出的单块运算 ----
def sm4_cbc(key: bytes, iv: bytes, data: bytes, enc: bool) -> bytes:
assert len(key) == 16 and len(iv) == 16, "SM4 KEY / IV 必须 16 字节"
c = sm4.CryptSM4()
c.set_key(key, sm4.SM4_ENCRYPT if enc else sm4.SM4_DECRYPT)
out, prev = b"", iv
for i in range(0, len(data), 16):
blk = data[i:i + 16]
if enc:
x = bytes(a ^ b for a, b in zip(blk, prev))
e = bytes(c.one_round(c.sk, list(x)))
out += e
prev = e
else:
d = bytes(c.one_round(c.sk, list(blk)))
out += bytes(a ^ b for a, b in zip(d, prev))
prev = blk
return out
def pkcs7_pad(data: bytes, block: int = 16) -> bytes:
pad = block - (len(data) % block)
return data + bytes([pad]) * pad
def pkcs7_unpad(data: bytes) -> bytes:
pad = data[-1]
if not (1 <= pad <= 16):
return data
return data[:-pad]
def decrypt_or_none(key: bytes, iv: bytes, ct: bytes):
try:
return pkcs7_unpad(sm4_cbc(key, iv, ct, False))
except Exception: # noqa: BLE001
return None
# ===== 1) 设备身份鉴别：接入请求签名验签 =====
def auth_request(priv, dev_id, nonce):
payload = f"{dev_id}|{nonce}"
h = sm3_hex(payload.encode("utf-8"))
signer = sm2.CryptSM2(public_key=pub_of(priv), private_key=priv)
return payload, signer.sign(h.encode("utf-8"), FIXED_K)
def verify_request(payload, sig, expect_dev, nonce_expect):
dev_id, nonce = payload.split("|")
h = sm3_hex(payload.encode("utf-8"))
verifier = sm2.CryptSM2(public_key=DEV_PUB, private_key=DEV_PRIV)
return (verifier.verify(sig, h.encode("utf-8"))
and dev_id == expect_dev
and nonce == nonce_expect)
NONCE = "n-20260928-1031"
req, sig = auth_request(DEV_PRIV, "PLC-LINE3-DEV07", NONCE)
ok_dev_auth = verify_request(req, sig, "PLC-LINE3-DEV07", NONCE)
# 篡改请求（把设备号换成另一台）
req_tam = req.replace("PLC-LINE3-DEV07", "PLC-LINE3-DEV99")
ok_tamper = not verify_request(req_tam, sig, "PLC-LINE3-DEV07", NONCE)
# 冒名设备用自己的私钥签
req_fake, sig_fake = auth_request(FAKE_PRIV, "PLC-LINE3-DEV07", NONCE)
ok_imposter = not verify_request(req_fake, sig_fake, "PLC-LINE3-DEV07", NONCE)
# ===== 2) 生产线密钥注入烧录：主密钥按「产线 + 设备」派生 =====
MASTER = b"PLANT-KEY-MANAGER-MASTER-2609"
k_dev07 = sm3_hex(MASTER + b"|line=LINE3|dev=DEV07")
k_dev08 = sm3_hex(MASTER + b"|line=LINE3|dev=DEV08")
ok_k_len = len(k_dev07) == 64
ok_k_diff = k_dev07 != k_dev08
ok_k_det = k_dev07 == sm3_hex(MASTER + b"|line=LINE3|dev=DEV07")
ok_k_rotate = k_dev07 != sm3_hex(b"PLANT-KEY-MANAGER-MASTER-2610" + b"|line=LINE3|dev=DEV07")
# ===== 3) 产线数据加密落库（工艺参数） =====
DATA_KEY = bytes.fromhex(k_dev07[:32])
IV = b"SM4IVPLANTLINE03"
param = ("工艺参数:temp=218.4C|press=6.12MPa|batch=B26092807").encode("utf-8")
ct_param = sm4_cbc(DATA_KEY, IV, pkcs7_pad(param), True)
ok_data_enc = decrypt_or_none(DATA_KEY, IV, ct_param) == param
ok_data_ct_diff = ct_param != param
# ===== 4) 下发指令完整性：控制指令签名验签 =====
cmd = "SET|LINE3|DEV07|SPEED=1200"
h_cmd = sm3_hex(cmd.encode("utf-8"))
cmd_signer = sm2.CryptSM2(public_key=DEV_PUB, private_key=DEV_PRIV)
cmd_sig = cmd_signer.sign(h_cmd.encode("utf-8"), FIXED_K)
ok_cmd_sign = cmd_signer.verify(cmd_sig, h_cmd.encode("utf-8"))
ok_cmd_tamper = not cmd_signer.verify(
cmd_sig, sm3_hex((cmd + "|SPEED=9999").encode("utf-8")).encode("utf-8"))
# ===== 5) 审计日志防篡改 =====
log = "LOG|DEV07|2026-09-28T10:31:05|auth_ok"
h_log = sm3_hex(log.encode("utf-8"))
log_signer = sm2.CryptSM2(public_key=DEV_PUB, private_key=DEV_PRIV)
log_sig = log_signer.sign(h_log.encode("utf-8"), FIXED_K)
ok_log_sign = log_signer.verify(log_sig, h_log.encode("utf-8"))
ok_log_tamper = not log_signer.verify(
log_sig, sm3_hex((log + "|auth_fail").encode("utf-8")).encode("utf-8"))
asserts = [
("设备身份鉴别验签通过", ok_dev_auth),
("篡改设备请求被拒绝", ok_tamper),
("冒名设备签名被拒绝", ok_imposter),
("设备派生会话密钥64位", ok_k_len),
("不同设备派生密钥不同", ok_k_diff),
("同一因子派生可复现", ok_k_det),
("主密钥轮换后派生值变化", ok_k_rotate),
("产线数据加密可还原", ok_data_enc),
("密文与明文不同", ok_data_ct_diff),
("下发指令签名验签通过", ok_cmd_sign),
("被篡改指令验签被拒", ok_cmd_tamper),
("审计日志签名验签通过", ok_log_sign),
("被篡改日志验签被拒", ok_log_tamper),
]
print("=" * 60)
for t, ok in asserts:
print(f"[{t}] = {'True' if ok else 'False'}")
text
============================================================
[设备身份鉴别验签通过] = True
[篡改设备请求被拒绝] = True
[冒名设备签名被拒绝] = True
[设备派生会话密钥64位] = True
[不同设备派生密钥不同] = True
[同一因子派生可复现] = True
[主密钥轮换后派生值变化] = True
[产线数据加密可还原] = True
[密文与明文不同] = True
[下发指令签名验签通过] = True
[被篡改指令验签被拒] = True
[审计日志签名验签通过] = True
[被篡改日志验签被拒] = True跑通之后，这四个环节要逐个对上：
环节一：设备接入必须是"验签通过才算数"。 演示里平台侧只持有设备公钥，私钥始终留在设备侧的安全载体里。任何接入请求都带设备签名，平台验签不过就拒绝。篡改设备号、换一台冒名设备签名，验签都会失败。这一条直接对应身份鉴别关，也是测评时最容易卡的一类------很多工厂的"身份"只是配置文件里的共享口令，谁拿到都能接入。
环节二：密钥要按"产线 + 设备"分域派生。 演示里同一把主密钥按不同设备因子派生出两把不同的会话密钥，主密钥轮换时各设备的派生值同步变化。这样即使某一台设备的数据密钥泄露，也解不开其他设备的数据；而运维轮换主密钥时，不需要逐台设备去改配置。这一条是数据保密关落地、也是密码应用测评追问"密钥怎么管"时的标准答案。
环节三：重要数据落库就是密文。 演示里工艺参数用派生密钥做 SM4 加密后落库，读取时再还原成明文，业务侧不需要改代码。透明加密的好处是不打断生产节拍，坏处是要保证密钥管理与根密钥保护到位------根密钥必须在硬件密码机里，永不明文导出。这一条对应数据保密性测评项。
环节四：指令和日志都要带签名。 演示里下发指令和审计日志都做了 SM2 签名，被篡改的内容验签直接失败。这一条让"数据完整性"和"审计完整性"从承诺变成可核查的事实：运维事后调日志，任何改动都骗不过验签。
这四个环节里，最容易被低估的是环节一和环节四------它们都属于"平时看不出问题、出事时才发现没做"的类型。
04 | 落地动作：工业互联网等保合规分线怎么做
要落到可执行，建议按四条线推进，每条线都有明确的交付物。
线一：设备身份治理。 给每条产线的 PLC、网关、SCADA 服务器签发可验证的设备凭据，凭据私钥驻留设备侧安全载体，配置文件里不再出现共享口令；梳理设备资产台账，做到"一台设备一把凭据、一个标识"。这条线的交付物是设备身份台账与凭据签发记录。
线二：操作员接入改造。 凡是登录设备维护终端、远程运维的操作，全部改为签名验签或多因素认证，淘汰共享账号；第三方远程运维接入要单独鉴权、单独审计。这条线的交付物是操作员认证规范与远程运维审计记录。
线三：数据分域加密。 工艺参数、配方、设备状态这类高敏感字段做透明加密落库，密钥按"产线 + 设备"或"应用 + 日期"派生，根密钥托管在硬件密码机。这条线要特别注意：设备侧密钥、应用侧密钥、数据库侧密钥应当共用同一套主密钥与派生规则，否则密钥数量随设备数量线性膨胀，轮换时必然漏换。交付物是密钥分域清单与字段加密清单。
线四：完整性闭环。 下发给设备的控制指令做签名下发与验签执行，设备的审计日志逐条签名入库。这条线把身份、密钥、日志三件事串成一条证据链：哪台设备、用哪个凭据、在哪段时间、做了什么、日志是否被改过，都能逐条还原。交付物是签名验签规范与日志完整性校验记录。
四条线推进有先后：线一是线二的前提，没有设备凭据就无法对接入做签名验签；线三依赖线一给出的可信身份和线二给出的访问控制；线四是把前面三线的产物串联成证据链，应当在前三线基本成型后再收口。
一个可参照的整改样本
背景：某制造企业已完成工业互联网平台搭建，但设备以共享口令接入、工艺参数明文落库、运维日志本地保存无签名。分级评估后定为三级，初次自评时身份鉴别、数据保密性、数据完整性三项均不达标。
动作：先给三条产线的关键设备签发设备凭据，私钥驻留安全载体，接入请求改为签名验签；把工艺参数与配方字段改为透明加密落库，密钥由主密钥按"产线 + 设备"派生，根密钥放入硬件密码机；下发指令改为签名下发、设备侧验签执行，审计日志逐条签名入库并集中校验。
结果：整改后的一次模拟演练中，用冒名配置接入被直接拒绝，篡改一条下发指令被设备侧验签拦截，改动一条历史日志被审计系统发现。三项原本不达标的测评项在复查时全部补齐，证据链从"我们分别做了"变成"我们能逐条还原"。
05 | 避坑清单：8 条最容易踩的坑
| # | 坑 | 后果 | 怎么验证避开了 |
|---|---|---|---|
| 1 | 设备用共享口令接入 | 谁拿配置都能接入，身份鉴别形同虚设 | 抽查设备配置，确认无共享口令、接入带签名验签 |
| 2 | 设备凭据私钥落配置文件 | 私钥泄露即全线失守 | 检查私钥是否驻留安全载体、配置文件无明文密钥 |
| 3 | 工艺参数明文落库 | 配方与参数随备份泄露 | 抽查数据库记录与备份文件是否为密文 |
| 4 | 一台设备一把密钥用到老 | 单点泄露连带全部设备 | 检查密钥派生因子是否含设备标识 |
| 5 | 下发指令不签名 | 篡改指令被执行，产线失控 | 用篡改指令访问设备，看是否被验签拒绝 |
| 6 | 审计日志无签名 | 日志可篡改，事后无法追溯 | 改一条历史日志，看是否通过完整性校验 |
| 7 | 密钥三套体系各管各的 | 轮换必漏、测评拼不出证据链 | 检查设备/应用/数据库密钥是否共用派生规则 |
| 8 | 根密钥明文导出 | 根一失，全部派生值失效 | 确认根密钥仅存于硬件密码机，无明文副本 |
挑第 5 条展开说。下发指令不签名这件事，在很多工控场景里被视为"内部网络可信、不需要签名"。问题在于工业互联网的边界早已不是物理隔离的------远程运维、云边协同、第三方接入都让"内部"不再可信。一条被篡改的转速或温度指令，落到执行侧如果不验签，设备照单全收，轻则废品，重则安全事故。给指令加签名、在设备侧验签，成本只是每次下发多一次签名运算，收益是把"指令完整性"这一测评项从承诺变成可核查的事实。
06 | 合规视角：工业互联网等保合规要对上哪些要求
制造企业的工业互联网系统在国内落地，通常同时面对几条线的要求，而这些要求的最终落点都在可提交的证据上。
等级保护相关要求。 关注身份鉴别、访问控制、数据保密性、数据完整性、安全审计。PLC、SCADA 这类承载工艺与控制的系统，一旦定为三级，测评项会逐条追到设备身份是否可验证、重要数据是否加密、指令与日志是否防篡改。前面三道关，正是对着这些测评项来的。
工信部工控安全防护指南合规要求。 工业领域对分类分级、安全防护有相应的指南与指引，强调按重要程度分级保护、关键系统重点加固。工业互联网等保合规不能只盯着一份测评表，还要把分类分级的口径落到资产台账里：哪些设备属于关键系统、哪些数据属于重要数据，分清楚了才能把保护资源投到对的地方。
工控安全相关国际标准，如 IEC 62443工控安全合规体系。 不少制造企业有出口业务或被外资供应链审核，对方会看 IEC 62443 这类工控安全体系的落地情况。它与国内等保在"区域隔离、访问控制、身份管理"上高度相通，工信部工控安全防护指南合规与 IEC 62443工控安全合规在"区域隔离、访问控制、身份管理"上高度相通，落地时可以把两套要求并到同一份证据链上，一次建设、两边受益。
密码应用基本要求。 关注身份鉴别、访问控制、数据完整性、数据保密性四个层面的密码技术应用。前面三道关，落到密码上就是设备凭据签名、数据加密、指令与日志签名。测评追问的是用什么算法、密钥在哪里生成与存放、多久轮换一次------生产线密钥注入烧录这类动作，必须写进密码应用方案，作为证据链的一环。
这里的实用建议是：不要把这些要求当成几份独立清单分别应对，而是建一张映射表，把每条要求映射到"设备凭据、密钥派生、数据加密、指令签名、日志签名"这五个动作上。一次建设，几份清单同时受益。
07 | 落地答案：工业互联网等保合规怎么承接
工业互联网等保合规落到产品能力上，通常这样组合三道关与证据链。
身份鉴别关这一段，需要的能力是"设备凭据签发 + 接入验签 + 操作员多因素"。统一身份认证平台承担设备与操作员的身份锚点，设备凭据的私钥驻留安全载体，接入请求由平台验签；对远程运维、维护登录这类敏感动作叠加额外的独立因素。签名动作由密码模块完成，私钥不出模块边界。
数据保密关这一段，需要的能力是"透明加密 + 分域密钥 + 硬件密码机根密钥"。数据库透明加密解决工艺参数与配方落盘这一层：敏感字段写入时自动加密、读取时自动解密，业务不需要改代码，对生产节拍无感。密钥管理平台承担主密钥保护、按产线或设备派生会话密钥、版本化轮换与历史解密支持，让生产线密钥注入烧录和日常轮换共用同一套治理。根密钥始终在硬件密码机内，永不明文导出。
完整性关这一段，需要的能力是"指令签名下发 + 日志签名入库 + 集中完整性校验"。下发给设备的控制指令由授权方签名、设备侧验签执行；设备的审计日志逐条签名后集中存储，定期做完整性校验。两项叠加，让数据完整性与审计完整性都成为可核查的事实。
这三段能力的组合，正好覆盖身份鉴别、数据保密、完整性三道关，也直接对应了 06 节里那几份清单的测评项。
08 | 验收清单与下一步
上线前建议逐项过一遍这张表：
| # | 验收项 | 通过标准 |
|---|---|---|
| 1 | 设备身份台账 | 每台关键设备一把凭据、一个标识，无共享口令 |
| 2 | 凭据私钥驻留 | 私钥在安全载体，配置文件无明文密钥 |
| 3 | 接入验签闭环 | 篡改或冒名接入被拒绝 |
| 4 | 共享账号清零 | 运维与维护无共享账号、无明文口令 |
| 5 | 多因素覆盖 | 远程运维与敏感操作叠加独立因素 |
| 6 | 敏感字段加密 | 工艺参数与配方落库为密文 |
| 7 | 密钥分域清单 | 设备/应用/数据库密钥按统一规则派生 |
| 8 | 根密钥保护 | 根密钥仅在硬件密码机内，无明文副本 |
| 9 | 派生可复现 | 同因子派生一致、不同设备派生不同 |
| 10 | 指令签名下发 | 被篡改指令被设备验签拒绝 |
| 11 | 日志签名入库 | 改动历史日志被完整性校验发现 |
| 12 | 密钥轮换演练 | 主密钥轮换后各设备派生值同步更新且业务无感 |
| 13 | 证据链串联 | 设备-凭据-密钥-日志可逐条还原 |
| 14 | 分类分级口径 | 关键设备与重要数据清单与保护资源对齐 |
| 15 | 测评项映射表 | 每条要求映射到五个落地动作 |
趋势上看，这套合规的重心正在从"采购安全设备"往"交付证据链"迁移。过去只要机房有防火墙、设备设了强口令就算建设；现在的测评会追到单台设备的凭据是否可验证、单条指令的签名是否成立、单把密钥的归属是否可追溯。这个迁移对架构的实质要求是：身份、密钥、日志三件事不能再各自为政，它们必须共享同一套设备标识、同一套密钥分域规则、同一条审计口径。
下一篇预告：我们接着拆房地产侧的同一件事：住建部房地产数据安全监管，看房地产中介的个人信息保护与售楼数据加密，怎么在合规框架下落地，和工业互联网"证据链"的做法有哪些相通、又有哪些根本不同。
09 | 常见问题：工业互联网等保合规的 4 个高频疑问
- Q: 工业互联网等保合规整改一般要多久？
- A: 周期主要取决于已建系统的改造量，不是设备数量本身。只做身份鉴别与日志签名这类轻改造，三到六个月可以补齐三级的多数测评项；涉及工艺参数透明加密、密钥体系重建的，往往要八到十二个月。真正拉长周期的是设备凭据治理，给每条产线的关键设备签发可验证凭据一般要两到三个月。
- Q: 生产线密钥注入烧录怎么做才符合密评要求？
- A: 判断标准是看密钥是否按设备分域派生，而不是看有没有加密。主密钥应托管在硬件密码机内，由密钥管理平台按"产线 + 设备"这类因子派生会话密钥，注入到设备侧安全载体而非明文配置文件；主密钥按年轮换，轮换后各设备派生值同步变化，历史密钥归档保留用于解密历史数据。
- Q: 工业互联网等保合规里的设备身份要怎么做才算达标？
- A: 设备身份达标的核心是"可验证、私钥不出设备"。每台关键设备应持有一把由私钥签名的凭据，接入请求带签名、平台只认公钥验签；私钥驻留设备侧安全载体而不是写进配置文件。用共享口令或明文密钥接入，身份鉴别这一测评项就无法通过。
- Q: 工控场景做透明加密要怎么做才不影响生产节拍？
- A: 优先选驱动层透明加密，写入即加密、读取即解密，对业务 SQL 和业务逻辑透明，不需要改应用代码。只对工艺参数与配方这类高敏感字段开启加密，普通业务字段保持明文；配合硬件加速，对生产节拍的影响通常控制在个位数百分比以内。
相关阅读
文章作者:安当加密-焱垚