2026-06-12 · architecture / security
零信任安全架构深度系列
零信任是 IAM 的自然延伸——当身份变成新边界，VPN 的'拨入即信任'模型必须被'永不信任、始终验证'取代。本系列从 NIST SP 800-207 规范、Google BeyondCorp 六篇论文、SPIFFE/SPIRE 联邦到微分段、持续验证、ZTNA 和零信任迁移的工程策略，系统拆解零信任的每一种组件和每一步实施。
ZTNA（Zero Trust Network Access）和 SDP（Software Defined Perimeter）这两个术语经常互换使用，但它们的来源和侧重点不同：SDP 是 CSA（Cloud Security Alliance）在 2014 年定义的一个协议框架，ZTNA 是 Gartner 在 2019 年定义的一个产品类别。今天大多数”ZTNA 产品”的协议层都是 SDP 或其变体。
前置阅读：身份感知代理。
在讨论 ZTNA 怎么替 VPN 之前，先看 VPN 模型为什么不再有效：
CSA 的 SDP 规范定义了三个组件和一个三阶段流程：
sequenceDiagram
participant Client as 客户端 (IH)
participant Controller as 控制器 (PDP)
participant Gateway as 网关 (PEP)
participant App as 企业应用
rect rgb(240, 248, 255)
Note over Client,Controller: Phase 1: SPA 单包授权
Client->>Controller: SPA Knock (UDP packet, HMAC-signed)
Controller->>Controller: 验证 SPA 签名 + 检查策略
end
rect rgb(255, 250, 240)
Note over Client,Gateway: Phase 2: mTLS 双向认证
Controller->>Client: 授权 token + Gateway 信息
Controller->>Gateway: 配置: 为该客户端打开端口
Client->>Gateway: TLS 握手 (client cert + server cert)
Gateway->>Gateway: 验证客户端证书 + SPIFFE ID
end
rect rgb(240, 255, 240)
Note over Client,App: Phase 3: 加密隧道
Client->>Gateway: 加密的应用数据
Gateway->>App: 转发至后端应用
endSPA 是 SDP 架构中最独特的概念。它的想法很简单：在不验证身份之前，连端口都不给你看。
传统网络服务的行为是——你连接 443 端口，服务端回复 SYN-ACK，然后开始 TLS 握手。攻击者可以通过端口扫描发现哪些 IP 上有哪些服务。
SDP 的默认行为是丢弃所有包——控制器（Controller）在防火墙层面屏蔽所有端口的入站连接。合法用户在连接应用之前，先向控制器发送一个 SPA 包——一个经过 HMAC 签名的 UDP 包，包含了用户身份、时间戳和请求信息。
控制器验证 SPA 签名后，在防火墙上临时为该客户端的 IP 开放指定的端口。密钥携带在客户端软件中，HMAC 签名防止了 SPA 包被重放或伪造。
无 SDP 的端口 443: 扫描 → SYN-ACK → 知道这里有服务
有 SDP 的端口 443: 扫描 → 无响应 → 不知道这里有服务 → 只有 SPA 敲门后才能看见SPA 的安全假设是：攻击者必须先知道 SPA 的秘密才能发送有效的敲门包，而有效的 SPA 包才能让控制器开放端口。但这个假设在 SP A 密钥分发上有个隐含问题：SPA 密钥存在每个客户端设备上，如果一台设备被攻破，攻击者就可以从该设备上提取 SPA 密钥来扫描整个网络。
SPA 通过后，用户获得”可见性”——网关的端口现在是可达的。然后是真正的身份验证：mTLS 握手。
这一步的关键是 SDP 期望客户端也出示证书——不是用户名/密码，而是设备证书 + 用户身份令牌（ID Token）。这确保了”不只是用户是对的，设备也是对的”。
认证通过后，客户端和网关之间建立加密隧道。与传统 VPN 的全隧道模式不同，SDP 的默认模式是按应用隧道——只为用户被授权的那个应用建立隧道。如果用户还授权了另一个应用，需要重新走 Phase 1 + Phase 2 流程（或通过已建立的 session 做额外的授权检查）。
| 维度 | Agent-based | Agentless（浏览器-only） |
|---|---|---|
| 代表产品 | Zscaler ZPA、Netskope NPA | Cloudflare Access、Google IAP |
| 设备姿态检查 | 完整（agent 直接采集设备信号） | 有限（浏览器指纹 + 基本信号） |
| 非 HTTP 协议 | 支持（SSH、RDP、SMB、数据库） | 不支持（HTTP/HTTPS only） |
| 部署复杂度 | 高（每台设备安装 agent） | 低（零安装） |
| 用户体验 | Agent 在后台运行，透明 | 浏览器内，无感 |
Agent-based ZTNA 在安全上更强——agent 可以采集设备姿态、验证 TPM quote、检查磁盘加密。Agentless ZTNA 更轻量，但只能验证用户身份和有限的浏览器信号。Google IAP 和 Cloudflare Access 是 agentless 模式的代表，它们实现 ZTNA 的方式本质上是一个带 OAuth2 认证的反向代理——和 IAP 机制 是同一做法。
Agent-based 模式的缺点是运维负担——每台设备上需要安装和持续运行 agent，agent 的版本更新和兼容性管理成为一个额外问题。大型企业（10000+ 设备）通常可以在 agent 部署上有足够的 IT 能力，但中小型企业更倾向于 agentless。
完全自建 ZTNA 在技术上是可行的。一个最小可行的技术栈：
| 组件 | 职责 | 开源选项 |
|---|---|---|
| 安全隧道 | 加密的数据通道 | WireGuard |
| 服务身份 | 为每个隧道端点发放短有效期证书 | SPIRE |
| 策略引擎 | 基于身份的访问控制 | OPA 或 Pomerium |
| 控制器 | 中心化的策略和配置管理 | 自建或 Pomerium |
WireGuard 是一个极简的 VPN 协议，以其简洁的代码量（约 4000 行）和高性能著称。它内置了 Curve25519 密钥交换和 ChaCha20 加密，密钥管理是基于公钥的——每个 peer 有一个公钥，WireGuard 通过公钥识别对方身份。
WireGuard 用于 ZTNA 的挑战：WireGuard 的认证模型是”公钥就是身份”，而零信任需要”SPIFFE ID 才是身份”。自建方案需要在 WireGuard 之上叠加 SPIRE 的身份层——WireGuard 提供加密隧道，SPIRE 提供证书和身份，OPA 在隧道之上做每个请求的授权检查。
自建 ZTNA 的隐性成本不在搭建上，而在运维上： - 密钥轮换：WireGuard 的密钥轮换没有内置机制——需要外部编排 - 多平台支持：macOS/Windows/Linux/iOS/Android 的客户端需要开发或组合多种工具 - 故障排查：当用户”连不上”时，排查路径包括 WireGuard、SPIRE、OPA 和网络——没有统一的诊断工具
对于技术能力强且有专门安全工程团队的组织，自建 ZTNA 是可行的。对于大多数组织，商业 ZTNA 产品或开源 IAP（如 Pomerium）是更务实的选择。
一个经常被忽视的 ZTNA 限制：ZTNA 从外到内好做，从内到外困难。
目前”从内到外”的实践是通过在服务器所在网络上部署出口代理（Egress Proxy），将出站流量也经过身份验证和策略检查。Google 的 BeyondCorp 在 2018 年后的演化就包含了这一部分——不只是”从外到内的零信任”，还有”从内到外的零信任”。
你是一个 <20 人的创业公司：
→ Cloudflare Access（免费层）或 Google IAP
→ 不需要安装 agent，一个 SSR 直接搞定
你是一个 50-500 人的技术公司：
→ Pomerium（开源自托管）或 Cloudflare Access
→ 开始需要细粒度的授权策略
你是一个 500+ 人的企业：
→ Zscaler ZPA / Netskope NPA（agent-based，完整设备姿态）
→ 需要覆盖 SSH/RDP/SMB 非 HTTP 协议的访问
你是金融机构或高安全组织：
→ Agent-based ZTNA + 自建 SPIRE mTLS 双保险
→ 零信任没有"足够安全"，只有"和风险的持续博弈"下一篇：零信任数据安全。
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-06-12 · architecture / security
零信任是 IAM 的自然延伸——当身份变成新边界，VPN 的'拨入即信任'模型必须被'永不信任、始终验证'取代。本系列从 NIST SP 800-207 规范、Google BeyondCorp 六篇论文、SPIFFE/SPIRE 联邦到微分段、持续验证、ZTNA 和零信任迁移的工程策略，系统拆解零信任的每一种组件和每一步实施。
2026-06-13 · architecture / security
从 2020 年 SolarWinds 到 2024 年 Okta 支持系统泄露，身份基础设施的安全失败反复证明一件事：IAM 不是 IT 支撑系统，而是安全架构的承重墙。本文建立现代 IAM 的全景地图——从认证协议、令牌体系、权限模型到身份治理与平台选型，给出 5 个贯穿全系列的核心问题。
2026-06-17 · architecture / security
前 9 篇讨论的都是'人'的身份——用户怎么登录、怎么验证。但微服务世界中，80% 的 API 调用是服务之间的。服务身份（Workload Identity）是整个 IAM 体系的另一半：mTLS 解决'传输层你是谁'，SPIFFE/SPIRE 解决'在平台层你是谁且怎么证明'，JWT Profile for OAuth 解决'我怎么拿到一个服务身份的 Token'。本文从这三条线拆解服务身份的工程实现。
2026-06-12 · architecture / security
NIST SP 800-207 给了零信任最权威的定义，但大多数讨论只复述了 7 条原则。本文拆解 NIST 文档的完整架构模型：PEP、PDP、Policy Engine、Policy Administrator 的分工与交互协议、信任算法的三种模型、以及 NIST 有意留白留给实现者的工程决策。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。