4. ABAC核心概念：属性、策略语言、规则引擎

ABAC（Attribute-Based Access Control）的核心思想是将访问控制决策建立在属性之上，通过灵活的策略语言描述规则，并由独立的规则引擎动态评估。从架构视角来看，这三个概念共同构成了ABAC的边界、分层和信任链路。本章将从边界定义、组件职责、数据流、选型权衡、风险点和落地步骤等维度拆解这些核心要素。

4.1 属性体系：主体、资源、环境、操作

ABAC将权限决策所需的全部上下文抽象为四类属性。属性的边界决定了策略的表达能力和性能开销。

4.2 策略语言：表达规则的标准与选择

策略语言是ABAC的“编程语言”，用于编写何时允许/拒绝访问的规则。主流选择包括XACML、ALFA以及各类自定义DSL。从分层角度，策略语言层位于规则定义工具与规则引擎之间。

• XACML：OASIS标准，基于XML，功能完备但冗长。适合大型跨组织体系。
• ALFA：更简洁的语法，可编译为XACML，降低编写门槛。
• 自定义DSL：如permit if user.department == resource.owner_department && time.hour in [9, 18]，性能高，但缺乏可移植性。

以下是一个简化的ALFA策略片段示例：

policy allowIntraDepartment {
  target clause Action == "read"
  condition user.department == resource.owner_department
  permit
}

4.3 规则引擎：决策与执行的组件职责

规则引擎是ABAC的运行时核心，按照参考架构分为三个关键组件：PEP（策略执行点）、PDP（策略决策点）、PIP（策略信息点）。它们的职责和交互形成了ABAC的数据流与控制流。

• PEP：拦截访问请求，向PDP发起决策请求，并根据返回的Decision（Permit/Deny/NotApplicable/Indeterminate）执行放行或拒绝。
• PDP：加载策略规则，调用PIP获取必要属性，执行规则引擎评估，返回决策。
• PIP：属性聚合器，从IAM、元数据服务、上下文代理等数据源拉取属性并缓存。

数据流与信任链路

一次典型ABAC决策的数据流如下：

1. 用户发起访问操作（例如：读取文档X）。
2. PEP拦截请求，提取主体、资源、操作、环境摘要，封装成XACML请求上下文。
3. PEP将请求上下文发送给PDP（可通过REST/gRPC）。
4. PDP解析策略规则，发现需要的属性（如部门、时间），向PIP发起属性查询。
5. PIP从各个数据源获取属性值（如LDAP查user.department，时钟查time），返回给PDP。
6. PDP执行规则引擎（如Balana、AuthzForce），得出决策。
7. PDP返回Decision给PEP，PEP执行放行或拒绝。

4.4 选型权衡：ABAC在设计阶段的决策点

4.5 风险点

• 属性源不可靠：属性值可能过时或被篡改，导致授权错误。
• 策略规则冲突：多条规则同时匹配时决策结果不确定，需定义冲突消解策略（如FirstMatch、DenyOverride）。
• 规则引擎性能瓶颈：在高并发场景下PDP成为热点，需水平扩展PDP实例或引入属性缓存。
• 属性泄露：PIP跨服务调用可能暴露敏感属性（如用户地理位置），应使用脱敏或最小属性原则。

4.6 落地步骤

1. 属性建模：与业务团队梳理所有可能需要的属性，定义数据结构、数据源和更新频率。
2. 策略语言选型：根据团队能力、性能要求和互操作性需求选择XACML、ALFA或自定义DSL。
3. 规则引擎开发/集成：开源选项如Balana、AuthzForce、OpenPolicyAgent；企业级可购买商业PDP。
4. PEP适配：在每个需要鉴权的业务服务前端嵌入PEP拦截器（如Spring Security Filter、API Gateway插件）。
5. PIP整合：对接IAM、CMDB、设备管理系统，实现属性查询接口及缓存策略。
6. 策略沙箱验证：建立测试环境，使用不同属性组合验证策略是否符合预期，并压测规则引擎性能。

4.7 验收标准

• 所有定义的策略在测试图中100%覆盖业务场景（正例、反例、边界例）。
• PDP在99%的请求中响应时间不超过50ms（不含属性源延迟）。
• 属性源接口可用性≥99.9%，PIP缓存命中率≥80%。
• 策略变更后10秒内生效（或通过重新加载机制），且变更历史可审计。
• 无属性泄露事件（通过渗透测试验证）。