在上一篇文章 个保法下的数据中台建设（一）：《个人信息保护法》解读 中，我们整体解读了下《个人信息保护法》，从该篇文章开始，我们聚焦在具体的领域中解决企业数据安全落地中的问题。
本文我们先来看一个最重要的功能：数据去标识化。
一、去标识化
在讲解去标识化的应用之前，我们先来看下个保法中，对于去标识化、匿名化、个人信息是怎么解释的：
去标识化，是指个人信息经过处理，使其在不借助额外信息的情况下无法识别特定自然人的过程。
匿名化，是指个人信息经过处理无法识别特定自然人且不能复原的过程。
个人信息是以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息，不包括匿名化处理后的信息。
我们可以得到两个关键信息：
1、完全匿名化处理的信息，不属于个人信息范畴。因此，如果不是为了当前的业务诉求，而是为了分析、算法训练等场景，是可以保存个人信息的，前提是个人信息已经匿名化，如使用内部ID代替手机号码来进行算法训练。
2、匿名化比去标识化的程度更深。去标识化后的数据借助额外信息可以识别到特定自然人，匿名化后的数据无法识别且不能复原。
但是对于什么样的技术手段算是去标识化，什么样的技术手段算是匿名化目前还没有明确的进行界定，且部分情况下两者的界限并不明显，因此对于这类操作，我们目前统称为去标识化。后续如果国家出具了更加详细的规定，我们在新文章里在进行解读。
二、去标识化的方法与场景
首先，我们先来看下去标识化的方法。根据我们处理方式的不同，去标识化的方法也多种多样，以下列举了常用的去标识化的手段：
去标识化方法 |
使用场景 |
脱敏-遮盖脱敏 |
遮盖脱敏适用于临时的、仅查看的数据脱敏，因为数据脱敏后无法复原，且不同的内容脱敏后可能是同样的结果，所以遮盖脱敏并不适用于数仓等场景。 举例：如姓名遮盖，“张三” 变成 “*三” 适用场景：数据查看、动态脱敏 |
脱敏-哈希脱敏 |
虽然存在潜在的撞库风险，但是哈希脱敏后的结果可以认为是不可复原的，尤其是加盐哈希脱敏之后的数据，可以认为除了知道算法和盐值的人之外，几乎无法碰撞出原值，有很好的保密性能。同时哈希脱敏之后的值具有较好的区分性，可以用来进行碰撞等操作，所以也适用于不需要原值的数据仓库业务。 举例：SHA算法、MD5算法和对应的加盐算法 适用场景：数据查看、动态脱敏、数据仓库（不需要复原 / 不允许复原） |
加解密 |
加解密方案支持使用算法对数据做完整的加密和解密操作，在隐藏敏感信息的前提下，能完整的对数据进行分析和加工处理，同时在有需要的时候，还可以对数据进行解密，是整体上最为推荐的方案。 举例：对称加密算法AES、非对称加密算法RSA等 适用场景：数据查看、动态脱敏、数据仓库（需要复原） |
映射替换 |
映射替换是在数据入库前，对数据的关键信息进行表的映射，并将映射表单独加密保存。常见的比如将用户注册的手机号使用用户账号或者用户id存储进数据仓库，进行数据分析；业务需要使用时，再出库关联回原来的手机号等，这样既可以做到敏感数据的脱敏，也可以正常实现业务的分析。 举例：将手机号17816812345替换为内部ID12345 适用场景：数据查看、动态脱敏、数据仓库（需要复原） |
统计汇总 |
统计汇总是指直接抹去和个人有关的信息，仅保留业务部分的内容，比如时间、门店、金额；或者将业务所需要的信息，按照所需粒度，统计为最终数据之后才进入数据仓库，比如不同地区、不同日期的营业额；该方法会损失大量原始数据，仅适用于小部分对详情不敏感的统计类业务。 举例：10个用户的消费账单，转化为当天的总收入。 适用场景：少部分的数据分析场景 |
而在数据的处理中，有以下几个场景需要对敏感数据做到保护：
去标识化场景 |
详情 |
数据集成 |
数据集成是数据批量输入输出的接口，是对数据去标识化要求最高的场景。通用的做法是对入库的数据按照数据中台的标准进行加密，在出库时按照中台的标准或者业务系统的标准进行相应的加密/解密。 |
数据服务 |
数据服务一般是数据对外服务的窗口，经常涉及到明细数据或者汇总数据的查询，一般来说数据服务都是根据业务场景和合规情况进行设计的，且一般都会比较重视性能，通过权限控制即可；在影响重大的场景，则可能需要对数据进行单独的加密/脱敏。 |
数据开发 |
对于数据中台内的数据开发场景，则会有很多中灵活的处理方式。对于绝密数据，可能入库进行加密，只有少部分人才能够进行解密操作；对于一般保密的数据，则可以通过加密或者动态脱敏的办法，进行敏感数据的保护。 |
需要注意的是，在完整的安全方案中，都会有一个不稳定的因素，也就是每个场景下操作的“人员”。所以，在安全的技术方案之外，想要达到理想的安全保障，对于人员的权限体系，也要做严格的权限控制和分配。
三、去标识化方案
以下用数据集成和数据研发为例，讲解在数据中台建设中的去标识化方案。如上文所诉，因为个保法发布后，我们认为数据进入中台前最好是经过去标识化的，所以我们用加解密来进行方案的解释。如果实际业务中不需要这么复杂的功能，比如只需要进行脱敏或者映射替换，则可以根据实际情况灵活调整。
1、透明加密方案（含出库脱敏）
1、方案原理
目前大部分数据源在底层存储上，都支持加密存储，有一些还提供透明加解密能力（数据入库自动加密，数据出库时对白名单自动解密，其他只能读取到加密数据），比如阿里云的Maxcompute，而我们就可以借助数据源的透明加解密功能，结合Dataphin的敏感数据保护功能一起，实现敏感数据的去标识化。
2、优缺点分析
优点：借助数据源能够快速实现入库数据加密；同时借助数据源的底层能力，在性能上有一定优化。
缺点：在加解密的灵活性上，如灵活指定加解密算法和密钥、数据出库加密等需求上存在一些差距；同时部分数据源不支持透明加解密、需要解决方案和实施的同学提前沟通好数据加解密形式；同时因为是整库加密，无法只针对敏感数据加解密等
3、Dataphin提供的能力：
3.1、对于敏感数据，提供敏感数据识别和脱敏功能，保证日常开发过程中（即席查询，开发写生产），敏感数据不泄漏
3.2、对于需要输出到业务系统的数据，提供静态加密能力，可以自定义上传UDF，通过代码任务生成自定义加密的数据，然后通过集成将加密后的数据输送到业务系统
2、独立加密方案
1、方案原理
支持完整的加解密算法和密钥的管理；在代码任务和集成任务中，支持加解密算法、密钥的调用；在数据开发任务中，支持更加灵活的加解密工具和动态脱敏等方式实现数据的去标识化
2、优缺点分析
优点：方案完整，客户完全可控（包括加密方式、密钥等），不会受到底层数据源能力的限制
缺点：对部分复杂的加密算法来说，性能上存在一定的损耗
3、Dataphin提供的能力
3.1、内置的加解密函数
3.2、支持在数据集成、数据开发中调用数据加解密算法
3.3、支持密钥的生成、注册、权限管理和调用（1期优先支持集成任务，支持全局参数之后支持代码任务）
3.4、同时支持数据的分类分级和动态脱敏等功能的使用
备注：
方案1和方案2并不是互斥关系，方案2（独立加密）也可以是方案1（透明加密）的升级版，即在透明加解密的基础上，在关键节点自定义加解密方案。
以上就是对于数据中台场景下进行数据去标识化的一些场景解读和实施方案的分享，欢迎大家来评论区讨论或者私信进一步沟通Dataphin的数据安全方案。对于个保法下数据中台建设的进一步解读，也可以关注后续系列文章，感谢大家。