角色扮演引擎

1）授權模式

RBAC（基於角色的訪問控制）：受試者獲得角色，角色與權利相關（permissions）。只是管理，有利於典型的職責。
ABAC（基於Attribute-Access Control）-解決方案取決於主題、資源、活動和環境（時間、IP、區域、風險）的屬性。靈活地擴展到復雜的規則。
RBAC+ABAC混合體：角色具有「基本」能力，屬性會縮小其範圍（條件）。
（可選）基於ReBAC/關系的：關系圖（所有者，團隊成員，代表）對於文檔和組織結構很有用。

2）體系結構： PDP/PEP和線程

PEP （Policy Enforcement Point）：解決方案應用地點（API網關、後端方法、SQL層、UI）。
PDP（策略決策點）：根據策略和屬性計算「ALLOW/DENY」的服務/庫。
PIP（策略信息點）：屬性源（IdP/配置文件、資源元數據、風險範圍、地理位置）。
PAP（策略管理點）：管理接口/策略存儲庫（版本、草稿、發布）。

線程：請求→ PEP形成上下文→ PDP收緊缺失屬性（通過PIP） →計算解決方案→ PEP應用（允許/禁止/切斷字段）→審核。

3）數據模型

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 「資源」的類型和屬性：「類型」，「owner_id」，「tenant_id」，「分類」（公共/confidential），「區域」，「標簽」。
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles （id, tenant_id, name, inherits［］）'-支持層次結構和模板。
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments （subject_id, role_id, scope）'-scope：全球/項目/對象。

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4）決策原則

Deny-overrides：明確禁令優先於許可證。
Least Privilege （PoLP）：提供最少的訪問權限,通過條件進行擴展。
使命分離（SoD）：禁止角色/動作組合（例如「創建付款」≠「崩潰」）。
Context-aware：在風險增加時加強需求（無MFA,可疑IP）。
Determinism：相同的上下文→相同的答案；在日誌中捕獲策略版本。

5）實現模式

5.1混合動力RBAC→ABAC（空調）

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5.2 Row/Field-Level Security

在DB級別：RLS策略（通過「tenant_id」，「owner_id」）。
在API級別：如果沒有'allow： read_sensitive_fields'則過濾集合並掩蓋字段。

5.3個「步進」解決方案"

allow if action == "export" and subject. mfa_verified == true else deny

5.4臨時入場

TTL贈款："分配。expires_at'，訪問窗口（在資源區域的工作時間）。

6）性能和緩存

使用短TTL的鍵「（subject_hash，resource_key，動作，policy_version）」的決策緩存（決策緩存）。
主題屬性邊緣緩存（令牌中的claims）+資源屬性的lazy-fetch。
Incremental invalidation：事件障礙（角色變更，策略更改，資源轉換為「機密」）。
Batch檢查：對於列表,使用「過濾器」（policy-predicate pushdown）進行評估,以免抽動PDP。

7）多範圍（Multi-tenant）

每個表都是「tenant_id」；默認策略會限制租賃內部的訪問。
租賃管理員僅管理其租賃的角色/權限。
跨租賃訪問-僅通過帶有deny-override的明確邀請/共享。

8）策略管理和生命周期

轉型：'政策。version'在PDP回復中，存儲在審計中。
環境：draft → canary（流量部分/影子模式）→ prod。
測試矩陣：按關鍵角色/屬性（合同測試）分列的真實性表。
更改管理：通過安全/合並審核對策略進行混淆。

9）審計和可觀察性

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.

度量標準：QPS PDP、p95潛伏期、hit-rate緩存、deny份額、step-up頻率、SoD事件。
跟蹤：span to PDP呼叫；與API查詢的相關性。
Replay：在新版本的策略上「重播」歷史決策的能力（安全檢查）。

10）與身份驗證和令牌集成

身份來自IdP（OIDC/SAML）。令牌具有最低屬性：「sub」，「tenant」，「roles」，「auth_time」，「amr」和「scopes」。
對於ABAC,從服務器端（PIP）拉起「嚴重」特征,以免充氣令牌。
簽名的資源tokens（能力/邀請）-用於嚴格限制的委托。

11）PDP偽代碼（簡化）

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12）反模式

「角色=頁面」（數百個沒有主題領域模型的小角色）。
僅將策略存儲在沒有版本/審核的代碼中。
缺少deny-override和SoD →增加欺詐風險。
規則中的硬列表「user_id」（代替屬性/關系）。
僅在UI中存在過濾器時,不存在數據級過濾（RLS）。
通過手動腳本同步角色,而無需事件和緩存故障。

13）案例和食譜

13.1字段級別掩碼：

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13.2僅從MFA導出數據：

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13.3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13.4委托（限定令牌）：

能力令牌包含「resource_id」，「actions=［」read「］」，「expires_at」，「aud」。PEP檢查簽名和截止日期。

14）測試

單位策略測試：按主要組合排列的真實性表。
基於屬性的：生成隨機屬性以搜索「洞」。
Golden Tests：鎖定一組關鍵端點解決方案。
Canary/Shadow：對新舊版本的策略進行並行評估，並顯示差異。

15）體系結構和協議部分的相關功能"

身份驗證和授權（OIDC/OAuth2）

同意管理

令牌化和密鑰管理

可觀察性： 邏輯、度量、跟蹤

地理路由和本地化

加密At Rest/In Transit

16）建築師支票清單

1.是否定義了主題角色及其層次結構？

2.是否有混合模型： 角色+屬性上的條件?

3.使用deny-overrides，SoD和step-up實現PDP？
4.PEP在哪裏？（網關、後端、DB、UI）-到處都是統一嗎？

5.是否針對事件設置了解決方案緩存和殘疾?

6.策略是否經過驗證、測試和滾動?

7.是否啟用了解決方案審核、指標和跟蹤?

8.支持多範圍和RLS/field-masking?

9.有關於事件和政策回歸的運行手冊嗎?

二.結論

RBAC提供可管理性，ABAC提供上下文和準確性。通過將角色與屬性條件結合起來，通過共享PDP/PEP，實施緩存，審核和策略測試，您可以將授權構建為平臺能力：可預測，可驗證和可擴展以滿足產品和監管要求。