静态脱敏系统安全评估

静态脱敏系统安全评估

一份能过核查与审计的静态脱敏系统安全评估，要回答的不是功能清单有多长，而是结论能不能被第三方复算。很多团队在采购或上线前都会问同一个问题：这套系统到底安不安全？但"安全"如果只停留在厂商的承诺页上，它就永远是一个无法验证的说法。真正能被审计、被监管、被业务方信任的评估，必须把脱敏系统的信任基元拆成一条条可以独立复算的检查项。

坐标先立：脱敏系统的安全评估不是另起炉灶，而是落在一个成熟的坐标系里——以等保 2.0 的数据安全相关要求、密评对完整性与机密性的要求、个人信息保护与数据安全相关法规为框架，再看这套系统在"确定性、保形、版本归因、可逆可控、导出受控"这几件事上能不能拿出可复算的证据。

01 | 静态脱敏系统安全评估，难在哪儿

脱敏系统看起来只是"把敏感字段换掉"，但一旦要评估它的安全性，难点会成倍出现。

• 难点一：确定性难验证。 同一姓名、同一证件号，在不同批次、不同时间脱敏后是不是同一个值？如果无法复算，下游的关联分析就会失真，评估也失去了基准。
• 难点二：保形只是表面。 很多方案声称"格式不变"，但格式不变不等于可逆可控，也不等于去标识。评估要区分"看起来像"和"算出来对"两件事。
• 难点三：版本归因缺失。 规则改过一次，旧数据是按哪个版本脱敏的？说不清版本，审计就断了链，出了问题无法回溯。
• 难点四：可逆与受控是两回事。 支持恢复不代表恢复受控。评估必须确认：谁有权恢复、用什么凭据恢复、恢复动作有没有留痕。
• 难点五：导出边界模糊。 脱敏数据出了生产域，是不是任何人都拿得到？没有签名凭据的导出一旦放行，脱敏的价值就归零。

这些难点之所以难，是因为它们都指向同一个本质：脱敏系统的安全性不是一种感觉，而是一组可以被验证的性质。如果一项性质无法被第三方用同样的输入复算出来，它就只能停留在厂商的口头承诺里。评估的价值，正是把这种承诺变成可检验的事实。

所以静态脱敏系统安全评估，第一步不是比对功能清单，而是确认这五项能不能被第三方复算。不少团队把静态脱敏系统常见问题解答当成验收口径，但问答里没有可复算的证据，不能代替评估。

02 | 静态脱敏系统安全评估的维度拆解

把静态脱敏系统安全评估拆成两条线：一条看厂商说了什么，一条看代码能证明什么。前者是文档，后者才是证据。文档能告诉你"支持确定性脱敏"，但只有把同值脱敏两次、把不同值各脱敏一次，才能确认它真的做到了。

比起静态脱敏系统常见问题解答里的经验之谈，评估更看重每一项能不能被独立复算。静态脱敏系统成本分析不能只看采购价，评估要把运行、轮换、整改都算进三年账，否则账算不平，安全投入也讲不清回报。

下面这张图把"看文档"和"看证据"的两条线并排摆出来，评估时逐项打勾：

静态脱敏系统安全评估：两条线模型
┌────────────────────┬──────────────────────────────────┐
│ 看文档(厂商说) │ 看证据(代码可复算) │
├────────────────────┼──────────────────────────────────┤
│ 支持确定性脱敏 │ 同值脱敏两次 → token 一致 │
│ 格式保持不变 │ 长度一致且不含原文 │
│ 规则可版本化 │ 不同版本 → 不同 token │
│ 可逆可控 │ 持密钥还原 / 换密钥解不开 │
│ 导出受控 │ 无签名凭据的导出被拒绝 │
└────────────────────┴──────────────────────────────────┘

在动手评估前，建议先把静态脱敏系统常见问题解答里的高频疑问整理成可复算的问题清单，而不是等到验收时才临时翻文档。同时，静态脱敏系统成本分析应当前置到选型阶段，把采购、运维、轮换、整改并列核算，避免上线后才发现隐性开销远超预期。评估与成本本就是同一件事的两面。

静态脱敏系统安全评估的判定清单

判定清单不是一张打分表，而是一组可以现场演出来的命题。每一条都对应一个能被代码复算的结论：确定性（同值同 token）、保形（长度一致且不含原文）、版本隔离（换版本 token 变）、可逆受控（持密钥还原、换密钥解不开）、导出受控（无凭据拒、篡改拒、冒名拒）。这五组命题构成了评估的骨架。

评估里最容易被忽略的版本归因

版本归因是评估里最容易漏掉的一项。规则一旦调整，历史数据按哪个版本脱敏就成了一段没人说得清的历史。评估时应当要求每一次脱敏作业都带有规则版本号，并且版本号进运算——不同的版本号必须产生不同的 token，这样审计时才能把一条数据还原到它当时的脱敏口径。

03 | 先跑通：静态脱敏系统安全评估的五个核对点

下面把六项可复算的核对项跑一遍。脱敏部分用确定性、保形、版本隔离、去标识四项验证；可逆部分用持有密钥还原与换密钥解不开验证；导出部分用签名凭据验证。每一项都给出正向断言，全部为 True 才说明该系统通过了基础核对。

# -*- coding: utf-8 -*-
"""D16#1 demo —— 静态脱敏系统安全评估
落点:安全评估一个脱敏系统,不是比对功能清单,而是把确定性/保形/版本归因/可逆可控/
导出受控拆成可逐项复算的清单;每一项都能被第三方用代码独立验证。
演示:确定性脱敏 + 保格式 + 规则版本进运算 + 不可逆 + 可逆受控(换密钥解不开) + 导出凭据受控。
注意:同一私钥 + 同一 FIXED_K 仅用于演示复现,真实环境禁止固定 K。
"""

from gmssl import sm2, sm4, sm3, func

PRIV_A = "6a3a91c46a3a91c46a3a91c46a3a91c4"
PRIV_B = "5b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d05b8e27d0" # 冒名方
FIXED_K = "0101010101010101010101010101010101010101010101010101010101010101"

def pub_of(priv: str) -> str:
return sm2.CryptSM2(private_key=priv, public_key="")._kg(
int(priv, 16), sm2.default_ecc_table["g"])

PUB_A = pub_of(PRIV_A)
PUB_B = pub_of(PRIV_B)

def sm3_hex(data: bytes) -> str:
return sm3.sm3_hash(func.bytes_to_list(data))

def sm4_cbc(key: bytes, iv: bytes, data: bytes, enc: bool) -> bytes:
assert len(key) == 16, "SM4 KEY 必须 16 字节"
assert len(iv) == 16, "IV 必须 16 字节(少一字节会 IndexError)"
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

def dec_is(key: bytes, iv: bytes, ct: bytes, plain: bytes) -> bool:
return decrypt_or_none(key, iv, ct) == plain

# ======================================================================= #
# ↓↓↓ 业务逻辑区 ↓↓↓
# ======================================================================= #

RULE_KEY = b"16BYTEMASKKEYPAY"
IV = b"16BYTEIVFORPAYGW"

def fmt_preserve(token_hex: str, original: str) -> str:
# 保格式:输出长度与原文一致,数字保持为数字(演示用 0-9 映射)
t = token_hex[:len(original)]
return "".join(str(int(c, 16) % 10) for c in t)

def mask(value: str, version: str) -> str:
h = sm3_hex(RULE_KEY + version.encode("utf-8") + value.encode("utf-8"))
return fmt_preserve(h, value)

# 1) 确定性:同值同 token(评估-核对项一——可复算)
v = "CUST-NO-77820"
tok = mask(v, "v1")
ok_det = tok == mask(v, "v1")
# 2) 不同值得到不同 token
ok_diff = mask("CUST-NO-33911", "v1") != tok
# 3) 保格式:长度一致(评估-核对项二——能直接装入原 schema)
ok_fmt = len(tok) == len(v)
# 4) 规则版本进运算:不同版本 → 不同 token(评估第三项——版本可归因)
ok_ver = mask(v, "v2") != mask(v, "v1")
# 5) 脱敏后不含原文(评估第四项——去标识)
ok_no_plain = tok != v
# 6) 可逆模式:持有密钥可还原(评估第五项——可逆受控)
rv = "settle-20261026-0081"
ct_rv = sm4_cbc(RULE_KEY, IV, pkcs7_pad(rv.encode("utf-8")), True)
ok_rev_enc = ct_rv != rv.encode("utf-8")
ok_rev_dec = decrypt_or_none(RULE_KEY, IV, ct_rv) == rv.encode("utf-8")
# 7) 换密钥解不开可逆密文
ok_wrong = not dec_is(b"16BYTEWRONGKEY99", IV, ct_rv, rv.encode("utf-8"))
# 8) 导出凭据签名受控(评估第六项——导出受控)
export_payload = "auditor|export=eval-set-masked|exp=2026-10-26T18:00"
export_hash = sm3_hex(export_payload.encode("utf-8"))
sm2_a = sm2.CryptSM2(public_key=PUB_A, private_key=PRIV_A)
export_sig = sm2_a.sign(export_hash.encode("utf-8"), FIXED_K)
ok_export = sm2_a.verify(export_sig, export_hash.encode("utf-8"))
ok_no_cred = not sm2_a.verify(export_sig, sm3_hex(b"other|export=x").encode("utf-8"))
ok_tamper = not sm2_a.verify(
export_sig, sm3_hex((export_payload + "|tampered").encode("utf-8")).encode("utf-8"))
sm2_b = sm2.CryptSM2(public_key=PUB_B, private_key=PRIV_B)
sig_b = sm2_b.sign(export_hash.encode("utf-8"), FIXED_K)
ok_imposter = not sm2_a.verify(sig_b, export_hash.encode("utf-8"))
ok_repro = sm2_a.sign(export_hash.encode("utf-8"), FIXED_K) == export_sig
ok_hash64 = len(export_hash) == 64

asserts = [
("安全评估-确定性脱敏:同值同 token", ok_det),
("安全评估-不同值得到不同 token", ok_diff),
("安全评估-保格式:输出长度与原文一致", ok_fmt),
("安全评估-规则版本进运算:不同版本 token 不同", ok_ver),
("安全评估-脱敏后不含原文(去标识)", ok_no_plain),
("安全评估-可逆模式:密文不同于原文", ok_rev_enc),
("安全评估-可逆模式:持有密钥可还原", ok_rev_dec),
("安全评估-换密钥解不开可逆密文", ok_wrong),
("安全评估-导出凭据签名验签通过", ok_export),
("安全评估-未授权导出被拒绝", ok_no_cred),
("安全评估-篡改导出内容被拒绝", ok_tamper),
("安全评估-冒名私钥签发被拒绝", ok_imposter),
("安全评估-固定 K 签名可复现", ok_repro),
("安全评估-SM3 摘要为 64 位十六进制", ok_hash64),
]

print("=" * 60)
for t, ok in asserts:
print(f"[{t}] = {'True' if ok else 'False'}")

============================================================
[安全评估-确定性脱敏:同值同 token] = True
[安全评估-不同值得到不同 token] = True
[安全评估-保格式:输出长度与原文一致] = True
[安全评估-规则版本进运算:不同版本 token 不同] = True
[安全评估-脱敏后不含原文(去标识)] = True
[安全评估-可逆模式:密文不同于原文] = True
[安全评估-可逆模式:持有密钥可还原] = True
[安全评估-换密钥解不开可逆密文] = True
[安全评估-导出凭据签名验签通过] = True
[安全评估-未授权导出被拒绝] = True
[安全评估-篡改导出内容被拒绝] = True
[安全评估-冒名私钥签发被拒绝] = True
[安全评估-固定 K 签名可复现] = True
[安全评估-SM3 摘要为 64 位十六进制] = True

逐条对照上面的输出，评估现场可以这样演：首先，取同一个标识脱敏两次，核对两次的 token 是否一致，不一致就说明系统做不到确定性，下游关联会乱；其次，取一个不同标识脱敏，核对 token 是否不同，相同则存在碰撞风险；第三，核对脱敏后的长度是否与原文一致且不含原文，确认既保形又去标识；第四，换一个规则版本号再脱敏，核对 token 是否变化，确认版本进运算；第五，对可逆模式分别用正确密钥与错误密钥还原，确认持密钥能还原、换密钥解不开；第六，对导出凭据分别用正确签名、错误内容、冒名私钥验证，确认只有带合法签名凭据的导出才通过。六组全绿，评估的基础项才算过关。

04 | 落地动作：静态脱敏系统安全评估怎么落地

评估不是一次性的体检报告，而应嵌入脱敏系统的日常运行。建议分四条线推进，每条线都有可执行动作，并配一个整改样本。

• 清单线： 把上文的五组命题做成评估清单，每次升级或换版本都重跑一遍，保留当时的输出作为证据。
• 版本线： 在做静态脱敏系统安全评估时，建议把每一次脱敏的规则版本号写进作业台账，这是可被审计回溯的关键。版本号与 token 绑定，出问题能定位到当时的口径。
• 恢复线： 可逆恢复必须走授权凭据，恢复动作写入独立日志，且恢复日志与生产日志分离，避免恢复权限被滥用。
• 导出线： 所有跨域导出必须带签名凭据，凭据含使用方、用途、有效期，越权或过期一律拒绝。

在排定四条线时，静态脱敏系统成本分析很容易只算软件授权而漏掉密钥轮换与恢复演练的人工，评估应当把这两类隐性开销单列，才能让三年总账对得平。

静态脱敏系统安全评估的整改样本

某制造企业上线脱敏系统后，首次评估发现可逆恢复没有独立凭据，任何拥有密钥的人都能还原明文。整改动作分三步：第一步，恢复接口改为必须持签名凭据调用，凭据与主体绑定；第二步，恢复日志写入独立审计库，与生产库分离；第三步，把恢复接口纳入定期评估，每月重跑核对项。整改后评估复算显示，换密钥无法还原、无凭据恢复被拒绝，两项均通过。在静态脱敏系统常见问题解答里被反复提到的『可逆可控』，评估时必须用密钥轮换来实地验证，仅靠文档声明不足以采信。

05 | 静态脱敏系统安全评估的八条避坑清单

坑六尤其常见：很多团队以为"大家都在问的问题"就是验收标准，于是把问答集当成了评估口径。问答可以提供思路，但不能替代代码复算。坑八则关系到评估的可持续性——密钥轮换、恢复演练这些动作年年都要做，只算采购硬件会严重低估真实成本。

06 | 合规视角：静态脱敏系统安全评估对上哪些要求

评估要能对齐几条公开的要求，而不是只对齐厂商的卖点。网络安全等级保护相关标准对数据在存储与传输中的机密性、完整性提出要求，脱敏系统的保形与去标识对应机密性，作业台账的整体签名对应完整性。商用密码应用安全性评估相关文件强调密码应用的合规与可验证，评估里的签名凭据、密钥轮换都要能讲清密码算法的合规使用。

个人信息保护与数据安全相关法规强调对敏感个人信息的去标识与最小化，脱敏系统的确定性、可逆可控正是把"最小化"落到可执行层面。静态脱敏系统常见问题解答往往只讲合规条文，不讲怎么落地，评估要补上这一环——把每条法规对应到一组可复算的检查项，而不是停留在引用条款。

在等保 2.0 的框架里，脱敏系统通常落在数据安全与密码应用两个层面，前者关心敏感数据是否被正确标识与保护，后者关心保护动作是否使用了合规的算法与密钥管理。评估时应当对照这两条线分别取证，而不是只看一份笼统的合规声明。密评强调的完整性，也要求在脱敏作业台账上使用签名，使得任何对历史记录的涂改都能被检出。

07 | 落地答案：静态脱敏系统安全评估看什么

落到选型上，静态脱敏系统安全评估给采购方的结论只有一句：能复算的才可信。具体看四件事：首要，确定性脱敏能不能被复算，这是下游关联分析的地基；其次，规则版本号是否进运算，这是审计归因的前提；第三，可逆恢复是否受控，这是防止"能恢复"变成"谁都能恢复"的闸门；第四，导出是否带签名凭据，这是脱敏数据出域后仍然受控的保证。

对采购方而言，静态脱敏系统成本分析的结论应落到『可复算的明细账』，而非一个总价。把一次性采购、常态化运维、密钥轮换、恢复演练、合规审计分别列项，评估时逐项核对，既能算清回报，也能在监管问询时拿出证据。

在具体选型时，采购方可以把评估结论转化为四句可验证的话：脱敏结果能被第三方复算、规则版本能被审计归因、恢复动作受凭据约束、跨域导出带签名验签。这四句话比任何宣传语都更有分量，因为它们每一项都能当场演给你看。

08 | 验收清单与下一步

上一阶段，静态脱敏系统成本分析要和验收清单绑定，避免事后补账。下一篇预告：脱敏系统的技术走向会越来越强调"可复算"作为出厂默认能力，我们将在《静态脱敏系统技术趋势分析》里拆开看确定性、保形、版本化与受控导出如何成为标配。

09 | 常见问题：静态脱敏系统安全评估的 4 个高频疑问

• Q: 做静态脱敏系统安全评估需要什么材料？

  • A: 评估要准备四类材料：一是脱敏规则说明与当前规则版本号，确认版本进运算；二是可逆恢复的流程说明与凭据样本，确认恢复受控；三是导出接口与签名凭据格式，确认导出受控；四是历次作业台账的签名记录，确认完整性可验。四类材料齐了，才能把文档里的承诺逐条变成可复算的证据，单靠功能清单无法完成有效评估。

• Q: 脱敏系统评估怎么做才能不走过场？

  • A: 不走形式的关键在于把每一项都现场演出来，而不是看文档签字。评估现场应取真实样本做确定性比对、版本隔离比对、可逆还原比对和导出凭据比对，并把输出留存为证据。规则版本号、作业台账签名、恢复日志独立性都要逐项核对，任何一项无法复算都应记为未通过，不能凭厂商声明放行。

• Q: 评估里版本归因需要多久能查清？

  • A: 版本归因的查清时间取决于规则版本号是否随脱敏进运算。如果每一批次都带版本号且版本号改变 token，清查找一条数据当时的口径只需一次核对，通常几分钟。若版本号没有进运算，历史数据无法归属到当时的脱敏规则，查清就只能靠人工回溯，耗时且不可靠，这也是评估要卡死版本进运算的原因。

• Q: 可逆脱敏在评估时如何确认受控？

  • A: 确认可逆受控要做两件事：一是用正确密钥还原、用错误密钥还原，核对前者成功、后者失败；二是检查恢复接口是否强制签名凭据，无凭据的恢复请求应被拒绝。恢复日志还要独立存放并与生产日志分离，确保恢复动作可审计。只证明"能还原"不够，必须证明"只有授权的凭据才能还原"。

相关阅读

• 静态脱敏系统数据脱敏
• 静态脱敏系统解决方案
• 静态脱敏系统密钥管理方案
• 静态脱敏系统在数据脱敏中的价值

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