本文為我跟 Ignasi Barrera 共同創作，本文英文版首發於 TheNewStack。
不同的公司或軟件供應商已經設計了無數種方法來控制用戶對功能或資源的訪問，如酌情訪問控制（DAC）、強制訪問控制（MAC）、基於角色的訪問控制（RBAC）和基於屬性的訪問控制（ABAC）。從本質上講，無論何種類型的訪問控制模型，都可以抽象出三個基本要素：用戶、系統 / 應用和策略。
在本文中，我們將介紹 ABAC、RBAC 以及一種新的訪問控制模型 —— 下一代訪問控制（NGAC），並比較三者之間的異同，以及為什么你應該考慮 NGAC。
什么是 RBAC？
RBAC，即基於角色的訪問控制，采用的方法是根據用戶在組織中的角色授予（或拒絕）對資源的訪問。每個角色都被分配了一系列的權限和限制，這很好，因為你不需要跟蹤每個系統用戶和他們的屬性。你只需要更新相應的角色，將角色分配給用戶，或者刪除分配。但這可能很難管理和擴展。使用 RBAC 靜態角色模型的企業經歷了角色爆炸：大公司可能有數萬個相似但不同的角色或用戶，他們的角色會隨着時間的推移而改變，因此很難跟蹤角色或審計不需要的權限。RBAC 具有固定的訪問權限，沒有規定短暫的權限，也沒有考慮位置、時間或設備等屬性。使用 RBAC 的企業很難滿足復雜的訪問控制要求，以滿足其他組織需求的監管要求。
RBAC 示例
下面是 Kubernetes 中 default 命名空間中的一個 Role，可以用來授予 pod 的讀取權限。
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: ["v1"] resources: ["pods"] verbs: ["get", "watch", "list"]什么是 ABAC？
ABAC 是 “基於屬性的訪問控制 “的縮寫。從高層次上講，NIST 將 ABAC 定義為一種訪問控制方法，“在這種方法中，根據分配的主體屬性、環境條件以及用這些屬性和條件指定的一組策略，批准或拒絕主體對對象進行操作的請求。” ABAC 是一個細粒度的模型，因為你可以給用戶分配任何屬性，但同時它也成為一種負擔，很難管理：
- 在定義權限的時候，用戶和對象之間的關系無法可視化。
- 如果規則設計的有點復雜或者混亂，對於管理員來說，維護和跟蹤會很麻煩。
當有大量的權限需要處理時，會造成性能問題。
ABAC 示例
Kubernetes 最初使用 ABAC 作為訪問控制，並通過 JSON 行配置，例如：
Alice 可以只讀取命名空間 foo 中的 pod。
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "foo", "resource": "pods", "readonly": true}}什么是 NGAC？
NGAC，即下一代訪問控制，采用將訪問決定數據建模為圖形的方法。NGAC 可以實現系統化、策略一致的訪問控制方法，以高精細度授予或拒絕用戶管理能力。NGAC 由 NIST（美國國家標准與技術研究所）開發，目前用於 Tetrate Q 和 Tetrate Service Bridge。
有幾種類型的實體；它們代表了您要保護的資源、它們之間的關系以及與系統互動的行為者。這些實體是：
- 用戶
- 對象
- 用戶屬性，如組織單位
- 對象屬性，如文件夾
- 策略類，如文件系統訪問、位置和時間
NIST 的 David Ferraiolo 和 Tetrate 的 Ignasi Barrera 在舊金山舉行的 2019 年服務網格日（Service Mesh Day 2019）上發表了關於下一代訪問控制的 演講，分享了 NGAC 的工作原理。
NGAC 是基於這樣一個假設：你可以用一個圖來表示你要保護的系統，這個圖代表了你要保護的資源和你的組織結構，這個圖對你有意義，並且符合你的組織語義。在這個對你的組織非常特殊的模型之上，你可以疊加策略。在資源模型和用戶模型之間，定義了權限。這樣 NGAC 提供了一種優雅的方式來表示你要保護的資源，系統中的不同角色，以及如何用權限把這兩個世界聯系在一起。
圖片來自於 Linear Time Algorithms to Restrict Insider Access using Multi-Policy Access Control Systems
NGAC 示例
下面的例子展示了一個簡單的 NGAC 圖，其中有一個代表組織結構的用戶 DAG，一個代表文件系統中的文件和文件夾的對象 DAG，一個文件的分類，以及兩個不同的策略 —— 文件系統和范圍，可以結合起來做出訪問決策。兩個 DAG 之間的關聯邊定義了行為者對目標資源的權限。
在這張圖中，我們可以看到 /hr-docs 文件夾中的兩個文件 resume 和 contract 的表示，每個文件都鏈接到一個類別（public/confidential）。還有兩個策略類，File System 和 Scope，圖中的對象被連接在這里 —— 需要滿足這些條件才能獲得對每個文件的訪問權。
在例子中，用戶 Allice 對兩個文件都有讀寫訪問權限，因為有一個路徑將 Allice 鏈接到每個文件，而且路徑授予了兩個策略類的權限。但是，用戶 Bob 只有對 resume 文件的訪問權，因為雖然存在一個從 Bob 到 contract 文件的路徑，該路徑滿足 File System 策略類的 “讀 " 權限，但沒有授予 Scope 策略類權限的路徑。所以，Bob 對 contract 文件的訪問被拒絕。
為什么選擇 NGAC？
在 ABAC 的情況下，需要跟蹤所有對象的屬性，這造成了可管理性的負擔。RBAC 減少了負擔，因為我們提取了所有角色的訪問信息，但是這種模式存在角色爆炸的問題，也會變得不可管理。有了 NGAC，我們在圖中就有了我們所需要的一切 —— 以一種緊湊、集中的方式。
當訪問決策很復雜時，ABAC 的處理時間會成倍上升。RBAC 在規模上變得特別難以管理，而 NGAC 則可以線性擴展。
NGAC 真正出彩的地方在於靈活性。它可以被配置為允許或不允許訪問，不僅基於對象屬性，而且基於其他條件 —— 時間、位置、月相等。
NGAC 的其他關鍵優勢包括能夠一致地設置策略（以滿足合規性要求）和設置歷時性策略的能力。例如，NGAC 可以在中斷期間授予開發人員一次性的資源訪問權，而不會留下不必要的權限，以免日后導致安全漏洞。NGAC 可以在一個訪問決策中評估和組合多個策略，同時保持其線性時間的復雜度。
總結
下表從幾個方面對 ABAC、RBAC 和 NGAC 進行了比較。
總而言之：
- RBAC 比較簡單，性能好，但在規模上會受到影響。
- ABAC 很靈活，但性能和可審計性是個問題。
- NGAC 通過使用一種新穎、優雅的革命性方法來修復這些差距：在用戶提供的現有世界表示之上疊加訪問策略。你也可以對 RBAC 和 ABAC 策略進行建模。
參考