属性授权按主体、资源、操作与环境条件计算访问决策

属性访问控制根据主体、资源、操作和环境的属性评估策略，决定一次请求是否允许。它比只按固定角色授权更能表达部门、数据敏感级别、项目归属、时间和设备状态等条件，也带来属性可信度、策略冲突和解释困难。ABAC 的价值来自受治理的属性与策略，不是条件数量越多越安全。

决策由多类属性共同形成

主体属性描述用户或工作负载，例如组织、岗位、许可等级和项目成员关系。对象属性描述资源所有者、分类、区域和生命周期。操作属性表示读取、修改、审批或导出，环境属性可包含时间、网络位置、设备健康和风险信号。

策略把这些属性关系写成允许或拒绝条件。例如“项目成员可以读取本项目内部数据”同时依赖主体项目、对象项目、操作类型和数据分类。若主体项目属性来自自报字段而非权威目录，策略形式再严密也不可信。

NIST SP 800-162 将 ABAC 描述为根据相关属性与策略评估授权的方法。它不限定某一种策略语言或部署产品。实现选型应从所需决策、属性来源和审计要求出发，不能把厂商语法当成概念本身。

策略决策点负责计算允许或拒绝，策略执行点拦截请求并执行结果。两者之间必须传递经过认证的主体、规范化资源标识、操作和环境。执行点若漏掉某条调用路径，中心策略无法补救。

策略信息点提供属性，可能来自身份目录、设备管理、资源目录或风险服务。每个属性要有权威来源、更新时间、有效期和失败行为。人员离职、项目结束或设备失去合规状态后，缓存属性必须在可接受时间内失效。

策略管理点负责创建、审核和发布策略。生产策略应版本化，变更要经过测试和审批。业务人员需要能理解授权含义，工程实现则要保留精确语义；只有自然语言说明或只有机器规则都不够。

多条策略可能同时适用。一条允许项目成员读取，另一条禁止受限数据离开指定区域。系统必须定义组合算法，例如拒绝优先、允许优先或只允许一条适用，不能依赖规则加载顺序。高敏感场景通常采用默认拒绝和显式允许。

未知属性与否定属性不同。无法取得设备状态，不等于设备不合规，也不应自动按合规处理。每个策略要定义缺失、过期和来源不可用时的结果。为可用性选择放行会产生安全风险，为安全选择拒绝则可能造成业务中断，需要按资源等级权衡并监控。

角色可以作为属性存在。RBAC 适合稳定岗位和粗粒度权限，ABAC 适合在角色基础上增加资源和环境条件。二者可以组合，没有必要为了追求纯粹模型把清晰角色全部拆成难懂条件。

零信任强调不能只因网络位置或既有会话就隐式信任，请求要依据身份、资源和上下文持续判断。ABAC 可承载这些条件，但认证、设备证明、网络保护和审计仍是独立能力。策略返回允许也不表示后续数据使用自动合规。

最小权限不仅限制允许操作，还限制资源范围和持续时间。临时项目访问可以带到期属性，紧急权限应有理由、审批和事后复核。宽泛通配符会让属性模型退化成永久超级权限。

服务到服务授权同样需要主体属性。工作负载身份、命名空间、部署环境和服务所有者可参与决策，但必须防止调用方自行伪造请求头。属性应由可信代理或令牌声明传递，并校验签名、受众和有效期。

每次请求远程查询多个属性会增加延迟和依赖。缓存能提高性能，却延长撤权时间。应按属性风险设置有效期，对高风险撤销提供推送或集中会话控制，并在属性服务故障时采用明确降级策略。

策略决策可以缓存，但键必须包含所有影响结果的属性和策略版本。遗漏环境或资源分类会复用错误结果。策略更新后需使相关缓存失效。不能只测平均延迟，还要测属性服务慢响应和批量撤权时的尾延迟。

分布式系统中的资源元数据可能短暂不一致。资源从内部改为受限后，旧副本仍可能返回允许。敏感分类变更需要明确一致性边界，必要时先阻止访问、更新属性，再重新开放。

策略测试应包含允许、拒绝、缺失属性、过期属性、冲突规则和边界时间。使用属性组合生成测试时，要覆盖现实可达状态，也要检查不应出现却可能由系统错误产生的状态。变更前后比较决策矩阵，可以发现权限扩大。

审计日志至少记录请求主体、资源、操作、决策、策略版本和关键属性来源，同时避免泄露完整敏感属性。日志应能解释为何拒绝或允许，而不是只返回布尔值。用户可见错误不必暴露策略细节，内部审计仍需足够证据。

定期审查要从真实资源与调用出发，识别长期未使用权限、永不命中的规则和大量例外。属性体系随着组织变化会老化；没有所有者的属性和策略应退出，而不是永久叠加。

ABAC 能表达细粒度授权，但复杂度也集中在属性治理和策略生命周期。先建立少量可信属性、明确组合与默认行为，再逐步扩展，比一次写出庞大条件集合更可控。