数据脱敏和数据加密的区别

做数据接入、日志上报或者测试环境供数时，常有人问一句「这块数据脱敏了没」——结果对方答的是「加密了」。两种手段解决的根本不是一类问题：一个防的是「看得懂」，一个防的是「拿到了也打不开」。这篇把判断口径拆开，给一套对照表和选型顺序，帮你在评审和自查时不再混着说。

做数据接入、日志上报或者测试环境供数时，常有人问一句「这块数据脱敏了没」——结果对方答的是「加密了」。这两种手段解决的根本不是一类问题：一个防的是「看得懂」，一个防的是「拿到了也打不开」。混着说，评审时就容易放过真正的风险点。

这篇按目的、可逆性、密钥依赖、适用场景四条线拆开，给一套对照表和选型顺序。适合数据开发和安全的同学在评审、自查或写方案时对着看，重点不是名词解释，是让你能判断「这个字段到底该上哪种手段」。

先分清它们防的是谁、防到哪一步

脱敏的落点是「降低可用性」——数据还能流转、还能进测试库、还能给别人看，但看的人认不出原始身份。加密的落点是「提高获取门槛」——数据形态不变、照样存照样传，只是没有密钥就打不开。一个是把内容改得没意义，一个是把内容锁起来。

脱敏

在流转、展示、测试环节让数据读不出原始身份，重点是削弱可用性，而不是拦住访问

加密

在存储和传输环节让数据被拿到也解不开，重点是在权限之外再加一层数学屏障

判断口径

担心内部人随手翻到、截图带走，偏脱敏；担心介质被拖走、备份被拷走，偏加密

有个容易忽略的边界：当数据本身就是敏感事实，比如疾病诊断、精确位置、完整通讯录，脱敏只能削弱它和其他字段的关联性，读出来的结论该敏感还是敏感。这类字段通常要加密加权限一起上，而不是指望替换几个字就安全了。站内对这类场景有分类口径，可以到 安全与合规（/safety） 对照。

可逆性：一张表分清两边边界

最典型的口径差别就在这：加密默认设计成可逆，有密钥就能还原；脱敏默认设计成不可逆或很难逆。把两者当同义词用，最常见的后果是把「假名化」误当成脱敏交付出去——假名化保留了映射表或固定盐值，本质是可还原的替换，映射表一泄露等于没做。

• 判断可逆性时先问：需求方后面会不会需要回溯真实身份。要回溯就不能用不可逆脱敏，得走加密加审计。
• 再看取值空间：手机号段、小范围日期这类低基数取值，哈希的防护效果远不如预期。
• 验收时别只测「能不能还原」，也测「用公开信息能不能猜出来」，小样本数据集尤其要做这一步。
• 映射表、盐值、密钥都要单独存放并记录轮换与交接，不能和生产数据搁一块。

什么情况下不适用不可逆脱敏：客服核实身份、账务对账、司法取证这类明确要求回溯的场景，就得用加密加权限加审计日志，硬上不可逆脱敏反而会把业务流程卡死。

谁掌握钥匙：流程上的分水岭

加密把安全责任几乎全压在密钥管理上：密钥在哪、谁能取、多久轮换、离职怎么交接，任何一环松掉整条链路就失效。脱敏没有这个单点，但它的责任分散在生产环节的每一条规则上——只要漏掉一个字段，那次输出就是裸的。

1. 列出密文与密钥的位置分别标注存储位置、读取方、调用方式。只要两者出现在同一处，就记为高风险项，先拆开。
2. 圈定可以取密钥的身份写成清单，逐条确认是否真的需要。取值链条越长，越要配合审计日志。
3. 定轮换与交接规则写清触发条件、执行人、回滚办法，并明确离职或转岗时密钥如何交接，不要靠口头约定。
4. 定期抽验恢复流程拿一份历史密文走一遍解密流程，确认流程文档和实际口径一致，而不是只有文档能跑通。

脱敏这边没有「一把钥匙全还原」的风险，但字段清单本身要有人维护，而且得和上游表结构变更挂钩。站内关于权限交接的通用做法可以借到密钥管理上，见 多把 Key 的轮换与最小权限（/guides/key-rotation-least-privilege）。

场景对照：哪些环节该用哪个

把环节列出来对号入座，比抽象讨论有效。原则是：数据要长期躺着、或者要跨网络走的，以加密为主；数据要给人用的、要进开发或测试流程的，以脱敏为主。两者不是竞争关系，是覆盖链路的不同段。

实操上更推荐顺着链路盘一遍：从采集、落到存储、进数仓、再到下游消费和对外出口，逐段记录字段范围与手段。凭印象讨论经常漏掉中间某一跳，站内有一篇顺着链路排查的思路可以参照 你的数据到底发到哪了（/guides/data-boundary-audit）。

常见组合：不是二选一

成熟的方案基本都是叠着用：落盘的是密文，进了业务系统之后按角色做字段级遮蔽，再叠一层访问控制和审计。少了审计这一层，谁能读到密文就能自己想办法去解，前面的工作意义会打折。

• 存储层加密、使用层脱敏，这是最通行的一种组合，边界清晰、责任也好分。
• 对外共享或跨区域传输时，先脱敏再加密，并单独记录批次与字段范围，方便出事时追溯。
• 访问控制与审计不能省，至少要能回答「谁在什么时候读了哪些字段」。
• 字段标准选一个地方作为唯一出处，别让同一份数据两套规则散在各个脚本里维护。
• 规则变更要走评审，改完在测试环境跑一遍，确认下游没有依赖被替换掉的字段。

四个最常见翻车点

下面这四条按出现频率排，评审时可以直接当检查项过一遍。前两条属于设计问题，后两条属于流程问题，两类都得管。

• 以为脱敏就万事大吉：单个字段看不出身份，但几个准标识字段组合起来照样能重新识别，小样本数据集里尤其明显。
• 加密了却在日志里打明文：请求体、异常堆栈、慢查询记录是最容易漏的三处，检索台上能搜到就等于没加密。
• 只做一次不留痕：字段加了、规则没跟着改，过一段时间没人说得清哪批数据处于什么状态。
• 把格式保留当成安全属性：保留格式方便联调，但这和不可逆没有关系，别拿它当验收理由。

第三条最隐蔽的地方在于，它不会当场报错，只会在半年后有人问「这份数据脱敏过吗」时谁都不敢答。所以状态记录要和字段清单绑在一起，而不是散在工单或聊天记录里。

评审和自查用的落地清单

下面这套顺序可以直接拿去用：先分类字段，再定手段，然后写责任与周期，最后扫一遍明文泄露面。每一项都要落到文档或清单上，口头约定不算数。

1. 给字段分三档标识类、准标识类、敏感事实，先分类再谈手段。准标识类要单独标注，它是最容易被忽视的一档。
2. 给每个字段写清四件事用哪种手段、是否可逆、责任人是谁、多久复查一次，写进文档并纳入变更流程。
3. 按最坏情况评估可重新识别风险凡是小样本或内部人可访问的场景，默认假设有人会尝试关联还原，用这个前提去测。
4. 上线前扫一遍明文落点日志、错误上报、监控面板、导出文件逐项确认，重点看可检索的位置。
5. 把复查和表结构变更挂钩上游加字段时自动触发一次规则复查，避免新字段悄悄裸奔。
6. 补齐操作细节与剩余风险到 数据脱敏怎么做（/guides/data-masking-howto） 和 数据脱敏会完全消除隐私风险吗（/guides/data-masking-privacy-limits） 看具体做法和边界。

脱敏管的是「看了也认不出」，加密管的是「拿了也打不开」；把这两句话分开，评审时能少吵一半的架。