•    引言
中国的电子政务建设已经历了十多年的历史，期间IT技术日新月异，我们经历了SOA、商业智能、网格计算、云计算、大数据等各种技术浪潮。无论IT技术如何发展，中国的电子政务建设必定是朝着为广大民众提供更优质服务的方向而进化。然而任何事物总有其两面性，安全问题也总是随着技术的发展如影随形。

•    电子政务在大数据时代的挑战
电子政务是利用现代化信息技术对政府及其事务进行信息化改造，以提高政府部门依法行政的水平。既然是信息化，那么其核心就是信息，而在我们IT系统当中，数据就是信息在电子化以后的存在形式。随着我们电子政务建设进程的发展，政府机构信息化程度越来越高，当中的数据也是越来越重要，其价值也是提升到了前所未有的高度。

•    数据安全
现在我们已经步入了大数据时代，当然并非任何一个单位想实现大数据分析都能做到的，其基础是各种标准化和非标准化数据在时间和数量上有了相当的积累才有可能。目前我国的许多电子政务系统已经过了十多年的沉淀，自然系统中就存在着大量的居民和企业信息，而且其信息的完整程度也非常高。也就是说我们能够轻易地在政务系统当中找到一个具体的个体，包括其各方面的资料。我们可以整合各机构的信息大幅简化各种政务流程；我们可以给每个民众建立完整的健康档案，以提供更好的医疗服务，甚至预防家族疾病……我们可以实现许多匪夷所思的民生建设。当然这是要建立在积极的思想角度上的。相反，如果有人想从中获取高收入人群的联系信息甚至背景资料来进行诈骗也是可以的，我们个人的纳税信息、社保信息、固定资产，甚至医疗信息、办事信息等等，都可以被有针对性地利用，像这种有针对性的诈骗，成功率是非常高的。因此，在大数据时代，数据安全对我们电子政务建设的确是一大挑战。

•    外包风险
说到数据安全，其实是个很大的范畴，现在可以说数据是无处不在，存在于移动终端里、网络上、数据库中，其实我们一直为此在做各种努力和投入，防火墙、加密、堡垒机、监控、审计、云桌面等等。这些手段我们一般更多的是用在生产环境中，而我们现在要讨论的是大家最容易忽视的地方，就是外包环节。在我们电子政务建设中，几乎所有项目都是外包的。外包商可能会用到开发环境、测试环境、培训环境等等。这些环境当然也会存在数据，那么这些数据是真实的吗？目前看来，大多数项目使用的确实都是真实数据。当然，对于安全问题，我们会与外包商签订保密协议，而外包人员则有职业道德来约束。不过，即便是安全意识如此先进的美国国家安全局，也没能预防棱镜门事件的发生，而事发之时斯诺登正是国防承包商的职员。不得不承认，外包项目在目前众多的政务建设中确实存在着相当的风险。

•    技术手段
为了防止数据泄漏，目前大多数的项目建设还主要靠一纸协议，而缺少有效的技术手段。即便我们在开发环境使用各种安全技术，包括监控、审计、云桌面等，也无法阻止开发人员直接接触数据。由于职责所在，我们必须允许开发人员能够通过各种方式准确高效地查阅甚至备份自己所处环境的数据。所以，针对非生产环境（包括开发环境、压力测试环境、培训环境等）最有效的数据保护技术就是数据脱敏。所谓的数据脱敏，指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的保护。它有别于加密技术，加密技术是指在数据存储或者传输过程中对数据使用密钥进行处理，变成不可见的密文，在需要使用时，则要用到密钥对数据进行反向运算获得真实数据。而脱敏，也是对数据进行一定逻辑的处理和运算，但是处理过后的数据并不是密文，而是完全有别于原文的另一套明文，在使用时无需反向运算即可直接使用。

•    系统建设目标
要对非生产环境的数据库的数据进行保护，首先需要明确具体的目标，需要做到什么程度。如果要将所有数据都进行处理，显然难度太高了，很难保证数据处理过程中还能保证各种数据之间的逻辑、运算关系。根据我们的经验，如果我们对一个系统数据库进行数据漂白脱敏以后，无法在该数据库中找到任何一个真实的个体，我们就认为这种保护是成功的。例如，我们将某个政务系统中所有“张三”的名字变成了“李四”，其身份证号、电话号码等个人资料也都变成了伪造且符合编码规则的数据，那么就是意味着在该系统数据库中已经不存在“张三”这个真实的个体了，即使开发人员查询到了这个“李四”的资料，也都是伪造的，而且也无法得知这个“李四”的真实姓名。即使“李四”的信息泄漏了，也不会对“张三”造成任何负面的影响，这样我们就成功的保护了“张三”的个人信息。
在各政府机构的电子政务系统中存在着的大量居民和企业单位信息，包括了姓名、居民身份证号码、企业单位名称、组织机构代码、工商注册号、纳税人识别号、电子邮箱、联系地址、电话等等，这些都属于敏感资料，也就是我们需要保护的对象。只要这些信息都经过脱敏，那么基本上系统中所存在的都是伪造的个体了。

•    数据脱敏要求
1. 数据关联性
所谓的数据关联性，是指数据库内部在不同表格、不同字段之间存在引用和依赖关系，主要用于保证业务数据的完整性。对于企业和单位来说，数据的关联性存在于三个层面上：
1）数据库外键层
通过数据库的外键定义来强制不同字段中数据的引用关系。这是最基本要求了，如 果数据经过脱敏处理以后，无法满足这点的话显然数据库层面就会报错，上层业务 系统就更无法使用了；
2）系统层面
这个层面指的是某个政务系统来说，一个业务数据在数据库内部可能会存在于多个 表中，但是系统在数据库设计的时候并不见得就会使用数据库外键定义，通过应用 程序来保证其关联性也是常见的做法。那么我们就要求要做到即使是在数据库内部 没有定义外键关系的数据，在脱敏以后也要保证整个政务系统级别的数据关联性。 否则，即使数据库不报错，应用程序在运行时也会造成数据紊乱；
3）全单位层面
这个层面是我们在过去众多单位的项目中遇到的问题。目前几乎每个单位都拥有不 止一个数据库了，一个居民在某个政府单位办理业务，比如说在网上预约，然后去 现场办理业务，还要获得其它单位的某些文件证明，也就是说办理一个业务涉及到 了多个系统。如果我们的脱敏仅仅在一个数据库内部保持其关联性，那么这个业务 可能就出问题了，在政务系统A上业务流程的申请人，跟系统B上该流程的申请人不 一样了。因此，在全局层面保持数据关联性，是现在数据互联互通的基本要求了， 自然在脱敏的时候也要能保证。

2. 数据不可逆
从安全角度上来说这是很正常的要求，从严格意义上来说，没有绝对破解不了的算法，只是时间问题。但由于脱敏算法的特殊性，我们并不是把明文变成密文，而是明文变成另一个明文，对于破解者来说，如果我们不给他真实数据作为对比的话，他说无法验证它的逆向算法是否可靠的。而如果他拥有了真实数据做对比的话，他又何须费时去逆向破解呢？这样显然我们是可以做到“不可逆”的。
3. 数据仿真性
从数据安全角度来说，或许对于脱敏以后的数据仿真度高低的要求并不明显。但是对于开发和测试的效果来说就有很大差异了。比如，将“张三”处理成了“NAME000001”，这里我们将所有名字都变成非常有规律的字符串，安全目的是达到了，不过对于研发和测试很不利，主要原因有：
•    测试数据太有规律了，数据库运行效率非常高，无法模拟真实环境的效率；
•    测试数据分布过于均匀，开发人员写的代码就无法适用于真实数据中数据倾斜的情况；
•    开发环境不存在数据质量问题，导致无法验证程序代码对边缘数据和异常数据的兼容性；
这也正是为什么，有些系统在压力测试的时候承载住了每秒钟一万次的访问量，结果正式上线以后，每秒一千次访问量就出问题了，往往这些测试系统使用的就是严重失真、过于理想的数据，当然测试场景的设计也可能是原因之一。可见，将数据漂白脱敏变成高仿真的数据，还是有必要的。
•    人员配置
对于人员的安排这点来说，确实在不同的单位可能会存在一定的争议。数据脱敏是在数据库层面进行的，是对表格中的字段进行处理，说到这些概念，当然拥有数据库技能的DBA就完全具备了作为执行者的能力。但是很多虽然DBA很熟悉数据库技术，但是各种政务系统数据库的库表结构是开发商设计的，我们单位里的DBA并没有参与其中。这就意味着DBA对数据模型不了解，即使拥有数据库设计文档，他最多能够知道哪些表的哪些字段是存放什么数据的，但是却很难决定该字段是否需要脱敏。另一方面，从数据模型角度来说，熟悉业务应用的研发人员可能会比较合适，某些项目中甲方或许会有研发人员参与到外包项目当中一起工作，这得以让他们能够深入了解系统。而从安全工作的责任来说，这又是属于安全部门的范畴。
在我们过去的经验里，因不同单位的人员配置和职责划分的不同，从而导致了脱敏的执行人员的也各不相同。最常见的执行人员就如以上所述的DBA、研发人员、安全部门。所以只需要根据自身单位的实际情况进行合理安排就足够了。

•    隐私数据的定位
刚刚我们也提到了数据模型，所谓的数据模型主要是指针对某个业务定义在数据库层面的数据结构、操作和约束。在这里我们只关心数据结构和约束了。因为脱敏只对数据本身进行处理，也就是说我们如果要对一个系统的数据库进行脱敏，我们需要了解这个数据库的数据模型，否则我们不知道哪些表的哪些字段是用于存放姓名、居民身份号码等等，也就根本无从下手进行数据保护。我们发现脱敏这个领域中，绝大部分产品都要求我们首先要建模，或者近似于建模的工作才行进行脱敏。这个工作量可以说是相当大的，即使我们拥有这个政务系统最准确无误的数据库设计文档，也需要至少几十人天的工作量，糟糕的是有时候因为某些原因这个工作量甚至到了不可控的程度。再说了，一个政府机构，无论大小，至少有几个系统，每个系统因为支撑的业务不一样、开发商不一样而导致了其数据模型也是完全不同的。可想而知，这总体的工作量是相当可观的。我们曾经遭遇过因为系统设计过于复杂，完全无法建模而宣告项目无法开展的。当然如果应用系统开发商以保密为由而不愿意提供设计文档的，自然也无法建模了。
建模确实是一项非常耗时和高难度的工作。不过，我们为什么要建模？其实我们被误导了，难道就因为外企的产品需要建模吗？我们再返回原点来思考，我们的目的是要做数据脱敏，脱敏的对象是字段，我们完全不关心表结构；对于数据关联性，我们前面也讨论过了，关联性有三个层面，数据模型也只是数据库外键层面的，系统层面和全单位层面是数据模型中无法覆盖的。那么，只要我们通过某种方法找到每一种需要脱敏的数据存在于哪些字段即可。
这里我们提出“自动发现”功能，发现功能能够对数据库进行自动化的分析，找出各种隐私数据处于哪些表格的哪些字段，并生成报告。这个“发现”功能其实并不罕见，在许多数的脱敏产品平台都有，但是由于使用的技术不同而效果差异非常大。从实用角度来说，自动发现的识别准确率至少要达到99%以上才有意义。或许很多人对99%这个数字没有太多感觉，我们举例来说，一个中等复杂度的数据库系统大约有5万个字段，如果一个发现功能的识别准确率只有60%的话意味着什么？意味着经过分析以后将会有2万个字段的结果是错误的，需要人为纠正。当然到底哪2万个字段是错的，这我们可是不知道的，由于错误率太高了，我们实际上还是要将所有5万个字段都检查校对一次的，那么这个功能有实用意义吗？答案显然是否定的。如果是99%的准确率则是意味着有少于500个可能是错误的，而且分析的算法是倾向于低可能性入选的话，我们的校对工作可能只需要1个小时就完成了。从至少几十个人天到一个小时，这可是几个数量级的进步。甚至原来完全不可能完成建模的系统，只要“自动发现”的准确率足够高，那么我们也只需要极短的时间就能完成数据梳理的工作。
目前“自动发现”的技术主要有三类：
1. 根据字段名的命名规则判断。比如NAME可能是姓名，但是也可能是其它各种名称，这种技术准确率低，而且没有多判断和漏判断的倾向性，没有实用性；
2. 使用正则表达式对数据本身进行扫描。比如用来分析电话号码规则，但是由于正则表达式的局限性，有许多规则超出正则表达式的语法范畴就完全无法分析，比如中文无法判断，拥有校验规则的数据无法判断等，因此适用面很窄，且准确率低，实用性也很低；
3. 对数据本身进行智能化分析，分析其数据特征、编码规则甚至语音。这需要对每一个数据都进行大量复杂的运算。这种技术完全依赖于算法的完善性和成熟度，只要足够完善，准确率能够接近100%。
当然准确率不可能达到100%的，为何？因为语言本身就是存在歧义的，以前我们曾见过一个字段只有一个数据“高雄”，在没有任何其它背景的条件下去回答这到底是“姓名”还是“地址”？到现在我们都还不知道答案。不过庆幸的是，经过不断改进，我们利用第三种技术已经能达到99.5%以上的准确率了，当然这跟数据质量有很大关系。在某些数据质量比较高的系统里，甚至到了100%。
这种智能化的“自动发现”功能，对于我们不断前进的电子政务建设来说尤为重要。假设我们第一期针对3个系统进行了脱敏，一年以后我们需要增加一个系统，我们只需要针对这个新的系统“发现”一次然后花一点时间校对，然后就可以立即进行脱敏了。若没有“自动发现”功能的话，我们就要针对新系统进行建模。如果我们要增加的不是一个系统，而是要对原来所有系统都增加一种新的隐私数据类型，比如对“纳税人识别号”的脱敏，使用智能化的发现功能进行增量处理的话工作量也是非常轻松的，但是如果使用建模的手段，恐怕我们原来的3个系统都要重新建模了。
•    用户体验
随着IT技术的蓬勃发展，我们发现各种IT系统，包括电子政务系统，架构是越来越复杂，运维成本也是节节攀升，同时也对各单位人员的技能水平不断提出更高的挑战。但似乎各单位的人员数量却并没有按比例的增加，增长速度远低于IT系统的膨胀。这很值得我们反思，既然计算机技术不断地飞越，它不断地实现新的需求、新的功能，但是为什么不能让我们的系统越来越简单呢？这理论上应该是可行的，有一句调侃的话叫“程序员是万能的”，但这句话非常有道理。只要是我们想象得出来的需求，代码就应该能够实现。所以，只要一切从使用者角度出发进行设计，就有可能做到最佳的用户体验。
我们不能要求业务人员去学习高深的技术，就像我们不能强制安全部门或者开发人员去精通数据库技术一样。但只要用户界面足够简单，简单到只需要鼠标点击“下一步”即可完成工作的话，相信即使完全不懂数据库技术的安全人员也能轻易地执行脱敏任务。
•    总结
传统的脱敏项目，我们需要采购各种软硬件产品搭建整个系统平台，投入少则几个人月多则几十人月的工作量，总投资至少是百万级别。项目的复杂程度、风险和投入都导致了我们在电子政务建设过程中对脱敏敬而远之。而现在，得益于智能化的“自动发现”、大量内置的脱敏规则、自动化的配置、各种人性化的功能和友善的用户界面，云图数据脱敏一体机InfoMask方案将整个项目实施周期已经从传统模式的至少几个人月缩短到了1个人天，这是革命性的进步。项目建设的复杂度和成本大大降低，这才使得脱敏有可能成为我们电子政务建设过程中的又一把螺丝刀。