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限制器和不可更改的审计。