基于属性的权限控制模型ABAC
本文來說下基于屬性的權限控制模型ABAC
文章目錄
- RBAC 的缺憾
- 什么是ABAC訪問控制模型
- ABAC相關術語
- ABAC的使用場景
- 為什么 ABAC 能解決復雜場景下的問題
- Attribute 易于管理
- 細粒度授權支持
- 訪問控制管理成本很低
- 動態的總體控制
- 本文小結
RBAC 的缺憾
RBAC 在很多時候是管用的，比如我們的系統是面向銷售公司或者學校這種組織架構很嚴整的地方，但是在復雜場景下，RBAC 漸漸就不夠用了，它會產生很多虛無的 role 而且在管理和控制上更難：在某個醫療機構中，我們想要控制一個科室內，護士只能訪問自己所負責的病人資料時，我們就無法直接使用 nurse 這個 role，我們需要更細粒度的 role 去劃分病人老張還是老王，這就會產生和現實不對應的 role，例如：老張的護士，老王的護士。在醫院這種病人流動性很大的場景下，頻繁的創建和銷毀 role 是很容易出問題，我們的確要求很頻繁，但是與現實不 match 的虛無的 role 很難管理。
另一種情況是，如果管理者考慮醫療數據的安全性與隱私性，不希望護士在離開醫院后能夠訪問到病人資料，我們會更加難辦，常見的策略要么是在底層網絡層進行處理，直接禁止在院外的一切訪問，但是很多企業的需求往往是，使用 VPN 我依舊可以訪問內部的資源，但是我還是希望基于所在地進行精確的控制，比如看郵件是可以的，但是看財務數據是不行的。在 RBAC 下，我們也可以通過虛擬的 role 來控制，比如下班后給與其 Out of Office 的 role，然后給與這個 role 最小的權限，這自然又需要虛擬的 role 與大量的動態控制。
一般來說，在 RBAC 中濫用 role 所帶來的問題被稱為 “role explosion”，跟“曹操”與“曹操小時候”這個笑話很類似，但的確我們的訪問控制系統中存在很多這樣的 role。
什么是ABAC訪問控制模型
所以，直覺上來說我們需要更多的“東西”來進行更精細的訪問控制，用來匹配我們復雜的業務場景，同時，我們也希望這個新的模型易于理解和實現，也利于控制與運維，這就是 ABAC —— 基于屬性的訪問控制 (Attribute Based Access Control) —— 想要解決的問題。簡單來說，對于 ABAC 我們判斷一個用戶是否能訪問某項資源，是對其很多不同屬性的計算而得到的。
傳統的 RBAC 與 ACL 等訪問控制機制中，可以認為是 ABAC 的子集，對于 RBAC，只是我們的訪問機制的實現只是基于屬性 role 而已，ACL 則是基于屬性是 identity 的 AC。
基于屬性的訪問控制（Attribute-Based Access Control，下文簡稱ABAC）是一種靈活的授權模型。是通過實體的屬性、操作類型、相關的環境來控制是否有對操作對象的權限。
例如：P5（職級）的同學有OA系統的權限。
上述是一個簡單的ABAC的例子，就是通過實體的職級這一屬性來控制是否有OA系統的權限
再比如：P5（職級）的研發（職位）同學有公司Gitlab的權限
上述例子是通過一組實體的屬性（職級和職位）來控制對操作對象的權限
再比如：P5（職級）的研發（職位）同學在公司內網（環境）可以查看和下載（操作）代碼。
上述例子顯然比之前兩個更加復雜，除了判斷實體的屬性（職級和職位），還判斷了當前的環境屬性和操作屬性
所以我們可以ABAC的訪問控制模型用下面這張圖表現出來
ABAC相關術語
ABAC的使用場景
ABAC授權模型理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。從使用場景來說比較適用于用戶數量多并且授權比較復雜的場景。簡單的場景也是可以使用ABAC的，但是使用基礎的ACL或者RBAC也能滿足需求。
場景一：
還是拿上面的例子來說：P5（職級）的研發（職位）同學在公司內網（環境）可以查看和下載（操作）代碼。
在需要根據環境屬性和操作屬性來動態計算權限的時候，使用其他的授權模型可能不太能滿足需求。這個時候就需要使用ABAC授權模型。
場景二：
ABAC也適用于 成員（角色）快速變化的場景，由于ABAC 是通過用戶的屬性來授權的。在新建用戶/修改用戶屬性時會自動更改用戶的權限，無需管理員手動更改賬戶角色。
在屬性的組合比較多，需要更細粒度地劃分角色的情況下。RBAC需要建立大量的角色。ABAC授權模型會更加靈活。
為什么 ABAC 能解決復雜場景下的問題
在學習 ABAC 的過程中我發現，ABAC 和很多創新一樣，并不是因為科技的突破性進展，而只是在 RBAC 的思維上前進了一點，理解 ABAC 的術語時，你能很快的聯想到已有的技術實踐，比如 AWS IAM。而且，這些術語也如同我們做面向對象編程時，是很好的描述現實的。
Attribute 易于管理
我們可以很容易的為不同的用戶設計 attribute，往往在很多企業的實現中存在一個 consumer profile 或者 user details 的服務，這些服務中很多字段比如職位、職級、辦公室、項目等就是天然的 attribute，對于需要管理的 object，如果是一臺虛擬機，那么 IP 地址、歸屬組織、cost code 等都可以是 attribute，而且因為 attribute 是 K-V 式的，往往一張一對多的表就可以控制好 subject、object 與 attribute 的對應。
細粒度授權支持
ABAC 能做到細粒度的授權管理，我們知道，在 policy 中，我們的準許訪問的判斷是可以寫的很靈活的，我們甚至可以判斷請求中的某個屬性是否滿足于一個正則表達式，或者字符串相等（這個很常見，特別是在使用 AWS IAM 做最小權限原則時），我們也可以使用邏輯與、邏輯或的關系自由組合很多不同的訪問規則。你可以使用之前提到的 Specification Pattern 很輕松的實現靈活的 policy，解析 JSON 或者 XML 去動態的創建規則，而這些含有規則的 JSON 或 XML，則是可以被編程實現的（可編程的 policy 是動態的授權驗權的前提）。你的 policy 甚至可以做到，只有姓張的工程師在某個項目時才能訪問某個資源，在 RBAC 的時代，這是很難的。
訪問控制管理成本很低
ABAC 對系統管理員是友好的，在 RBAC 的時代，如果我需要實現細粒度的資源管理或者經常 subject 與 object 的對應關系經常變動，那么管理員難以操作的，也很容易出現問題，其中常常被采用的解決方案就是創建那些本不應該存在的 role。但是在 ABAC 時代，管理員的管理對象會縮減到 policy，也就是只處理訪問控制。我們再回到醫療機構的那個例子中，如果某個護士負責照顧老張，系統管理員只需要新建一個 policy 并寫上允許訪問即可，當老張出院后，只需要刪除或者失效這個 policy 就可以了。在 RBAC 的環境中，你可能需要為某個虛擬的 role 動態的添加 permission，而 permission 如果到了針對單個病人的情況下，是絕對多如牛毛的，特別是有兩個叫做老張的病人時。
動態的總體控制
Environment conditions 也能夠提供統一的系統級別的控制，比如威脅等級或者按照區域劃分安全級別，不同的區域使用 ABAC 時，可能環境上會有變化。例如我們常用紅區來表示最高安全級別，那么我們默認就需要 deny 所有請求，并且會觸發警報等等，但是在綠區這種辦公區域，可能默認所有的請求都是被允許的等等。Environment conditions 可以提供“拉閘”這樣的功能，而且它也是可以動態調整的。
本文小結
本文介紹了基于屬性的權限控制模型ABAC的一些基礎知識與內容。微服務的流行與 ABAC 的配合值得寫另一篇文章，特別是分布式身份驗證之后，怎么做到分布式的授權與驗權，怎么實現 PEP、PDP 等 ABAC 提倡的模塊設計，這些東西可否做成應用程序透明的方式，可否與 security sidecar 集成等等，這些都是可以進一步完善的。
總結
以上是生活随笔為你收集整理的基于属性的权限控制模型ABAC的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Fugl-Meyer Assessmen
- 下一篇： 管理培训生