一. 数据脱敏是什么？

数据脱敏顾名思义就是对敏感数据进行变形处理，其目的是保护隐私数据等信息的安全，例如机构和企业收集的个人身份信息、手机号码、银行卡信息等敏感数据。数据脱敏从技术上可以分为静态数据脱敏和动态数据脱敏两种。静态数据脱敏一般应用于数据外发场景，例如需要将生产数据导出发送给开发人员、测试人员、分析人员等；动态脱敏一般应用于直接连接生产数据的场景，例如运维人员在运维的工作中直接连接生产数据库进行运维，客服人员通过应用直接调取生产中的个人信息等。

二. 数据脱敏的实现方式有哪些？

1、 使用脚本进行脱敏

事实上，很多用户在信息化发展的早期，就已经意识到了数据外发带来的敏感数据泄露的风险，那时候用户往往通过手动方式直接写一些代码或者脚本来实现数据的脱敏变形，比如：简单的将敏感人的姓名、身份证号等信息替换为另一个人的，或者将一段地址随机变为另一个地址。

2、使用专业的数据脱敏产品进行脱敏

近年来，随着各行业信息化管理制度的逐步完善、数据使用场景愈加复杂、脱敏后数据仿真度要求逐渐提升，为保证脱敏果准确而高效，专业化的数据脱敏产品逐渐成为了用户的普遍选择。相比传统的手工脱敏方法，专业的脱敏产品除了保证脱敏效果可达，更重要的价值点在于提高脱敏效率，在不给用户带来过多额外工作量的同时，最大程度节省用户操作时间。

三. 数据脱敏技术

数据脱敏的基本原理是通过脱敏算法将敏感数据进行遮蔽、变形，将敏感级别降低后对外发放，或供访问使用。根据不同的使用场景可以分为“静态脱敏”和“动态脱敏”两类技术，这两类脱敏技术从适用场景、技术手段、部署方式三个方面有所不同。

1、静态脱敏与动态脱敏使用场景和用途的区别

静态脱敏适用于将数据抽取出生产环境脱敏后分发至测试、开发、培训、数据分析等场景。

原理是将数据抽取进行脱敏处理后，下发至脱敏库。开发、测试、培训、分析人员可以随意取用脱敏数据，并进行读写操作，脱敏后的数据与生产环境隔离，满足业务需要的同时保障生产数据的安全，静态脱敏可以概括为数据的“搬移并仿真替换”。

动态脱敏适用于不脱离生产环境，对敏感数据的查询和调用结果进行实时脱敏。

原理是将生产库返回的数据进行实时脱敏处理，例如应用需要呈现部分数据，但是又不希望应用账号可以看到全部数据；运维人员需要维护数据，但又不希望运维人员可以检索或导出真实数据，动态脱敏可以概括为“边脱敏，边使用”。

2、静态脱敏与动态脱敏的技术路线的区别

静态脱敏直接通过屏蔽、变形、替换、随机、格式保留加密（FPE）和强加密算法（如AES）等多种脱敏算法，针对不同数据类型进行数据掩码扰乱，并可将脱敏后的数据按用户需求，装载至不同环境中。静态脱敏可提供文件至文件，文件至数据库，数据库至数据库，数据库至文件等不同装载方式。导出的数据是以脱敏后的形式存储于外部存贮介质中，实际上已经改变了存储的数据内容。

动态脱敏通过准确的解析SQL语句匹配脱敏条件，例如：访问IP、MAC、数据库用户、客户端工具、操作系统用户、主机名、时间、影响行数等，在匹配成功后改写查询SQL或者拦截防护返回脱敏后的数据到应用端，从而实现敏感数据的脱敏。实际上存储于生产库的数据未发生任何变化。

3、静态脱敏与动态脱敏的部署方式的区别

静态脱敏可将脱敏设备部署于生产环境与测试、开发、共享环境之间，通过脱敏服务器实现静态数据抽取、脱敏、装载。

动态脱敏采用代理部署方式：物理旁路，逻辑串联。应用或者运维人员对数据库的访问必须都经过动态脱敏设备才能根据系统的规则对数据访问结果进行脱敏。

四. 数据脱敏的价值？

无论是静态脱敏还是动态脱敏其最终都是为了防止组织内部对隐私数据的滥用，防止隐私数据在未经脱敏的情况下从组织流出。满足组织既要保护隐私数据，同时又保持监管合规，满足合规性。

大数据时代的到来，颠覆了传统业态的运作模式，激发出新的生产潜能。数据成为重要的生产要素，是信息的载体，数据间的流动也潜藏着更高阶维度的价值信息。对于数据控制者和数据处理者而言，如何最大化数据流动的价值，是数据挖掘的初衷和意义。然而，一系列信息泄露事件的曝光，使得数据安全越来越受到广泛的关注。

数据脱敏（Data Masking），顾名思义，是屏蔽敏感数据，对某些敏感信息（比如，身份证号、手机号、卡号、客户姓名、客户地址、邮箱地址、薪资等等 ）通过脱敏规则进行数据的变形，实现隐私数据的可靠保护。业界常见的脱敏规则有，替换、重排、加密、截断、掩码，用户也可以根据期望的脱敏算法自定义脱敏规则。

通常，良好的数据脱敏实施，需要遵循如下两个原则，第一，尽可能地为脱敏后的应用，保留脱敏前的有意义信息；第二，最大程度地防止黑客进行破解。

数据脱敏分为静态数据脱敏和动态数据脱敏。静态数据脱敏，是数据的“搬移并仿真替换”，是将数据抽取进行脱敏处理后，下发给下游环节，随意取用和读写的，脱敏后数据与生产环境相隔离，满足业务需求的同时保障生产数据库的安全。动态数据脱敏，在访问敏感数据的同时实时进行脱敏处理，可以为不同角色、不同权限、不同数据类型执行不同的脱敏方案，从而确保返回的数据可用而安全。

GaussDB (DWS)的数据脱敏功能，摒弃业务应用层脱敏依赖性高、代价大等痛点，将数据脱敏内化为数据库产品自身的安全能力，提供了一套完整、安全、灵活、透明、友好的数据脱敏解决方案，属于动态数据脱敏。用户识别敏感字段后，基于目标字段，绑定内置脱敏函数，即可创建脱敏策略。脱敏策略（Redaction Policy）与表对象是一一对应的。一个脱敏策略包含表对象、生效条件、脱敏列-脱敏函数对三个关键要素，是该表对象上所有脱敏列的集合，不同字段可以根据数据特征采用不同的脱敏函数。当且仅当生效条件为真时，查询语句才会触发敏感数据的脱敏，而脱敏过程是内置在SQL引擎内部实现的，对生成环境用户是透明不可见的。

动态数据脱敏，是在查询语句执行过程中，根据生效条件是否满足，实现实时的脱敏处理。生效条件，通常是针对当前用户角色的判断。敏感数据的可见范围，即是针对不同用户预设的。系统管理员，具有最高权限，任何时刻对任何表的任何字段都可见。确定受限制用户角色，是创建脱敏策略的第一步。

敏感信息依赖于实际业务场景和安全维度，以自然人为例，用户个体的敏感字段包括：姓名、身份证号、手机号、邮箱地址等等；在银行系统，作为客户，可能还涉及银行卡号、过期时间、支付密码等等；在公司系统，作为员工，可能还涉及薪资、教育背景等；在医疗系统，作为患者，可能还涉及就诊信息等等。所以，识别和梳理具体业务场景的敏感字段，是创建脱敏策略的第二步。

产品内置一系列常见的脱敏函数接口，可以针对不同数据类型和数据特征，指定参数，从而达到不一样的脱敏效果。脱敏函数可采用如下三种内置接口，同时支持自定义脱敏函数。三种内置脱敏函数能够涵盖大部分场景的脱敏效果，不推荐使用自定义脱敏函数。

• MASK_NONE：不作脱敏处理，仅内部测试用。
• MASK_FULL：全脱敏成固定值。
• MASK_PARTIAL：使用指定的脱敏字符对脱敏范围内的内容做部分脱敏。

不同脱敏列可以采用不同的脱敏函数。比如，手机号通常显示后四位尾号，前面用"*"替换；金额统一显示为固定值0，等等。确定脱敏列需要绑定的脱敏函数，是创建脱敏策略的第三步。

以某公司员工表emp，表的属主用户alice以及用户matu、july为例，简单介绍数据脱敏的使用过程。其中，表emp包含员工的姓名、手机号、邮箱、发薪卡号、薪资等隐私数据，用户alice是人力资源经理，用户matu和july是普通职员。

假设表、用户及用户对表emp的查看权限均已就绪。

• （1）创建脱敏策略mask_emp，仅允许alice查看员工所有信息，matu和july对发薪卡号、薪资均不可见。字段card_no是数值类型，采用MASK_FULL全脱敏成固定值0；字段card_string是字符类型，采用MASK_PARTIAL按指定的输入输出格式对原始数据作部分脱敏；字段salary是数值类型，采用数字9部分脱敏倒数第二位前的所有数位值。

postgres=# CREATE REDACTION POLICY mask_emp ON emp WHEN (current_user !='alice')
ADD COLUMN card_no WITH mask_full(card_no),
ADD COLUMN card_string WITH mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12), 
ADD COLUMN salary WITH mask_partial(salary, '9', 1, length(salary) - 2);

切换到matu和july，查看员工表emp。

postgres=> SET ROLE matu PASSWORD 'Gauss@123';
postgres=> SELECT * FROM emp;
 id | name |  phone_no   | card_no |     card_string     |        email         |   salary   |      birthday       
----+------+-------------+---------+---------------------+----------------------+------------+---------------------
  1 | anny | 13420002340 |       0 | ####-####-####-1234 | smithWu@163.com      | 99999.9990 | 1999-10-02 00:00:00
  2 | bob  | 18299023211 |       0 | ####-####-####-3456 | 66allen_mm@qq.com    |  9999.9990 | 1989-12-12 00:00:00
  3 | cici | 15512231233 |         |                     | jonesishere@sina.com |            | 1992-11-06 00:00:00
(3 rows)
postgres=> SET ROLE july PASSWORD 'Gauss@123';
postgres=> SELECT * FROM emp;
 id | name |  phone_no   | card_no |     card_string     |        email         |   salary   |      birthday       
----+------+-------------+---------+---------------------+----------------------+------------+---------------------
  1 | anny | 13420002340 |       0 | ####-####-####-1234 | smithWu@163.com      | 99999.9990 | 1999-10-02 00:00:00
  2 | bob  | 18299023211 |       0 | ####-####-####-3456 | 66allen_mm@qq.com    |  9999.9990 | 1989-12-12 00:00:00
  3 | cici | 15512231233 |         |                     | jonesishere@sina.com |            | 1992-11-06 00:00:00
(3 rows)

• （2）由于工作调整，matu进入人力资源部参与公司招聘事宜，也对员工所有信息可见，修改策略生效条件。

postgres=> ALTER REDACTION POLICY mask_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));

切换到用户matu和july，重新查看员工表emp。

postgres=> SET ROLE matu PASSWORD 'Gauss@123';
postgres=> SELECT * FROM emp;
 id | name |  phone_no   |     card_no      |     card_string     |        email         |   salary   |      birthday       
----+------+-------------+------------------+---------------------+----------------------+------------+---------------------
  1 | anny | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | smithWu@163.com      | 10000.0000 | 1999-10-02 00:00:00
  2 | bob  | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | 66allen_mm@qq.com    |  9999.9900 | 1989-12-12 00:00:00
  3 | cici | 15512231233 |                  |                     | jonesishere@sina.com |            | 1992-11-06 00:00:00
(3 rows)
postgres=> SET ROLE july PASSWORD 'Gauss@123';
postgres=> SELECT * FROM emp;
 id | name |  phone_no   | card_no |     card_string     |        email         |   salary   |      birthday       
----+------+-------------+---------+---------------------+----------------------+------------+---------------------
  1 | anny | 13420002340 |       0 | ####-####-####-1234 | smithWu@163.com      | 99999.9990 | 1999-10-02 00:00:00
  2 | bob  | 18299023211 |       0 | ####-####-####-3456 | 66allen_mm@qq.com    |  9999.9990 | 1989-12-12 00:00:00
  3 | cici | 15512231233 |         |                     | jonesishere@sina.com |            | 1992-11-06 00:00:00
(3 rows)

• （3）员工信息phone_no、email和birthday也是隐私数据，更新脱敏策略mask_emp，新增三个脱敏列。

postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN phone_no WITH mask_partial(phone_no, '*', 4);
postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN email WITH mask_partial(email, '*', 1, position('@' in email));
postgres=> ALTER REDACTION POLICY mask_emp ON emp ADD COLUMN birthday WITH mask_full(birthday);

切换到用户july，查看员工表emp。

postgres=> SET ROLE july PASSWORD 'Gauss@123';
postgres=> SELECT * FROM emp;
 id | name |  phone_no   | card_no |     card_string     |        email         |   salary   |      birthday       
----+------+-------------+---------+---------------------+----------------------+------------+---------------------
  1 | anny | 134******** |       0 | ####-####-####-1234 | ********163.com      | 99999.9990 | 1970-01-01 00:00:00
  2 | bob  | 182******** |       0 | ####-####-####-3456 | ***********qq.com    |  9999.9990 | 1970-01-01 00:00:00
  3 | cici | 155******** |         |                     | ************sina.com |            | 1970-01-01 00:00:00
(3 rows)

• （4）考虑用户交互的友好性，GaussDB (DWS) 提供系统视图redaction_policies和redaction_columns，方便用户直接查看更多脱敏信息。

postgres=> SELECT * FROM redaction_policies;
 object_schema | object_owner | object_name | policy_name |            expression             | enable | policy_description 
---------------+--------------+-------------+-------------+-----------------------------------+--------+--------------------
 public        | alice        | emp         | mask_emp    | ("current_user"()='july'::name) | t      | 
(1 row)
postgres=> SELECT object_name, column_name, function_info FROM redaction_columns;
 object_name | column_name |                                             function_info                                             
-------------+-------------+-------------------------------------------------------------------------------------------------------
 emp         | card_no     | mask_full(card_no)
 emp         | card_string | mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV'::text, 'VVVV-VVVV-VVVV-VVVV'::text, '#'::text, 1, 12)
 emp         | email       | mask_partial(email, '*'::text, 1, "position"(email, '@'::text))
 emp         | salary      | mask_partial(salary, '9'::text, 1, (length((salary)::text) - 2))
 emp         | birthday    | mask_full(birthday)
 emp         | phone_no    | mask_partial(phone_no, '*'::text, 4)
(6 rows)

• （5）突然某一天，公司内部可共享员工信息时，直接删除表emp的脱敏策略mask_emp即可。

postgres=> DROP REDACTION POLICY mask_emp ON emp;

更多用法详情，请参考GaussDB (DWS) 8.1.1产品文档。

GaussDB (DWS)数据脱敏功能，基于SQL引擎既有的实现框架，在受限用户执行查询语句过程中，实现外部不感知的实时脱敏处理。关于其内部实现，如上图所示。我们将脱敏策略（Redaction Policy）视为表对象上绑定的规则，在优化器查询重写阶段，遍历Query Tree中TargetList的每个TargetEntry，如若涉及基表的某个脱敏列，且当前脱敏规则生效（即满足脱敏策略的生效条件且enable开启状态），则断定此TargetEntry中涉及要脱敏的Var对象，此时，遍历脱敏列系统表pg_redaction_column，查找到对应脱敏列绑定的脱敏函数，将其替换成对应的FuncExpr即可。经过上述对Query Tree的重写处理，优化器会自动生成新的执行计划，执行器遵照新的计划执行，查询结果将对敏感数据做脱敏处理。

带有数据脱敏的语句执行，相较于原始语句，增加了数据脱敏的逻辑处理，势必会给查询带来额外的开销。这部分开销，主要受表的数据规模、查询目标列涉及的脱敏列数、脱敏列采用的脱敏函数三方面因素影响。

针对简单查询语句，以tpch表customer为例，针对上述因素展开测试，如下图所示。

图(a)、(b)中基表customer根据字段类型和特征，既有采用MASK_FULL脱敏函数的，也有采用MASK_PARTIAL脱敏函数的。MASK_FULL对于任何长度和类型的原始数据，均只脱敏成固定值，所以，输出结果相较于原始数据，差异很大。图(a)显示不同数据规模下，脱敏和非脱敏场景简单查询语句的执行耗时。实心图标为非脱敏场景，空心图标为被限制用户，即脱敏场景。

可见，数据规模越大，带有脱敏的查询耗时与原始语句差异越大。图(b)显示10x数据规模下查询涉及脱敏列数不同对于语句执行性能的影响。涉及1列脱敏列时，带有脱敏的查询比原始语句慢，追溯发现，此列采用的是MASK_PARTIAL部分脱敏函数，查询结果只是改变了结果的格式，结果内容的长度并未变化，符合“带有脱敏的语句执行会有相应的性能劣化”的理论猜想。随着查询涉及脱敏列数的增加，我们发现一个奇怪的现象，脱敏场景反倒比原始语句执行更快。进一步追溯多列场景下脱敏列关联的脱敏函数，发现，正是因为存在使用MASK_FULL全脱敏函数的脱敏列，导致输出结果集部分相比原始数据节省很多时间开销，从而多列查询下带有数据脱敏的简单查询反倒提速不少。

为了佐证上述猜测，我们调整脱敏函数，所有脱敏列均采用MASK_PARTIAL对原始数据做部分脱敏，从而能够在脱敏结果上保留原始数据的外部可读性。于是，如图(c)所示，当脱敏列均关联部分脱敏函数时，带有数据脱敏的语句比原始语句劣化10%左右，理论上讲，这种劣化是在可接受范围的。上述测试仅针对简单的查询语句，当语句复杂到带有聚集函数或复杂表达式运算时，可能这种性能劣化会更明显。

GaussDB (DWS)产品数据脱敏功能，是数据库产品内化和夯实数据安全能力的重要技术突破，主要涵盖以下三个方面：

1. 一套简单、易用的数据脱敏策略语法；
2. 一系列可覆盖常见隐私数据脱敏效果的、灵活配置的内置脱敏函数；
3. 一个完备、便捷的脱敏策略应用方案，使得原始语句在执行过程中可以实时、透明、高效地实现脱敏。

总而言之，此数据脱敏功能可以充分满足客户业务场景的数据脱敏诉求，支持常见隐私数据的脱敏效果，实现敏感数据的可靠保护。

点击关注，第一时间了解华为云新鲜技术~

“ 今天和大家聊聊在数据工作中的常见场景：脱敏。”

数据安全，一向是我们做数据的同学所必须关注的。我们之前分享过《数据安全治理》、《个保法施行的影响》、《联邦学习》等文章。今天我们聊一聊关于数据的脱敏。

一、数据脱敏的基础概念

所谓的数据脱敏，是指在不影响数据分析结果的准确性前提下，对原始数据中的敏感字段进行处理，从而降低数据敏感度和减少个人隐私风险的技术措施。

具体效果上，主要是去标识化和匿名化。

• 去标识化：是指通过对个人信息的技术处理，使得在不借助额外信息的情况下，无法识别个人信息主体
• 匿名化：是指通过对个人信息的技术处理，使得个人信息主体无法被识别或关联，且处理后的信息不能被还原的过程

二、常见的脱敏场景

企业内部常见的数据脱敏场景主要包括数据报告脱敏、应用系统脱敏、数据库脱敏等。

（1）静态（数据文件）脱敏

适用于批量进行脱敏数据。比如用于模型训练的测试数据，再比如数据的导出用于离线数据分析。

（2）动态（数据库）脱敏

动态数据脱敏主要指的是数据库脱敏。具体而言，指的是比如研发人员的开发调试、DBA日常数据管理、运维人员基础运维等。

（3）应用系统脱敏

应用系统脱敏主要指的是前端页面的敏感数据脱敏，以及数据类型接口API的透出数据脱敏。

（4）数据报告及数据产品脱敏

这类场景主要包括内部的数据监控类产品或者看板、对外服务的数据类产品、基于数据分析的报告，比如业务汇报、项目复盘

三、常用的脱敏技术方法

常见的数据脱敏技术主要包括以下几类。

（1）统计技术

统计技术是一种对数据集进行去标识化的常用方法，主要包括数据抽样和数据聚合两种技术。

• 数据抽样：是通过选取数据集中有代表性的?集来对原始数据集进?分析和评估的，它是提升去标识化技术有效性的重要?法。
• 数据聚合：作为?系列统计技术（如求和、计数、平均、最?值与最?值）的集合，应?于微数据中的属性时，产?的结果能够代表原始数据集中的所有记录。

（2）密码技术

密码技术是去标识化或提升去标识化技术有效性的常法，采?不同类型的加密算法所能达到不同的脱敏效果。

• 确定性加密：?种?随机对称加密，常见对id类数据进?处理，可在必要时对密?进?解密还原为原id，但需要对密钥进?妥善保护。
• 不可逆加密：通常散列（hash）函数对数据进?处理，常见于对id类数据进?处理，不可以直接解密，需保存映射关系，同时因为hash函数特性，会存在数据碰撞的问题，?法简单，不?担?密钥保护。
• 同态加密：?密?同态算法，其特点是密?运算的结果解密之后和明?运算相同，因此常见于对数值类字段进?处理，但性能原因，?前未?范围使?。

（3）抑制技术

抑制技术即对不满?隐私保护的数据项删除或屏蔽，不进?发布。

• 屏蔽：是指对属性值进行屏蔽，最常见的脱敏方式，如对手机号、身份证进行打*号处理，或对于地址采取截断的方式；
• 局部抑制：是指删除特定的属性值（列）的处理方式，删除非必要的数据字段；
• 记录抑制：是指删除特定的记录（行）的处理方式，删除非必要的数据记录。

（4）假名化技术

假名化技术是?种使?假名替换直接标识（或其它敏感标识符）的去标识化技术。假名化技术为每?个?信息主体创建唯?的标识符，以取代原来的直接标识或敏感标识符。

• 可以独成随机值对原始ID进?对应，并保存映射关系表，同时对映射关系表的访问进?严格控制；
• 同样可以采?加密的?式?产假名，但需为妥善保存解密密钥；

该技术?泛使?在数据使数量多且相互独?的情况，?如开放平台场景的openid，同样?个?户，不同开发者获取的openid不同。

（5）泛化技术

泛化技术是指?种降低数据集中所选属性粒度的去标识化技术，对数据进?更概括、抽象的描述。泛化技术实现简单，能保护记录级数据的真实性，常见于数据产品或数据报告中。

取整：涉及到为所选的属性选定?个取整基数，?如向上或向下取证，产出结果100、500、1k、10k

顶层与底层编码技术：使?表?顶层（或底层）的阈值替换?于（或低于）该阈值的值，产出结果为 “?于X”或 “低于X”

（6）随机化技术

随机化技术作为?种去标识化技术类别，指通过随机化修改属性的值，使得随机化处理后的值区别于原来的真实值。该过程降低了攻击者从同?数据记录中根据其它属性值推导出某?属性值的能?，但会影响结果数据的真实性，常见于?产测试数据。

关于数据脱敏，今天主要就分享这些内容，欢迎朋友们继续关注。

根据百度词条的解释，数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一，数据库安全技术主要包括：数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。”

随着信息时代的发展，我们对数据信息的安全要求越来越重视，比如对非生产环境下的敏感数据的脱敏保护。在金融、运营商、政府、能源等部门，非生产环境下数据脱敏已列入监管部门的法规要求。非生产环境数据多用于开发、测试、培训以及第三方数据分析、挖掘，如果不能有效实施敏感数据保护，极易造成敏感数据的泄露。所以，保证非生产数据的安全已经成为一个重要的课题，要求我们能够通过对敏感信息进行脱敏、变形，实现有效的数据保护。

数据脱敏工具应该具有对多种异构数据源的支持，从而将一个脱敏规则应用于不同的数据源，比如针对“客户名称”字段的修改，脱敏规则基本一致，所以应该可以在 Excel、TXT、Oracle、MS SQLServer、MySQL、Hadoop 等数据源上直接引用。另外，工具还应支持将脱敏数据完全不落地分发，提供文件到文件、文件到数据库、数据库到数据库、数据库到文件等方式，并且不需要在生产系统或本地安装任何客户端。

本文介绍的脱敏数据报表查询将利用润乾集算器编写 SPL 脚本，对敏感信息字段 ( 如: 姓名、证件号、银行账户、住址、电话号码、企业名称、工商注册号、纳税人识别号) 等通过预定义的脱敏规则进行数据脱敏、变形，实现敏感隐私数据的保护。

润乾集算器能使脱敏工作变得的简单易行，同时可以减少大量重复性工作。通过集算器 SPL 脚本实现的脱敏数据，可直接作为报表数据集进行查询分析，也可以作为开发、测试和其它非生产环境或外包环境下的真实数据集使用。

数据脱敏不仅要执行数据漂白，抹去数据中的敏感内容，同时也需要保持原有的数据特征、业务规则和数据关联性，保证开发、测试、培训以及大数据类业务不会受到脱敏的影响，达成脱敏前后的数据一致性和有效性：

l 保持原有数据特征

数据脱敏前后必须保证数据特征的保持，例如：身份证号码由十七位数字本体码和一位校验码组成，分别为区域地址码（6 位）、出生日期（8 位）、顺序码（3 位）和校验码（1 位）。那么身份证号码的脱敏规就需要保证脱敏后依旧保持这些特征信息。

l 保持数据之间的一致性

在不同业务中，数据和数据之间具有一定的关联性。例如：出生年月或年龄和出生日期之间的关系。同样，身份证信息脱敏后仍需要保证出生年月字段和身份证中包含的出生日期之间的一致性。

l 保持业务规则的关联性

保持数据业务规则的关联性是指数据脱敏时数据关联性以及业务语义等保持不变，其中数据关联性包括：主、外键关联性、关联字段的业务语义关联性等。特别是高度敏感的账户类主体数据往往会贯穿主体的所有关系和行为信息，因此需要特别注意保证所有相关主体信息的一致性。

l 多次脱敏之间的数据一致性

相同的数据进行多次脱敏，或者在不同的测试系统进行脱敏，需要确保每次脱敏的数据始终保持一致性，只有这样才能保障业务系统数据变更的持续一致性以及广义业务的持续一致性。

一般常见的数据脱敏场景，是将生产数据或是生产数据文件按照脱敏规则，将数据不落地脱敏至测试数据库或是测试数据文件中，具体如下所示：

使用集算器的 SPL 可以按照业务场景要求自行定义和编写脱敏规则，比如针对上面的人员信息：姓名、身份证号、地址、电话号码、卡号等进行不落地脱敏，满足数据脱敏需要。

集算器是一个无框架，可快速部署开发的数据计算中间件工具，能够直接运行编写好的 SPL 数据脱敏脚本即时进行数据脱敏，支持各种常见的数据脱敏的处理方式，包括数据替换、无效化、随机化、偏移和取整、掩码屏蔽、灵活编码等，本文介绍的数据脱敏方法都可以在实际应用中混合替换使用。

本文中应用场景的数据脱敏都是基于下表数据内容进行的，数据存储在“数据脱敏验证表.txt”文件中。

数据脱敏要求：用设置的固定虚构值替换真值。例如将手机号码统一替换为 13800013800。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入“数据脱敏验证表”的文本数据。手机号码脱敏前的显示值如下：

A2：将手机号码统一数据替换。直接使用run()函数对 mobile 手机号码字段数据进行赋值替换为13800013800。数据替换后，手机号码脱敏后的显示值如下：

数据脱敏要求：通过对数据值得截断、加密、隐藏等方式使敏感数据脱敏，使其不再具有利用价值，例如将地址以 ****** 代替真值。数据无效化与数据替换所达成的效果基本类似。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入“数据脱敏验证表”的文本数据。地址脱敏前显示值如下：

A2：将地址进行数据隐藏式的无效化脱敏。直接使用run()函数对 address 地址字段数据进行无效化的 ****** 处理。数据无效化后，地址脱敏后的显示值如下：

A3：将地址进行数据截断式的无效化脱敏。使用left()函数对 address 地址源字符串的左边三位字串加上 ****** 的截断无效化处理。截断无效化的地址脱敏后显示值如下：

数据脱敏要求：采用随机数据代替真值，保持替换值的随机性以模拟样本的真实性。例如用随机生成的姓和名代替真值。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入外部姓名字典表，用于随机化替换姓名真值。此处需特别注意一下，由于“姓氏”和“名字”文本数据都是单列数据表，在使用import()函数时需要增加 @i 选项，@i 表示文本数据只有1列时返回成序列，在单元格 A3 中可以直接位置获取随机值。

A2：导入“数据脱敏验证表”的文本数据。姓名脱敏前显示值如下：

A3：将姓名进行随机化脱敏。直接使用run()函数对 name 姓名进行随机化，使用rand()函数从“姓氏.txt”和“名字.txt”外部字典表随机化组合生成姓名。随机化后姓名的显示值如下：

【注意】这个例子中我们针对数据脱敏引入了外部字典表，实际情况中可以根据数据脱敏要求，随时引入任意外部字典表，通过数据的随机化组合，实现替换真值数据的脱敏处理。

数据脱敏要求：通过随机移位改变数字数据，例如日期 2018-01-02 8:12:25 变为 2018-01-02 8:00:00，偏移取整在保持了数据的安全性的同时保证了范围的大致真实性，此项功能在大数据利用环境中具有重大价值。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入“数据脱敏验证表”的文本数据。操作日期脱敏前显示值如下：

A2：将操作日期进行时间的偏移和取整脱敏。使用使用string()函数按照偏移和取整规则格式化成“yyyy-MM-dd HH:00:00”格式，操作时间脱敏后的显示值如下：

【注意】脱敏后的日期时间保持了原有的数据特征，方便脱敏数据的后续使用。

数据脱敏要求：掩码屏蔽是针对账户类数据的部分信息进行脱敏时的有力工具，比如银行卡号或是身份证号的脱敏。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入“数据脱敏验证表”的文本数据。身份证号脱敏前显示值如下：

A2：将身份证号的出生日期进行掩码屏蔽脱敏。使用left()函数截取身份证号的左边 6 位 + 字符串 ********+right()函数截取身份证号右边 4 位替换源身份证字符串，身份证号码脱敏后的显示值如下：

数据脱敏要求：在需要特殊脱敏规则时，可执行灵活编码以满足各种可能的脱敏规则。比如用固定字母和固定位数的数字替代合同编号真值。

使用集算器 SPL 编码实现的脚本，如下：

A1：导入“数据脱敏验证表”的文本数据。合同编号脱敏前显示值如下：

A2：将合同编号进行自定义编码脱敏。自定义编码规则：4 位固定码 + 当前年份 + 源目标字符串 4 位号码 +9 位数值组成，使用的函数已有介绍，不再赘述，合同编号脱敏后显示值如下：

集算器 SPL 支持文件到文件、文件到数据库、数据库到数据库、数据库到文件的脱敏数据分发。下面分别进行具体说明：

使用集算器 SPL 编码实现的文本分发到文本的脚本如下：

A1-B1：引入外部字典表“姓氏”和“名字”的文本数据，用于随机组合生成姓名信息。

A2：使用游标导入大数据量的“数据脱敏验证表”文本数据。

A3：按照脱敏规则进行数据表脱敏。

A4：直接将脱敏的数据导出到文本文件。使用export()函数导出脱敏数据，其中，其中 @t 指定将第一行记录作为字段名, 如果不使用 @t 选项就会以 _1，_2,…作为字段名，@a表示追加写, 不使用 @a 表示覆盖，分发到文本的脱敏结果如下：

【注意】集算器 SPL 的文件处理能力还支持导入、导出 xls、xlsx、csv 等多种类型文件。

使用集算器 SPL 编码实现的文本分发到数据库（以 MySQL 为例）的脚本如下：

A1-A3：同上。

A4：连接 MySQL 数据源。使用connect()进行 MySQL 数据库的连接。如果用鼠标点击 A4 单元格，可以直接查看 MySQL 数据库的连接信息。具体查看数据库配置教程相关章节文档配置说明。

A5：更新 MySQL 数据库中“personinfo”库表的数据。使用update()将单元格 A3 的游标数据更新到 MySQL 数据库“personinfo”库表中。使用数据库工具查看结果如下

A6：使用close()函数关闭 A4 建立起的 MySQL 数据源连接。

使用集算器 SPL 编码实现的数据库分发到数据库的脚本如下（均以 MySQL 为例）：

A1：同上。

A2：连接 MySQL 数据源。

A3：游标读取 MySQL 中表“personinfo_copy”的待脱敏数据。该表的数据如下：

A4：同上。

A5：更新 MySQL 数据库中“personinfo_copy_test”库表的数据。使用update()将单元格 A3 的游标数据更新到 MySQL 数据库的“personinfo_copy_test”库表中。结果如下：

A6：使用close()函数关闭 A2 建立起的 MySQL 数据源连接。

使用集算器 SPL 编码实现的数据库（以 MySQL 为例）分发到文本的脚本如下：

A1-A4：同上。

A5：直接将脱敏的数据库（MySQL）数据分发到文本文件。分发到文本的脱敏结果同上。

A6：使用close()函数关闭 A2 建立起的 MySQL 数据源连接。

下面我们就结合上面介绍的数据脱敏方法，具体实现一个可以动态配置是否脱敏数据的报表查询实例，大致流程如下：

利用上面已有的"数据脱敏验证表.txt" 文本数据，实现脱敏数据报表查询，具体脚本如下：

A1-B1：引入外部字典表“姓氏”和“名字”的文本数据，用于随机组合生成姓名信息。

A2：定义一个子程序。使用func函数定义一个通用的数据脱敏规则处理子程序，该子程序主要是调用配置文件中的数据脱敏规则进行数据脱敏。不同数据字段可以根据自身特点和业务要求进行规则复用。关于子程序的内容可以参考：集算器 -> 教程 -> 高级代码 ->子程序文档说明。

B3：读取数据脱敏规则配置文件信息。使用property()函数从“数据脱敏规则配置.ini”属性文件中读取 type 属性值。

B4-B5：使用动态解析并计算规则配置文件中的规则，实现对应字段的数据脱敏处理。其中，子程序中使用eval()函数动态解析并计算表达式，实现动态解析并替换脱敏规则配置文件（*.ini）中的 "?" 值，增加一个 type 值判断，将一般 type 中的 "?" 替换为调用 func 子程序主格的位置值，对引入外部数据字典表的 tpye2 规则，单独判断替换 "?" 值为外部字典所在单元格值，最终计算替换的表达式并执行对应字段的数据脱敏。

B6:使用宏动态计算表达式并返回运算结果，使用return函数将从属性配置文件中读取的 type 属性值通过“${}”宏替换并返回运算结果给被 B9 单元格调用的程序中。

A7：游标获取未脱敏的源端生产数据。

A8：通过传递的网格参数 type（type=0:不脱敏）值判断是否对数据脱敏，如果脱敏，则执行 B9 单元格的源端生产数据的脱敏处理。

B9：按照脱敏规则进行数据表脱敏，直接调用 A2 主格子程序 func 进行数据脱敏。

A10：根据 type 值返回对应的脱敏或未脱敏数据。

接下来，需要在集算器设计器的功能菜单“程序 -> 网格参数”中设置一个参数“type”，用于接收报表参数传递进行是否脱敏的数据权限控制。

至此，集算器的 SPL 脚本编写和设置完成，下一步进行“数据脱敏规则配置.ini”文件的新建设置。

文件“数据脱敏规则配置.ini”为集算器 SPL 脚本提供了对数据字段的脱敏规则配置，从而实现脱敏规则与脚本分离的设计，可以在不修改脚本的情况下自定义脱敏规则。当然，这个配置文件也可以数存储在数据库中，提供全局的脱敏规则配置管理。该配置文件的内容如下：

配置文件说明：#自定义配置脱敏规则，使用 eval() 函数实现动态解析替换解析 "?"，通常 type 中的 "?" 是指固定调用 func 子程序的主格，这里 tpye2 规则特殊，需要单独判断替换 "?"。

【注意】这里仅是提供一种脱敏规则的配置思路，目的是可以最大限度的复用和灵活调用，相似的数据字段就不需要重复定义和编写脱敏规则了。实际应用中，程序员们可以根据需求自定义配置。

使用最新版本的润乾报表 V2018 版本开发一张报表模板，并设置报表是否脱敏参数“type”（与集算器 SPL 脚本中的网格参数对应使用）。

设置集算器 SPL 脚本为报表的数据集“ds1”，选中对应的 dfx 脚本，并配置 type 参数表达式，具体如下：

开发的报表模板“报表数据脱敏.rpx”如下：

【注意】这里面调用的集算器数据集返回的是游标，需要在报表属性 -> 常规 设置集算器数据集为大数据集，并且该功能需要报表产品包含集算器授权。

直接在报表设计器中启动 web 服务，使用浏览器浏览报表，当设置参数 type 值为“0”不脱敏时，报表展示数据如下：

当参数 type 设置非“0”值时，报表展示数据如下：

这个脱敏数据报表查询实例有以下四个特点：

l 1）直接对源数据脱敏后在报表 WEB 端进行数据查询和展示。

没有按常规数据脱敏的方式，先将脱敏数据进行分发入库或入文件，而是直接将数据使用集算器 SPL 脚本进行脱敏，配合报表的大数据集异步数据加载实现了大数据的即时脱敏数据查询展示。免去源数据脱敏 -> 目标入库 -> 数据展示的目标入库步骤。

l 2）免去新建数据脱敏库步骤，减少脱敏工作量。

为了应对一些老项目或特殊情况，比如脱敏的数据表都是明文显示，但是不能分发或新建脱敏后的数据库表，通过对明文数据直接抽取加密，免去新建脱密库步骤，减少整体脱敏工作量。

l 3）自定义配置数据脱敏规则。

可以灵活配置规则文件，满足不同的规则配置需求。

l 4）动态控制数据是否开启脱敏权限。

可以根据平台用户查看数据的权限，动态的传递参数值控制是否对数据进行脱敏显示，一方面防止数据的泄密，从底层保证数据安全，另一方面也为高权限客户提供查看敏感数据的途径。

数据脱敏是数据安全领域落地场景较为成熟的技术手段，在数据深层次、大范围的共享开放的今天，数据脱敏在不影响数据使用的前提下保护敏感隐私数据，已成为数据安全建设重要内容。

具体来说，数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。

数据脱敏发展到现在，经历了三个阶段：

人工脱敏阶段：多为SQL脚本方式，在ETL处理过程中进行脱敏，该方式工作量大、数据处理效率低，同时存在数据质量差、无法保证数据结构的完整性、数据间的关联性。

平台脱敏阶段： 融合了敏感数据自动发现、系统流程化脱敏、支持丰富数据源、脱敏算法库充足、敏感类型丰富等功能，从而减轻人工成本的同时提升效率，保证数据脱敏的基本诉求。

自动脱敏阶段：通过应用机器学习等技术，结合各类数据分类分级规则及已实际使用的数据脱敏策略及规则，实现自动化实时敏感数据发现、自动化脱敏规则匹配等智能化数据脱敏的结果。同时，具备分布式等多种部署支持，智能性能分析，自动化调优等能力。

当前，数据脱敏需要具备的技术能力主要有以下几类：

1、高仿真能力：

保持数据原始业务特征

保持数据之间的关联性

保持数据之间逻辑一致性

业务依赖数据对象同步

2、丰富数据源支持

关系型数据库支持

大数据平台支持

特殊文件类型支持

消息列队支持

3、内置丰富脱敏规则

支持多种数据脱敏算法

支持组合脱敏、自定义分段规则

具备细粒度数据处理能力

4、高处理效率

单台设备性能最大化

具备增量脱敏能力

支持分布式部署

数据脱敏可分为两大类：静态数据脱敏和动态数据脱敏。静态数据脱敏通常用于非实时场景，比如将生产环境中的数据脱敏用于测试环境。动态数据脱敏通常用于生产环境等实时场景，在应用或平台用户访问敏感数据的同时进行脱敏，用于解决根据不同情况对统一敏感数据读取时需要进行不同级别、类型脱敏的场景，适用于对生产数据共享或时效性很高的数据访问场景等，实现对生产数据库中的敏感数据进行透明、实时脱敏。

在设定具体场景下数据脱敏策略时应充分考虑数据脱敏后数据自身可用性及数据保密性寻求两者间的平衡。数据脱敏策略的选择如下显示。数据脱敏的目标包括：

避免攻击者识别出原始个人信息主体；

控制重标识的风险，确保重标识风险不会增加；

在控制重标识风险的前提下，确保脱敏后的数据集尽量满足其预期目的；

选择合适的数据处理方式保证信息攻击成本不足以支撑攻击动机。

1、敏感数据识别，对生产系统中敏感数据的识别，主要包括：

存储位置：明确敏感数据所在的数据库、表、字段（列）；

数据分类、分级：明确敏感数据所属类别及敏感级别。

2、策略选择、算法配置，脱敏算法配置主要包括：数据脱敏后保持原始特征的分析、数据脱敏算法的选择和数据脱敏算法参数配置。

保持原始数据的格式、类型；

保持原有数据之间的依存关系；

保持引用完整性、统计特性、频率分布、唯一性、稳定性。配置需要脱敏的目标（数据库名/表名/字段名）以及适当的脱敏算法参数，根据业务需求完成其他算法的参数配置。

3、数据脱敏任务执行阶段，按照不同需求选择，动态脱敏处理步骤和静态脱敏处理步骤：

动态脱敏处理步骤：

协议解析：解析用户、应用访问大数据组件网络流量；

语法解析：对访问大数据组件的语句进行语法分析；
脱敏规则匹配：根据用户身份信息及要访问的数据；

下发脱敏任务：由脱敏引擎调度脱敏任务；
脱敏结果输出：将脱敏后的数据输出，保证原始数据的不可见。

静态脱敏处理步骤：

数据选择/策略配置：选择待脱敏的数据库及表，配置脱敏策略及脱敏算法，生成脱敏任务；

执行脱敏处理：对不同类型数据进行处理，将数据中的敏感信息进行删除或隐藏；

将脱敏后的数据按用户需求，装载至不同环境中，包括文件至文件，文件至数据库，数据库至数据库，数据库至文件等多种装载方式。

1.开发测试场景：

开发测试场景中，如银行、证券等金融行业业务系统中含有姓名、身份、账号等敏感信息，由于开发测试需要使用仿真的数据，因此需通过脱敏手段保证敏感数据不被泄露。

场景特点：

数据库类型多，系统体系架构复杂，跨系统、跨平台测试数据难以获取。

开发测试场景需高度模拟生产环境，对脱敏后数据与业务的一致性有严格要求。

生产环境与开发测试环境互相隔离，彼此无法互相访问。

部分行业如银行金融机构日新增数据量较大，无法定期对全量数据进行脱敏，要求数据脱敏系统具备增量脱敏能力。

要求具备多种脱敏算法。如在金融机构脱敏场景中，需保持脱敏后不同字段之间的数据计算关系，如“2+3=5” 脱敏后需要保持等号左边的数值等于右边。

关键能力：

支持主流关系型数据库、大数据平台、格式化文本文件、Oracle dump 文件。

支持通过ftp文件服务器的连接，对隔离的开发测试环境进行中转导入。

支持对于Oracle dmp文件进行直接解析，并进行脱敏处理。

数据脱敏根据实际业务需求提供脱敏数据，可通过数据子集、黑名单、白名单等方式控制数据脱敏范围。

支持对生产数据全量和增量的方式脱敏，可设置脱敏的作业的调度周期，并对作业过程进行监控，支持脱敏前后的数据在线比对功能。

提供多种数据脱敏算法。

2.教学培训场景：

教学培训场景，即通过对数据进行统计分析，以用于科学研究。该场景下需要保证数据特征，脱敏后保证科学研究所必须的内容。

场景特点：

为保证获取的数据可以满足科学研究，保留数据的真实有效性。

脱敏后的数据需要有教学培训的价值，数据的业务特征不能丧失。

脱敏后的数据需要保持其完整性，保证其长度不变、数据内涵的不丢失

关键能力：

内置丰富的数据脱敏算法及数据分段脱敏的能力，可适配不同的数据分析场景，从而在保证数据脱敏或降敏的前提下，安全地进行各种数据分析。

保证主外键一致、业务关联一致、有依赖字段的敏感信息脱敏一致、多次脱敏结果保持一致等，整体保证脱敏前后一致性，保持数据间的逻辑关系。

保持数据字段、数据对象从源到目标的完整迁移。

3.分析挖掘场景

数据分析的有效性往往依赖于基础数据的质量，基础数据的可用性直接影响分析结果和企业决策。在涉及到大数据分析应用的领域，企业需要在保证数据安全及合规的前提下，依旧能够保有数据的可用性及可挖掘分析的价值。

场景特点：

数据脱敏时应保持与原数据高仿真，不破坏数据间的关联关系，确保数据分析结果仍然具有指导性。

大数据分析平台中包括海量的用户隐私和敏感数据，针对大数据环境进行数据脱敏，数据结构复杂，包括结构化、非结构化数据等，脱敏操作复杂。

特定场景下需对脱敏数据进行复敏，例如银行通过对脱敏后的转账记录、贷款记录、还款记录等进行分析，评估出个性信用等级，最后将结果回溯到真实银行客户。

关键能力：

内置丰富的数据脱敏算法及数据分段脱敏的能力，可适配不同的数据分析场景，从而在保证数据脱敏或降敏的前提下，安全地进行各种数据分析。

保证主外键一致、业务关联一致、有依赖字段的敏感信息脱敏一致、多次脱敏结果保持一致等，整体保证脱敏前后一致性，保持数据间的逻辑关系。

支持HDFS、Hive、Impala、ODPS、Teradata、Greenplum、MongoDB、FusionInsight等大数据敏感源。

支持数据脱敏复敏，具备复敏权限的用户才能进行此操作，充分保证安全性。

4.数据上报场景

数据上报场景很可能涉及隐私敏感数据信息，在上报过程中对敏感数据需要进行有效保护。

场景特点：

数据脱敏能够有效防止敏感数据泄漏，但是像医疗、金融、政府等具有强监管机构的行业，需要进行数据上报的数据流动场景。

数据上报过程中的脱敏数据要保持与原数据高仿真，不破坏数据间的关联关系，确保数据上报的内容仍然具有其业务特征。

部分行业的数据上报需对脱敏数据进行复敏，例如政务行业、金融行业有强监管的需求。

关键能力：

保证主外键一致、业务关联一致、有依赖字段的敏感信息脱敏一致、多次脱敏结果保持一致等，整体保证脱敏前后一致性，保持数据间的逻辑关系。

内置数据水印及溯源功能，用户可自定义水印内容，同时通过算法保证水印内容的抗破坏性，从而保证在数据被分享给第三方后，可通过系统进行溯源及追责。

支持数据脱敏复敏，具备复敏权限的用户才能进行此操作，充分保证安全性。

5.共享交换场景

现代企业对外合作日益增多，数据交换愈发频繁，因此需要合理管控数据外发，当敏感数据外发至低安全区域时，通过对数据进行脱敏变形，避免隐私数据泄露。

场景特点：

数据共享场景中，特定需求下需要保留部分敏感数据字段，但对其他隐私数据可以进行遮蔽、仿真等操作。

作为数据提供方，需要提供溯源机制，当发生数据泄露的时候，可以确定数据泄露方，便于溯源追责。

关键能力：

预设丰富的敏感对象，包括个人隐私、金融财务、商业机密、医疗数据、相关证件等，在进行数据脱敏时，将会对设定的敏感对象按照规则进行脱敏，且可根据实际需求自定义敏感对象，完善敏感对象库。

对于脱敏源中存在的脏数据（不符合敏感对象业务特征的数据），系统同样会对这部分数据进行变形处理，以避免隐形敏感数据泄露。

内置数据水印及溯源功能，用户可自定义水印内容，同时通过算法保证水印内容的抗破坏性，从而保证在数据被分享给第三方后，可通过系统进行溯源及追责。

6.业务查询场景

在业务系统对外提供服务时，常常面临客户群体通过账号即可访问真实数据的情况，一旦账户被仿冒登陆，显示真实信息、未对关键信息进行脱敏，会加大数据泄露的现象。

场景特点：

业务访问隐私化处理，在医疗、金融的典型行业中，业务系统的访问常常需要直接去隐私化展示信息。

防止批量脱库数据泄露，黑客会通过访问前端应用程序过程中植入漏洞窃取数据，因此在访问过程中做到敏感数据及时脱敏，可以大大减少批量数据泄露问题。

关键能力：

无需对应用系统进行改造、无需修改数据库及存储数据，即可实现数据动态脱敏；

能够精确识别业务系统三层的用户身份，针对不同的身份采用不同的动态脱敏策略，对不同权限的用户可分别返回真实数据、部分遮盖、全部遮盖等脱敏结果。

支持的灵活脱敏策略配置

7.运维管理场景

运维管理场景下往往是需要对于系统运维人员的操作及管理进行全面审计及访问控制，从而达到数据在维护时的安全呈现。

场景特点：

运维人员拥有高权限账户，如果未加管控，意味着可以任意访问数据，也是批量数据泄露的主要来源之一。

从职责分离的原则上，实现既允许运维人员访问业务生产数据库又不能让他们看到核心敏感数据，对于隐私保护同时还需要有预防性（事前）的技术能力。

关键能力：

准入控制：支持多维身份管理；支持对运维工具或客户端应用程序进行签名登陆验证，防止恶意和仿冒工具/程序登陆数据库；支持安全管理员、系统管理员、安全审计员三权分立。

访问控制：支持禁止DBA、SYSDBA、Schema User、Any等特权用户访问和操作敏感数据集合。支持查询结果返回行数控制，避免数据大量泄漏；支持访问频次控制，避免一定时间内的高频次访问，避免数据流失；支持敏感SQL管理。

全面运维审计，记录包括用户名、IP地址、MAC地址、客户端程序名、执行语句的时间、执行的SQL语句、操作的对象等，对其行为进行全程细粒度的审计分析。

1、建立组织架构，对参与人员进行职责划分：

脱敏操作员：负责数据脱敏工作的具体执行，并向安全管理员和脱敏审计员定期汇报工作情况。

安全管理员：负责制定脱敏系统的安全策略，数据脱敏工作的范围和日程，并进行日常安全检查、权限管理和日常操作培训。

审计管理员：负责对脱敏操作员、安全管理员的操作行为进行审计、跟踪、分析、和监督检查，及时发现违规行为和异常行为，进行数据库日志、脱敏系统日志、安全事件的分析和取证。

2、建立符合业务需求的数据脱敏技术流程：

确定需求：根据业务需求,确定数据脱敏的方式,以及数据的用户管理策略。

确定脱敏对象：确定哪些是需要脱敏的敏感数据,以及脱敏数据的来源等。

配置脱敏规则：根据不同的应用场景,不同的数据,采用适当的脱敏算法进行规制的配置。

脱敏执行、数据验证：执行脱敏，之后通过工具和业务系统进行数据验证。

3、制定行之有效的数据脱敏评价办法：

组建评价团队，定期开展脱敏过程评价工作。

明确评价范围，全面涵盖脱敏场景、脱敏技术、脱敏工具、执行人员等。

制定评价指标，围绕敏感数据识别、脱敏权限分配、脱敏策略配置及执行、脱敏效果评估、脱敏数据标识、数据脱敏审计等过程的技术和安全要求，结合实际制定评价指标。

选定评价方式，采用多种方式组合开展评价工作，包括资料查阅、人员访谈、功能演示、技术检测等。

判定评价结果，收集并整理相关证明材料，组织召开相关会议确认评价结果，输出评价报告。

欢迎关注 @亿信华辰，让数据驱动进步~

更多赋能产品、案例分析、资料下载，戳↓