Data Masking-克隆“真实”的假数据
N年前，本人曾经参与过一个*局旅馆业管理的开发项目，其中要实现的一个重要功能就是在客人入住酒店前将其个人信息进行后台比对，以验证其是否是犯罪分子。开发测试阶段，*局信息部IT人员直接把全国在逃犯信息数据库直接导入到我们开发库中.，茶余饭后偶尔浏览一下犯罪分子的个人信息，至今依稀还记得那种后背冒凉风的感觉。如果这些数据真的泄露出去，势必增加犯罪分子的逃跑机会，后果不堪设想，无奈*机关没有萨班斯法案。如果四大在给企业做安全审计，这种安全隐患应该是不会被放过的。
防数据泄露是数据安全领域的重要课题，一些安全厂商的防数据泄漏产品可避免数据通过光盘、移动硬盘、网络或者邮件传播出去。Oracle公司也先后推出基于数据库安全的产品包，如Database Vault数据访问准入控制可精确限制不同角色用户的可访问区域，Audit Vault 及时检测及警报嫌疑活动并检测数据变化，避免敏感信息的泄露。这类产品侧重于在业务正常运行时避免信息泄露，但正如本文前面所示，也许你的业务系统还没有正式上线，敏感数据就已经泄露，开发测试阶段数据的安全性反倒成为大家容易忽视的角落。
为了保证开发和测试的质量，往往需要开发、测试访问的是真实的数据，尤其是功能测试、性能测试、系统支撑能力测试对数据的真实性和数据数量要求更高，DBA经常用到以下几种方法来造测试数据：
1. 生产库中export出所有数据，import到测试库中，包含所有的真实信息，保证了数据的数量和质量，但这种方法的安全隐患不必多说。
2. 生产库中export出数据，import到测试库中，编写脚本对敏感数据进行修改，如对于信用卡号码的所有位加1，这样“62258001。。。”变成“73369112。。。”。数据数量有保证，质量有保证，但加密容易，解密也容易，通过一个简单脚本可以快速还愿数据，同样存在安全隐患。另外如果一个数据库中包括成千上万个包含敏感数据的表，让DBA完成数据修改工作也是不可能完成的任务。
3. 自己造数据，“张三，李四，王二麻子。。。”，电话号码“13988888888，13900000000.。。。”，也许勉强可以完成功能测试，但由于制造的数据量有限，完全不能满足应用上线前的性能测试，支撑能力测试，试运行，甚至会误导测试结果。
Data Masking Pack作为Oracle Enterprise Manager中的一个重要产品包，可以轻松解决上面的技术难题。Data Masking内嵌丰富的数据修改规则，通过各种复杂算法，可自动批量快速完成对敏感数据的修改，从而保证克隆出来的数据库的数据量完全等同于生产库的数据量，敏感数据又做了伪装，如身份证号，电话号码，信用卡号码，姓名，日期，家庭住址，工资等，看起来是真数据实际上是假数据，从而消除了敏感数据的泄露隐患。流程如下图所示:
Data Masking Package具备以下特点：
- 提供丰富的，可扩展的Masking规则定义库，对于常见的字段类型如信用卡号、姓名、电话号码等可直接使用默认的定义规则。
- 除了内嵌的Masking规则，用户可以自定义任意格式的Masking规则，如电话号码的前三位固定为“010”
- 数据字典搜索功能，自动发现数据库中包含敏感数据的字段，而不需要逐个表进行修改。
- 自动识别表之间的主外键关系，一旦某一表中的某一字段被Mask，Data Masking会自动识别与该表该列有主外键关系的所有其他表和列进行自动Mask，从而保证数据的一致性。
- masking定义可重用，一旦表和列的masking定义已经完成，可以将这些定义内容倒出成XML格式模板，如果将来需要重新克隆和Mask数据，这些独立于数据库保存的模板可以重用而不需要重定义，即便是数据库已经删除。
- 易管理，易移植，Data Masking全部采用图形化界面，Mask过程可自动生成脚本，便于理解mask动作的整个过程，该脚本可直接修改重用。
如果你是开发商的DBA，不要再去做费力不讨好的事了，Data masking可以帮你快速生成一份不包含敏感信息的“真实”测试数据；如果你是售前工程师在向用户推荐Data Masking产品，除了向用户DBA介绍产品功能外，是否有机会给用户的CXO讲几个数据泄露的故事。DBA的工作重点是保证数据库的高可用，高性能，日常维护，数据的备份，数据安全性不一定是他们的兴趣点，而CXO肯定非常关注数据的安全性；如果你是运营维护的DBA，通过Data Masking给开发商提供测试数据让你避免在将来可能出现的“数据门”事件中成为“替罪羊”。
下面地址可以找到Oracle Data Masking Pack的最新功能介绍：
http://www.oracle.com/technology/products/oem/pdf/ds_datamasking.pdf