8月14日，一名攻擊者在黑客論壇上聲稱，竊取了美國電信運營商T-Mobile的服務器數據，約1億用戶個人數據，總計106GB數據，其中包括T-Mobile的客戶關係管理（CRM）數據庫，姓名、電話、出生日期、駕駛執照號碼和社會保險號碼。8月17日，T-Mobile承認發生數據洩漏事件，據悉，受這次數據洩漏影響的用戶超過4000多萬。
除了T-Mobile外，今年以來美國管道、保險和肉類供應企業等相繼遭遇網絡攻擊事件，且都是針對數據的攻擊。根據公開報道，2020年全球數據洩漏的平均損失1145萬美元，2019年數據洩漏事件達到7098起來，涉及151億條數據記錄，比2018年增幅284%。
由此可見，數據洩漏事件影響大、損失重。
眾所周知，當前全球已逐漸進入數字化時代，數據已成為企業的核心生產要素，任何數據數據安全事件都是影響重大的。一旦出現數據安全事件，不僅對用戶的使用體驗和個人隱私帶來威脅，且企業也可能面臨重大損失及經營風險。數據安全防護已經日漸成為企業關注的重要訴求之一。
為幫助廣大企業客戶有效保護數據安全，阿里雲數據庫團隊推出覆蓋事前、事中及事後的全鏈路數據安全防護方案，並已服務了上萬企業客戶。
一、細粒度權限
數字經濟高速發展的今天，依靠傳統的DBA/運維單點響應所有人員對數據庫的訪問請求已經是極大的瓶頸也不現實了。
但是依靠數據庫原生的賬號權限管控能力，眾多數據庫類型只支持最細到表級別的授權，如果按照最小權限授予原則，不同人員訪問不同數據那麼就需要在數據庫上建立眾多的賬號。
一旦這樣的話，那麼勢必會遇到人員轉崗、離職等情況，權限無法自動、有效的回收（因為賬號一旦給出去也有可能被直接用於訪問生產服務的代碼配置裡，若直接回收也有可能就影響了生產服務）；但不回收不更換肯定也是隱藏了數據洩露的風險的，極其容易出現人員離職後大量數據洩露、尤其是敏感數據洩露等問題。
那麼是不是有好的辦法來解決這些問題呢？
相比較於傳統數據庫訪問方式在數據庫上創建多個賬號的方式，阿里雲數據管理DMS提倡統一管理入口，僅需要給DMS創建一個專用賬號，避免所有人員直接接觸數據庫賬號密碼，所有訪問都通過產品按需申請、流程審批開通使用。
在這裡我們支持庫、表、字段多種對象粒度，查詢、導出、變更多種操作類型進行組合，支持最細小時級別的授權靈活滿足各種場景，比如項目協作排查問題只需要開通1個小時，開通1小時的權限則會在到期後自動回收。
同時，在使用過程中結合安全規則的配置，對SQL語法、影響行數等各方面都能有效的攔截進而保障數據庫的服務安全，關於安全規則咱們會在後面的章節進一步介紹，這裡暫時不做展開。
通過DMS的細粒度權限管控，同時也能滿足安全合規需要定期更換數據庫賬號密碼但不影響任何人員，也不用擔心更換有未知風險，無需通知與溝通。
二、賬號體系
到這裡大家可能想問是不是隻支持雲賬號登錄？答案是否定的，目前企業域賬號可以通過阿里雲用戶SSO/角色SSO來對接使用。
同時我們通過OpenAPI能支持員工入職、離職賬號安全、自動化管控。
在人員入職環節中增加賬號的創建與授權，在離職流程前置賬號的回收清理，藉助於產品規避了人員直接接觸數據庫賬號密碼，在人員變動時只需要回收人員的賬號即可避免人員離職後再接觸任何企業內的數據，同時，運維人員也無需頻繁調整數據庫賬號。
下圖是我們的一個最佳實踐示例，供大家參考。
三、可控SQL請求
刪庫跑路到今天也不再是句玩笑話，而是真真實實的發生了。那麼針對這種刪庫跑路、數據洩露等惡性事件，除了平時人員的管理之外，我們有沒有可能在數據庫操作的管控層面做到杜絕呢？
答案肯定是可以的，通過DMS有了統一訪問入口的權限管控後，企業內所有用戶對數據庫的請求都從產品內發起，可以經過鑑權、語法校驗、訪問規則有效的來保障數據安全與數據庫服務安全。
在數據訪問安全上，咱們可以控制每次查詢返回行數、每天查詢返回行數、每天查詢次數等可有效避免暴力拖庫現象的發生；
目前在阿里內部我們對生產環境數據庫實例一般控制單次查詢返回行數上限為200條，測試環境數據庫實例一般控制單次查詢返回行數上限為500條，每人每天查詢總次數上限2000次，每天查詢總行數上限20000行。
同時，在數據庫服務安全上，咱們可以控制每次查詢超時時間、每次查詢全表掃描大表空間閾值等可有效避免慢查詢拖垮數據庫的現象發生；
一般默認查詢超時為60s，也可以根據需要進行適當的調整，比如在雙十一大促期間我們會設置查詢超時時間為5s，超過5s就自動取消查詢避免峰值期間的負載疊加；對大表的全表掃描我們一般設置超過10G就不允許執行計劃不走索引的SQL下發了。
另外，基於前面介紹的細粒度權限管控，最小權限授予使用的管理原則，企業內不僅可以規避不必要的敏感數據接觸，同時對高危操作刪庫、刪表等動作也都能有效攔截。
四、敏感數據管理
數據的洩露尤其是敏感數據的洩露將直接影響企業業務的發展，針對以往的數據洩露事件分析，常見的除了黑客攻擊，更有超過50%以上的數據洩露事件是由於管理不善導致的內鬼所為或數據庫信息被公開。
用戶個人信息、銀行卡號、身份證號、地址等敏感數據如何有效識別、有效管理呢？在企業成千上萬甚至是上億的數據字段裡，怎麼快速有效的識別、定位到敏感信息進行分類管控呢？
目前DMS產品內支持通過規則掃描字段命名或者抽樣少量數據內容進行分類識別打標，針對打標好的敏感、機密字段有又可以統一設置各種加密算法，在查詢時即使已經有了庫、表權限，針對此類字段還需要額外申請字段權限才可以使用，否則對應字段會被加密，並且無法作為查詢條件進行數據的過濾提取。
下面是一個示意截圖，當有字段的明文權限時字段跟其他內容一樣，如果只有半脫敏權限則會根據加密算法加密顯示，如果沒有權限則會全部星號顯示。
五、靈活、差異化管控
在企業裡不同業務的差異、甚至同一個業務不同環境的差異在管理策略上可能都是不一樣的，傳統的方案一般是企業內一刀切，那麼勢必會造成對有的業務太嚴格、有的業務又不夠靈活，進而影響到研發效率。
那麼今天通過DMS安全規則，我們可以支持企業內最細到單個數據庫實例級別制定不一樣的設計規範、研發流程、操作規範與審批流程。
比如每個業務新建的表都需要以業務縮寫前綴來區分識別，建表的時候A業務必須有自增主鍵id、以及gmt_create、gmt_modified時間字段表示記錄創建與最後更新時間，並且每個字段都需要有註釋。B業務建表要求表上必須有created_at、updated_at 表示記錄創建與最後更新時間字段。那麼就可以通過2個安全規則來實現靈活的支持，哪個業務也不必強套另外一個業務的規範或者往通用規範上靠。
這裡額外提一下，目前DMS內置了阿里巴巴內部運行的安全規範，同時企業也可以根據不同的業務按需定義符合企業的最佳安全規範，支持通過DSL語言擴展定義；凡是不滿足規範定義內的操作，DMS均會攔截。
六、操作全方位審計
前面我們已經介紹了細粒度權限、SQL請求、敏感數據、安全規則這幾個數據訪問安全解決方案，最後我們再來看下作為訪問安全最後一環的操作審計。在合規面前，所有行為要有據可循，有據可依。
通過DMS產品內的每一個操作我們都會詳細記錄，管理員、安全管理員進行隨時通過頁面或者OpeAPI獲取進行分析、合規審計與問題排查，這個記錄在企業上市合規審計、IT內審等環節中都有重大幫助作用。
下面這個是我們當前頁面的一個截圖供大家參考。
