3. 访问策略模型：RBAC、ABAC 与 PDP/PEP

策略模型这东西，说白了就是「谁在什么条件下能干什么」。我在网关安全项目里摸爬滚打这些年，见过太多因为策略模型选型失误导致的权限泄露事故。今天咱们就把 RBAC、ABAC 这两个主流模型，以及 PDP/PEP 这个决策执行架构彻底讲透。

3.1 基于角色的访问控制（RBAC）

RBAC 是最经典的策略模型。它的核心思想很简单：把权限分配给角色，再把角色分配给用户。用户不直接拥有权限，而是通过角色间接获得。

举个例子。我在某金融网关项目中，给运维团队定义了三个角色：

角色	可访问资源	允许操作
系统管理员	所有网关配置、策略库	增、删、改、查
安全审计员	审计日志、告警记录	只读
普通运维	设备状态、流量统计	查看、重启服务

新员工入职，我只需要给他分配一个角色，权限自动到位。离职时撤销角色关联就行。这种模型的好处是管理成本低，适合组织架构稳定的场景。

3.2 基于属性的访问控制（ABAC）

ABAC 比 RBAC 灵活得多。它不依赖固定的角色，而是根据属性动态计算决策。属性可以来自用户、资源、环境甚至操作本身。

你想想看，RBAC 能处理「允许运维人员在工作时间访问生产环境」这种需求吗？不能，因为「工作时间」这个条件角色表达不了。但 ABAC 可以。

我习惯用策略表达式来描述 ABAC 规则。比如：

# 允许财务部员工在工作日 9:00-18:00 访问财务系统
PERMIT
  WHEN subject.department == "财务部"
    AND resource.type == "财务系统"
    AND environment.time BETWEEN "09:00" AND "18:00"
    AND environment.day_of_week IN ["Mon","Tue","Wed","Thu","Fri"]

这个表达式里没有角色，全是属性。新来的财务实习生，只要他的部门属性是「财务部」，策略自动生效。不需要提前建角色。

3.3 RBAC vs ABAC：怎么选？

很多新手问我：到底用 RBAC 还是 ABAC？我的回答是：看场景，也可以混着用。

对比维度	RBAC	ABAC
管理复杂度	低，角色定义清晰	高，属性管理需要规范
灵活性	低，新增场景需新建角色	高，属性组合即可
性能	快，缓存友好	相对慢，需实时计算
适用场景	组织稳定、权限变化少	动态环境、细粒度控制

实际项目中，我常用的是RBAC + ABAC 混合模型。先用 RBAC 做粗粒度控制，比如「运维人员可以访问服务器」；再用 ABAC 做细粒度过滤，比如「只能访问自己负责的服务器，且必须在 VPN 环境下」。这样既保留了 RBAC 的管理效率，又获得了 ABAC 的灵活性。

3.4 策略决策点（PDP）与策略执行点（PEP）

模型讲完了，接下来是架构层面的东西。PDP 和 PEP 是策略执行的核心组件，我把它俩比作「大脑」和「手脚」。

• PDP（Policy Decision Point）：策略决策点。它负责接收访问请求，根据策略模型计算「允许」还是「拒绝」。PDP 不关心请求怎么来的，只做决策。
• PEP（Policy Enforcement Point）：策略执行点。它拦截实际访问请求，把请求发给 PDP 问「能放行吗？」，然后根据 PDP 的决策结果执行放行或阻断。

下面这张图展示了 PDP 和 PEP 的协作流程：

我在实际部署时，通常把 PDP 做成独立服务，部署在管控中心。PEP 则嵌入到每个网关节点里。这样做的好处是：策略变更只需要更新 PDP，所有 PEP 自动生效，不需要逐个重启网关。

3.5 三者如何联动？

最后咱们把 RBAC、ABAC、PDP/PEP 串起来。一个典型的网关访问策略模型是这样的：

1. PEP 拦截请求，提取主体、资源、环境属性
2. PEP 构造决策请求，发给 PDP
3. PDP 先查 RBAC 角色，判断用户是否有基本权限
4. PDP 再跑 ABAC 规则，检查属性条件是否满足
5. PDP 返回 Permit 或 Deny
6. PEP 执行最终动作

嗯，这里要注意：RBAC 和 ABAC 的执行顺序很重要。我习惯先 RBAC 后 ABAC。RBAC 先做粗筛，把明显没权限的请求直接拒绝，减少 ABAC 的计算压力。只有 RBAC 通过了的请求，才进入 ABAC 的细粒度判断。