数据匿名化数据安全 QA视角看数据匿名化

分享到社交媒体：

数据匿名化，是数据安全相关的实践。目前从网上能找到的内容主要是关于匿名化的实现技术。最近，笔者在项目中以QA和用户的双重身份接触到了数据匿名化，决定跟大家分享一下这段经历，从QA的视角来聊聊数据匿名化。

数据匿名化及其实现概述

在聊项目经历之前，还是有必要大概介绍一下数据匿名化。

数据匿名化是指从数据集中将个人身份信息（Personal Identification Information, PII）清除/脱敏，让人无法识别数据所描述/关联的主体，以实现保护隐私的目的。

很多场景下需要使用和处理生产环境的真实数据，比如：以测试、培训、数据对外发布、数据分析等为目的的场景。但生产环境的真实数据包含个人身份信息，由于隐私保护需要，不能直接使用。这个时候数据匿名化很有必要。

实现数据匿名化的操作（参考Wikipedia）常见的有五种类型：泛化（Generalization），抑制（Suppression），解剖（Anatomization），置换（Permutation）和扰动（Perturbation）。具体的实现技术细节不是QA视角关注的重点，本文不做展开，对此感兴趣的朋友请自行研究学习。下表列举一些简单的数据匿名化例子：

数据匿名化方法	方法详情	方法示例
取整	数值或日期数据的取整	15:25:25 => 15:00:00
屏蔽	屏蔽部分数据，如电话号码、身份证号码等	187****1234
截断	数据部分截断	0086-10-88888888 => 0086-10
替换	使用替换表对敏感数据进行替换	IBM=>1, HP=>2, MS=>3
哈希	将数据映射为固定长度的字符串	IBM=>a23d, HP=>1fc2
重排	将数据库的某一列值进行重排	81,87,85 => 87,85,81
保留格式加密（FPE）	明文和密文格式不变	18712345678 => 18587654321

数据匿名化后需要关注以下几个方面：

安全性：之所以要将数据匿名化，为的就是保护个人隐私，是从数据安全性角度考虑的。因此，安全性是数据匿名化后需要着重考虑的关键点。
可用性：数据匿名化肯定是有其目的用途的，不管是应用于前面提到的哪个场景，都需要保证匿名化后的数据是满足需求的，也就是数据可用性。
可用性和安全性的平衡：如果数据匿名化做的很彻底，完全识别不出原来数据的面目，定会影响到数据的可用性，因此，可用性和安全性是相互制衡的两个方面，唯有根据实际需求保持好两者的平衡才能真正发挥作用。

数据匿名化的项目实践

这不是一个大数据项目，数据分析（虽有必要但）不是重点；这是一个普通的企业管理系统和用户系统，有着大量的用户数据，而且数据机密程度要求比较高。下面来看为什么要在项目内做数据匿名化，以及项目的数据匿名化是怎么做的、有哪些坑。

数据匿名化由项目痛点驱动

项目痛点

生产环境缺陷较多是困扰客户和开发团队的问题，是项目迫切需要解决的痛点。

生产环境数据机密性要求较高，数据可访问权限受限，测试环境的数据量和复杂度都无法和生产环境相比。这种环境数据的差异性使得生产环境缺陷的诊断定位非常困难，也很难在测试环境提前发现可能引起的生产环境问题。虽然从缺陷分析、缺陷响应机制、增加日志监控等方面做了很多工作，但还是会有很多缺陷在生产环境出现，而且总会冒出一些稀奇古怪的新的缺陷类型来。

于是，团队跟客户讨论最终决定采用数据匿名化技术将生产环境数据匿名化后用于测试，以尽早暴露生产环境问题，同时帮助更方便生产环境问题的诊断定位。

数据匿名化的项目实现流程

项目的数据匿名化实践主要经历以下四个阶段：分析设计、落地实施、测试确认和交付使用。

这里主要是为了方便描述，分成了四个看似独立的阶段，其实每个阶段之间的分界线不是那么清晰的，实际操作过程中有反复和叠加的情况存在，如下图中虚线所示。例如：在落地实施阶段发现有些分析做的不够或者设计不合理，需要返回重新分析和设计；在测试确认阶段发现有的数据匿名化有问题，需要返回重走实施流程执行优化的匿名化方案等。

数据匿名化实践流程

1. 数据匿名化项目的分析设计

要实现数据匿名化首先要搞清楚需要脱敏的数据，以及如何对数据进行脱敏，这就是对应到分析设计阶段的两个主要任务：定义PII信息和制定数据匿名化策略。这部分由业务、开发和测试等多个角色合作完成。

定义PII信息

定义PII信息主要是根据业务需求分析出系统中的哪些数据是不能对外公开需要脱敏的，以确定数据脱敏的范围。常见的PII信息可能有：个人身份信息（姓名、身份证号、电话号码、职业、薪水等）、部门信息、签署的协议内容等。

除了基本的个人信息外，不同的业务领域或客户对机密信息的定义也会有区别。数据脱敏范围一定要根据具体的业务需求来确定。

制定数据匿名化策略

确定了脱敏范围，接下来就是确定详细的脱敏方式，选择合适的工具，也就是制定数据匿名化策略。

首先是工具选型。项目选择的是 Tonic，之所以选择这个工具很大部分原因是客户提出来的，当然这个工具也是很强大的。作为QA，并没有亲密接触到这个工具，在此也就不多展开，更多关于工具的详情，请自行研究对比。

然后是根据工具以及系统PII数据的存储特点，确定最终可以实现脱敏的数据范围。比如，项目中的不同类数据有不同的方案：

直接以数值形式存储在DB里的PII数据，可以对其进行脱敏，实现匿名化；
以文件形式存储的协议、报告等数据，都是只读的PDF格式，这种数据难以脱敏，只能放弃这些文件数据，不进行导入；
用户登录认证相关数据，脱敏成本较高，采用Mock的方式，让用户仍然能够登录系统进行使用。

进行数据脱敏还要注意不同类型的数据一般会有不同的脱敏方式，比如：人名的脱敏有专门的词库，脱敏后看起来还是人名的样子；而有些固定格式的字段，像身份证号、电话号码、车牌号这些脱敏后虽然数值变了，格式还需要保留原样。因此，对于每一个不同的数据字段都要设定好详细的脱敏策略。

2. 数据匿名化项目的落地实施

制定好详细的数据匿名化策略，接下来就是利用工具实现脱敏了，这部分由专门负责的开发人员来完成。下面根据项目经历，分享落地实施的执行流程和踩过的坑。

数据匿名化的实施

流程

数据匿名化的具体实施经历了以下几个步骤：

数据分析：确定 DB 涉及表单的范围，识别 PII 数据存储列，分析数据关联并确认外键关联列、enum 存储列等核心关系列。
数据生成：采用工具Tonic，与 Tonic 支持团队合作，根据不同列的脱敏方案进行脱敏，生成新的匿名化数据。
环境搭建：这些匿名化后的数据是用于测试环境的，但不是直接导入测试环境，需要验证可用之后才能切换到测试环境。因此，需要的单独搭建一套测试环境用来导入脱敏后的数据。本步骤实现环境基础设施搭建，安装配置所有第三方支持组件。
数据导入：在新搭建的环境导入 Tonic 生成的数据，简单验证保证系统正常运行起来，后续再交给QA团队来做进一步的测试确认。

注意：这里的数据分析跟前面分析设计阶段的分析师不同的，分析设计阶段是从业务上对PII数据的分析确认，在实施阶段是对数据库表里存储的实际数据进行分析。

难点

在数据匿名化实施过程中踩到了一些坑，在此也跟大家分享一下：

潜在数据关系错综复杂，有些未被提前识别，导致生成的数据不可用；
为了保证导入数据正常工作，需要Mock不能实现匿名化的用户登录认证系统，这是一个难点；
系统存在大量的事件（Event），基于导入数据重新生成Event也比较麻烦；
匿名化后导致有不少跟环境配置相关的数据需要修复。

3. 数据匿名化的测试确认

测试确认是QA主要参与的阶段，对脱敏后生成的数据的测试主要从安全性和可用性两个方面进行测试确认。

数据匿名化的测试

安全性

首先要保障的是数据的安全性，也就是需要满足数据不能被识别，测试过程中主要关注以下几个方面：

确认分析阶段确认需要脱敏的数据是否都已经脱敏，或者已经通过Mock的方式处理。
是否有分析过程中漏掉的同样需要脱敏但没有脱敏的信息，对于这样的数据需要再次进行脱敏。
对于已经脱敏的数据是否有猜测出真实信息的可能，通过系列数据的关联、对比等方式。
可用性和安全性没法两全，需要作出取舍，对于那些为了保证可用性而没法脱敏的数据是否有从访问控制的角度保障一定的安全性。比如：只能有限的用户可以访问，并且需要在内网才能访问等。

可用性

可用性主要是通过测试系统功能来确认，这跟平常的功能测试差异不大，不过可以重点关注以下几个方面：

系统各个功能模块的连通性、与外部系统的连通性，通过验证已有数据和新增数据是否都能工作正常。
脱敏后的数据是否有问题，比如类型错误可能导致数据存储被破坏而不能通过数据校验等。我们在实践过程中就发现有date类型的数据不小心给脱敏成了string类型，导致存储失败。
数据唯一性保障，确保不会有重复数据影响功能使用。举例说明，系统有个功能需要存储客户的短名称，脱敏过程中实现方式是用前三个字母，假设有几个客户名字分别被脱敏为：“New Star”、“New World”、“New Land”，那么它们的短名称就都变成了“New”，是相同的，而事实上是对应到不同的客户，这必然会影响功能的使用。

4. 数据匿名化的交付使用

确认了匿名化后的数据没问题、系统工作正常就正式投入使用了，这时候QA身份也变成了用户，团队的业务和开发人员也是这个环境的用户。这部分主要分享一下脱敏后的数据给我们团队带来的价值，以及使用过程中的一些感受和想法。

数据匿名化的项目使用价值

价值

我们采用每月导入一次数据的做法，以尽量保证这个测试环境的数据跟生产环境的接近。利用脱敏的生产环境数据测试带来的价值主要有：

功能相关bug可以提前在测试环境发现，减少流入生产环境的bug数，降低了修复成本。
利用这个环境做性能测试，尽早发现之前到生产环境才能暴露的性能问题，尽早修复，降低了成本，并且带来更好的用户体验；另外，我们还通过这个环境跟踪性能趋势，尽早做好性能优化工作。
利用这些数据重现生产环境的缺陷，加快线上问题诊断速度，提高响应效率，改善用户支持体验。

使用感受

脱敏后的数据的使用跟原来测试环境自己创建的数据使用还是很不一样的感受：

不是测试人员熟悉的数据，相对不易于测试，不如自己创建的数据使用的那么顺手。
数据辨识度降低，脱敏后的数据很多都是没有任何意义的一些字符拼凑的词语（我们的系统是英文的），有些功能就很难使用。比如搜索，每次需要输入一些没有意思的字符串还是很费劲的，这样的话，可能会导致测试人员尽量不用搜索功能而漏掉搜索功能本身存在的bug。
每次重新导入新的数据都会清理掉原来的数据，包括测试人员新建数据，也就是每月都要面对一批新的数据，这种体验也是很特别的。
含有PII的文件难以匿名化，文件数据没法导入，从而导致有些功能没法使用原有数据进行验证。
用户登录认证相关信息没法匿名化导入，被Mock掉了，导致无法验证原有用户的真实登录功能。

数据匿名化属于测试右移实践之一

本文项目实践只是将数据脱敏用于测试，数据匿名化还有很多其他的用途，比如数据挖掘、数据分析等。

数据匿名化的实践过程相当于一个小项目交付过程，同样包含需求分析、设计、开发（匿名化实施）、测试和发布（交付）等环节，在每个环节会有不同的角色参与协作，也同样需要遵循质量内建理念，前期工作做的充分，后面返工就会减少。

生产环境下的QA

数据匿名化是对生产环境的真实数据的处理，不管用于什么用途，都可以算是生产环境下的QA/测试右移的实践之一。

希望本文能够给没有做过数据匿名化的同学带来一些帮助，也欢迎有经验的同学来分享更多的经验。