API中的訪問控制和RBAC
1）為什麼API中的訪問控制
授權是對"此代理人現在可以對該資源執行此操作嗎？».錯誤導致BOLA/IDOR泄漏，權利升級和違反監管機構的要求。目的是構建一個分層模型：外圍→服務市政廳→業務規則，在對象級別上具有明確的策略和檢查。
2）授權模式： 何時選擇
RBAC（基於角色的訪問控制）-角色→權限。簡單，穩定，但容易出現「角色爆炸」。
ABAC（基於屬性）-針對主體/對象/上下文屬性（國家/地區、KYC級別、資源所有者、風險）的解決方案。
ReBAC（基於關系的）是關系圖（所有者，團隊成員，「項目經理」）；解決復雜的層次結構。
Scopes（OAuth）是客戶端與資源服務器之間有關「訪問區域」（例如「payments：write」）的合同。
實踐：基本矩陣的RBAC、上下文和約束的ABAC、復雜層次結構（文件夾、組織、限制和子目錄）的ReBAC。
3）資源和行動的分類法
層次結構：'org → project → wallet → transaction'。自上而下的權利繼承與可能的「限制」。
行動：CRUD+域特異性（「approve」，「refund」，「settle」）。
資源屬性：所有者,區域,狀態,風險標簽（AML/KYC）,限制。
多重性：所有解決方案均包含「tenant_id」；默認情況下禁止交叉限定請求（deny-by-default）。
4）體系結構： 在哪裏做出決定
PEP （Policy Enforcement Point）-驗證位置：網關/API網關,sidecar市政廳,服務本身。
PDP（政策決策點）是策略引擎：集中（OPA服務，Cedar引擎）或內置庫。
PIP （Policy Information Point）-屬性源：用戶/角色目錄、tenant配置文件、KUS/風險、資源所有權卡。
PAP（策略管理點）-策略版本控制、發布、審核。
建議：在PEP中集中化PDP+本地解決方案緩存；當存在域不變性時，服務中的復雜對象檢查。
5）代幣，汙名和身份
OIDC/OAuth2：「sub」（主題標識符），「aud」（目標服務），「scope」/「roles」，「tenant」，「kyc_level」，「risk_tier」。
JWT：RS/ES簽名，簡短的「exp」，重新發行。不要放下PII；使用「jti」進行召回/跟蹤審核。
mTLS/HMAC：服務臺服務和合作夥伴；粘合劑通過「client_id」從目錄中拉出。
Device/Context： IP/ASN, geo, Day Time-登錄ABAC解決方案（例如,禁止在工作時間之外寫入）。
6）對象級別授權（BOLA-first）
每個操作都必須響應"對象是否擁有"resource_id"？
所有權檢查：'資源。owner_id == subject.id"或具有角色的'org'成員資格。
樣本過濾： 始終叠加「WHERE資源」。tenant_id =:tenant AND...` (row-level security).
對於引用操作（路徑/主體中的ID）-規範化並驗證業務邏輯。
7） RBAC設計： 角色、分辨率、套件
許可證（permissions）是原子權利： 'wallet。read`, `wallet.write`, `payment.refund`.
角色-命名權限集： 「admin」、「support」。read`, `cashier`, `fraud.analyst`.
Scopes是客戶的外部合同（映射scope→permissions）。
避免角色爆炸：- 基本角色+「附加組件」（permission packs）,
- ABAC（國家/地區/tenant）的限制，
- 「臨時升級」（Just-In-Time Access,有效期）。
8） AVAS/上下文限制
地理/管轄權：禁止來自被禁國家的寫作（制裁/監管）。
時間/風險：大型操作的'risk_score <threshold'。
KUS/限制：「kyc_level>=2」用於>X結論；控制事務之間的「冷卻」。
「受信任的設備」：要求危險路線上的合作夥伴使用mTLS。
9） ReBAC和權利圖
適用於復雜的業務結構（組、團隊、品牌、分支機構）。
關系：「成員」，「admin」，「owner」，「viewer」。
衍生權利：資源的「查看者」是從「org」擁有的「成員」項目繼承而來的。
圖存儲庫：具有關系矩陣的DB，專業服務（本著Zanzibar方法的精神）。緩存響應「check（主題、關系、對象）」。
10）解決方案緩存和性能
PEP級別的PDP緩存（例如網關中的PDP緩存）按鍵為："sub'tenant"資源"action" policy_version"。
TTL短（秒數至分鐘）+事件致殘：改變角色/關系/特南特。
列表的batch檢查（bulk authz）：減少PDP charges。
測量解決方案的後端；退化-graceful-degradation僅用於閱讀（絕不用於寫作/現金）。
11）政策示例
11.1個JWT標簽→粗糙的PEP（偽網關）
yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"11.2 OPA/Rego (ABAC + BOLA)
rego package authz
default allow = false
allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}
allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}11.3管轄限制（deny-list policy）
rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}11.4 ReBAC（偽）政策)
allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org) ∧ wallet. tenant == subject. tenant.12）策略和版本管理
將策略（「policy_version」）和金絲雀轉換為危險更改。
「Dry-run/shadow decisions」-在沒有影響的情況下編寫「allow/deny」。
策略和遷移目錄：誰，何時以及為什麼更改；與事件匹配。
否定情景測試（禁止的案例）-在CI中是強制性的。
13）可觀察性和審計
解決方案的邏輯是：「trace_id」，「subject」，「tenant」，「action」，「resource_id」，「result」，「policy_version」，拒絕的原因。
度量標準：「authz_decision_latency」，「authz_denied_total {action}，」BOLA嘗試份額，緩存命中率。
Dashbords：在行動/tenant上排名第一，政策發布後的趨勢。
14）安全和可持續性
Deny-by-default：沒有顯式分辨率=禁令。
失敗封閉：當PDP不可用時,關鍵的寫作→禁止（或降級為嚴格驗證角色的「最小集」）。
關鍵不變量（例如「tenant」/「owner」）服務中的本地「警衛檢查」。
JWT中的汙名最小化；通過安全通道通過PIP裝載敏感屬性。
15） iGaming/財務細節
角色： 「cashier」，「kyc」。agent`, `aml.officer`, `fraud.analyst`, `vip.manager`, `risk.admin`.
限制：支付操作取決於「kyc_level」，責任支付限制，AML狀態/制裁。
鎖註冊表：'org/brand/device/payment_instrument'-write上的ABAC過濾器。
審計日誌對KYC/AML/結論操作不變；按照監管期限進行存儲。
Partnership API： mTLS+路線上的合同「scopes」 、周邊的地理/ASN過濾器。
16）測試和驗證
Negative矩陣：列出顯式「禁止」案例並通過測試固定。
Fuzz授權：變換「tenant_id」，「owner_id」，在分區/排序時繞過過濾器。
PDP負載測試：檢查p95/p99緩存的潛在性和行為。
策略發布：dry-run+canary+自動驗證與預期的deny/allow。
事件：在看臺上使用策略的精確版本進行查詢。
17）反模式
僅依靠「scope」而不進行對象檢查（BOLA）。
在沒有集中化模型的情況下,將業務邏輯和權限驗證混為一談。
在UI中扮演角色並信任客戶解決方案。
DB查詢中缺少「tenant」/「owner」過濾器（leaky reads）。
在改變角色/關系時,不會導致緩存決策失效。
長壽的JWT，沒有召回/旋轉。
18）準備就緒支票清單
- 定義資源/活動、層次結構和多範圍。
- 基本的RBAC矩陣+需要的ABAC限制器是ReBAC。
- PDP/PEP設計；有一個本地解決方案緩存及其殘疾。
- 政策制定者在CI中進行反向場景測試。
- 在每個write/read中對特定的「resource_id」進行BOLA檢查。
- JWT具有最小的烙印，短的「exp」；「jti」審計/召回。
- 決策度量/logs、dashbords、alerta by deny/latency。
- 對於關鍵的寫作是失敗的；折返模式已記錄下來。
- 客戶文檔：「scopes」，錯誤代碼（401/403/404/409），示例。
19) TL;DR
建立BOLA第一授權：中央PDP+解決方案緩存,RBAC作為基礎,ABAC為上下文,ReBAC為關系。所有查詢都在「tenant」和特定的「resource_id」上下文中；deny-by-default，JWT短，DB中的對象過濾器。測試和測試策略,量度latency/deny,事件再現回放.對於iGaming，是單獨的角色（KYC/AML/收銀員），剛性ABAC限制器和不可更改的審計。