權限設計=功能權限+數據權限

權限設計=功能權限+數據權限

權限管理 Authority Management

目前主要是經過用戶、角色、資源三方面來進行權限的分配。
具體來講，就是賦予用戶某個角色，角色能訪問及操做不一樣範圍的資源。
經過創建角色系統，將用戶和資源進行分離，來保證權限分配的實施。

通常指根據系統設置的安全規則或者安全策略，
用戶能夠訪問並且只能訪問本身被受權的資源。

---

場景舉例

企業IT管理員通常都能爲系統定義角色，給用戶分配角色。
這就是最多見的基於角色訪問控制。

場景舉例：

1. 給張三賦予「人力資源經理」角色，「人力資源經理」具備「查詢員工」、「添加員工」、「修改員工」和「刪除員工」權限。此時張三可以進入系統，則能夠進行這些操做；
2. 去掉李四的「人力資源經理」角色，此時李四就不可以進入系統進行這些操做了。

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

好比：

1. 由於張三是北京分公司的「人力資源經理」，因此他可以也只可以管理北京分公司員工和北京分公司下屬的子公司（海淀子公司、朝陽子公司、西城子公司、東城子公司等）的員工；
2. 由於王五是海淀子公司的「人力資源經理」，因此他可以也只可以管理海淀子公司的員工；
3. 普通審查員審查財務數據的權限是：在零售行業審覈最高限額是￥50萬，在鋼鐵行業最高限額是￥1000萬；高級審查員不受該限額限制；
4. ATM取款每次取款額不能超過￥5000元，天天取款總額不能超過￥20000元。

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

---

分類

從控制力度來看，能夠將權限管理分爲兩大類：

1. 功能級權限管理；
2. 數據級權限管理。

從控制方向來看，也能夠將權限管理分爲兩大類：

1. 從系統獲取數據，好比查詢訂單、查詢客戶資料；
2. 向系統提交數據，好比刪除訂單、修改客戶資料。

---

概念

用戶身份認證，是要解決這樣的問題：用戶告訴系統「我是誰」，系統就問用戶憑什麼證實你就是「誰」呢？
因此，用戶身份認證，根本就不屬於權限管理範疇。
　　對於採用用戶名、密碼驗證的系統，那麼就是出示密碼
　　——當用戶名和密碼匹配，則證實當前用戶是誰；
　　對於採用指紋等系統，則出示指紋；
　　對於硬件Key等刷卡系統，則須要刷卡。
密碼加密，是隸屬用戶身份認證領域，不屬於權限管理範疇。

系統管理，通常是系統的一個模塊。
並且該模塊通常還含有權限管理子模塊。
所以，不少人誤認爲權限管理系統只是系統的一個小小的子模塊。

系統管理裏面的權限管理模塊，只是一個操做界面，讓企業IT管理員可以設置角色等安全策略。
系統背後還有不少權限驗證邏輯，這些都並不屬於該模塊。
整體來講，該模塊至關於給權限管理模塊提供了一些數據，好比：張三是人力資源經理等。
更多混淆概念，請參考：《對權限管理認識的一些誤區》。

---

技術實現

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

① 功能權限管理技術實現

功能權限管理技術，通常就使用基於角色訪問控制技術RBAC（Role Based Access Control）。該技術被普遍運用於各個系統，很是容易掌握。該技術模型以下圖示：

權限驗證
功能級的權限驗證邏輯很是簡單：查看該當前登陸用戶的角色是否包含該功能的權限。
若是有，則表示有權訪問，不然表示無權訪問。
對於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；
    開源框架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系統交互。

---

實施

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

② 部分預約義好的數據級權限
有些複雜一點的系統，提供了一些規則和管理界面，
可讓系統使用者（通常是企業IT管理員）輸入規則參數。

好比普通審查員審查財務數據的金額區間，勾選某用戶可以查詢哪些組織機構的訂單數據。

這是給企業提供了部分控制數據級權限的能力。
但該能力還很是弱，僅限於已定義好的策略，不能適應安全策略變化。
並且，企業需求確定會隨着業務發展、時間推移，發生變化。

好比：普通審查員審查區間由原來的單一設置區間，改成按照行業、按照地域來設置不一樣的區間。
用戶查詢訂單不只和組織機構有關，還和訂單業務領域（體育、食品等）有關。

當這些需求發生的時候，企業還要求助於軟件開發商進行修改。

③ 企業徹底掌控安全策略

企業完整掌控安全策略，應該包括2個方面內容：

1. 功能級權限管理徹底自我掌控；
2. 數據級權限管理徹底自我掌控。

實現這方面須要，還須要考慮企業的IT能力：
IT能力沒有軟件開發商強，並且權限管理涉及整個系統安全，關係重大。

所以軟件必須是這樣的：

1. 圖形化、集中管理的，便於企業管理；
2. 可在線測試的，定製策略後在不影響業務的狀況下，進行測試，確保無誤。
   目前，就Ralasafe和Oracle、IBM產品知足要求。

---

注意問題

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

不少系統，尤爲是採用硬編碼方式的系統，存在權限邏輯與業務代碼緊密耦合，
同時又分散在系統各個地方，系統漏洞勢必很是多，
並且隨着系統不斷修改，漏洞逐步增多。

好的系統，應該將權限邏輯集中起來，由專業的安全引擎進行設置、解析。
業務邏輯調用安全引擎，得到權限結果，再也不使用非專業模式。

這種轉變，如圖示：

---

權限能夠怎樣設計？

• 後臺設計三原素

• 聯運後臺的設計

原文地址：https://www.jianshu.com/p/0ab125cf8258