權限管理

企業IT管理員一般都能為系統定義角色，給用户分配角色。這就是最常見的基於角色訪問控制。場景舉例：

1、給張三賦予“人力資源經理”角色，“人力資源經理”具有“查詢員工”、“添加員工”、“修改員工”和“刪除員工”權限。此時張三能夠進入系統，則可以進行這些操作；

2、去掉李四的“人力資源經理”角色，此時李四就不能夠進入系統進行這些操作了。

以上舉例，侷限於功能訪問權限。還有一些更加豐富、更加細膩的權限管理。比如：

1、因為張三是北京分公司的“人力資源經理”，所以他能夠也只能夠管理北京分公司員工和北京分公司下屬的子公司（海淀子公司、朝陽子公司、西城子公司、東城子公司等）的員工；

2、因為王五是海淀子公司的“人力資源經理”，所以他能夠也只能夠管理海淀子公司的員工；

3、普通審查員審查財務數據的權限是：在零售行業審核最高限額是￥50萬，在鋼鐵行業最高限額是￥1000萬；高級審查員不受該限額限制；

4、ATM取款每次取款額不能超過￥5000元，每天取款總額不能超過￥20000元。

這些權限管理和數據（可以統稱為資源）直接相關，又稱為數據級權限管理、細粒度權限管理或者內容權限管理。

從控制力度來看，可以將權限管理分為兩大類：

1、功能級權限管理；

2、數據級權限管理。

從控制方向來看，也可以將權限管理分為兩大類：

1、從系統獲取數據，比如查詢訂單、查詢客户資料；

2、向系統提交數據，比如刪除訂單、修改客户資料。

用户身份認證，根本就不屬於權限管理範疇。用户身份認證，是要解決這樣的問題：用户告訴系統“我是誰”，系統就問用户憑什麼證明你就是“誰”呢？對於採用用户名、密碼驗證的系統，那麼就是出示密碼。當用户名和密碼匹配，則證明當前用户是誰；對於採用指紋等系統，則出示指紋；對於硬件Key等刷卡系統，則需要刷卡。

密碼加密，是隸屬用户身份認證領域，不屬於權限管理範疇。

系統管理，一般是系統的一個模塊。而且該模塊一般還含有權限管理子模塊。因此，很多人誤認為權限管理系統只是系統的一個小小的子模塊。系統管理裏面的權限管理模塊，只是一個操作界面，讓企業IT管理員能夠設置角色等安全策略。系統背後還有很多權限驗證邏輯，這些都並不屬於該模塊。總體來説，該模塊相當於給權限管理模塊提供了一些數據，比如：張三是人力資源經理等。

更多混淆概念，請參考：《對權限管理認識的一些誤區》。

按照權限管理的力度，逐步介紹權限管理實現技術。

功能權限管理技術，一般就使用基於角色訪問控制技術RBAC（Role Based Access Control）。該技術被廣泛運用於各個系統，非常容易掌握。該技術模型如圖1示：

權限設置

一般來説，系統提供如下功能：

1、角色管理界面，由用户定義角色，給角色賦權限；

2、用户角色管理界面，由用户給系統用户賦予角色。

3、一些優秀系統，還支持用户定義權限，這樣新增功能的時候，可以將需要保護的功能添加到系統。

這裏，我們談談Spring Security框架。它將訪問角色固化到程序代碼裏面。那麼這種控制就相當於由軟件開發人員完成，而不是最終用户。這從實施角度來看，是完全錯誤的。更多閲讀，可以查看《Spring Security優劣之我見》。

功能級的權限驗證邏輯非常簡單。查看該當前登錄用户的角色是否包含該功能的權限。如果有，則表示有權訪問，否則表示無權訪問。

對於WEB系統，一般定義一個Filter就可以完成權限驗證，無需在各個程序入口進行權限判斷。程序偽代碼如下：

// 獲取訪問功能

String url=request.getRequestPath();

// 進行權限驗證

User user=request.getSession().get("user");

boolean permit=PrivilegeManager.permit( user, url );

if( permit ) {

chain.doFilter( request, response );

} else {

// 可以轉到提示界面

}

目前，數據級權限管理領域，一直沒有統一的技術。大體上，軟件開發人員採用如下技術：

1、硬編碼，也就是將這種邏輯以if/else等形式與業務代碼耦合在一起，這種情況居多；

2、使用規則引擎，也有一些企業將這種邏輯以規則形式提出來，並使用規則引擎解析規則；

3、使用第三方專業軟件，有開源中間件Ralasafe ^[1]  ；開源框架Spring Security ^[2]  ；商業產品Oracle Entitlements Server，IBM Tivoli Access Manager，UPMS通用用户權限系統等。

硬編碼形式弊端是非常顯然的。耦合性強，難以測試；系統組件複用率低；系統後期改動代價非常大，牽一髮而動全身。

使用規則引擎可以解決很多問題，學習難度尚可。但規則引擎並不是專業用於權限管理的，所以對於複雜一些的權限管理，就顯得力不從心。

Ralasafe和Oracle、IBM的商業產品一樣，都是中間件形式。對應用系統和應用數據庫結構沒有要求。都有管理界面進行直接操控管理，而且都能在線進行測試。相比較，Ralasafe還可以控制查詢權限（即從系統查詢訂單、查詢客户等），Oracle、IBM的商業產品沒有這方面功能；從產品學習難度來看，Ralasafe只要有一些IT經驗，就能快速上手；Oracle、IBM產品即使是專業人員，也難以掌握。

Spring Security是框架，需要對你的應用系統進行改動，你的系統必須在該框架進行設計編寫。它只是幫助開發人員將權限提取出來了，但數據級權限還需要開發人員開發Voter。而且配置工作巨大，難以測試。

雖然上述提到的產品，都是Java產品。但Ralasfe和Oracle、IBM的商業產品，以中間件形式，可以部署在獨立服務器上，使用web service等方式與非Java系統交互。

這是很多系統都能做到的。讓系統使用者（一企業IT管理員）定義角色，給用户分配角色。成功實施該步驟，用户能在功能級進行權限管理。整個過程無需軟件開發商參與。

有些複雜一點的系統，提供了一些規則和管理界面，可以讓系統使用者（一般是企業IT管理員）輸入規則參數。比如普通審查員審查財務數據的金額區間，勾選某用户能夠查詢哪些組織機構的訂單數據。

這是給企業提供了部分控制數據級權限的能力。但該能力還非常弱，僅限於已定義好的策略，不能適應安全策略變化。而，企業需求肯定會隨着業務發展、時間推移，發生變化。比如：普通審查員審查區間由原來的單一設置區間，改為按照行業、按照地域來設置不同的區間。用户查詢訂單不僅和組織機構有關，還和訂單業務領域（體育、食品等）有關。當這些需求發生的時候，企業還要求助於軟件開發商進行修改。

企業完整掌控安全策略，應該包括2個方面內容：1，功能級權限管理完全自我掌控；2，數據級權限管理完全自我掌控。實現這方面需要，還需要考慮企業的IT能力：IT能力沒有軟件開發商強，而且權限管理涉及整個系統安全，關係重大。因此軟件必須是這樣的：1，圖形化、集中管理的，便於企業管理；2，可在線測試的，定製策略後在不影響業務的情況下，進行測試，確保無誤。

目前，就Ralasafe和Oracle、IBM產品滿足要求。

不良的權限管理系統，必然留下系統漏洞，給黑客可趁之機。很多軟件可以輕鬆通過URL侵入、SQL注入等模式，輕鬆越權獲得未授權數據。甚至對系統數據進行修改、刪除，造成巨大損失。

很多系統，尤其是採用硬編碼方式的系統，存在權限邏輯與業務代碼緊密耦合，同時又分散在系統各個地方。系統漏洞勢必非常多，而且隨着系統不斷修改，漏洞逐步增多。 好的系統，應該將權限邏輯集中起來，由專業的安全引擎進行設置、解析。業務邏輯調用安全引擎，獲得權限結果，不再使用非專業模式。