新成立的组织可以从头搭建零信任架构。但大多数有历史组织面临的是棕地（Brownfield）迁移——数百个遗留系统没有 mTLS 能力、几十个应用不支持 OIDC、几千台设备没有 TPM 或 MDM 管理。

前置阅读：BeyondCorp 六篇论文、身份系统迁移与事故响应（IAM 系列）。

一、棕地迁移的冰山模型

迁移前安全团队看到的是可见部分——“我们要在 12 个月内部署 mTLS 和微分段”。但在水面下隐藏着大多数人忽视的：

可见部分（经常被讨论）： - 部署 Istio service mesh 为所有流量加密 - 配置微分段策略限制 blast radius - 替换 VPN 为 ZTNA

隐藏部分（经常被忽略）： - 有 15 个 Java 1.6 的服务，不支持 TLS 1.2 - CI/CD 管道需要在构建环境中注入 sidecar - 有 3 个服器用的是自定义 TCP 协议，无法用标准 sidecar 代理 - 有 4 个业务部门使用独立的 IdP，身份不统一 - 开发、运维和安全团队需要进行跨团队的协调

二、遗留系统的四种升级策略

2.1 Sidecar 代理模式

在应用的 K8s Pod 或 VM 旁边注入一个代理（Envoy/NGINX），应用本身不感知 mTLS：

# Pod spec: 注入 Envoy sidecar
spec:
  containers:
    - name: app
      image: legacy-payment-service:1.0
      # 应用仍然监听 127.0.0.1:8080（无 TLS）
    - name: envoy-sidecar
      image: envoyproxy/envoy:v1.29
      # Envoy 处理所有入站 mTLS + 向应用转发明文
      # 出站 mTLS + 向目标发起 mTLS 连接

适用场景：应用本身没有 TLS 能力，但可以部署在 K8s 或支持 sidecar 的环境中。 不适用：非 HTTP 协议的自定义 TCP 应用。 成本：每个应用一个 sidecar，约 50MB 内存 + 0.1 CPU per sidecar。

2.2 反向代理包装

在遗留服务的前面放置一个 L7 反向代理（NGINX/Envoy），代理处理所有 mTLS/OIDC/策略，遗留服务不用改动：

外部请求 → 反向代理 (mTLS/TLS 终结 + OIDC 验证) → 遗留服务 (明文 HTTP)

适用场景：物理服务器上的遗留应用、大型的单体应用。 成本：需要配置和管理独立的反向代理实例。

2.3 身份桥接（Identity Bridging）

在旧认证系统（LDAP/Kerberos）和新身份系统（OIDC/SPIFFE）之间建立翻译桥：

OIDC Token → 身份桥接服务 → 转换为 Kerberos Ticket → 遗留服务验证

Google BeyondCorp 迁移中的最大挑战之一就是”所有应用必须支持 OIDC”是不现实的——最终 Google 用了身份桥接来处理遗留的基于 Kerberos 的应用。

适用场景：大量基于 LDAP/Kerberos 的企业内部应用。 成本：需要开发和维护桥接服务 + 旧协议的审计和安全加固。

2.4 协议适配器

对使用自定义 TCP 协议的遗留服务编写专用的协议适配器。没有通用方案——每个自定义协议都需要独立的适配层。

适用场景：少数高价值的遗留服务（< 10 个）。 成本：开发时间 1-3 人月 per 适配器。

如果有 50+ 个自定义协议的服务，这个方案不适用——应该首先考虑逐步替换这些服务，而不是为它们写适配器。

三、渐进式切流的工程控制

3.1 切流维度

切流不应该是”下周一 9 点全公司从 VPN 切到 ZTNA”——而是逐层推进：

• 按用户群：先从安全团队自己开始（10 人），然后扩展到基础设施团队（50 人），再到全公司（500 人）
• 按地理位置：先从北京办公网开始，再扩展到新加坡、伦敦
• 按应用：先从低敏感应用（内部 Wiki）开始，再到中敏感（代码仓库），最后到高敏感（生产数据库）
• 按设备类型：先覆盖公司配发的 macOS，再覆盖 Windows，最后处理 Linux 和 BYOD

3.2 可观测性驱动的推进

迁移进入下一阶段的条件不是”时间到了”，而是 “监控数据显示上一阶段的流量绝大多数已通过新路径”。

Google BeyondCorp 迁移的关键指标： - VPN 上仍在传输的应用流量占所有应用流量的百分比——当这个百分比降到 5% 以下时，才考虑关闭 VPN - Helpdesk 工单中”VPN 连接问题”的比例——当这个比例降到 1% 以下时，说明用户已经习惯了新模型

四、迁移中的人力成本

零信任迁移不是安全团队自己的事——它涉及：

• 每个应用团队：配置 mTLS sidecar、验证应用在 mTLS 下正常工作、更新 CI/CD
• IT 团队：升级设备管理、部署设备姿态 agent、帮助用户做设备合规
• 运维团队：部署和管理 SPIRE、Istio、策略引擎等新基础设施
• 安全团队：制定微分段策略、配置 SIEM 规则、培训其他团队

在迁移计划中，最被低估的成本不是许可证费用，而是应用团队理解 mTLS 和身份模型所需要的时间。如果安全团队只是提供”一个服务 mesh 的文档”而没有提供”你的具体应用需要在 YAML 里改什么”，迁移会在应用团队的无尽拖延中失败。

下一篇：零信任可观测性与 SIEM 集成。

参考资料

1. Spear, B. et al. (2017). “Migrating to BeyondCorp: Maintaining Productivity While Improving Security”. ;login:.
2. Google. (2018). “BeyondCorp: Building a Healthy Fleet”. ;login:.
3. NIST SP 1800-35. (2025). Implementing a Zero Trust Architecture.