第4章 规则引擎架构：策略决策点(PDP)、策略执行点(PEP)、策略信息点(PIP)的协作

4.1 模块边界与分层

规则引擎在 ABAC 中承担“理解策略 → 收集上下文 → 做出判断 → 强制执行”的全链路职责。按 XACML 参考架构的标准划分，边界如下：

4.2 组件职责

• PEP（策略执行点）：嵌入在业务网关、API 中间件或应用拦截器中。职责包括：① 拦截用户操作请求；② 构造属性上下文并转发给 PDP；③ 接收 PDP 决策结果并强制执行（允许/拒绝/降权）；④ 记录审计日志。
• PDP（策略决策点）：规则引擎的“大脑”。职责包括：① 加载并解析策略集（XACML/ALFA/自定义 DSL）；② 接收 PEP 发来的属性上下文；③ 执行策略评估（组合、消歧、优先级裁决）；④ 返回决策结果（Permit / Deny / NotApplicable / Indeterminate）。
• PIP（策略信息点）：数据代理层。职责包括：① 对接用户身份系统（LDAP/IDP）、资源标签系统、环境上下文（时间/位置/设备）；② 缓存高频属性以减少源系统压力；③ 统一属性格式并返回给 PDP。

4.3 数据流与控制流

一次完整的权限判断遵循 5 步协作模型，数据流与控制流在组件间交替传递：

1. PEP 拦截 → 用户发起操作，PEP 提取请求主体、动作、资源三元组，封装为 RequestContext 发送至 PDP。
2. PDP 属性请求 → PDP 根据策略中声明的属性需求（如“用户部门”“资源密级”），向 PIP 发起批量属性查询。
3. PIP 数据回填 → PIP 从用户系统、CMDB、环境传感器等数据源拉取属性，聚合后返回给 PDP。
4. PDP 策略评估 → PDP 将属性注入策略引擎，执行规则匹配与组合算法，生成最终决策与责任链。
5. PEP 强制执 → PDP 将决策结果（含 Obligation / Advice）返回 PEP，PEP 执行允许/拒绝、附加审计或触发二次验证。

4.4 信任链路

三个组件之间必须建立明确的信任边界，防止中间人篡改或属性注入：

• PEP ↔ PDP：使用 mTLS 双向认证，请求与响应必须携带签名令牌（JWS），防止伪造请求或篡改决策结果。
• PDP ↔ PIP：PIP 应提供 signed attribute assertions，PDP 只接受来自受信 PIP 的属性响应，拒绝未签名的属性值。
• PIP → 数据源：PIP 自身需要凭证管理，以最小权限原则连接 LDAP、数据库或 API，避免属性泄露或被滥用。

4.5 选型权衡

4.6 风险点

• PDP 性能衰减：策略数量超过 10,000 条或属性维度超过 20 时，评估耗时指数增长。必须引入策略索引与评估超时熔断。
• PIP 级联故障：数据源不可用导致属性获取失败，PDP 应设定属性缺失默认值（Deny 优先），而非抛出异常。
• PEP 绕过风险：应用端直接调用资源接口而非通过 PEP，导致权限控制被绕过。需在基础设施层强制流量经过 PEP。

4.7 落地步骤

1. 组件选型：确定 PDP（如 AuthZForce、OPA、自研引擎）、PEP SDK 语言版本、PIP 适配器列表。
2. 属性源梳理：枚举所有用户属性、资源标签、环境上下文，完成 PIP 对接适配器开发。
3. 策略迁移与分层：将现有 RBAC 权限转化为 ABAC 策略，按“全局策略→应用策略→资源策略”分层存放。
4. 集成与联调：PEP 嵌入业务网关 → 连接 PDP 沙箱 → PIP 注册测试数据源 → 端到端验证 100 条典型场景。
5. 灰度上线：先 10% 流量经新规则引擎，对比决策结果与旧 RBAC 系统，确认无误后全量切换。

4.8 验收标准

4.9 协作架构总览

下图展示了 PDP、PEP、PIP 及周边策略存储、数据源之间的完整协作关系与数据流向：