DBA 日常：規模使用者資料庫訪問許可權管理

前言

研發、資料分析師及運維內部人員有資料查詢、資料訂正等需求。若無管控平臺，則只能透過授予賬號的形式來授權這些使用者直接訪問資料庫。一般會按型別建幾個不同級別許可權的賬號給對應的同學使用，這會導致以下問題：

1. 因為一個賬號對應的使用人很多，無法精準的定位請求人；同時只能依靠賬號許可權來限制使用者行為，無法對請求進行流程上（經審批人稽核）的約束；
2. 同時受訪問的資料庫的穩定性也無法得到保障，若有訪問許可權的使用者執行了高消耗的 SQL 很有可能會導致資料被打掛；
3. 賬號許可權調整繁瑣，若要限制某個使用者訪問，則需要修改使用者密碼，然後再知會出限制人外的其它人修改資訊。

從這些問題中我們能夠發現，在企業級開發場景中，需要將資料庫的訪問許可權納入管控，以免造成資料洩露、丟失、濫用等問題。這時就需要一款具備許可權管理和安全協同能力的資料庫開發工具，幫助 DBA 在完成管控任務的同時，儘可能降低運維成本。OceanBase 開發者中心（ODC）作為 OceanBase 資料庫官方配套的開發平臺，自 V3.2.0 版本引入許可權模型以來，提供了公共資源的全生命週期許可權管理能力，現已迭代至 V4.1.0 版本。那麼，大家瞭解 ODC 資料庫訪問許可權管理背後的設計思考和基本原理嗎？為了幫助大家更順暢地使用 ODC，以及遇到問題時能夠更快速地解決，本文將以資料庫的訪問控制為例，為大家解答上述問題。

案例分析：如何給 DBA 減負？

首先來看一個真實案例：某網際網路公司電商業務的開發環境共有 OceanBase 資料庫 250 套，需要分配給 3 個業務部門使用，要求每個部門的資料庫相互之間不可見。公司電商業務線擁有約 200 名研發人員，但僅有 1 個由 3 人組成的 DBA 團隊，並且處於業務上升期，頻繁有新員工加入和部門間人事調動。

在大多數企業級場景下，研發人員數量遠大於 DBA，如何給 DBA 減負是個亟需解決的問題：

問題一：黑屏操作很繁瑣，況且為了保證資料庫安全可控，也不能將連線賬密直接給研發同學，該如何管理呢？

問題二：研發人員太多管不過來，不如讓各部門 Leader 自己管，如何優雅地下放許可權呢？全公司用一套系統，怎麼保證部門間的資源隔離？

問題三： 新員工加入到研發團隊，每次都要手動給他/她授權，如何解放 DBA 的雙手？

ODC 如何解決這些問題

下面我們來看使用ODC怎麼解決上述問題，只需以下關鍵三點：

第一，資源許可權管理

ODC 提供了公共資源許可權管理的功能。具備管理許可權的使用者登入 ODC 後，可以進入公共資源管控臺後，進行資料庫資源許可權的分配和管控。例如針對上述客戶案例，可以進行如下配置：新建角色  department_A_RD 併為其分配  生產庫 A 的只讀許可權和  研發庫 A 的讀寫許可權，然後將角色  department_A_RD 授予隸屬  部門 A 的研發人員。那麼， 部門 A 的研發人員登入 ODC 後將自動獲得相應資料庫的訪問許可權。

第二，靈活配置許可權

ODC 提供兩種授權方式供使用者靈活選擇：一是透過建立角色，配置角色擁有的許可權，然後將角色授予使用者，來讓使用者獲得角色擁有的相應許可權；二是直接以公共連線為單位，管理使用者的訪問許可權。

透過角色間接管理使用者許可權的方法適用於批次管理的場景。例如，需要讓  部門 A 的所有研發人員都擁有  生產庫 A 的只讀許可權，就可以透過建立角色配置  生產庫 A 的只讀訪問許可權，並將該角色授予  部門 A 的研發人員來實現。對於一些定製化場景，例如需要給  部門 A 中的特定幾名員工授予  高危資料庫 的訪問許可權，就可以直接在 ODC 管控臺中，將這幾名員工的賬號新增到可訪問高危資料庫的使用者列表中，而不需要額外建立角色。

ODC V4.1.0 版本還支援為角色配置資源管理許可權和系統操作許可權。透過該功能，可以將部分低危資料庫的管理許可權下放給部門管理員，降低 DBA 的工作負擔。

第三，自動授權規則

基於上述功能，ODC 已經能夠解決規模使用者的資料庫訪問許可權管理問題。為了進一步減少人工干預、節省人力成本，ODC V4.1.0 推出了自動授權功能。該功能允許使用者使用文字表示式配置授權規則，實現通用化場景下的自動授權操作。例如，要讓  部門 A 的新員工首 次登入 ODC 後自動獲得  部門 A 研發人員 的許可權和  高危資料庫 的可申請許可權，可配置圖示自動授權規則：

ODC 解決問題的背後邏輯

透過上面的例子，我們不難發現，ODC 解決問題背後的邏輯涉及兩方面，一方面是許可權模型，另一方面是許可權框架。

許可權模型

ODC 採用基於角色的訪問控制（Role-Based Access Control, RBAC）和基於屬性的訪問控制（Attribute-Based Access Control, ABAC）並存的許可權模型，如下圖所示。基於 RBAC 模型，ODC 可以實現使用者許可權的批次操作和統一管理；基於 ABAC 模型，ODC 可以跳過角色直接將許可權授予使用者，適用於細粒度的訪問控制。兩種許可權模型互不干擾：在對使用者操作進行鑑權時，會同時從這兩條線路計算使用者許可權，只要任意一條透過即透過鑑權。

許可權框架

許可權框架主要完成兩個任務：一是對許可權本身進行抽象和管理；二是為鑑權提供介面和實現。

許可權的抽象

許可權可以抽象為對資源的行為。在 ODC 中，我們使用資源表示式對資源其進行表述，其採用層級化思想，結構為： ${ResourceType}:${ResourceId}[/${ResourceType}:${ResourceId}/...]。例如，對於 ID 為 1 的公共連線，用  ODC_CONNECTION:1表示；對於 ID 為 1 的資源組中的所有公共連線，可以用  ODC_RESOURCE_GROUP:1/CONNECTION:*表示。

ODC 使用者可獲得的資料庫許可權包括訪問許可權和管理許可權。其中，訪問許可權包括可申請、只讀和讀寫；管理許可權包括僅檢視、可編輯、可管理、可新建。使用行為描述符的組合來對資源的許可權進行表述，具體如下：

不同的行為之間可能存在隱含關係。例如，若使用者擁有公共連線的讀寫（connect）許可權，就自然應該有該公共連線的僅檢視（read）和可申請（apply）許可權。 ODC 透過二進位制掩碼的位運算實現不同行為間隱含關係的判斷：若行為 1 的掩碼與行為 2 的掩碼進行 按位與（&） 操作後等於行為 2 的掩碼，則說明行為 2 隱含了行為 1。

鑑權流程

使用者要想對資料庫等公共資源進行訪問和管理，都需要發起 API 呼叫請求，獲取返回值。API 呼叫本質上是呼叫 ODC 後端的方法。因此，鑑權的時機可以放在方法呼叫前和執行結果返回前，具體鑑權流程如下圖所示：

鑑權的邏輯可以簡要概括為：獲取當前的使用者資訊，然後從後設資料庫中查詢使用者直接擁有的許可權和透過關聯角色而獲得的許可權，接著將使用者已有的許可權（acquiredPrivilege）和執行方法所需的許可權（requiredPrivilege）進行比對，如果 acquiredPrivilege 隱含了 requiredPrivilege，則透過鑑權；否責鑑權不透過，程式會丟擲異常。

小結

管控協同在企業開發場景下實屬剛需。本文以資料庫的訪問控制為例，向您介紹了 ODC 在許可權管理上的產品形態和實現原理。由於內容不涉及太多技術細節，大家有相關疑問可以在評論區展開討論。事實上，ODC 的管控協同能力才剛剛嶄露頭角。未來，我們將支援庫、表、敏感列等更細粒度的許可權管理，並提供更易用的團隊協同互動體驗，敬請期待！