ABAC 模型详细设计：属性、策略与动态授权决策

RBAC 能说明王芳具备付款审批能力，却不能完整表达：只能审批华东分公司、金额不超过十万元、不能审批本人创建的付款单、必须完成 MFA、设备风险不能过高。把这些条件继续拆成角色，会产生“华东十万元审批员”“华东五十万元审批员”等角色爆炸。

ABAC 根据主体、资源、操作和环境属性执行策略，适合动态、细粒度的授权判断。

1. 四类属性

主体属性

subject.department_id
subject.position
subject.approval_limit
subject.employment_status
subject.mfa_level

资源属性

resource.tenant_id
resource.organization_id
resource.creator_id
resource.amount
resource.sensitivity
resource.status

操作属性

action.name = approve
action.risk_level = HIGH
action.is_bulk = false

环境属性

environment.current_time
environment.source_ip
environment.device_trust
environment.risk_score
environment.impersonation

属性必须有定义、数据类型、可信来源和失败策略。不能让客户端自己提交 approval_limit 或 department_id 并直接作为可信属性。

2. 属性来源 PIP

属性可能来自身份系统、组织中心、业务数据库、设备管理、风险引擎和请求上下文。高风险策略需要知道属性的事实源和新鲜度。

subject.department_id → 组织中心
resource.amount → 财务服务
resource.creator_id → 付款单数据库
environment.device_trust → 设备风险服务

属性定义应声明：是否必需、是否多值、缓存 TTL、来源失败时拒绝还是使用可信快照。必需属性缺失应产生 Indeterminate 并最终拒绝。

3. 策略结构

一条完整策略通常包含：

• Target：适用于哪些主体、资源和操作。
• Condition：需要满足的表达式。
• Effect：Permit 或 Deny。
• Obligation：允许后必须执行的动作。
• Advice：非强制提示。

付款审批策略可以表达为：

Target: finance:payment:approve
Condition:
  subject.department_id == resource.organization_id
  AND resource.amount <= subject.approval_limit
  AND resource.creator_id != subject.id
  AND environment.mfa_level >= 2
Effect: Permit
Obligation: WRITE_HIGH_RISK_AUDIT

策略语言应保持授权语义，不要把库存计算、会计分录和复杂状态机全部搬进策略引擎。

4. PAP、PDP、PEP、PIP

• PAP：创建、测试、发布和回滚策略。
• PDP：接收请求、加载策略和属性，作出决策。
• PEP：在 API、Service、网关或 Repository 执行结果。
• PIP：提供主体、资源和环境属性。

PDP 不直接修改付款单，它只返回：

{
  "decision": "ALLOW",
  "reason": "ALLOW_PAYMENT_POLICY",
  "obligations": ["WRITE_HIGH_RISK_AUDIT"],
  "policyVersion": "finance.payment.approval@12"
}

PEP 必须执行强制义务；无法完成高风险审计时，应拒绝，而不是静默忽略。

5. 四态决策

策略引擎内部常见：

对业务系统最终必须收敛为 ALLOW/DENY。Not Applicable 不形成允许依据；Indeterminate 默认拒绝，除非明确允许使用未过期、可验证的安全快照。

6. 策略组合算法

Deny Overrides

任何适用策略 Deny 即拒绝。适合租户隔离、外部用户限制、MFA、敏感数据和职责分离。

Permit Overrides

任意策略 Permit 即允许。适合多个独立的低风险允许来源，但不能覆盖系统级强制 Deny。

First Applicable

按明确顺序使用第一条适用策略。适合例外在前、默认规则在后的场景，顺序必须版本化和可测试。

Priority Based

按显式优先级选择。适合紧急策略、灰度策略和复杂业务例外，不能依赖数据库无序返回。

不同策略集可以使用不同算法，不能把“Deny 永远优先”硬编码为唯一模型。

7. 强制策略与业务策略

强制安全策略包括：租户不匹配、主体禁用、权限撤销、代理会话过期、敏感操作缺少 MFA。它们应在普通业务策略之前执行，不能被业务 Permit 覆盖。

业务策略包括审批额度、工作时间、项目阶段和外部成员下载限制。它们可以有自己的组合算法，但必须服从强制边界。

8. 属性和策略传播

ABAC 中更准确的说法是属性传播和策略层级，而不是角色式权限继承。

例如项目设置 sensitivity=CONFIDENTIAL，子文档默认继承该属性；某文档可以设置更高的 SECRET，但不能降低到低于项目强制级别。组织属性可以向成员提供默认数据归属，但用户临时项目身份可能追加另一个 Scope。

每类传播都要定义：

• 从哪里到哪里；
• 子级能否覆盖；
• 覆盖是提高还是降低限制；
• 如何停止传播；
• 最终决策如何展示来源。

9. 付款审批完整决策

王芳审批 P1001 时：

1. RBAC 确认她拥有 finance:payment:approve。
2. Scope 确认 P1001 属于华东分公司。
3. ABAC 确认 8 万元不超过 10 万元额度。
4. 动态职责分离确认创建人刘敏不是王芳。
5. 环境策略确认 MFA 与设备风险。
6. 返回 Allow 和高风险审计义务。
7. 业务服务再确认状态为待审批并执行乐观锁更新。

权限和业务状态不能互相替代。

10. Obligation 与 Advice

常见 Obligation：

• MASK_SENSITIVE_FIELDS：返回前脱敏。
• ADD_WATERMARK：文档预览或下载加水印。
• REQUIRE_MFA：继续操作前完成二次认证。
• LIMIT_EXPORT_ROWS：限制导出数量。
• WRITE_HIGH_RISK_AUDIT：必须持久化高风险日志。
• REQUIRE_HUMAN_CONFIRMATION：Agent 高风险工具调用需人工确认。

Advice 可以提示权限即将到期或建议记录扩展日志，但不能作为安全边界。

11. 委托、代理和 Agent

王芳委托五万元以内的审批能力时，策略必须同时检查：委托未过期、权限不超过王芳原授权、Scope 不扩大、金额不超过委托额度、被委托人不是付款单创建人。

Agent 代表张三时采用权限交集：

Effective = 张三权限 ∩ report-agent权限 ∩ Agent工具权限

即使张三可以修改订单，默认只读的 report-agent 也不能修改。提示词不能改变授权上下文，工具调用参数还必须在 PEP 重新校验。

12. 策略版本与发布

已发布策略不可原地修改。流程建议：

DRAFT → TESTING → SHADOW → PUBLISHED → DEPRECATED → RETIRED

Shadow 模式只计算新策略结果，不影响真实决策，用于与旧策略对比。决策日志必须记录策略版本、输入属性摘要和命中规则，才能复现历史结果。

策略发布前应运行固定测试用例和属性边界测试，例如金额 49999、50000、50001，时间窗口起止点，以及缺失属性。

13. 可解释性

仅返回 false 无法运维复杂策略。内部决策结果至少应包含：

{
  "decision": "DENY",
  "reasonCode": "DENY_APPROVAL_LIMIT_EXCEEDED",
  "matchedPolicy": "finance.payment.approval-limit",
  "policyVersion": 12,
  "attributes": {
    "resource.amount": 120000,
    "subject.approval_limit": 100000
  }
}

面向用户可以只显示“审批金额超过权限范围”，避免泄露安全策略细节；内部日志保留完整解释。

14. 性能设计

性能瓶颈通常不在布尔表达式，而在属性获取和远程调用：

• 将稳定主体属性做版本化缓存；
• 把业务请求已经读取的资源属性直接传给 PDP，避免重复查询；
• 高并发服务可部署本地 PDP 或 Sidecar；
• 批量资源使用批量决策或数据过滤表达式；
• 动态风险属性设置短 TTL，不能与岗位属性使用相同缓存周期；
• 决策缓存键必须包含影响结果的上下文摘要和 policyVersion。

15. 常见错误

• 把所有业务 if 都迁移到策略引擎。
• 客户端提交的部门、额度被当成可信属性。
• 属性缺失时默认允许。
• 多策略冲突依赖数据库返回顺序。
• 已发布策略原地修改，历史结果无法复现。
• 只缓存 userId + permissionCode，忽略金额、资源和设备。
• PEP 收到脱敏或审计义务却没有执行。
• 策略只有技术人员能看懂，权限产品和审计人员无法解释。

16. 适用边界

ABAC 适合动态条件和跨维度策略，但它不能替代 RBAC 的可管理性，也不能自动解决 SQL 数据过滤。常见组合是：RBAC 提供基础能力，ABAC 判断动态条件，数据权限把条件落到查询和写操作。

参考资料

• OWASP Authorization Cheat Sheet

• NIST Role Based Access Control

• NIST SP 800-162: Guide to Attribute Based Access Control

• OASIS XACML 3.0 Core Specification

• Zanzibar: Google’s Consistent, Global Authorization System

• Cedar Policy Language Reference Guide

• Open Policy Agent Documentation

• Keycloak Authorization Services