鄭昀 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年開始在加拿大新斯科舍發生了一系列不大可能發生的事情，許多種類的鯨——很可能是所有種類的鯨——會永遠消失。就在那里，一個叫格斯納的人發明了煤油。
——《趣味生活簡史》