3. 设备接入策略引擎：PEP/PDP 架构与 ABAC 实战

策略引擎，说白了就是零信任架构里的「大脑」。设备能不能接入？能访问哪些资源？全得靠它说了算。我刚开始接触零信任时，总觉得策略引擎就是个规则匹配器，后来踩了不少坑才明白——它的架构设计直接决定了整个系统的安全水位和性能上限。

3.1 PEP/PDP 架构设计：谁来做决策，谁来执行？

零信任里有个经典的分工：PDP（Policy Decision Point） 负责决策，PEP（Policy Enforcement Point） 负责执行。你想想看，如果让同一个组件既做决策又做执行，一旦被攻破，攻击者就能自己给自己发通行证——这太危险了。

我在项目中遇到过一种典型架构：PEP 部署在网关或代理层，所有设备接入请求先到 PEP，PEP 把上下文信息打包发给 PDP，PDP 返回「允许」或「拒绝」，PEP 再执行相应动作。嗯，这里要注意——PEP 和 PDP 之间的通信必须加密，而且要有超时和降级策略。

PEP/PDP 交互流程

1. 设备发起接入请求：携带设备ID、用户身份、地理位置、时间等属性
2. PEP 拦截请求：提取上下文，构造策略评估请求（PAR）
3. PEP 发送 PAR 给 PDP：通过 gRPC 或 REST API，使用 mTLS 加密
4. PDP 执行策略计算：基于 ABAC 规则，结合属性源数据
5. PDP 返回决策结果：Permit / Deny / NotApplicable / Indeterminate
6. PEP 执行决策：放行、阻断、或触发二次认证

PEP/PDP 部署模式对比

部署模式	适用场景	优点	缺点
集中式 PDP	中小规模，策略统一	管理简单，策略一致	单点故障，性能瓶颈
分布式 PDP	大规模，多区域部署	高可用，低延迟	策略同步复杂
嵌入式 PEP+PDP	边缘设备，离线场景	本地决策，无网络依赖	策略更新困难

我个人习惯在大型项目中使用分布式 PDP + 本地缓存。每个区域部署一个 PDP 实例，策略从中心同步到边缘。这样既保证了决策速度，又避免了单点故障。

3.2 基于 ABAC 的策略定义：属性才是王道

传统基于角色的访问控制（RBAC）有个硬伤——角色粒度太粗。比如「管理员」这个角色，可能包含 50 种权限，但某个设备只需要其中 3 种。你给多了有风险，给少了又没法干活。ABAC（属性基访问控制）就是来解决这个问题的。

ABAC 的核心思想是：用属性来描述主体、资源、环境和动作，然后基于属性组合来定义策略。说白了，就是「谁（主体属性）在什么时间（环境属性）用什么设备（主体属性）对什么资源（资源属性）做什么操作（动作属性）」。每个维度都可以灵活组合。

ABAC 属性分类

属性类别	示例	来源
主体属性	用户角色、设备类型、设备合规状态、设备位置	IAM、MDM、CMDB
资源属性	资源分类、敏感等级、所属部门、数据标签	数据目录、标签系统
环境属性	当前时间、网络位置、威胁等级、地理位置	时钟、GPS、威胁情报
动作属性	读、写、执行、删除、导出	API 定义、操作枚举

我在项目中遇到过这样一个场景：某公司的研发人员需要从内网访问生产数据库，但只能在工作时间操作，而且必须使用公司配发的合规笔记本。用 ABAC 来表达就是：

策略示例：
IF
  主体.角色 == "研发工程师" AND
  主体.设备类型 == "公司笔记本" AND
  主体.设备合规状态 == "合规" AND
  资源.敏感等级 <= "L3" AND
  环境.时间 BETWEEN "09:00" AND "18:00" AND
  环境.网络位置 == "内网" AND
  动作 == "查询"
THEN
  决策 = "允许"

策略定义的最佳实践

• 属性值尽量用枚举：避免自由文本，比如设备类型用 "笔记本/手机/服务器" 而不是用户自己填
• 策略要有版本号：每次修改都生成新版本，方便回滚和审计
• 默认拒绝：所有未匹配到策略的请求，默认 Deny
• 策略优先级：越具体的策略优先级越高，避免冲突

3.3 动态策略计算与缓存机制：又快又准才是真本事

策略引擎光能决策还不够，还得快。你想想看，每次设备接入都要查数据库、算属性、匹配规则，如果耗时太长，用户早就骂娘了。动态策略计算的核心就是：在保证安全的前提下，尽可能快地给出决策。

动态策略计算流程

1. 请求入队：PEP 发送 PAR 到 PDP，PDP 将请求放入处理队列
2. 属性解析：从 PAR 中提取主体、资源、环境、动作属性
3. 属性补全：从属性源（如 LDAP、CMDB）获取缺失的属性
4. 策略匹配：遍历策略库，找到所有匹配的策略
5. 策略评估：按优先级计算策略组合结果
6. 决策输出：返回 Permit / Deny 及决策原因

嗯，这里要注意——属性补全这一步最容易成为性能瓶颈。每次都要查外部系统，延迟肯定高。我的解决方案是：预加载 + 缓存。

缓存机制设计

缓存层级	缓存内容	失效策略	推荐 TTL
L1 本地缓存	策略定义、设备属性、用户属性	定时刷新 + 事件通知	5-10 分钟
L2 分布式缓存	策略评估结果、属性聚合数据	LRU + 过期删除	1-5 分钟
L3 持久化存储	策略库、审计日志	不主动失效	永久

我曾经在项目中遇到过一个经典问题：缓存里的设备属性是旧的，导致合规设备被误判为不合规。后来我加了一个「属性版本号」机制——每次设备属性变更时，版本号递增。PDP 在决策时先比较版本号，如果缓存版本落后，就重新查询属性源。嗯，这个方案虽然增加了一点复杂度，但彻底解决了数据一致性问题。

动态策略计算的性能指标

• P50 延迟 < 10ms：大部分请求应该从缓存命中
• P99 延迟 < 50ms：最慢的请求也不能超过 50ms
• 缓存命中率 > 95%：如果命中率太低，说明缓存策略有问题
• 策略加载时间 < 1s：PDP 启动时加载所有策略的时间