Kiểm soát truy cập dựa trên quan hệ (ReBAC) và Google Zanzibar
1. Tổng quan
Định nghĩa: Kiểm soát truy cập dựa trên quan hệ (ReBAC, Relationship-Based Access Control) là mô hình ủy quyền lấy "quan hệ (relation)" tồn tại giữa chủ thể (người dùng) và khách thể (tài nguyên) làm căn cứ hàng đầu cho quyết định ủy quyền, và Google Zanzibar là thiết kế tiêu biểu của một hệ thống ủy quyền triển khai mô hình này một cách nhất quán ở quy mô toàn cầu.
Kiểm soát truy cập ban đầu khởi đầu từ ACL (Access Control List) gắn trực tiếp danh sách quyền vào tài nguyên, và khi tổ chức lớn lên, nó phát triển thành RBAC (Role-Based Access Control) gom quyền vào vai trò. RBAC hoạt động tốt dưới giả định "những người làm cùng công việc có cùng quyền", nhưng các dịch vụ cộng tác hiện đại bị chi phối bởi các trường hợp mà quyền được xác định bởi một quan hệ cụ thể giữa tài nguyên và người dùng, chẳng hạn "người đã tạo tài liệu này", "người được chia sẻ thư mục này", hay "thành viên của tổ chức này đồng thời được mời vào một dự án cụ thể". Nếu cố biểu diễn các yêu cầu đó bằng cách tăng số vai trò của RBAC thì sẽ phát sinh vấn đề "bùng nổ vai trò (role explosion)", nơi vai trò tăng tỷ lệ với số lượng tài nguyên.
ReBAC quy giản quyền thành một truy vấn đồ thị: "Người dùng U có quan hệ Rel với tài nguyên R không?" Ví dụ, "Alice có thể xem tài liệu doc:readme không?" trở thành một phép duyệt quan hệ: "Alice có phải viewer của doc:readme, hay là editor/owner, hoặc là viewer của thư mục mà doc:readme thuộc về?" Góc nhìn này mô hình hóa một cách tự nhiên việc ủy quyền chi tiết (fine-grained authorization) trong các dịch vụ như Google Drive, GitHub và Slack xử lý hàng trăm triệu người dùng và hàng tỷ khách thể.
Một lý do khác khiến ReBAC được chú ý là nó gắn với xu hướng ngoại biên hóa và tập trung hóa logic ủy quyền. Trước đây mỗi ứng dụng triển khai quyết định quyền rải rác trong mã nội bộ, nhưng khi microservice gia tăng, cùng một câu hỏi về quyền bị triển khai lặp lại ở từng dịch vụ và diễn giải khác nhau, làm gia tăng sự không nhất quán. Bằng cách hợp nhất mô hình quyền và dữ liệu vào một dịch vụ chuyên biệt duy nhất và để mỗi dịch vụ chỉ gọi API Check, tính nhất quán của chính sách, kiểm toán và quản lý thay đổi đều hội tụ về một nơi. ReBAC có lợi thế cấu trúc ở chỗ nó cung cấp một mô hình dữ liệu thống nhất (bộ quan hệ) phù hợp để dịch vụ ủy quyền trung tâm này xử lý.
Google đã công bố Zanzibar trong bài báo USENIX ATC năm 2019. Zanzibar đảm nhận việc ủy quyền cho nhiều dịch vụ gồm Google Drive, Calendar, Cloud, YouTube và Photos, và theo bài báo, nó quản lý hàng nghìn tỷ (trillions) bộ quan hệ và hàng triệu lượt kiểm tra quyền mỗi giây trong khi đạt độ trễ phân vị 95 dưới 10ms và độ sẵn sàng trên 99.999%. Cốt lõi của chủ đề này không chỉ đơn thuần là khái niệm "xem quyền qua quan hệ" mà là các kỹ thuật thiết kế đồng thời thỏa mãn tính đúng đắn (đặc biệt là tính nhất quán của việc thu hồi quyền) và độ trễ thấp trong môi trường phân tán toàn cầu. Trong bài thi Kỹ sư chuyên nghiệp, cần trình bày đồng thời mô hình, cấu trúc dữ liệu, cơ chế nhất quán và các đánh đổi vận hành.
2. Sự tiến hóa của các mô hình kiểm soát truy cập và vị trí của ReBAC
2.1 ACL → RBAC → ABAC → ReBAC
Các mô hình kiểm soát truy cập được phân biệt bởi "quyền được gắn vào cái gì". ACL liệt kê các cặp (chủ thể, hành động được phép) theo từng tài nguyên. Nó trực quan khi biểu diễn nhưng khó quản lý khi người dùng tăng, và truy vấn ngược "tất cả tài nguyên mà người dùng này có thể truy cập" thì tốn kém. RBAC giảm gánh nặng quản lý bằng cấu trúc ba tầng người dùng-vai trò-quyền, nhưng khó biểu diễn việc chia sẻ chi tiết thay đổi theo từng tài nguyên.
ABAC (Attribute-Based Access Control) đạt được tính linh hoạt qua thuộc tính của người dùng, tài nguyên, môi trường cùng các quy tắc chính sách (ví dụ: "phòng ban = tài chính AND thời gian = giờ làm việc"), nhưng khi chính sách trở nên phức tạp thì khó truy vết "tại sao quyền này được cho phép/từ chối" và khó bảo đảm hiệu năng truy vấn quy mô lớn. ReBAC quy giản quyền thành bài toán khả đạt (reachability) trên đồ thị quan hệ, đồng thời đạt được tính chi tiết và khả năng giải thích. Trong thực tế, các mô hình lai giữ ReBAC làm bộ khung cơ bản và tăng cường bằng các điều kiện kiểu ABAC (contextual tuple, caveat) ngày càng phổ biến.
| Mô hình | Đối tượng gắn quyền | Điểm mạnh | Giới hạn |
|---|---|---|---|
| ACL | Danh sách chủ thể theo tài nguyên | Trực quan, chi tiết | Truy vấn ngược, khó quản lý quy mô lớn |
| RBAC | Vai trò | Quản lý đơn giản, dễ ánh xạ tổ chức | Bùng nổ vai trò, khó biểu diễn chia sẻ theo tài nguyên |
| ABAC | Thuộc tính, biểu thức chính sách | Linh hoạt, điều kiện động | Khó gỡ lỗi, hiệu năng, bảo đảm nhất quán |
| ReBAC | Đồ thị quan hệ giữa các khách thể | Chi tiết + giải thích được, kế thừa phân cấp | Chi phí duyệt đồ thị, độ phức tạp triển khai |
Điều quan trọng trong so sánh này không phải là sự hơn kém của mô hình mà là ngữ cảnh áp dụng. Quyền toàn doanh nghiệp lấy cơ cấu tổ chức làm trung tâm thì RBAC có lợi, phán đoán động dựa trên quy định thì ABAC có lợi, còn quyền sản phẩm lấy chia sẻ và cộng tác làm trung tâm thì ReBAC có lợi. Có thể coi Zanzibar là thiết kế đặt ReBAC ở trung tâm nhưng hấp thụ RBAC qua tư cách thành viên nhóm và các yếu tố ABAC qua bộ quan hệ có điều kiện.
2.2 Bộ quan hệ như một mô hình dữ liệu
Trong Zanzibar, mọi quyền đều được lưu dưới dạng duy nhất là bộ quan hệ (relation tuple). Ký pháp là ⟨object⟩#⟨relation⟩@⟨user⟩; ví dụ doc:readme#viewer@user:alice nghĩa là "viewer của tài liệu readme là alice". Ở vị trí người dùng có thể đặt không chỉ một người dùng đơn lẻ mà còn một userset trỏ tới tập hợp khác. doc:readme#viewer@group:eng#member biểu diễn, trong một bộ duy nhất, "tất cả member của nhóm eng là viewer của readme".
Khả năng "userset rewrite" này tạo nên sức biểu đạt của ReBAC. Tư cách thành viên nhóm, kế thừa thư mục và phân cấp vai trò đều được thống nhất thành dạng "một quan hệ tham chiếu đến một quan hệ khác". Kiểm tra quyền rốt cuộc trở thành bài toán duyệt đồ thị có hướng do các bộ này tạo thành để xác định "nút người dùng có thể đạt tới nút (khách thể, quan hệ) hay không". Vì một bộ là một hàng (row) đơn giản nên việc mở rộng theo chiều ngang dễ dàng, và vì thêm/xóa một quan hệ chính là cấp/thu hồi một quyền nên cũng có lợi cho việc kiểm toán (audit).
2.3 Ví dụ cụ thể về bùng nổ vai trò
Tại sao bùng nổ vai trò lại chí mạng sẽ rõ ràng khi nhìn bằng con số. Giả sử một công cụ cộng tác có 10.000 dự án, mỗi dự án cần ba mức truy cập: viewer, editor và admin. Để biểu diễn bằng RBAC thì cần các vai trò như project-1-viewer, project-1-editor…, tức là số dự án × số quyền = 30.000 vai trò, và nếu dự án tăng lên 100.000 thì vai trò trở thành 300.000. Vì bản thân vai trò tăng tỷ lệ với số tài nguyên nên việc quản lý, tìm kiếm và kiểm toán danh bạ vai trò đều sụp đổ.
ReBAC biểu diễn cùng yêu cầu đó bằng một bộ duy nhất như project:123#editor@user:alice. Thay vì sao chép khái niệm trung gian là vai trò theo từng tài nguyên, nó mô tả trực tiếp quan hệ giữa tài nguyên và người dùng. Nếu cần kế thừa, chỉ cần khai báo một lần bằng quy tắc namespace như project:123#viewer: editor or admin thì áp dụng cho mọi dự án. Sự tách biệt "khai báo một lần, dữ liệu bằng quan hệ" này là lý do thực chất nhất khiến ReBAC được chọn trong ủy quyền chi tiết quy mô lớn.
3. Kiến trúc và nguyên lý hoạt động của Zanzibar
flowchart LR
App["Dịch vụ khách (Drive, v.v.)"] -->|"Check/Read/Write/Expand"| ACL["aclserver (kiểm tra quyền)"]
ACL -->|"tra cứu bộ quan hệ"| SP["Spanner (CSDL phân tán toàn cầu)"]
ACL -->|"tra cứu cache"| LH["Leopard (chỉ mục tập hợp)"]
SP -->|"luồng nhật ký thay đổi"| LH
App -->|"content version khi ghi"| ACL
ACL -->|"trả về zookie (token nhất quán)"| App
SP -->|"dấu thời gian TrueTime"| ACL
Trong cấu trúc trên, dịch vụ khách đăng ký chính sách quyền của mình với Zanzibar dưới dạng cấu hình namespace (namespace config), thay đổi quyền thực tế được thực hiện bằng cách thêm hoặc bớt bộ qua Write, và phán đoán quyền được truy vấn qua API Check. Có bốn API cốt lõi. Check ("U có quan hệ với R không") trả về cho phép/từ chối, Read tra cứu các bộ đã lưu nguyên vẹn, Expand mở toàn bộ tập người dùng của một (khách thể, quan hệ) cụ thể thành cây để gỡ lỗi và xem quyền, và Write thay đổi các bộ.
Tầng lưu trữ là Google Spanner. Nhờ tính nhất quán bên ngoài (external consistency) của Spanner và đồng hồ toàn cầu TrueTime, mọi thay đổi bộ đều có thể được gắn một dấu thời gian so sánh được trên phạm vi toàn cầu. Dấu thời gian này là nền tảng của token nhất quán (zookie) được giải thích bên dưới. Vì kiểm tra quyền có tải đọc áp đảo nên các tập (khách thể, quan hệ) được hỏi thường xuyên sẽ được một hệ thống chỉ mục tập hợp riêng gọi là Leopard cụ thể hóa (materialize) một cách bất đồng bộ, làm giảm chi phí duyệt của việc lồng nhóm sâu.
3.1 Quá trình đánh giá kiểm tra quyền
sequenceDiagram
participant C as Khách
participant A as aclserver
participant S as Spanner
C->>A: "Check(doc:readme#viewer@alice, zookie)"
A->>A: "diễn giải quy tắc namespace (viewer = viewer ∪ editor ∪ parent.viewer)"
A->>S: "tra cứu các bộ doc:readme#viewer"
S-->>A: "không có editor@alice, parent=folder:eng"
A->>S: "tra cứu folder:eng#viewer (đệ quy)"
S-->>A: "khớp group:eng#member@alice"
A-->>C: "được phép (allowed), cache kết quả đánh giá"
Kiểm tra quyền mở rộng các quan hệ theo các quy tắc được định nghĩa trong cấu hình namespace. Ví dụ, nếu có quy tắc "viewer bao gồm editor và kế thừa viewer của thư mục cha", thì kiểm tra doc:readme#viewer được thực hiện bằng một phép duyệt đồ thị có hướng đi theo bộ trực tiếp → bộ editor → viewer của thư mục cha. Vì quá trình này có thể trở nên sâu, Zanzibar song song hóa các truy vấn con, cache các kết quả trung gian thường dùng, và áp dụng khử trùng lặp yêu cầu cùng phân mảnh khóa cache để giảm nhẹ các "điểm nóng" nơi lưu lượng dồn vào các khách thể phổ biến.
Để xử lý nhanh việc lồng sâu mà không làm tổn hại tính đúng đắn của kết quả đánh giá, Zanzibar chia mỗi bài toán con thành một đơn vị có thể cache độc lập. Chẳng hạn tập thành viên của group:eng#member được tham chiếu lặp lại trong nhiều lần kiểm tra tài liệu, nên được tính một lần và tái sử dụng. Ngoài ra, khi cùng một truy vấn (khách thể, quan hệ, người dùng) đổ về trong thời gian ngắn (ví dụ: một tài liệu công khai phổ biến), cơ chế "request hedging và deduplication" gộp các yêu cầu trùng lặp thành một lần đánh giá để giảm tải backend.
3.2 Tính nhất quán và zookie — Cân bằng giữa "Áp dụng quyền mới" và "Thu hồi tức thì"
Trong hệ thống ủy quyền, lỗi nguy hiểm nhất là việc thu hồi quyền được phản ánh trễ. Nếu một tài liệu đã được gỡ chia sẻ mà vẫn có thể xem được do cache, đó là một rò rỉ thông tin nghiêm trọng. Ngược lại, thực hiện mọi lần kiểm tra luôn trên dữ liệu mới nhất với tính nhất quán mạnh sẽ khiến độ trễ và chi phí bùng nổ. Zanzibar giải quyết căng thẳng này bằng một token nhất quán gọi là zookie.
Khi khách lưu nội dung, nó giữ zookie (bên trong là dấu thời gian Spanner) do Zanzibar cấp cùng với nội dung đó. Sau đó, một lần Check trên nội dung đó được bảo đảm sẽ được đánh giá trên một ảnh chụp tại hoặc sau thời điểm mà zookie chỉ ra. Điều này ngăn chặn sự đảo ngược "phán đoán bằng ACL cũ hơn thay đổi nội dung", qua đó ngăn vấn đề new-enemy (nội dung mới được thêm sau khi thu hồi quyền bị phơi bày dưới quyền cũ, hoặc chia sẻ thay đổi nhưng bị phán đoán theo thứ tự cũ). Trong vận hành bình thường, Check dùng một ảnh chụp nhất quán hơi quá khứ để nâng tỷ lệ trúng cache và giảm độ trễ, đồng thời đặt một cận dưới qua zookie ở nơi cần tính đúng đắn. Đây là một ví dụ điển hình về việc bảo đảm bằng thiết kế "mới đúng mức cần thiết" thay vì "luôn mới nhất".
Nhìn vấn đề new-enemy một cách cụ thể, có hai kịch bản. Thứ nhất, ngay sau khi Alice gỡ Bob khỏi một tài liệu, cô thêm nội dung bí mật, nhưng nếu lần kiểm tra quyền được đánh giá trên ảnh chụp từ trước khi gỡ, Bob sẽ thấy được nội dung mới. Thứ hai, Alice nâng quyền của Bob và ngay lập tức chuyển một tài liệu nhạy cảm vào thư mục đó, nhưng nếu thứ tự của hai thay đổi bị đánh giá đảo ngược, sự phơi bày trái với ý định sẽ xảy ra. Zookie chặn sự đảo thứ tự này tại gốc bằng cách cưỡng chế "tại hoặc sau thời điểm ACL đã tạo ra trạng thái hiện tại của nội dung". Nghĩa là, cốt lõi là bảo đảm rằng các tối ưu hóa cache và ảnh chụp cho hiệu năng không bao giờ hy sinh tính an toàn của việc thu hồi quyền.
4. Hệ sinh thái triển khai và so sánh
Vì Zanzibar chỉ được công bố dưới dạng bài báo, các triển khai mã nguồn mở và thương mại tạo nên hệ sinh thái. Các ví dụ tiêu biểu gồm OpenFGA (do Auth0/Okta dẫn dắt) trong CNCF Sandbox, SpiceDB (AuthZed), Ory Keto, và các dịch vụ được quản lý như Auth0 FGA và AuthZed Cloud. Mỗi triển khai chia sẻ các khái niệm bộ, namespace và Check/Expand của Zanzibar, nhưng khác nhau về mô hình nhất quán và sự thuận tiện vận hành.
| Triển khai | Dẫn dắt | Đặc điểm | Ghi chú |
|---|---|---|---|
| OpenFGA | Okta (Auth0) | Mô hình dựa trên DSL, CNCF Sandbox | Cộng đồng sôi động, SDK đa ngôn ngữ |
| SpiceDB | AuthZed | ZedToken tương tự zookie, hỗ trợ caveat (có điều kiện) | Trung thành nhất với Zanzibar, backend Postgres/Spanner |
| Ory Keto | Ory | Dựa trên Go, tích hợp hệ sinh thái Ory | Nhẹ, tự lưu trữ |
| Google Zanzibar | Nội bộ Google | Bản gốc, Spanner+Leopard | Không công khai (chỉ có bài báo) |
Khác biệt thực tiễn quan trọng nhất giữa các triển khai là phương thức kiểm soát nhất quán. Việc phơi bày cơ chế tương ứng với zookie ra sao—như ZedToken của SpiceDB hay tùy chọn consistency của OpenFGA—quyết định tính đúng đắn của ứng dụng. Chẳng hạn khi tính tức thì của việc thu hồi quan trọng, như thay đổi chuỗi phê duyệt trong một dịch vụ tài chính, người ta chọn truy vấn "nhất quán hoàn toàn (fully consistent)", còn khi một độ trễ nhỏ được chấp nhận, như phơi bày một bài đăng công khai, người ta chọn truy vấn "giảm thiểu độ trễ (minimize latency)"—thiết kế một bậc nhất quán theo từng tài nguyên.
4.1 Ví dụ di chuyển quyền kế thừa sang ReBAC
Giả sử một dịch vụ cộng tác tài liệu giả định trước đây quản lý quyền bằng một bảng quan hệ (doc_permissions(doc_id, user_id, role)). Bước đầu tiên của di chuyển là ánh xạ (mapping) trực tiếp các hàng này thành bộ quan hệ. Một hàng doc_permissions(42, alice, editor) trở thành một bộ doc:42#editor@user:alice. Nếu có hàng chục triệu hàng, hãy Write hàng loạt theo lô, nhưng vì các thay đổi quyền mới tiếp tục xảy ra trong lúc di chuyển, hãy đồng bộ delta sau di chuyển qua bắt thay đổi dữ liệu (CDC).
Bước thứ hai là công việc thay thế logic quyết định quyền rải rác trong mã ứng dụng (if user.role in (...) phân tán ở nhiều dịch vụ) bằng một lần gọi Check duy nhất. Ở đây, thay vì chuyển đổi ngay lập tức, hãy chạy logic hiện có và quyết định ReBAC đồng thời và so sánh kết quả (shadow mode). Ví dụ, nếu trong 100 triệu quyết định quyền mỗi ngày mà sự không khớp hội tụ xuống dưới 0,001%, chỉ khi đó mới thăng ReBAC thành điểm quyết định có thẩm quyền. Nếu bỏ qua việc chuyển đổi dần này, các lỗi mô hình hóa sẽ chuyển thẳng thành sự cố vận hành, đó là lý do trong các cuộc di chuyển quy mô lớn thực tế, nhiều thời gian nhất được đầu tư vào bước xác minh này.
Một cân nhắc thực tiễn khác là thiết kế lược đồ (mô hình). Trong DSL của OpenFGA, bạn khai báo quan hệ và kế thừa như define viewer: [user] or editor or viewer from parent, và nếu mô hình hóa sai thì đồ thị trở nên quá sâu, làm tăng độ trễ, hoặc xảy ra rò rỉ quyền ngoài ý muốn. Trong các trường hợp triển khai thực tế, các thất bại phổ biến nhất là lỗi mô hình hóa và bỏ sót đồng bộ bộ, và thiết kế di chuyển để chuyển dữ liệu quyền của hệ thống hiện có thành bộ quyết định sự thành bại của dự án.
5. Chuyên sâu — Mẫu hình triển khai và xu hướng mới nhất
Việc triển khai tại hiện trường thường tiến hành theo ba giai đoạn. Thứ nhất là định nghĩa mô hình quyền trung tâm, hội tụ logic quyền dựa trên câu lệnh if rải rác vào một mô hình OpenFGA/SpiceDB. Thứ hai là xác minh vận hành kép (shadow), chạy đồng thời phán đoán quyền hiện có và phán đoán ReBAC rồi so sánh sự không khớp qua nhật ký để chuyển đổi an toàn. Thứ ba là chuyển đổi hoàn toàn, nơi ứng dụng chỉ gọi API Check và các thay đổi quyền được nhất thể hóa qua Write. Trong quá trình này, điều quan trọng là ngăn sự không nhất quán bằng cách ràng buộc thay đổi dữ liệu (chia sẻ/thu hồi) và việc ghi bộ vào cùng một ranh giới giao dịch.
Về xu hướng mới nhất: thứ nhất, sự lan rộng của quyền có điều kiện (caveat/contextual tuple). Các điều kiện kiểu ABAC như "chỉ trong giờ làm việc" hay "chỉ từ một dải IP cụ thể" được kết hợp vào bộ, hòa trộn ReBAC và ABAC. Thứ hai, ủy quyền cho tác nhân AI và khối lượng công việc phi tiêu chuẩn. Khi một tác nhân truy cập tài nguyên thay mặt người dùng, các nỗ lực biểu diễn quan hệ ủy thác "người dùng-tác nhân-tài nguyên" dưới dạng bộ đang gia tăng. Thứ ba, các thảo luận chuẩn hóa: xu hướng ngoại biên hóa và tập trung hóa ủy quyền chi tiết (Fine-Grained Authorization) đang lan rộng song hành với khái niệm điểm quyết định chính sách (PDP) của zero trust. Thứ tư, với việc OpenFGA được nâng cấp trong CNCF và việc các đám mây ra mắt FGA được quản lý, mô hình "tiêu thụ ủy quyền như một dịch vụ" đang định hình.
Đặc biệt, trong nước, nhu cầu kiểm soát truy cập chi tiết trong khu vực công và tài chính gắn với nghĩa vụ quản lý đặc quyền truy cập và lưu giữ hồ sơ truy cập theo luật bảo vệ thông tin cá nhân, khiến tính truy vết và chứng cứ của việc cấp/thu hồi quyền ngày càng quan trọng. Mô hình dựa trên bộ quan hệ ghi lại dưới dạng dữ liệu "ai đã có được quyền truy cập, khi nào, và qua quan hệ nào", nên kết hợp tự nhiên với nhật ký kiểm toán và chứng cứ kiểm soát truy cập. Ngược lại, chỉ riêng các biểu thức chính sách kiểu ABAC phức tạp thì khó giải thích sau sự việc.
Các hướng ra đề khả dĩ gồm ① so sánh ReBAC với RBAC/ABAC và tiêu chí áp dụng, ② giải thích zookie của Zanzibar và cơ chế bảo đảm nhất quán, ③ các khái niệm bộ quan hệ và userset rewrite cùng phép duyệt đồ thị quyền, và ④ hàm ý của việc ngoại biên hóa ủy quyền chi tiết đối với kiến trúc zero-trust và microservice. Trong bài làm, tốt nhất nên trình bày "tại sao cần ReBAC ở quy mô lớn (bùng nổ vai trò)" và "sự đánh đổi tính đúng đắn-độ trễ đã được giải quyết bằng thiết kế ra sao (zookie)" làm các trục cốt lõi.
6. Cân nhắc và hàm ý
Thứ nhất, sự đánh đổi tính đúng đắn-độ trễ phải được thiết kế theo từng bậc tài nguyên. Làm cho mọi lần Check đều nhất quán hoàn toàn sẽ gây độ trễ và chi phí quá mức, còn làm tất cả ưu tiên cache thì có nguy cơ bỏ sót thu hồi. Hãy tách các bậc nhất quán (nhất quán hoàn toàn vs. giảm thiểu độ trễ) theo mức nhạy cảm của tài nguyên, và đặt cận dưới zookie một cách tường minh cho các tài nguyên mà việc thu hồi là chí mạng.
Thứ hai, việc đồng bộ dữ liệu quyền và dữ liệu nghiệp vụ phải được bảo đảm bằng giao dịch. Nếu việc gỡ chia sẻ thành công nhưng việc xóa bộ thất bại thì một quyền ma sẽ còn lại. Hãy dùng cách tiếp cận dựa trên sự kiện thay đổi (mẫu outbox) hoặc chiến lược ghi hai pha để loại bỏ về mặt cấu trúc "sự không nhất quán dữ liệu-bộ", và đưa kiểm toán nhất quán định kỳ cùng xác minh dựa trên Expand vào vận hành.
Thứ ba, thiết kế mô hình và quản trị đồng thời quyết định hiệu năng và bảo mật. Nếu đồ thị quan hệ quá sâu hoặc có chu trình thì độ trễ tăng, và nếu quy tắc kế thừa mơ hồ thì phát sinh quyền quá mức. Hãy vận hành việc rà soát, quản lý phiên bản và phân tích tác động (thay đổi này làm thay đổi quyền của những người dùng nào) đối với các thay đổi mô hình, kết hợp với Chính sách như Mã (Policy as Code).
Thứ tư, việc ngoại biên hóa ủy quyền phải đi cùng chiến lược tổ chức và kiến trúc. Tách ủy quyền chi tiết thành một dịch vụ trung tâm giúp việc nhất quán và kiểm toán dễ dàng hơn, nhưng vì mọi dịch vụ đều phụ thuộc vào Check nên nó trở thành một điểm trọng yếu đơn lẻ về độ sẵn sàng và độ trễ. Phải tiền định việc nhân bản theo vùng, một tầng cache, một chính sách fail-safe (từ chối mặc định) khi gặp sự cố, và việc quản lý SLO của chính dịch vụ ủy quyền, đồng thời phải thiết kế nhất quán với nguyên tắc tách PDP/PEP của zero trust.
Thứ năm, phải cân nhắc sự phụ thuộc vào nhà cung cấp/triển khai và tính khả chuyển. Mô hình Zanzibar là chung, nhưng token nhất quán, bộ có điều kiện và DSL lược đồ khác nhau theo từng triển khai. Đặt mô hình phía sau một tầng trừu tượng và thiết kế sao cho logic quyền cốt lõi không bị ghép quá mức vào API của một sản phẩm cụ thể sẽ giảm chi phí chuyển đổi trong tương lai.
Thứ sáu, phải quản lý khả năng quan sát hiệu năng và chi phí như các chỉ số vận hành. Ủy quyền chi tiết gọi Check trên mọi đường đi của yêu cầu, nên số lượt gọi, độ trễ p95/p99, tỷ lệ trúng cache và độ sâu duyệt đồ thị chi phối chất lượng dịch vụ. Hãy quan sát liên tục các chỉ số này trên bảng điều khiển, tái cấu trúc các mô hình có độ sâu quá mức, và phản ứng trước với các tài nguyên có nhiều truy vấn tập hợp bằng chỉ mục cụ thể hóa. Vì ủy quyền nằm trên đường đi tới hạn của mọi yêu cầu, nên coi việc lập kế hoạch dung lượng và quản lý chi phí (FinOps) của dịch vụ ủy quyền là một nhiệm vụ riêng là điều nên làm.
Tài liệu tham khảo
- Google, "Zanzibar: Google's Consistent, Global Authorization System", USENIX ATC 2019: https://research.google/pubs/pub48190/
- USENIX ATC '19 tài liệu trình bày (Zanzibar): https://www.usenix.org/conference/atc19/presentation/pang
- OpenFGA (tài liệu chính thức): https://openfga.dev/docs
- AuthZed SpiceDB (tài liệu chính thức): https://authzed.com/docs
- Ory Keto: https://www.ory.sh/keto/
Tóm tắt một câu: ReBAC lấy "quan hệ" giữa người dùng và tài nguyên làm trục của quyết định quyền để giải quyết bùng nổ vai trò trong ủy quyền chi tiết quy mô lớn, và Google Zanzibar là thiết kế tiêu biểu đồng thời đạt độ trễ thấp và tính đúng đắn của thu hồi ở quy mô toàn cầu thông qua bộ quan hệ, userset rewrite và token nhất quán zookie.