關於資料許可權設計的一些想法

Franson發表於2016-06-08

序言

        在各種系統中,要保證資料物件的安全性以及易操作性,使企業的各業務部門、職能部門能夠方便而且高效的協同工作,那麼一個好的資料許可權管理設計就成為一個關鍵的問題。雖然企業中各個單元的工作流程有所不同,處理的資料物件也有所不同,但是在組織結構、資訊的處理方式上具有很多相同的地方,這就為設計資料物件的許可權控制提供了一個抽象基礎。資料許可權的控制不同於一般的功能許可權的控制,一般的功能許可權指的是某個使用者、角色或者是某個使用者組能不能操作某種功能。而資料許可權指的是某個使用者、角色或者是某個使用者組對某個資料物件的操作邊界的問題,比如說使用者A可以對資料物件進行完全控制,而使用者B則只能對資料物件進行瀏覽的許可權,部門主管可以檢視隸屬該部門所有同事的資訊,某個同事只能檢視他自己的資訊等等。

同時資料許可權控制隸屬於動態許可權控制的範疇。

資料許可權設計

        在當前的許多應用程式中都會涉及到許可權管理,許可權主要分為功能許可權和資料許可權,至於功能許可權相對簡單些,網上也有不少的實現方案,這裡不再介紹,下邊主要探討下資料許可權的設計方案。

        資料許可權跟功能許可權有很大的不同,顆粒度很小,貫穿於整個專案的開發週期中,無法像功能許可權一樣在專案要結尾的時候追加,也有一些公司有自己的許可權元件(功能許可權),給已完成的專案配上許可權元件就生效了。資料許可權做不到元件級別,必須在專案設計階段就已經規劃好。之前看網上同樣有人想基於spring切面的原理去實現資料許可權,這樣就可以做到了低侵入、低耦合,想法很好,可是現實很骨感,這樣做使整個應用系統效率大減折扣,同樣對資料許可權的控制策略也很不靈活。

        下邊提出自己的設計方案,在系統中獨立一個資料許可權模組,該模組可以根據當前業務模組的SQL、當前操作人資訊、當前許可權的策略來自動生成對應的帶資料許可權的SQL語句給業務模組繼續處理,如下圖所示:

 

資料許可權設計分析

SQL語句可擴充套件

        資料許可權往往作為功能許可權的高階行為,可以從資料物件的幅度方面進行控制,比如使用者只能看自己的訂單、普通會員看不到某資料物件的高階屬性(欄位)等等。顆粒度這麼細的情況下對結果集處理顯然是不可能了,這時只能介入到SQL語句中了,此時又不想在開發階段讓開發人員過多的考慮資料許可權的問題,這時最好把SQL語句給提到一個配置檔案中,或者資料庫中,開發階段只需開發人員通過資料許可權模組的介面呼叫得到已實現資料許可權控制的SQL語句,這樣也算做到的程式碼的低侵入。

SQL語句高效解析處理

        資料許可權模組的核心之一就有SQL語句的高效解析處理,SQL處理指根據當前登入人資訊及資料許可權策略生成一個帶有資料許可權處理結果的SQL語句,所以這裡對SQL語句的解析處理必須要求精確、準確。在開發階段由開發人員把SQL寫入到配置檔案中,在執行階段由資料許可權取得該SQL進行分析處理(加上資料許可權),這樣就完成了SQL的組裝處理。

資料許可權策略設計

        最核心的地方就是資料許可權策略的設計了,這裡先引入幾個概念:

1、資源:資料許可權的控制物件,業務系統中的各種資源。比如訂單單據、銷售單等

2、主體:使用者、部門(使用者組)、角色等

3、規則:用於【資料許可權】的條件規則

4、許可權:功能許可權(如選單許可權),資料許可權,欄位許可權 

這裡側重分析下主體及規則,主體有層級關係,可以為不同主體設定不同規則,比如:當前資料僅對建立人(或者某個人)有效、下級主體的許可權對於上級主體同樣有效(可配置,如可勾選)、非當前主體只能看到部分資料(部分資料可選)。這裡只提供部分規則示例,現實環境中需要根據企業環境或者專案環境去完善這些規則。

資料許可權策略優化

        資料許可權同樣屬於許可權範疇,每次訪問都會去請求驗證許可權,所以許可權的認證必須要高效,這時可以寫演算法或者是用MEMCACHE等來提高響應速度。

相關文章