許可權管理，一般指根據系統設定的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源，不多不少。許可權管理幾乎出現在任何系統裡面，只要有用戶和密碼的系統。 很多人常將“用戶身份認證”、“密碼加密”、“系統管理”等概念與許可權管理概念混淆。
基本介紹
- 中文名：許可權管理
- 外文名：authority management
- 規則：根據系統設定的安全規則
- 分類：身份認證”、“密碼加密”
- 認證：用戶和密碼的系統
場景舉例,分類,概念,技術實現,實施,注意問題,
場景舉例
1、給張三賦予“人力資源經理”角色，“人力資源經理”具有“查詢員工”、“添加員工”、“修改員工”和“刪除員工”許可權。此時張三能夠進入系統，則可以進行這些操作；
2、去掉李四的“人力資源經理”角色，此時李四就不能夠進入系統進行這些操作了。
以上舉例，局限於功能訪問許可權。還有一些更加豐富、更加細膩的許可權管理。比如：
2、因為王五是海淀子公司的“人力資源經理”，所以他能夠也只能夠管理海淀子公司的員工；
3、普通審查員審查財務數據的許可權是：在零售行業審核最高限額是￥50萬，在鋼鐵行業最高限額是￥1000萬；高級審查員不受該限額限制；
4、ATM取款每次取款額不能超過￥5000元，每天取款總額不能超過￥20000元。
這些許可權管理和數據（可以統稱為資源）直接相關，又稱為數據級許可權管理、細粒度許可權管理或者內容許可權管理。
分類
從控制力度來看，可以將許可權管理分為兩大類：
1、功能級許可權管理；
2、數據級許可權管理。
從控制方向來看，也可以將許可權管理分為兩大類：
1、從系統獲取數據，比如查詢訂單、查詢客戶資料；
2、向系統提交數據，比如刪除訂單、修改客戶資料。
概念
用戶身份認證，根本就不屬於許可權管理範疇。用戶身份認證，是要解決這樣的問題：用戶告訴系統“我是誰”，系統就問用戶憑什麼證明你就是“誰”呢？對於採用用戶名、密碼驗證的系統，那么就是出示密碼。當用戶名和密碼匹配，則證明當前用戶是誰；對於採用指紋等系統，則出示指紋；對於硬體Key等刷卡系統，則需要刷卡。
密碼加密，是隸屬用戶身份認證領域，不屬於許可權管理範疇。
系統管理，一般是系統的一個模組。而且該模組一般還含有許可權管理子模組。因此，很多人誤認為許可權管理系統只是系統的一個小小的子模組。系統管理裡面的許可權管理模組，只是一個操作界面，讓企業IT管理員能夠設定角色等安全策略。系統背後還有很多許可權驗證邏輯，這些都並不屬於該模組。總體來說，該模組相當於給許可權管理模組提供了一些數據，比如：張三是人力資源經理等。
更多混淆概念，請參考：《對許可權管理認識的一些誤區》。
技術實現
按照許可權管理的力度，逐步介紹許可權管理實現技術。
4.1、功能許可權管理技術實現
功能許可權管理技術，一般就使用基於角色訪問控制技術RBAC（Role Based Access Control）。該技術被廣泛運用於各個系統，非常容易掌握。該技術模型如下圖示：
RBAC許可權模型
RBAC許可權模型許可權設定
一般來說，系統提供如下功能：
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 {
// 可以轉到提示界面
}
4.2、數據級許可權管理技術實現
目前，數據級許可權管理領域，一直沒有統一的技術。大體上，軟體開發人員採用如下技術：
1、硬編碼，也就是將這種邏輯以if/else等形式與業務代碼耦合在一起，這種情況居多；
2、使用規則引擎，也有一些企業將這種邏輯以規則形式提出來，並使用規則引擎解析規則；
3、使用第三方專業軟體，有開源中間件Ralasafe；開源框架Spring Security；商業產品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系統互動。
實施
5.1、功能級許可權控制
這是很多系統都能做到的。讓系統使用者（一企業IT管理員）定義角色，給用戶分配角色。成功實施該步驟，用戶能在功能級進行許可權管理。整個過程無需軟體開發商參與。
5.2、部分預定義好的數據級許可權
有些複雜一點的系統，提供了一些規則和管理界面，可以讓系統使用者（一般是企業IT管理員）輸入規則參數。比如普通審查員審查財務數據的金額區間，勾選某用戶能夠查詢哪些組織機構的訂單數據。
這是給企業提供了部分控制數據級許可權的能力。但該能力還非常弱，僅限於已定義好的策略，不能適應安全策略變化。而，企業需求肯定會隨著業務發展、時間推移，發生變化。比如：普通審查員審查區間由原來的單一設定區間，改為按照行業、按照地域來設定不同的區間。用戶查詢訂單不僅和組織機構有關，還和訂單業務領域（體育、食品等）有關。當這些需求發生的時候，企業還要求助於軟體開發商進行修改。
5.3、企業完全掌控安全策略
企業完整掌控安全策略，應該包括2個方面內容：1，功能級許可權管理完全自我掌控；2，數據級許可權管理完全自我掌控。實現這方面需要，還需要考慮企業的IT能力：IT能力沒有軟體開發商強，而且許可權管理涉及整個系統安全，關係重大。因此軟體必須是這樣的：1，圖形化、集中管理的，便於企業管理；2，可線上測試的，定製策略後在不影響業務的情況下，進行測試，確保無誤。
目前，就Ralasafe和Oracle、IBM產品滿足要求。
注意問題
不良的許可權管理系統，必然留下系統漏洞，給黑客可趁之機。很多軟體可以輕鬆通過URL侵入、SQL注入等模式，輕鬆越權獲得未授權數據。甚至對系統數據進行修改、刪除，造成巨大損失。
許可權由緊密分散，轉換為集中專業管理
許可權由緊密分散，轉換為集中專業管理