摘要： 前段時間，某酒店集團資料洩露引起軒然大波，洩露的資料中包含了使用者姓名、手機號、郵箱、身份證號等多項資訊。賣家對這個約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白名單，來源管控