零信任架构核心组件：策略引擎、策略管理员、策略执行点与信任评估引擎
零信任架构不是买一台设备就能搞定的。它是一套组件协同工作的体系。我个人习惯把核心组件拆成四个角色：策略引擎（PE）、策略管理员（PA）、策略执行点（PEP），以及信任评估引擎。这四个东西各司其职，缺一个都不行。
说白了，零信任的决策逻辑就是：先评估信任，再制定策略，然后下发执行。今天我们就把这套流程掰开揉碎讲清楚。
核心观点：零信任架构的本质是「持续验证，永不信任」。所有组件都围绕这个原则运转。
2.1 策略引擎（PE）—— 决策的大脑
策略引擎是整个零信任架构的决策中心。它负责回答一个核心问题：「这个请求该不该放行？」
我在项目中遇到过不少团队，一开始把策略引擎当成一个简单的规则匹配器。嗯，这其实是个误区。真正的策略引擎需要综合多个维度的信息来做决策：
- 身份信息：谁在请求？是员工、外包还是第三方系统？
- 设备状态：设备是否合规？有没有打补丁？有没有安装杀毒软件？
- 网络环境：请求来自内网还是外网？IP 是否可信？
- 行为特征：这个用户平时的访问模式是怎样的？有没有异常？
- 数据敏感度：要访问的数据是公开的、内部的还是绝密的？
策略引擎拿到这些信息后，会输出一个决策结果：允许、拒绝、或需要进一步验证（比如 MFA）。
我的经验：策略引擎的决策速度很关键。如果每次请求都要等几百毫秒才能拿到结果，用户体验会非常差。我建议把高频决策缓存起来，或者用本地策略代理来加速。
2.2 策略管理员（PA）—— 策略的翻译官
策略管理员是连接「策略引擎」和「策略执行点」的桥梁。它的工作很简单：把策略引擎的决策翻译成执行点能理解的指令。
你想想看，策略引擎输出的可能是「允许用户 A 访问应用 B」，但策略执行点（比如一个防火墙或 API 网关）需要的是具体的规则，比如「源 IP 段 X，目标端口 Y，协议 Z，放行」。策略管理员就是做这个翻译工作的。
我曾经见过一个项目，策略引擎和策略执行点之间没有策略管理员，直接硬编码规则。结果每次策略变更都要改代码，运维同学苦不堪言。后来我们引入了策略管理员，把策略抽象成「策略即代码」，用 YAML 或 JSON 来描述，再自动下发到各个执行点。效率提升了一大截。
| 组件 | 核心职责 | 常见实现 |
|---|---|---|
| 策略引擎（PE） | 基于信任评估做出决策 | OPA、自定义策略服务 |
| 策略管理员（PA） | 翻译并分发策略到执行点 | 策略代理、配置中心 |
| 策略执行点（PEP） | 在请求路径上拦截并执行策略 | API 网关、防火墙、代理 |
| 信任评估引擎 | 持续评估信任分数 | UEBA、风险分析服务 |
2.3 策略执行点（PEP）—— 门卫
策略执行点就是那个站在门口检查通行证的人。它部署在请求的必经之路上，拦截所有流量，然后问策略管理员：「这个请求能过吗？」
策略执行点有几个关键特性：
- 无处不在：可以在网络层（防火墙）、应用层（API 网关）、甚至数据层（数据库代理）部署。
- 无状态：它不保存策略，只负责执行。策略变更由策略管理员统一管理。
- 高性能：不能成为性能瓶颈。我见过一些方案把 PEP 做成一个中心化的代理，结果所有流量都经过它，延迟飙升。更好的做法是分布式部署，让 PEP 靠近被保护的资源。
避坑指南：我曾经在一个项目中，把所有 PEP 都部署在同一个数据中心。结果数据中心网络抖动，所有业务都受影响。后来我们做了多活部署，每个区域都有独立的 PEP 集群，即使某个区域挂了，其他区域还能正常工作。
2.4 信任评估引擎—— 持续的打分器
信任评估引擎是零信任架构里最「智能」的部分。它不直接做决策，而是给策略引擎提供「信任分数」。
举个例子：用户 A 从公司内网登录，设备合规，行为正常，信任分数可能是 90 分。但如果他突然从海外 IP 登录，设备也没打补丁，信任分数可能瞬间降到 30 分。策略引擎拿到这个分数后，可能会要求他做 MFA，或者直接拒绝访问。
信任评估引擎通常依赖以下数据源：
- 身份与访问管理（IAM）：用户身份、角色、权限。
- 终端检测与响应（EDR）：设备健康状态、是否有恶意软件。
- 用户与实体行为分析（UEBA）：行为基线、异常检测。
- 威胁情报：IP 信誉、已知攻击模式。
我个人习惯把信任评估引擎设计成「实时 + 离线」双模式。实时模式处理在线请求，离线模式做批量分析和模型训练。这样既能保证响应速度，又能不断优化评估准确性。
2.5 组件协作流程
这四个组件是怎么配合的？我画了一张图，你看完就明白了。
流程其实不复杂：
- 用户发起请求，首先碰到 PEP。
- PEP 自己没有决策能力，它向 PA 查询策略。
- PA 把请求转给 PE，PE 开始做决策。
- PE 向 信任评估引擎 获取当前的信任分数。
- 信任评估引擎返回分数，PE 综合所有信息做出决策（允许/拒绝/MFA）。
- 决策通过 PA 翻译成执行指令，下发给 PEP。
- PEP 执行指令：放行请求到资源，或者直接拒绝。
我的建议：在实际部署时，不要把 PEP 和 PA 放在同一个进程里。它们职责不同，应该独立部署，方便独立扩缩容。PEP 需要高性能，PA 需要高可用，分开部署更灵活。
2.6 组件之间的通信安全
这四个组件之间要频繁通信。你想想看，如果通信链路被篡改或窃听，整个零信任架构就形同虚设。所以组件之间的通信必须做到：
- 双向 TLS（mTLS）：每个组件都要验证对方的证书，确保通信双方都是可信的。
- 请求签名：每个请求都要带签名，防止中间人篡改。
- 最小权限：组件之间的 API 只开放必要的接口，不要暴露全部功能。
我曾经见过一个项目，PEP 和 PA 之间用的 HTTP 明文通信。结果被攻击者抓包后伪造策略指令，直接把敏感数据全放出去了。嗯，从那以后我要求所有组件间通信必须走 mTLS，而且证书要定期轮换。
避坑指南：证书轮换是个容易被忽略的点。我建议用自动化的证书管理工具（比如 cert-manager），设置好证书有效期和自动续期。否则证书过期那天，你会发现所有策略执行都失败了，业务直接瘫痪。
2.7 小结
零信任架构的四个核心组件，说白了就是一套「评估-决策-执行」的闭环。信任评估引擎负责打分，策略引擎负责决策，策略管理员负责翻译和分发，策略执行点负责落地。每个组件都有自己的职责，但必须紧密协作才能发挥作用。
我个人觉得，理解这些组件的职责和交互方式，是设计零信任架构的第一步。下一步就是根据实际业务场景，选择合适的实现方案。这个我们后面会详细讲。