Google 設計了 Zanzibar 授權系統來處理其複雜的訪問需求。瞭解如何利用此係統在您的應用中建立細粒度的 ReBAC.
Google Zanzibar 是 Google 於 2019 年釋出的一份白皮書，其中介紹了其用於處理大量使用者和服務的訪問控制的內部授權系統。如今，它仍然是 IAM 領域中非常流行的術語，幾乎被用來描述細粒度授權，就像基於角色的訪問控制 (RBAC)用於描述授權系統一樣。
Google Zanzibar 以其分散式、可擴充套件且一致的架構而聞名，它允許開發人員將其許可權建模為圖中的資料，併為實現基於關係的訪問控制 (ReBAC)提供自然解決方案。Google Zanzibar 既細緻、創新，又耗費大量資源且複雜，優點和缺點很多。在本部落格中，我們將介紹什麼是 Google Zanzibar、何時以及如何實施它來解決應用程式的授權需求。
Google Zanzibar 的要點：
- 它是一個全球分佈、可擴充套件且一致的授權系統，每秒能夠處理超過 1000 萬個客戶端查詢。
- 它使用圖資料模型來表示使用者和資源之間的關係（如所有權），從而實現基於關係的訪問控制（ReBAC）。
- 它採用有向圖表示，其中許可權檢查成為圖遍歷問題，試圖找到從請求的資源到使用者的路徑。
- 它利用關係重寫來減少冗餘資訊並規範化圖形資料。
谷歌為什麼要建設Zanzibar ？
- Google 需要一種統一的方式來處理其眾多服務和龐大使用者群的授權，同時確保安全性、靈活性和可擴充套件性。
- 他們現有的授權系統缺乏一致性，因此難以在全球範圍內執行政策並跨服務重用元件。
- Zanzibar 提供了一個集中的、標準化的授權解決方案，提高了整個 Google 基礎架構的安全性、可測試性和可重用性。
細粒度授權中的 ACL 與 RBAC
多年來，訪問控制列表 (ACL) 一直是分散式系統（如網路裝置）中首選的許可權管理解決方案。ACL 具有高準確性（因為系統中的每個許可權都明確寫在列表中），因此提供了一種簡單且安全地驗證使用者訪問許可權的方法。
ACL 還非常適合處理高度精細的授權策略，因為系統中的每個物件都與其許可權一起顯示在列表中。
問題是，隨著分佈的擴大和資料量的不斷增長，ACL 幾乎不可能分發、維護或計算。雖然可能找到一種能夠正確集中和分發它們的模型，但在現代應用程式中維護它，尤其是在 Google 規模上，變得不可能。
ACL 無法為使用者和開發人員提供體驗。對於開發人員來說，這種缺乏源於無法以集中方式維護它們。對於使用者來說，當你想讓他們管理大量許可權時（這種情況經常發生），ACL 的功能過於簡單，配置和維護也過於複雜。
解決這種複雜性的方法是什麼？基於角色的訪問控制 (RBAC)。
RBAC 專注於使用者（或主體），使許可權的維護和配置變得簡單而直接。RBAC在此過程中失去的是粒度（這會帶來複雜性和昂貴的記憶體使用成本）。這意味著 Google 需要一種方法來結合 ACL 的粒度和 RBAC 的簡單性，並使它們在其規模內發揮作用。如果您熟悉 ACL，您可能知道這個挑戰基本上是不可能完成的。
從列表到圖
- 擴充套件 ACL 的主要挑戰之一是其名稱 - 它是一個列表。雖然列表是一種非常可靠且正確的資料結構，但它們效率極低，尤其是在搜尋和遍歷操作方面。
- 出於這個原因，Google 決定採用一種更適合搜尋的結構，選擇將 ACL 儲存在圖中。
Zanzibar ：
- 並不採用每個使用者或每個物件的平面、水平的許可權列表，
- 而是為系統中的每個主體和物件建立一個節點，並透過邊來宣告它們之間的關係。
使用者Bob和Bob's Files資料夾是節點，Owner他們之間的關係是邊，決定了兩者之間的關係（從而決定了許可權級別）。
可利用物件之間的關係來派生新關係：
- 如果 Bob 是 "Bob's Files "的所有者，
- 而 "Bob's Pics "和 "Bob's Docs "資料夾位於該資料夾內，
- 則 Bob 將自動被指定為這兩個資料夾及其內檔案的所有者。
Google Zanzibar 標準
從實施和消費角度來看，Google Zanzibar 論文假設了定義 Zanzibar 系統的兩種主要方法：函式和元組。
函式是使用者在圖表中使用的基本、直觀的方法。這些包括：
- Read 圖中的具體物件
- Write 新的節點和邊
- Watch 配置和資料更改
- Check 使用遍歷搜尋獲取使用者的許可權或使用者許可權列表。
Google Zanzibar 檢查函式使用通常的Subject、Action、Resource引數來返回使用者許可權（is Bob (subject) allowed to write (action) a document (resource)）。
為了有效地描述圖並利用這些函式，Zanzibar 包含一個稱為元組的術語/方法。元組是我們用來描述resources:object、objectrelation和 objectrelation@user 關係的約定。
使用這些元組，Google Zanzibar 建立了一種語言，讓所有消費者都可以輕鬆使用策略圖。
例如，我們可以這樣表示 Bob 對 finance_reports 資料夾的所有權：folders:finance_reportowner@Bob。
Zanzibar 問題：
- Zanzibar 基於圖的模型擅長管理 ReBAC 所需的層次結構和巢狀關係，但引入了系統複雜性和依賴性。
- 記住：萬物在上下文中發生關係，授權就是預先定義好一些操作上下文，然後將這個上下文的操作許可權授權給某個使用者，角色是上下文的另外一種稱呼，RBAC是使用者-角色-資源許可權這種關係，Zanzibar 將角色-許可權關係儲存在圖中。
- Zanzibar 是一個白皮書標準，它不是一種實現。他們有一個內部實現（也稱為 Zanzibar，因此造成混淆）。
網友：
1、有充分的理由說明 Zanzibar 可能不是大多數公司（甚至可能是 Google）處理 AuthZ 的最佳方式。類似 Zanzibar 的實現不如 RBAC 更可取，後者要簡單得多，並且仍然允許在服務級別進行基於屬性的身份驗證。
例如，如果所有者 Bob 只對地理位置 Bar 中的資源 Foo 具有編輯許可權，我可以檢查 JWT 中與 Bob 匹配的主題，並知道從 URL 訪問了哪些資源，但要獲取地理位置規則和資訊，我可能需要進行另一次服務呼叫。
由於提供資源的服務可能已經可以訪問該資訊，因此在我看來，更有意義的是隻檢查角色和資源，然後將其傳遞給服務以針對地理位置進行第二次身份驗證檢查。
- Ory 有一個開源實現：https://github.com/ory/keto
- SpiceDB https://github.com/authzed/spicedb
2、如果您有 docker 主機，您現在就可以執行 zanzibar 的開源版本 - 請檢視https://openfga.dev
OpenFGA 太棒了！以下是它和 Permit 之間的一些區別，有興趣的可以看看：
- Permit 專注於授權平臺，這意味著使用者可以使用 RBAC、ABAC、ReBAC 和 PBAC 模型來建模和配置他們的策略，然後根據應用程式的需求進行混合搭配。OpenFGA 方法主要側重於將策略作為圖形/資料，很難將更直接或其他策略模型與其混合。有關將策略作為資料與將策略作為程式碼的更多資訊，請訪問： https://www.permit.io/blog/zanzibar-vs-opa
- 作為平臺方法的一部分，Permit 不開發策略引擎（例如 OpenFGA），而是讓開發人員根據自己的選擇使用策略引擎。使用 Permit 平臺，開發人員（或其他利益相關者）可以透過 UI、API 或 IaC 配置策略。Permit 將根據他們選擇的策略引擎生成程式碼或配置。目前，Permit 支援 OPA（包括基於 OPA 的 Zanzibar 實現）和 Cedar，但 OpenFGA 以及其他 Zanzibar 實現都在我們的路線圖中。我們在這裡與 OpenFGA 和 Cedar PM 一起舉辦了直播： https://www.youtube.com/watch ?v=sG2OUXes8Hs
- OpenFGA 的使用更像是將庫整合到您的應用程式中；這意味著您必須自己編寫程式碼。Permit 是一個完全外部化的授權平臺，旨在從組織級別無縫地融入 SDLC，而不是從單個應用程式級別。以下是 SDLC 中 Permit 元件的概述： https://docs.permit.io/how-to/SDLC/modeling-implementation-components
- OpenFGA 與其他 Zanzibar 實現一樣，是一個集中式配置和執行系統。這意味著使用者需要在其所有應用程式中分發 OpenFGA 和整個圖表。Permit 的根源在於策略即程式碼模型，透過在策略引擎之間分片資料，實現了圖表和策略引擎的去中心化。使用者可以使用去中心化的資料和引擎來保持集中式配置。OPAL 是用於同步策略和資料的 Permit OSS 工具，是實現這種集中式/去中心化模型的引擎：github.com/permitio/opal