链接：https://www.zhihu.com/question/372531840/answer/1840036336
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
大数据时代的到来，颠覆了传统业态的运作模式，激发出新的生产潜能。数据成为重要的生产要素，是信息的载体，数据间的流动也潜藏着更高阶维度的价值信息。对于数据控制者和数据处理者而言，如何最大化数据流动的价值，是数据挖掘的初衷和意义。然而，一系列信息泄露事件的曝光，使得数据安全越来越受到广泛的关注。
什么是数据脱敏？
数据脱敏（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、使用专业的数据脱敏产品进行脱敏
近年来，随着各行业信息化管理制度的逐步完善、数据使用场景愈加复杂、脱敏后数据仿真度要求逐渐提升，为保证脱敏果准确而高效，专业化的数据脱敏产品逐渐成为了用户的普遍选择。相比传统的手工脱敏方法，专业的脱敏产品除了保证脱敏效果可达，更重要的价值点在于提高脱敏效率，在不给用户带来过多额外工作量的同时，最大程度节省用户操作时间。
三. 数据脱敏技术
数据脱敏的基本原理是通过脱敏算法将敏感数据进行遮蔽、变形，将敏感级别降低后对外发放，或供访问使用。根据不同的使用场景可以分为“静态脱敏”和“动态脱敏”两类技术，这两类脱敏技术从适用场景、技术手段、部署方式三个方面有所不同。
1、静态脱敏与动态脱敏使用场景和用途的区别
静态脱敏适用于将数据抽取出生产环境脱敏后分发至测试、开发、培训、数据分析等场景。
原理是将数据抽取进行脱敏处理后，下发至脱敏库。开发、测试、培训、分析人员可以随意取用脱敏数据，并进行读写操作，脱敏后的数据与生产环境隔离，满足业务需要的同时保障生产数据的安全，静态脱敏可以概括为数据的“搬移并仿真替换”。
动态脱敏适用于不脱离生产环境，对敏感数据的查询和调用结果进行实时脱敏。
原理是将生产库返回的数据进行实时脱敏处理，例如应用需要呈现部分数据，但是又不希望应用账号可以看到全部数据；运维人员需要维护数据，但又不希望运维人员可以检索或导出真实数据，动态脱敏可以概括为“边脱敏，边使用”。
2、静态脱敏与动态脱敏的技术路线的区别
静态脱敏直接通过屏蔽、变形、替换、随机、格式保留加密（FPE）和强加密算法（如AES）等多种脱敏算法，针对不同数据类型进行数据掩码扰乱，并可将脱敏后的数据按用户需求，装载至不同环境中。静态脱敏可提供文件至文件，文件至数据库，数据库至数据库，数据库至文件等不同装载方式。导出的数据是以脱敏后的形式存储于外部存贮介质中，实际上已经改变了存储的数据内容。
动态脱敏通过准确的解析SQL语句匹配脱敏条件，例如：访问IP、MAC、数据库用户、客户端工具、操作系统用户、主机名、时间、影响行数等，在匹配成功后改写查询SQL或者拦截防护返回脱敏后的数据到应用端，从而实现敏感数据的脱敏。实际上存储于生产库的数据未发生任何变化。
3、静态脱敏与动态脱敏的部署方式的区别
静态脱敏可将脱敏设备部署于生产环境与测试、开发、共享环境之间，通过脱敏服务器实现静态数据抽取、脱敏、装载。
动态脱敏采用代理部署方式：物理旁路，逻辑串联。应用或者运维人员对数据库的访问必须都经过动态脱敏设备才能根据系统的规则对数据访问结果进行脱敏。
四. 数据脱敏的价值？
无论是静态脱敏还是动态脱敏其最终都是为了防止组织内部对隐私数据的滥用，防止隐私数据在未经脱敏的情况下从组织流出。满足组织既要保护隐私数据，同时又保持监管合规，满足合规性。
数据脱敏(Data Masking),又称数据漂白、数据去隐私化或数据变形。
数据脱敏的定义为：指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。
数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。数据安全技术之一，数据库安全技术主要包括：数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。数据库安全风险包括：拖库、刷库、撞库。
需要数据滴滴我！
数据脱敏是隐藏原始数据与修改的内容（字符或其他数据）的过程。对数据脱敏的原因主要是为了保护个人身份信息，敏感个人数据或者商业数据，也就是刚才我们在推特上看到的那些客户信息。
数据脱敏最大的要点，在隐藏了数据之后，数据必须要保持可用，而且看上去也要像真的一样，否则我们就直接把这些信息都改成ABCD就好了。
比如某个人叫张三，要把他改成李四。手机号码也要变成不存在的号码，但是还是得有11位，不能变成字母。身份证号和信用卡号也要符合规则，比如身份证特定几位必须是生日，信用卡的奇偶校验那一位必须是正确的，否则将会变成无效卡号等等。
上面这个还是简单的，数据脱敏还需要在各个级别上都让数据有意义，比如混淆地址，必须要保证是一个正确的地址，而且还要让邮政编码是正确的，这通常会跨数据库的多个字段。又比如某个人力资源系统里，一个员工的职位是工程师，那么这个职员关联到的另外一张工资表上的工资，不可以是一千万，否则就出了大笑话。还比如说某个呼叫中心的客户接到了银行的客户投诉，这个客户如果是一个VIP客户，就必须要匹配到客服数据库里面的相关客户等级和服务。
所以数据脱敏主要的工作不是把数据藏起来，而是把数据弄得跟真的一样，还不能是真的。
