📚 课程目录第3章零信任架构核心组件

3. 零信任架构核心组件

零信任不是买一个盒子就能搞定的事。它是一套组件协同工作的体系。今天咱们就拆开看看，这些核心部件到底怎么配合。

我个人习惯把零信任架构比作一个机场安检系统。你想想看，PDP就是那个中央决策中心，PEP就是安检闸机，IAM是身份登记处，微隔离是不同候机区之间的隔离墙，持续监控则是遍布机场的摄像头和巡逻队。缺一个，安全就漏风。

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

这两个是零信任的“大脑”和“手脚”。PDP负责想，PEP负责干。

3.1.1 PDP：大脑怎么思考？

PDP（Policy Decision Point）接收来自PEP的访问请求，然后根据策略引擎的规则做出“允许”或“拒绝”的决定。它不直接接触流量，只做判断。

我在项目中遇到过一种情况：某客户把PDP和PEP部署在同一台服务器上。结果PDP挂了，整个网络都瘫痪了。嗯，这里要注意——PDP必须独立部署，而且要集群化。

  PDP的核心职责：
  接收PEP转发的访问请求（源、目标、时间、设备状态等）
查询身份与权限数据库
结合上下文（设备健康度、地理位置、行为基线）做决策
返回决策结果（允许/拒绝/二次认证）

3.1.2 PEP：手脚怎么执行？

PEP（Policy Enforcement Point）是真正拦截流量的组件。它部署在数据路径上，所有流量都必须经过它。PEP把请求发给PDP，然后根据PDP的指令放行或阻断。

说白了，PEP就是个听话的门卫。但它不能太笨——当PDP不可达时，PEP需要有降级策略。我曾经见过一个案例，PDP宕机后PEP直接放行了所有流量，等于零信任变成了零防御。

避坑指南： 我曾经在部署PEP时忽略了它的高可用设计。结果一次网络抖动导致PDP与PEP通信中断，PEP默认策略设成了“允许”，内部横向移动攻击直接爆发。后来我强制要求：PEP的降级策略必须是“拒绝所有”，除非有明确的业务豁免。

3.1.3 PDP与PEP的通信协议

PDP和PEP之间通常使用RADIUS、Diameter或自定义API通信。我个人推荐使用TLS加密通道，防止中间人篡改决策结果。

协议	适用场景	安全性	我踩过的坑
RADIUS	传统网络接入	中等（需配合TLS）	UDP传输容易丢包，建议用RADIUS over TLS
Diameter	4G/5G核心网	较高	配置复杂，小团队慎用
自定义API	云原生环境	取决于实现	必须做API鉴权和限流

3.2 身份与访问管理（IAM）

零信任的基石是身份。没有IAM，PDP就是个瞎子。

3.2.1 IAM的核心能力

IAM不只是用户名密码。它要管三件事：你是谁（认证）、你能干什么（授权）、你干了什么（审计）。

你想想看，IoT设备没有“人”的概念，只有设备ID。所以IoT场景下的IAM要支持设备证书、预共享密钥、甚至硬件指纹。我建议每个IoT设备出厂时就烧录唯一的X.509证书，这样PDP才能信任它。

个人经验： 我在一个智能工厂项目中，发现所有传感器都用了同一个默认密码。攻击者只要破解一个，就能控制整个车间。后来我强制要求：每台设备出厂前必须注入唯一身份凭证，并且首次上线强制修改。

3.2.2 身份生命周期管理

设备会报废、员工会离职。IAM必须能及时吊销身份。我曾经见过一个案例：一台被感染的摄像头因为证书没吊销，持续向内部服务器发送恶意流量长达两周。

# 示例：使用OpenSSL吊销设备证书
openssl ca -revoke device_cert.pem -crl_reason superseded
openssl ca -gencrl -out crl.pem
# 将CRL分发到PDP和PEP

3.3 微隔离

传统网络靠防火墙划分内外网。但内网一旦被突破，横向移动如入无人之境。微隔离就是要把“内网”切成无数个小格子。

3.3.1 微隔离的实现方式

微隔离有三种主流实现：基于网络（VLAN/VxLAN）、基于主机（防火墙策略）、基于身份（零信任代理）。我个人倾向第三种，因为它不依赖网络拓扑。

我记得有一次帮客户做微隔离设计，他们问：“能不能只靠VLAN？”我说可以，但VLAN的粒度太粗。一个VLAN里可能有100台设备，只要一台被攻破，其他99台都危险。微隔离要做到“每台设备一个安全域”。

  微隔离的粒度对比：
  粗粒度： 按部门/网段隔离（传统防火墙）
中粒度： 按应用/服务隔离（NGFW）
细粒度： 按设备/进程隔离（零信任代理）

3.3.2 微隔离策略示例

假设一个IoT场景：温度传感器只能向数据采集服务器发送数据，不能访问其他任何设备。

# 微隔离策略（伪代码）
策略名称: 温度传感器-数据采集
源: 温度传感器 (设备ID: SENSOR-001)
目标: 数据采集服务器 (IP: 10.0.1.100, 端口: 8443)
协议: MQTT over TLS
动作: 允许
条件: 设备健康度 > 80%, 时间: 全天
日志: 开启

策略名称: 温度传感器-默认拒绝
源: 温度传感器 (设备ID: SENSOR-001)
目标: 任何
动作: 拒绝
日志: 开启

3.4 持续监控与审计

零信任不是“一次认证，永远信任”。它要求持续验证。持续监控就是那个“持续”的保障。

3.4.1 监控什么？

我建议监控三个维度：流量行为、设备状态、用户行为。任何一个维度出现异常，PDP都应该重新评估信任等级。

流量行为： 连接频率、数据包大小、目标IP分布
设备状态： 固件版本、补丁状态、CPU/内存使用率
用户行为： 登录时间、操作频率、异常地理位置

避坑指南： 我曾经在一个项目中只监控了流量行为，忽略了设备状态。结果一台设备被植入挖矿程序，CPU飙到100%，但流量看起来完全正常。后来我加上了设备健康度监控，才堵住这个漏洞。

3.4.2 审计日志怎么用？

审计日志不只是为了合规。它是事后溯源的唯一依据。我建议日志格式统一为JSON，包含时间戳、源/目标、决策结果、上下文信息。

{
  "timestamp": "2025-03-15T14:23:10Z",
  "source": "SENSOR-001",
  "target": "10.0.1.100:8443",
  "decision": "DENY",
  "reason": "设备固件版本过低 (v1.2, 要求 v2.0+)",
  "pdp_id": "PDP-CLUSTER-01"
}

3.5 核心组件协作流程图

下面这张图展示了PDP、PEP、IAM、微隔离和持续监控如何协同工作。我建议你仔细看看数据流的方向——所有请求都必须经过PEP，PEP再问PDP，PDP再查IAM和监控数据。

3.6 组件部署建议

最后，我总结一下各组件在实际项目中的部署建议。这些经验来自我踩过的坑和填过的坑。

组件	部署位置	高可用要求	我踩过的坑
PDP	独立集群，与数据面隔离	必须（至少3节点）	单点故障导致全网瘫痪
PEP	数据路径上，靠近设备	必须（主备或负载均衡）	降级策略设成“允许”
IAM	独立服务，与PDP内网互通	必须	证书吊销不及时
微隔离	PEP侧或主机侧	建议	粒度太粗，等于没隔离
持续监控	独立集群，采集全量数据	建议	只监控流量，忽略设备状态

嗯，这一章的内容就到这里。核心组件之间的关系你理清楚了吗？PDP做决策，PEP执行，IAM提供身份，微隔离限制横向移动，持续监控保证动态信任。这五个组件缺一不可，少一个，零信任就变成了“零信任”。