数据库脱敏规则
一般的脱敏规则分类为可恢复与不可恢复两类。
可恢复类，指脱敏后的数据可以通过一定的方式，可以恢复成原来的敏感数据，此类脱敏规则主要指各类加解算法规则。
不可恢复类，指脱敏后的数据被脱敏的部分使用任何方式都不能恢复出。-般可分为替换算法和生成算法两大类。替换算法即将需要脱敏的部分使用定义好的字符或字符串替换，生成类算法则更复杂一些，要
金融数据库脱敏硬件设备
数据库脱敏规则
一般的脱敏规则分类为可恢复与不可恢复两类。
可恢复类，指脱敏后的数据可以通过一定的方式，可以恢复成原来的敏感数据，此类脱敏规则主要指各类加解算法规则。
不可恢复类，指脱敏后的数据被脱敏的部分使用任何方式都不能恢复出。-般可分为替换算法和生成算法两大类。替换算法即将需要脱敏的部分使用定义好的字符或字符串替换，生成类算法则更复杂一些，要求脱敏后的数据符合逻辑规则，即是“看 起来很真实的假数据”。
数据库脱敏功能
确保数据脱敏有效性：保证脱敏后的数据能够准确反映原始数据的业务属性和数据分布特征，例如对于原始数据中的姓名、地址、病症、企业名称等信息需要在脱敏后仍然具有可读性；脱敏后的数据需要满足业务系统的数据规则，能够正确的通过业务系统的数据有效性验证，如身份号、银行号的校验码，生日数据的区间，有效的发卡行信息，年龄与出生日期的匹配等。
保留数据关联性：脱敏后的数据应能满足业务系统的数据关系特征，严格保留原有的数据关系；例如身份号在多个表中出现，需要保证这些数据经过脱敏后也是一样的。另外，对于具有时间序列关系的数据，需要保证每个日期脱敏后仍然能够保持原有的时间序列。
保证脱敏：高场景下的数据量很大，包括表数量多，单表数据多，每日增量数据多等等。为了能够尽可能节省人工劳动成本，脱敏产品的性能一定要高，能够支持增量数据定期自动执行脱敏。
数据库脱敏实现背后的秘密
数据脱敏功能，基于SQL引擎既有的实现框架，在受限用户执行查询语句过程中，实现外部不感知的实时脱敏处理。关于其内部实现，如上图所示。我们将脱敏策略（Redaction Policy）视为表对象上绑定的规则，在优化器查询重写阶段，遍历Query Tree中TargetList的每个TargetEntry，如若涉及基表的某个脱敏列，且当前脱敏规则生效（即满足脱敏策略的生效条件且enable开启状态），则断定此TargetEntry中涉及要脱敏的Var对象，此时，遍历脱敏列系统表pg_redaction_column，查找到对应脱敏列绑定的脱敏函数，将其替换成对应的FuncExpr即可。
经过上述对Query Tree的重写处理，优化器会自动生成新的执行计划，执行器遵照新的计划执行，查询结果将对敏感数据做脱敏处理。带有数据脱敏的语句执行，相较于原始语句，增加了数据脱敏的逻辑处理，势必会给查询带来额外的开销。这部分开销，主要受表的数据规模、查询目标列涉及的脱敏列数、脱敏列采用的脱敏函数三方面因素影响。
是否需要对数据库数据进行脱敏处理？
取决于你们公司的实际业务场景和数据敏感度。比如如果你现在的单位是银行，因为涉及用户的财产安全，数据库是肯定需要进行脱敏处理的，
以防用户数据泄露，对银行或者储户造成损失。这里的泄露有可能是被别人技术套取，也有可能是内部员工职业操守出现问题而导致“家贼难防”的事情发生，
这时候数据库脱敏就显得尤为必要。当然银行也不
