郑昀 2017/4/29 最后更新于2017/5/9
关键词：依法合规，责权对等，脏数据，企业内部安全审计，数据不一致，
由于我们2011年就开始着手上市事宜，当年引入了德勤企业内部安全审计，所以在事情还没有演变到不可收拾的地步之前，我们已经开始着手建立各种制度、规范和系统，全都为了合规，最终几年后登陆NASDAQ。
什么是（技术上的）合规？（我们这里暂不谈财务合规和用工合规。）
-
数据是平的。一个数据的产生肯定有前因后果，来龙去脉，不可能架空飞来，是的，审计就是要看数据是不是平的。审计秉持的态度是，企业可能在作假，我们要找出造假的证据。数据不平，就有可能是造假。
-
变更有操作记录，即事后有迹可寻，保证历史可回溯。这也就是为什么我们开发了数据库自动化运维系统iDB，开发了运维自动化平台SimpleWay，开发了研发协作平台CloudEngine，开发了大数据协作平台魔盒的原因之一。
-
重要变更有审核记录，即事前有看门人。iDB里就留存着DBA审核工程师提交的数据库变更请求的审核证据。
-
安全有效的保护，如数据库备份的可恢复性测试需有书面证据证明。
-
责权利对等，即系统权限与员工岗位职责要对等。再譬如不要共用帐号。
饶是如此，2011年底，在面对各种主客观原因产生的脏数据时，我、雷电、金钟、亦男四位仍是无语凝噎，白了少年头。
以前讲过我们脏数据产生的各种场景：
-
滥用IT系统
-
前期产品设计的功能自由度太大，未严格限制输入，在区区IT系统面前，人民群众是无（wu）所（kong）不（bu）能（ru）的。而产品设计者和系统开发者又容易在“非禁止则可输入和选择”和“锁死一切，只能输入已知的数据序列，并做上下文校验”之间首鼠两端，导致输入数据随意性大，杂乱无章；
-
因功能缺失导致有意利用系统（漏洞）完成流程；
-
不同系统均可录入和修改，违反了在数据源头修改的大原则，造成数据（到处）不一致，看上去很像是数据造假；
-
软件BUG
-
代码低级失误
-
分布式系统问题，比如未能做到防重复提交和防并发提交，比如主从延迟问题引发的BUG
-
缺乏开发规范和意识，譬如不同环境随意对接，违反流程规范，原本应该测试环境对接测试环境，镜像环境对接镜像环境，生产环境对接生产环境，结果随心所欲，交叉对接；
-
缺乏审计意识，譬如随心所欲删除数据，毁尸灭迹，尤其是不了解数据表结构，导致删数据还删不平，看上去更像造假；
-
刷库刷错，譬如上线时数据迁移刷错了，或修复BUG时刷数据漏刷了。
仅仅是2011年当年，德勤提出的整改点就有如下这几点：
-
重要缺陷 / Significant Deficiency
-
-
系统数据管理不完善；
-
系统功能不完善，导致交易和退款等关键记录不完整；
-
必须加强系统变更管理（即操作记录和审核记录）；
-
用户权限管理存在不足；
-
-
系统部分用户权限与员工岗位职责不相符，部分研发体系人员拥有生产系统权限；
-
员工的系统权限与其岗位职责不相符，会造成滥用系统权限、修改系统数据等不当操作，存在数据被篡改和泄露的风险；
-
德勤要求参照用户岗位职责与系统用户权限相符合的原则，对不符合其岗位职责的权限进行删除或修改，使员工的系统权限达到职责分离的要求；
-
-
-
缺陷 / Deficiency
-
-
没有建立起完善的内部（IT）审计体系；
-
务必加强用户密码等敏感信息的存储和管理；
-
加强数据备份管理并定期进行可恢复性测试；
-
部分电子表格（即IT系统中的导表操作）缺乏安全有效的保护；
-
以后每年都会出具审计意见。按他们的这些要求整改后，才慢慢地勉强达到合规。
这也就是为什么我这么多年一直强调一点：
-
我不承认生产环境有所谓的测试帐号，测试数据。没有，永远没有。
-
生产环境里都是真实有效的生产经营数据，大数据部门不做任何屏蔽和过滤，以此保证不同历史时期不同部门的数据输出口径前后一致。
再说一下数据。
电商核心服务都是分布式应用，分布式事务如处理不妥善，容易产生数据不一致。一旦出现数据不一致，一定要有旁证来修正。
所以2012年，我在文章里特地强调，数据库中以下关键资源的记录，原则上不允许直接修改历史数据：
-
下单；
-
支付购买；
-
生码/验码/物流信息记录；
-
退款；
-
结算；
-
用户注册；
-
与第三方系统的数据同步；
这里的“直接修改”特指，没有把变更行为记录到日志表里，而是直接在原始记录上 update 甚至 delete ，这种“篡改”和“毁尸灭迹”是明文禁止的，即使留下了文件类型日志也是不允许的。
第一，要修改这些记录的关键字段时，必须在相关日志表里保留变更日志，并记录操作人和发起人，一定要确保历史可回溯。
第二，严禁对记录做物理删除，只能是软删除。
什么叫历史可回溯？
系统可能对关键记录做了一系列修改，甚至有程序在某个时间段内误写引入了脏数据，但我们依然能从各种操作日志表中随时倒推回历史某一个时刻的快照，一是确保随时能安全地把数据还原回去，二是管理平台可以清晰地展示出由谁引发、怎么变化的历史，三是便于排查问题。
譬如，对于记录了订单信息的 order_info 表，会员如果点击使用账户余额支付了订单的应付金额，那么该订单操作日志表就会做如下记录，原订单记录的重要字段（what）在什么时候（when）从什么变为了什么（how），都会详细记录。
正像前不久我们做的集团重组合规演练一样，第三方就是要保证我们从更多维度合规：
流程图：健全业务流程标准体系；
部门制度：提高内部控制水平；
业务文档：夯实业务基础工作；
部门架构：增强业务资源配置能力；
财务报表：报表数据合理合规；
产品收入: 与市场同类产品对标。
这样在未来某一天上市前过会的时候，大家才会安之若素，会心一笑：等你很久了。
-EOF-
赠语一枚：
到18世纪末，照明的质量已经有大约3000年时间没有变化了。说不清楚那个伟大的捕鲸时代有多少头鲸死于照明事业。要不是从1846年开始在加拿大新斯科舍发生了一系列不大可能发生的事情，许多种类的鲸——很可能是所有种类的鲸——会永远消失。就在那里，一个叫格斯纳的人发明了煤油。
——《趣味生活简史》