本文分析數據庫國產化后的一個重要使用場景問題，即國產數據庫的訪問權限管控該如何設計才能做到在確保數據安全可靠的前提下又能盡可能方便用戶使用。
問題背景
數據庫訪問權限屬于運維權力的一部分，權力跟責任總是要匹配的。有權力但不履行責任或者疲于履行責任，都屬于權責失衡的表現。
數據庫權限的責任包含：
-
1. 數據存儲安全。具體指服務器或網絡故障后數據存儲數據不丟，數據讀寫服務能快速恢復。
-
2. 數據讀寫路徑安全。具體指所有數據庫的訪問路徑都安全，除了應用程序外還有其他數據庫客戶端訪問、數據庫主機訪問等。避免重要數據被非法訪問、篡改、導出泄露等。
-
3. 數據庫運行性能良好。數據庫讀寫性能符合業務需求，避免不正確的數據庫讀寫方式給數據庫性能或安全帶來影響。
對于責任 1 是運維的本職工作，受到領導的高度重視。通常都不會有問題，如果有問題那運維負責人必定是第一責任人被問責。
對于責任 2 和 3 ，也跟運維工作有關，實際執行效果在不同客戶里不盡相同，反映了企業的科技力量建設成熟度。本文就是就這兩點展開論述。
傳統數據庫的權限管控思想
傳統數據庫運維下，數據庫的訪問都是通過堡壘機控制訪問終端。訪問終端包括 SSH 終端（有 Putty、XSHELL、Mabaxterm、SecureCRT、Remote Desktop 等）和數據庫客戶端終端（SQL Navicat、PLSQL Developer、DBeaver 等）。
堡壘機是訪問的重要關卡。一般堡壘機賬戶到個人，也有的為了簡單在多個人之間共用賬戶。堡壘機針對 SSH 終端有文字審計功能，針對圖形化客戶端有截屏審計。如果知道某個時間段有非法訪問或操作，就事后查看堡壘機的審計記錄。如果線索很少，基本上就是大海撈針。
SSH 終端也不是本文重點，就不展開說。數據庫客戶端終端通常是已經綁定了某個數據庫的某個賬戶。每一個使用這個數據庫客戶端終端的都是使用同一個賬戶讀寫數據庫。控制這一個賬戶的權限就能控制數據庫的讀寫風險。此外，少數人如果有 SSH 終端權限，也可以直接在命令行下使用賬戶讀寫數據庫。這個數據庫賬戶可能是給到人的，也可能是共用的。
以上這個設計在安全上有一定的防護作用，但也有問題。問題包括：
-
1. 共用數據庫賬戶，非法操作單憑終端的審計日志無法確定是哪個人操作，還需要結合堡壘機的登錄使用日志聯合確定。
-
2. 數據庫用戶很多，這樣的數據庫客戶端連接需要配置很多，每個連接的用戶權限都需要在數據庫上配置并確保安全。通常賬戶的安全使用守則遵循 NEED TO KNOWN 原則（僅限知悉必要信息）。但是不同人的需求不一定相同，共用賬戶最終導致這個賬戶在數據庫上的權限對于部分人是過大的。
-
3. 這個機制對于有合法訪問權限的人的非法訪問和操作數據起不到防護作用。有合法訪問權限是指有堡壘機登錄權限以及這個數據庫客戶端入口訪問權限，有非法訪問和操作是指有些數據很敏感，應限制能訪問的人。這個能訪問的人的集合實際上是能訪問堡壘機以及數據庫客戶端的人集合的子集。這個設計實際上卻做不到。
-
4. 當非法數據訪問和操作東窗事發后（如篡改數據、刪庫跑路），回過頭來查詢堡壘機審計記錄，即使能找到責任人都已經于事無補。如果事情沒有暴露，很可能都沒人知道或者關心是否有非法訪問數據問題。有些行業里數據泄露問題（被拖庫）很嚴重，這個訪問路徑有漏洞就是其中一個關鍵原因（另外一個泄露渠道是從應用出去的，那也是名義上的合法訪問路徑）。
堡壘機的管理權限在運維，權力在運維這邊，出問題追責時，運維自然也難以豁免。于是一種極端的做法就是嚴格管控有堡壘機訪問權限的人，對于非運維人員不允許或者盡可能少的訪問生產環境堡壘機里的數據庫終端或數據庫客戶端。至于這些人為什么要訪問數據庫，有什么需求就跟運維沒有關系了?；蛘呔椭苯诱f業務研發人員沒有需求訪問生產數據庫。直接從源頭上消滅這個問題。在管理學上，這叫“懶政”。
這種管理思想屬于“收”或“堵”。業務應用在線上運行，應用出功能問題或者性能問題時，不可避免的就要訪問數據庫進行排查。如果把這個正常的需求給堵死了，雖然運維一方的安全問題風險是降低了，但業務研發方卻會非常難受。站企業總體利益角度來說，這是有損的。
另外一種管理思想是“放”。把權限放出去。不同應用的數據庫從服務器上就彼此隔離（很多是虛擬機）。每個業務應用的數據庫的虛擬機訪問權限（SSH 終端或者數據庫客戶端終端）權限都給到應用負責人。應用自己用，出問題自己負責（運維只負責最基礎的數據庫部署、監控、主備高可用、備份等）。放權，也釋放一些不必要的責任。這個做法也有它的好處，組織運行效率更高，但是缺點也很明顯。問題還是可能出了，只是跟運維無關。這就是敏感數據泄露的一個常見原因。
網絡流量旁路產品
傳統數據庫安全產品里還有一類特殊的產品，在網絡層面通過對數據庫流量抓包來監控或攔截非法訪問或操作。這個設計符合安全邏輯，也不跟其他堡壘機或數據庫客戶端產品、或者應用沖突，也很常用。這個方案本質上是一個網絡流量監控方案（就跟我們都知道的那個防火墻設計一樣）。為了能將報文內容跟實際數據庫庫表聯系上，產品的使用還需要配置數據庫實例信息。
實際部署使用的時候，對網絡流量抓包對網絡性能會有影響。所以這類產品會做一個旁路設計，會將數據庫流量復制一份經過這個產品所在服務器網卡，然后進行分析。這就是旁路網絡流量。如何確保無損。生活中我們遭遇過在某些偏僻地方貴重物品失竊或者發生交通事故，當要調監控的時候得到的答復是“真不巧，這幾天的監控數據沒有或者這個監控已經壞了很長時間”。旁路流量就可能有這個問題。它只能證明事件記錄存在過，但是不能證明事件記錄不存在過。當數據庫規模很大的時候，要做到網絡流量旁路，硬件上也要做相應的投入。這個投入隨著業務的發展可能會出現“后勁不足”的地步。
流量旁路安全產品要解釋報文內容必須跟數據庫實例配合使用。它也不能阻止其他數據庫訪問通道。（所以產品受歡迎）。 它還會存在有些數據庫的流量并不在監控范疇內。當然，它最大的問題依然是只能監控不能管控。技術上是能管控攔截，但沒有人敢這么用，因為會降低數據庫讀寫性能，引起其他人和應用的抵制。
有沒有一種既能收攏權限保障數據安全又能方便用戶使用的方案或產品？傳統數據庫的運維思想、生態產品都已經固化，不大可能會變革了。這種方案或產品只可能出現在國產數據庫大興的時代了。
國產數據庫的權限管控思想
應用研發人員在國產數據庫項目中的困難
數據庫國產化，絕不僅僅是換個數據庫那么簡單。上下游的應用和相關人員都會受到影響。特別是應用研發人員，在數據庫國產化項目中會非常被動。
具體體現在：
-
對國產數據庫功能原理不熟悉，使用經常報錯，溝通解決成本很高。
這些用法可能在傳統數據庫里用了很多次都沒問題，到國產數據庫下就有問題。雖然有些應用研發也很有探索精神，但國產數據庫通常文檔欠缺或質量不高，網上相關案例文章經驗分享也很少，應用研發人員可以參考或者尋求幫助的途徑非常有限。在有些客戶項目里，很可能運維人員對國產數據庫也是一知半解的情況，出現問題溝通效率非常低。此時就依賴國產數據庫廠商原廠支持。
支持客戶是原廠售后的職責，但是讓客戶滿意卻是可遇不可求的事情。因為客戶非常多，每個客戶的問題也非常多，大量問題涌來，原廠支持人員的支持力度很難跟上。態度好的，按部就班；客戶第一的，疲于奔命。
如果是一個成熟的數據庫，應用研發只要增刪改查，都不會有問題。偶爾就是大批量數據查詢和修改有些性能問題。但國產數據庫雖然號稱兼容傳統數據庫（MySQL、ORACLE 或 PostgreSQL），但深入使用又會發現還是有些不一樣的地方。這個細節不一樣是合理的，特別對于那些是完全自主研發的國產數據庫，它只是功能接口兼容傳統數據庫，其底層原理完全是自主設計跟傳統數據庫的底層原理很可能完全不同。
所以深入使用國產數據庫時，是需要結合應用和數據庫的特點去重新設計優化的。把老的設計跑在新的國產數據庫上，有問題是難免的。有些應用研發也能認識到這點，只是難度在于數據庫的訪問受限，導致有些時候沒辦法自主研究，不得不去找運維溝通，或者找廠商溝通。這就又回到第一個現象里。這個受限通常是在生產環境。
當然設計優化更應該是在開發測試環境就要解決的。開發測試環境數據庫訪問限制會少很多，很多時候都是直接給到客戶端直接連接數據庫權限。
這個客戶端往往是傳統的數據庫客戶端。如 SQL Navicat、DBeaver、MySQLBench 之類。這些傳統的客戶端強在數據庫開發設計（如表結構設計、存儲過程設計等），弱在問題診斷能力。曾經有款很好的傳統數據庫客戶端 Toad（支持 MySQL/ORACLE/SQLServer/DB2等），內嵌了很多數據庫診斷腳本和文檔，可惜后來也沒落了。其他客戶端雖然沒有多少診斷能力，并不妨礙應用研發分析數據庫問題，因為傳統數據庫的生態很完善，很多問題在網上都有解決方案。而回到國產數據庫則相反。還是同樣的客戶端，同樣的用法，但是數據庫會有新的問題，很多時候研發都想不明白到底是什么問題。關于這類項目經驗說到具體的國產數據庫，那說一天也未必能說得完，以后再另起一篇文章分析。
所以，國產數據庫開發難問題，一部分跟國產數據庫權限管控有關，一部分跟數據庫產品功能成熟度和生態有關。
國產數據庫的數據安全問題和應對
傳統數據庫換做國產數據庫，可能應用也改造或者替換了。除此之外，人還是那些人。但從數據安全分析角度看，數據庫國產化，不過就是“舊瓶裝新酒”，面臨的數據安全挑戰一樣沒少，甚至更嚴峻。
國產數據庫特別是分布式數據庫，由于單機能力相比傳統數據庫單機能力要差一些，所以在規模上就遠超傳統數據庫服務器規模。另外一個重要原因是互聯網業務的發展促進數據規模和訪問流量的高速增長。多方面因素使得運維人員現在要管控的國產數據庫更多了。如果還是堡壘機加數據庫客戶端那種管理方式，其隱藏的安全風險可能會被進一步放大（窟窿更多了）。權力還是在運維手上沒什么變化，責任風險更大了。權責不匹配，久而久之，總會出問題。
不過有些國產數據庫出自互聯網大廠，在內部的時候造就積累了這類問題的應對經驗，很值得外部企業借鑒。螞蟻集團自主研發的分布式數據庫 OceanBase 以及其生態產品就是一個很好的學習例子。
OceanBase 基本占據了螞蟻業務里關系數據庫絕大部分市場，同時也進軍了阿里集團原屬于分布式 MySQL 數據庫的業務板塊（如高德、餓了嗎業務等）。OceanBase 在螞蟻和阿里集團的集群規模可以說非常龐大，其面臨的數據安全挑戰也就更大。
OceanBase 數據庫的生態產品里有一款客戶端產品 ODC，全名 OceanBase 開發者中心。最初目的就是降低 OceanBase 開發者使用門檻（這個開發者也包括螞蟻內部用戶），提升用戶使用體驗。翻譯成大白話就是 OceanBase 早期出來的時候運維人員和開發人員都抱怨太難用了。即使是到現在，還有些客戶在抱怨這點。其中有一部分原因還是傳統的數據庫安全管控方案。不過這里我們只說 OceanBase 產品自身的問題。
OceanBase 也從來沒有回避過這些問題，而是積極的通過產品迭代去不斷解決這類問題。如今在大部分客戶的心智里，OceanBase 的運維平臺 OCP 和開發者中心 ODC 是當之無愧的最好用的國產數據庫生態產品。當然迭代快的另外一個問題就是解決老問題的同時可能引入新問題。這點瑕不掩瑜，是否升級客戶自己抉擇。OceanBase 產品研發團隊也不回避這個問題，繼續迭代
ODC 是如何解決前面提到的易用性和安全問題呢？ 簡單總結如下：
-
1. ODC 里包含傳統數據庫客戶端基礎功能。如圖形化創建和查看數據庫對象能力（表/視圖/函數/存儲過程/觸發器等等）、SQL 窗口鄧麗。
-
2. ODC 的 SQL 窗口除了能執行 SQL，還能引導看執行計劃（解析執行計劃/實際執行計劃），有 SQL 執行畫像（解釋 SQL 執行性能中的關鍵數據，對性能診斷有幫助）
-
3. ODC 里引入了任務流和工單機制，支持數據庫變更需求。變更工單會有流程審批機制、定時執行機制、回滾機制。
-
4. ODC 支持數據安全需求。能對數據分級分類進行定義，查詢觸發敏感數據能自動攔截，并提示發起工單審批。目的合法的訪問敏感數據通過工單審批解決。所有在 ODC 里發起的查詢都在 ODC 里有審計記錄可以查詢。對于危險的 SQL 會給出風險提示，并按最高風險級別應對（發起工單審批）。工單里還可以附帶數據操作對應的備份回滾機制，審批人員檢查這個正確性。
-
5. ODC 里的賬戶都屬于 ODC 的平臺賬戶，不是數據庫里的賬戶。ODC 管理數據庫實例使用一個專用的高權限數據庫賬戶，用戶操作的權限管控都在 ODC 里做?？梢院唵卫斫鉃?ODC 就是 OceanBase 的數據庫堡壘機。
ODC 的數據安全應對思路就是通過堡壘機封堵其他數據庫訪問通道，所有人包括運維人員對數據庫的讀寫訪問都通過 ODC 。當然運維任務主要還是在 OCP 里完成，以及部分運維人員要登錄數據庫主機，這些訪問權限就通過堡壘機控制，收斂到只有少數運維人員自己可以操作。
ODC 確實能降低 OceanBase 的使用門檻，且將數據庫權限下放給業務研發人員又控制住了數據安全風險，是權責匹配的一個好的實現案例。有關 ODC 的詳細介紹可以參考文末另外一篇文章。
ODC 是 OceanBase 的數據庫堡壘機，這句話基本是對的。目前看 ODC 的發展也開始支持 ORACLE 、MySQL 和 PostgreSQL 的部分功能。ODC 能做這個的原理也是探索目標數據庫的功能原理去適配實現相應 ODC 場景。
有些企業客戶使用了多個國產數據庫，比如說達夢、OceanBase、TiDB、TDSQL、GaussDB。ODC 就支持不了這么多了。且不論 OceanBase 團隊會不會支持其他國產數據庫，其他數據庫廠商肯定不樂意支持 ODC 。
其他數據庫廠商也解決不了這個通用性問題。
云趣的數據庫安全管控產品 QueryX 的權限管控思想
所以，國產數據庫的數據安全問題的解決方案就最可能在第三方數據庫生態公司落地實現。下面介紹的就是浙江云趣公司的數據庫安全管控產品 QueryX 。
簡單的總結，QueryX 功能包含：
-
1. 支持常見的傳統數據庫（ORACLE/MySQL/PostgreSQL/SQLServer/MongoDB/Informix）、老牌國產數據庫（達夢/金倉/Gbase）、新興的分布式數據庫（OceanBase/TiDB/TDSQL/PolarDB-X/GaussDB/TDSQL/GoldenDB 等）。
-
2. 功能包含數據庫對象圖形化查看和變更、SQL執行窗口、工單流程系統、數據分級分類定義和權限管控。
-
3. 安全管控的核心思想也是將 QueryX 的平臺賬戶關聯到具體的用戶（人），QueryX 跟數據庫只有一個高權限賬戶，所有權限管控在 QueryX 內部實現。支持三權分立、查導分離。
QueryX 的安全管控也需要堡壘機封堵其他數據庫讀寫渠道，同時也不能監控業務的操作記錄。業務應用是合法的數據庫訪問途徑，應用內部的數據安全風險問題必須通過應用自身的日志、權限管控和審計功能去解決。這點在某些行業里（如銀行、證券）里顯得尤為必要。
下面舉一個使用場景例子。
某城市銀行的很多應用都是外部開發商提供。外包開發人員過千人，每周的數據庫變更任務成百上千。數據庫涉及到 MySQL、TiDB、OceanBase。 這些數據庫變更就是通過 QueryX 的工單系統去完成。平時的數據問題排查、數據導出，更是涉及到很多數據庫。運維人員自身肯定沒法一一管控到。借助于 QueryX，運維人員維護好實例后，還維護好對應的應用方負責人，有些工單審批也讓應用負責人從業務層面參與把關，運維人員做最基礎的檢查。然后工單的執行由平臺在自定義的時間（通常是晚上低峰期）去執行。這樣兩個運維人員就可以支持好幾千人的研發團隊的數據庫需求。
有關 QueryX 的詳細介紹可以參考文末鏈接。
總結
最后，不得不補充一句，以上討論的始終是技術層面的解決方案。國產數據庫的數據安全關鍵還是相關責任人的思想。說通俗一點就是要有責任心，同時又要有為其他人提供更好服務的意愿，那么再搭配好的產品就是如虎添翼。否則，數據庫國產化，舊瓶裝新酒，繼續沿用老的運維方式，只會讓國產化之路更加坎坷或者充滿風險。
此外，數據庫權限的收與放還影響業務研發人員的數據庫使用體驗。特別是國產數據庫，研發人員也是要從頭學習，缺乏必要的權限也就限制了研發主動分析解決問題的能力。問題是會客觀存在，并且會不斷放大。問題最終會傳遞到運維端。解決問題效率低下對企業整體利益也是有損的。
浙公網安備 33010502006954號 
