「數據門」事件頻發如何避免人爲因素致使數據泄露？

摘要： 前段時間，某酒店集團數據泄露引發軒然大波，泄露的數據中包含了用戶姓名、手機號、郵箱、身份證號等多項信息。賣家對這個約5億條數據打包出售價格爲8比特幣或520門羅幣。

前段時間，某酒店集團數據泄露引發軒然大波，泄露的數據中包含了用戶姓名、手機號、郵箱、身份證號等多項信息。賣家對這個約5億條數據打包出售價格爲8比特幣或520門羅幣。

而關於這次信息泄露事件的緣由，目前還沒有定論。據悉，因爲集團某程序員將服務器及數據庫信息泄露到了Github，致使被黑客利用，經過弱密碼攻擊攻陷了酒店服務器和數據庫體系。不過這一說法目前只是推斷。

內部管控不嚴泄密加上黑客攻擊成爲了這場數據泄露事件的主要緣由。
外部攻擊咱們尚可加防，內部運維咱們應該如何自防呢？在平常的數據庫使用過程中，運維人員在數據分析、線上問題排查、臨時修正數據等多個環節都可直接接接觸數據庫中的數據，也就是說這些環節都有可能出現問題。

傳統數據庫安全管控方案漏洞頻出
傳統的人爲數據安全管控方案有兩種，集權管理和分權管理。使用集權管理方案須要在業務代碼使用帳號以外，建立獨立的讀寫帳號、只讀帳號，只給與DBA、運維等特定的人員，可是這種方案的弊端在於，對於有些須要快速響應查看數據進行決策的場景，繁瑣的步驟將直接影響研發效率。

在平常數據庫使用過程當中，應用代碼的在線服務訪問是最主要的一種方式，但人員基於數據分析、線上問題排查、新需求變動結構、臨時修正數據等各類訴求也須要直接接觸數據庫。

若是採用分權管理，建立獨立的讀寫帳號、只讀帳號，分發到一線負責人，相較於集權管理，效率有必定的提高，可是接觸數據庫帳號密碼人員較多，人員變更時須要及時變動帳號密碼信息確保安全。

這兩種方案不只自己存在弊端，且在大批量管理時，實施難度也將成指數級放大。如此一來，企業還能如何避免人爲因素致使的數據泄露事件發生呢？

阿里雲數據管理DMS企業版針對此問題，提供了從訪問源頭開始防禦的完善、成熟的數據安全訪問解決方案。

DMS企業版高效保障數據安全，提高研發效率

與傳統的數據訪問方案相比，DMS企業版消除了人員瓶頸，在保障數據安全的前提下也兼顧了企業的研發效率。DMS企業版主要從訪問和變動兩個方面進行安全管控。

在訪問方式上，區別於傳統方案，無需直連數據庫，只需提早錄入須要管理的數據庫實例、接觸數據庫的人員，當須要訪問數據庫、表的時候，可直接在產品內按需申請或由數據owner主動受權，具有權限後登陸DMS企業版便可直接訪問數據庫，再也不接觸任何數據庫的帳號密碼。

在訪問權限粒度上也設定了相應的規範，若無對應權限則不可大量數據導出、不可提交數據變動（DML、DDL等）操做，避免了數據被大量泄漏。同時，DMS企業版支持了特有的字段級別權限管控，方便企業在身份證、銀行卡、密碼等敏感信息上進行精細化的管理。

DMS企業版對於保障訪問性能安全也作了特別的處理，好比數據庫級別閥值禁止全表掃描管控，當表空間大於必定值執行計劃不走索引則禁止發起查詢；用戶級別單天查詢行數、次數上限管控；產品內單次查詢返回行數上限管控等，全方位保障訪問安全。

變動安全管控主要加入了實例級別變動流程管控、任務調度負載管控以及數據變動update、delete默認備份前鏡像，若是遇到異常狀況可快速恢復，而且避免了元數據鎖爭用阻塞數據庫、避免thread_running太高時調度加劇負載。

除此之外，DMS企業版還提供了雲帳號准入、企業人員准入、企業內網准入三層登陸安全保障；在開啓內網准入（訪問IP白名單）管控後，即便企業內人員變動流失帳號未及時回收，但因爲人員已不能再登陸企業內網環境這無疑又是一道安全保障。

值得注意的事，在人員帳號都精細化按需使用後，帳號無共用，產品內人員的每個操做都將可被溯源。公司內（尤爲是上市公司）固定週期的操做審計將是重要的數據支撐來源。

數據安全任重道遠
數據安全任重道遠，企業內數據做爲一個企業的核心資產、賴以生存的命脈，數據安全是重中之重；也是最值得持續投入改進、不斷增強的一個方向。DMS企業版將不斷努力，助力企業完善數據安全管理。

最後附上【數據安全管理小建議】1）禁止弱密碼的存在，即便生產服務使用的數據庫帳號密碼若有可能建議按期更換2）禁止敏感信息的大量接觸，敏感信息嚴格限制可接觸人員3）禁止公開企業內數據庫訪問方式、服務器IP等敏感信息4）設置數據庫服務器的可訪問IP白名單，來源管控5）設置數據庫帳號的可訪問IP白名單，來源管控