【零信任安全架构】软件定义边界与 ZTNA：VPN 替代方案的协议与产品对比

ZTNA（Zero Trust Network Access）和 SDP（Software Defined Perimeter）这两个术语经常互换使用，但它们的来源和侧重点不同：SDP 是 CSA（Cloud Security Alliance）在 2014 年定义的一个协议框架，ZTNA 是 Gartner 在 2019 年定义的一个产品类别。今天大多数”ZTNA 产品”的协议层都是 SDP 或其变体。

前置阅读：身份感知代理。

一、VPN 模型的三个致命缺陷

在讨论 ZTNA 怎么替 VPN 之前，先看 VPN 模型为什么不再有效：

1. 网络级授权：VPN 授权是”你能进入 10.0.0.0/8 网络”，不是”你能访问 order-service 的 GET /orders 端点”。一旦连上 VPN，用户可以 SNMP scan 整个内网。
2. 一次性认证：认证只发生在连接建立时——通常是一次密码 + OTP。连接建立后的数小时内，没有设备姿态的变化会被发现。
3. 全隧道模型：VPN 把所有流量都路由通过公司网络——用户在看 YouTube 时流量也要经过公司 VPN，带宽浪费且隐私问题。

二、SDP 协议的三阶段

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: 转发至后端应用
    end

Phase 1: SPA（Single Packet Authorization）

SPA 是 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 密钥来扫描整个网络。

Phase 2: mTLS 双向认证

SPA 通过后，用户获得”可见性”——网关的端口现在是可达的。然后是真正的身份验证：mTLS 握手。

这一步的关键是 SDP 期望客户端也出示证书——不是用户名/密码，而是设备证书 + 用户身份令牌（ID Token）。这确保了”不只是用户是对的，设备也是对的”。

Phase 3: 应用级隧道

认证通过后，客户端和网关之间建立加密隧道。与传统 VPN 的全隧道模式不同，SDP 的默认模式是按应用隧道——只为用户被授权的那个应用建立隧道。如果用户还授权了另一个应用，需要重新走 Phase 1 + Phase 2 流程（或通过已建立的 session 做额外的授权检查）。

三、Agent-based vs Agentless ZTNA

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

完全自建 ZTNA 在技术上是可行的。一个最小可行的技术栈：

WireGuard 作为 ZTNA 的传输层

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 限制：ZTNA 从外到内好做，从内到外困难。

• 从外到内（员工从咖啡店访问公司应用）：ZTNA 原生支持的场景——用户设备 → ZTNA 网关 → 企业应用
• 从内到外（企业服务器主动连接外部 SaaS API）：ZTNA 模型不直接支持——企业服务器没有”agent”，并且连接是”服务到外部”，不是”用户到内部”
• 外部合作伙伴（合作公司的员工访问你公司的一个项目管理系统）：双方都有各自的 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 双保险
  → 零信任没有"足够安全"，只有"和风险的持续博弈"

下一篇：零信任数据安全。

参考资料

1. Cloud Security Alliance. (2014). Software Defined Perimeter (SDP) Specification 1.0.
2. Gartner. (2019). Market Guide for Zero Trust Network Access.
3. WireGuard. Protocol & Cryptography. https://www.wireguard.com/protocol/
4. Tailscale. How Tailscale Works. https://tailscale.com/blog/how-tailscale-works
5. Cloudflare. Zero Trust Network Access. https://www.cloudflare.com/zero-trust/