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

權限管理 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注入等模式，輕松越權獲得未授權數據。
甚至對系統數據進行修改、刪除，造成巨大損失。

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

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

這種轉變，如圖示：

 

---

權限可以怎樣設計？

1、后台設計（一）：后台設計三原素

后台系統，在目前接觸來看，主要分幾種：管人、管事、管物。管人的，有對內和對外的兩種類型，對外的CRM（客服管理系統）、對內的考勤系統；管事的，簡而言之，就是人可以做什么事、可以怎樣去做事，這種最經典的就是數據統計后台、業務流管理后台；管物的，主要是指電商類型的商城管理后台，用於管理商品的交易

    但是，從本質上看，后台主要有權限管理、工作流、記錄流三大方面。可以歸結為一句話，誰可以對什么進行怎樣的操作，需要產生什么記錄：簡稱who-where-how-what

權限管理（who-where）

權限管理，是指一般指根據系統設置的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源。通俗解釋就是，誰是否對某資源具有實施 某個動作（運動、計算）的權限

      權限管理，目前主要是通過用戶、角色、資源三方面來進行權限的分配。具體來說，就是賦予用戶某個角色，角色能訪問及操作不同范圍的資源。通過建立角色系統，將用戶和資源進行分離，來保證權限分配的實施。

       那么，權限可以怎樣設計呢？

       如果是業務流后台，在設計權限時，可以按業務類型進行角色設計，比如客服、運營、充值員；如果是數據統計后台，可以按用戶類型來進行角色設計，如對外用戶、內部人員；如果是CRM，則可以按用戶的職位等級進行划分。在進行一級划分后，往往還需要對角色進行細分，例如客服，可以細分為 普通客服、客服組長、客服總監，通過級別的划分來控制可訪問及操作的數據。

        另外，在進行角色的細化時，有兩點是需要注意的：

1. 同類型的角色，上下級角色的權限關聯是怎樣的？上級角色是否能對下級角色的業務進行操作？下架的操作是否需要上級的審核？

2. 對外用戶，是采取權限分離，還是采取兩個不同的后台去處理？前者的話，實現起來方便一些，就看系統對於安全性的考慮；后者的話，會更加的安全，在數據的處理上也會方便一些

        雖然我們將權限管理放在第一位，但是在實際開發過程中，權限的分配往往是在整個后台開發完畢后才去實現的（主要是為了避免權限設置對開發造成影響）。

工作流（how）

工作流（Workflow），指“業務過程的部分或整體在計算機應用環境下的自動化”。是對工作流程及其各操作步驟之間業務規則的抽象、概括描述

        工作流主要解決的主要問題是：為了實現某個業務目標，利用計算機在多個參與者之間按某種預定規則自動傳遞文檔、信息或者任務。

        設計工作流時，除了最基本的單個后台工作流的設計，還有多個后台之間進行工作流的設計。OK，先從最基本的單個后台開始聊聊，工作流的設計，其實和2C產品的需求設計很相似：

1. 在了解業務需求后，產出適合的業務流程圖（業務流程圖此處不展開，稍后另開一章來寫）、狀態圖（部分簡單的工作流不需要出這個），通過業務流程圖，向開發更好的傳遞業務需求

2. 搭建工作流的產品架構圖，主要是羅列工作流涉及到的功能模塊（廣度思考），這個時候，就可以將產品架構圖和其他人進行碰撞；為什么不使用產品原型圖來碰呢？這個以下幾點原因：

（1）產品原型產出周期較長，不適合前期的思維碰撞

（2）產品架構圖比產品原型返工更容易，能夠更快的迭代

（3）可以針對后期加入的需求低成本的進行討論，使開發設計庫表時，更好的考慮拓展性

3. 通過前兩步，基本可以把工作流較好的傳遞給研發那邊；緊接着，可以將產品架構圖進行細化，細化到什么程度呢？最好是把工作流涉及的點都能夠細化在上面，這樣，在產出產品原型圖的時候，可以更加全面的是思考單個模塊與整個后台系統之間的交互

4.在第三點，有提到了產品架構圖的細化，接着，就是放大招的時候— 出產品原型圖

5.適當的重復上述3、4點，這樣，一個較完整的工作流就設計好了

      在出了產品原型圖，就要開始和研發大大進行更凶殘的肉體碰撞了，關於肉體碰撞的細節，在這里就不展開了，但是可以補充一句：做產品得耐操！

      上面講述的都是單個系統內的工作流設計，那么 多個系統協同處理的工作流有什么不同呢？

      首先在設計上，基本流程不會有區分。主要是要和系統架構師多多溝通，讓一整套系的工作流能夠更好的滿足業務需求。在進行溝通的時候，最好可以先自己擬定一份假想架構圖，這份產出物更多關注的是不同系統之間的數據交互，表明系統間的輸出、輸入，這樣，在定好滿足需求的架構上，才能夠更好的對工作流進行設計。

       其次，還有一點細節是需要關注的，那就是在不同后台的原型圖中，要注意描述清楚工作流是否與其他模塊有所交互，這樣方便自己，也方便他人。

記錄流（what）

      后台系統進行設計時，往往都會有一個專門的操作日志，記錄后台登錄用戶的操作軌跡，主要是因為后台數據對於企業來說是比較有價值的，所以需要對其進行保護。

      總的來說，記錄流主要分 操作軌跡、數據查詢兩種。

      操作軌跡，很容易理解，就是用戶對后台的數據進行操作所產生的記錄，需要達到一步一記錄的程度。這種，在進行設計時，就是將初始狀態、變更狀態、操作內容、操作人、操作時間羅列清楚就OK了，不同業務差異性不大，算是后台的標配模塊

      數據查詢，這個的話，更多是對於工作流中產生的數據進行整理，然后形成的功能模塊。這種的話，不會像操作軌跡那樣，每一步都會記錄下來。而是會根據具體的業務需求來進行設計，以滿足用戶能夠在后台中針對不同緯度的數據進行查詢、了解、分析，獲取價值。

      出了上述的三個基本模塊，在進行后台設計的時候，還有一點可以關注一下，盡量使用默認控件去進行設計，以及不同模塊之間，能夠使用較為統一的交互方式，這樣開發起來更有效率。