許可權控制的解決方式(科普向)

1 許可權控制是什麼

認證（Authentication）和 授權（Authorization）是兩個概念：

• 認證的目的是為了認出用戶是誰，解決的是『Who am I』的問題；

• 而授權的目的是為了決定用戶能夠做什麼，解決的是『What can I do』的問題。

形象的來說：假設系統是一個屋子，持有鑰匙的人可以開門進入屋子。那麼屋子就是通過鎖和鑰匙來進行『認證』的，開門的過程對應的就是登陸。開門之後，能訪問哪個屋子，什麼事情能做，什麼事情不能做，就是『授權』的管轄範圍了。

某個主體（subject）對某個客體（object）需要實施某種操作（operation），系統對這種操作的限制就是許可權控制。在一個安全的系統中，通過認證來確認主體的身份。客體是一種資源，是主體發起請求的對象。主體所能做什麼，就是許可權，許可權可以細分為不同的能力，例如：在Linux文件系統中，將許可權分為 讀、寫、執行 三種能力。"基於角色的訪問控制"和"基於數據的訪問控制"是進行系統安全設計時經常用到的兩種控制方式，下文會涉及到。

以下是一些常見的許可權控制模型： 

1.1 ACL

ACL(Access Control List) 控制訪問列表。在ACL中，包含用戶(User)、資源(Resource)、資源操作(Operation)三個關鍵要素。每一項資源，都配有一個列表，記錄哪些用戶可以對這項資源執行哪些操作。當系統試圖訪問這項資源時，會檢查這個列表中是否有關於當前用戶的操作許可權。

總的來說，ACL是面向"資源"的訪問控制模型，機制是圍繞"資源"展開的。模型如下圖所示：

ACL典型的例子：

在 Linux 中，主體是系統用戶，客體是被訪問的文件，一個文件所能執行的操作分為讀(r)、寫(w)、執行(x)，這三種操作同時對應著三種主體：文件擁有者、文件擁有者所在的用戶組、其他用戶。主體-客體-操作這三種的對應關係構成了 ACL 控制訪問列表，當用戶訪問文件時，能否成功將由 ACL 決定。 

1.2 RBAC

1.2.1 名詞術語

用戶（user）：人、機器、網路等，進行資源或服務訪問的實施主體

角色（role）：一個工作職能，被授予角色的用戶將具有相應的權威和責任

會話（session）：從用戶到其激活的角色集合的一個映射

許可權（permission）：對受RBAC保護的一個或多個對象執行某個操作的許可

操作（operation）：一個程式可執行的映像，被調用時為用戶執行某些功能

客體（object）：需要進行訪問控制的系統資源，例如：文件、印表機、資料庫記錄等 

1.2.2 RBAC定義

RBAC(Role-Based Access Control)：基於角色的訪問控制。 RBAC認為授權實際就是 who，what，how 三者之間的關係，即 who 對 what 進行 how 的操作。

• Who：許可權的擁用者或主體（如 User、Group、Role 等等）

• What：許可權針對的對象或資源

• How：具體的許可權

RBAC的關註點在於 Role 和 User, Permission 的關係。稱為 User assignment(UA) 和 Permission assignment(PA)。關係的左右兩邊都是 Many-to-Many 關係。就是 user 可以有多個 role，role 可以包括多個 user。User 通過成為 Role 而得到這些 Role 的 Permission，Role 隔離了 User 和 Permission 的邏輯關係。

RBAC支持三個著名的安全原則：

• 最小許可權原則：要求系統只授予主體必要的許可權，而不要過度授權，這樣能有效減少系統、網路、應用、資料庫出錯的機會。RBAC可以將其角色配置成其完成任務所需要的最小的許可權集

• 責任分離原則：調用相互獨立互斥的角色來共同完成敏感的任務。例如：記賬員和財務管理員共同參與同一過賬

• 數據抽象原則：許可權的抽象。如：財務操作用借款、存款等抽象許可權，而不用操作系統提供的典型的讀、寫、執行許可權。 

1.2.3 RBAC分類

1.2.3.1 RBAC0

RBAC0：RBAC的核心部分，是通用的許可權模型，其他的版本都是建立在 RBAC0 的基礎上併進行相應的擴展。 模型圖如下：

use和role關係：N:N

role和permission關係：N:N

在用戶的會話中保持激活狀態的角色的許可權構成了用戶的可用許可權

1.2.3.2 RBAC1

RBAC1：基於 RBAC0 的角色層次模型，角色層次定義了角色間的繼承關係，例如：角色 r1 繼承了角色 r2，r1 則擁有了 r2 的所有許可權。模型圖如下： 

使用第一種模型也可以，不過會存在數據冗餘，沒有RBAC1更面向對象 

1.2.3.3 RBAC2

RBAC2：基於 RBAC0 的約束模型，增加了職級分離關係，用來實施利益衝突策略防止組織中用戶的越權行為，限制了用戶的許可權。包含SSD（靜態職級分離）和DSD（動態職級分離）概念。

SSD：用戶/角色分配約束，由2個參數定義 ：

• 包含2或2個以上角色的角色集合

• 用戶擁有的角色在該角色集中小於某個閥值

DSD：會話與角色之間的約束，約束一個用戶會話可以激活的角色來限制用戶的許可權。例如：一個用戶擁有3個角色，一個會話中只激活1個角色。模型圖如下

1.2.4 RBAC 介面

RBAC介面定義規範，可參考：GBT 25062-2010 信息安全技術 鑒別與授權 基於角色的訪問控制模型與管理規範

2 垂直許可權（功能許可權）

訪問控制是建立用戶與許可權之間的關係，目前常用的一種方法就是基於 RBAC 模型，我們可稱之為『垂直許可權』。例如：在一個論壇中，有admin、普通用戶、匿名用戶三種角色，admin有刪除、編輯、置頂帖子的許可權，普通用戶有評論和瀏覽帖子的許可權，匿名用戶只有瀏覽帖子的許可權。目前已有 Shiro，Spring Security 等基於 RBAC 模型的成熟框架來處理功能許可權管理和鑒權的問題。

垂直許可權的漏洞舉例：Web應用程式在服務端沒有做許可權控制，只是在前端菜單顯示上將部分頁面隱藏了。此時，惡意用戶可以猜測其他管理頁面的 URL，就可以訪問或控制其他角色擁有的數據或頁面，達到越權操作的目的，可能會使得普通用戶擁有了管理員的許可權。

解決：對管理員所見的管理界面 URL，每次用戶訪問時，都要判定該用戶是否有訪問此 URL 的許可權。推薦使用成熟的許可權解決方案框架。 

3 水平許可權（數據許可權）

用戶A和用戶B可能同屬於一個角色 RoleX，但用戶 A 和用戶 B 都各自有一些私有數據，正常情況下，用戶自己只能訪問自己的私有數據，例如：你有刪除郵件的功能（操作許可權），但只能刪除自己的郵件，不能誤刪其他人的郵件（數據許可權）。但在 RBAC 模型下，系統只會驗證用戶A是否屬於角色 RoleX，而不會判斷用戶A是否能訪問只屬於用戶B的數據 DataB，此時就可能發生越權訪問。

這種問題，稱之為『水平許可權管理問題』，又可以稱之為『基於數據的訪問控制』：相比垂直許可權管理來說，水平許可權問題出現在同一個角色上，系統只驗證了能訪問數據的角色，沒有對數據的子集做細分，因此缺乏了一個用戶到數據級之間的對應關係。對於數據的訪問控制，與業務結合的比較緊密，目前還沒有統一的數據級許可權管理框架，一般是具體問題具體解決。

數據許可權就是控制訪問數據的可見範圍，表現形式是：當某用戶有操作許可權時候，不代表對所有數據都有查看或管理的許可權。一般表現為行許可權和列許可權：

1. 行許可權：限制用戶對某些行的訪問，例如：只能對某人、某部門的數據進行訪問；也可以是根據數據的範圍進行限制，例如：按合同額大小限制用戶對數據的訪問

2. 列許可權：限制用戶對某些列的訪問，例如：某些內容的摘要可以被查閱，但詳細內容只有 VIP 用戶能查閱

水平許可權的漏洞案例：Web應用程式接受用戶的請求，修改某條數據id（資源的唯一編號）時，而沒有判斷當前用戶是否可以訪問該條記錄，導致惡意用戶可以修改本不屬於自己的數據。例如：`/api/v1/blog?blogId=xxx [DELETE]` 這是刪除博客內容的url，當用戶改變 blogId 時，後端如果未校驗博客的所屬人是否是當前用戶，則可以刪除其他人的博客內容。

解決方案：用戶做出相應動作時（新建、刪除、更新等）時，需要對其會話身份進行驗證（可採用Cookie機制），並且對用戶訪問的對象記錄校驗數據許可權是否ok（按業務場景）。

4 OAuth

OAuth 是一個在不提供用戶名和密碼的情況下，授權第三方應用訪問 Web 資源的安全協議。例如一個 OAuth 場景：用戶將照片存儲在Google，然後在"雲沖印"的網站，將照片沖印出來。那麼，"雲沖印"網站需要獲得用戶的授權來讀取Google上的用戶照片。

OAuth 的一些名詞：

• Third-party application：第三方應用程式，又稱 "Client" 客戶端，上例中的"雲沖印"網站

• HTTP Service：HTTP服務提供商，上例中的Google

• Resource Owner：資源所有者，就是用戶

• User Agent：用戶代理，就是瀏覽器

• Authorization server：認證伺服器，即服務商提供商專門處理認證的伺服器

• Resource server：資源伺服器，即服務提供商存放用戶生成的資源的伺服器

OAuth 的授權流程：

A：用戶打開第三方應用程式 Client，Client 要求用戶給與授權

B：用戶同意給予 Client 授權

C：Client 使用 B 步驟中獲得的授權，向認證伺服器申請令牌

D：認證伺服器對 Client 進行認證之後，確認無誤，同意發放令牌

E：Client 使用令牌，向資源伺服器申請獲取資源

F：資源伺服器確認令牌無誤之後，同意向 Client 開放資源

對於 B 步驟中的用戶給 Client 第三方程式授權，OAuth2.0 定義了以下四種授權模式：

4.1 授權碼模式（authorization code）

授權碼模式是功能最完整、流程最嚴密的授權模式，它的特點是通過 Client 的後臺伺服器，與服務提供商的認證伺服器進行交互

將每一步驟與所需的參數用時序圖表示如下：

其中A.3中的scope是申請用戶授權的許可權範圍，會向用戶顯示一個可授權列表，例如：獲取用戶信息、相冊列表、點贊等資源，例如下圖所示：

實例可參考：微信公眾平臺技術文檔-微信網頁授權

QQ互聯-使用Authorization_Code獲取Access_Token 

4.2 簡化模式（implicit）

簡化模式不通過第三方應用程式的伺服器，直接在瀏覽器中向認證伺服器申請令牌，跳過了授權碼的步驟。所有步驟都在瀏覽器中完成，令牌對訪問者是可見的，且 Client 不需要認證

將每一步驟與所需的參數用時序圖表示如下：

實例可參考：QQ互聯-使用Implicit_Grant方式獲取Access_Token

4.3 密碼模式（resource owner password credentials）

密碼模式中，用戶向 Client 提供自己的用戶名和密碼，Client 使用這些信息，向服務提供商索要許可權。這種模式中，用戶需要將自己的密碼提供給 Client，但 Client 處不得存儲密碼，這通常用於用戶對 Client 高度信任的情況下，例如：Client 是操作系統的一部分或一個著名公司。而認證伺服器只有在其他授權模式無法執行情況下，才會採用這種模式。

將每一步驟與所需的參數用時序圖表示如下：

4.4 客戶端模式（client credentials）

客戶端模式，指 Client 以自己的名義，而不是以用戶的名義，向服務提供商進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向 Client 註冊，Client 以自己的名義要求服務提供商提供服務，其實不存在用戶的授權問題。

將每一步驟與所需的參數用時序圖表示如下：

實例可參考：微信公眾平臺技術文檔-獲取access token （微信公眾號的API介面調用，與用戶授權無關）

5 參考

《白帽子講Web安全》

理解OAuth2.0

https://github.com/casbin/casbin