角色扮演引擎

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，实施缓存，审核和策略测试，您可以将授权构建为平台能力：可预测，可验证和可扩展以满足产品和监管要求。