数据库脱敏泄露风险模型

是对所有可标识列进行移除或是脱敏，使得攻击者无法直接标识用户。但是攻击者还是有可能通过多个半标识列的属性值识别个人。攻击者可能通过社工(知道某个人的姓名，邮编，生日,性别等)或是其他包含个人信息的以开放数据库获得特定个人的半标识列属性值，并与大数据平台数据进行匹配，从而得到特定个人的敏感信息。如果攻击者知道某用户的邮编和年龄，就可以得到该用户的疾病敏感信息。为了避免这种情况的发生，通常需要对半标识列进行脱敏处理，如数据泛化等。数据泛化是将半标识列的数据替换为语义--致但更通用的数据，已上述数据为例，对邮编和年龄泛化后的数据。

数据库脱敏实现背后的秘密

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

经过上述对Query Tree的重写处理，优化器会自动生成新的执行计划，执行器遵照新的计划执行，查询结果将对敏感数据做脱敏处理。带有数据脱敏的语句执行，相较于原始语句，增加了数据脱敏的逻辑处理，势必会给查询带来额外的开销。这部分开销，主要受表的数据规模、查询目标列涉及的脱敏列数、脱敏列采用的脱敏函数三方面因素影响。

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

1、 使用脚本进行脱敏

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

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

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

是否需要对数据库数据进行脱敏处理？

取决于你们公司的实际业务场景和数据敏感度。比如如果你现在的单位是银行，因为涉及用户的财产安全，数据库是肯定需要进行脱敏处理的，

以防用户数据泄露，对银行或者储户造成损失。这里的泄露有可能是被别人技术套取，也有可能是内部员工职业操守出现问题而导致“家贼难防”的事情发生，

这时候数据库脱敏就显得尤为必要。当然银行也不是对所有数据都进行脱敏处理，对一些不重要不涉及用户或单位敏感信息的数据，是不需要也不会对其进行脱敏处理的。

因为数据脱敏是有操作维护成本以及使用成本的，而且成本不小，在后续的数据维护和数据使用过程中，会产生各种不方便及额外的时间及性能损耗。