cloudflare-one-migrations

Cloudflare One 迁移

在生成精确配置前，请先获取当前的 Cloudflare 文档、Cloudflare API 架构以及源厂商的导出文档。

工作流程

1. 确定源堆栈：Zscaler ZIA、Zscaler ZPA、Palo Alto NGFW/Prisma/GlobalProtect、传统 VPN/SWG/SD-WAN 或其他。
2. 在映射前请求导出和日志。优先使用结构化导出，而非截图或文字摘要。
3. 构建清单：身份、组、应用、目标、连接器/隧道、DNS/URL/防火墙/DLP/TLS 策略、对象/列表、位置/站点、例外、命中次数以及合规日志。
4. 生成映射计划：源对象、Cloudflare One 目标资源、置信度、前提条件、不支持/部分映射以及手动决策。
5. 首先创建依赖项：身份/SCIM、连接器/入口、路由/DNS、列表/对象、TLS 绕过、Access 应用/策略、Gateway 策略、DLP/CASB、日志。
6. 安全分阶段：使用迁移前缀，默认创建禁用/审计模式规则，从小型组/站点试点，比较日志，然后扩展部署。
7. 覆盖每条源规则。每条规则必须映射到一个 Cloudflare 对象或一个明确的“未迁移”行，并附上原因和安全影响。

需要请求的导出

• ZIA：URL 过滤、防火墙过滤、SSL 检查、DLP、自定义 URL 类别、IP 组、网络服务/服务组、用户/组/部门、位置、GRE 隧道和静态 IP。
• ZPA：应用段、段组、服务器组、应用连接器/连接器组、访问策略、IdP/组映射、私有 DNS 域、端口和协议。
• Palo Alto/Prisma：安全/NAT/解密规则、地址/服务对象和组、URL 类别、HIP 配置文件、GlobalProtect 配置、Prisma Access 远程网络/服务连接配置、区域、标签、日志和命中次数。

映射启发式规则

• ZIA/SWG 策略通常映射到 Gateway 流量策略 和 Gateway 列表。
• ZPA 私有应用访问通常映射到 Access 应用类型、Cloudflare Tunnel、私有网络路由/DNS 和 Access 策略。
• Palo Alto 规则只有在理解流量方向、区域、对象、用户、应用、解密和命中次数后才能映射。不要盲目地将区域扁平化为列表。
• 传统 VPN 替换通常是 Access + Cloudflare One Client / WARP + Tunnel 或 Mesh 用于应用访问。仅在需要站点到站点流量时使用 Cloudflare WAN；使用 网络 VPN 迁移设计指南 和 替换你的 VPN 文档获取当前模式。

迁移评估提示

• 源覆盖范围：哪些产品在范围内，哪些导出可用，以及截图/文字摘要是否隐藏了缺失的对象文件。
• 规则数量和命中数据：按规则类型统计数量、已禁用/过时规则、无命中规则、高命中规则以及关键业务例外。
• 对象依赖关系：地址对象、服务对象、组、自定义类别、网络服务、应用 ID、区域、标签、连接器和服务器组。
• 身份就绪：IdP、SCIM/组同步、组名称规范化、个人用户规则、本地组、服务账户和承包商身份。
• TLS/DLP 就绪：源解密规则、证书固定绕过、DLP 引擎/配置文件、自定义正则表达式、精确匹配数据和有效载荷日志记录期望。
• 连接就绪：源隧道/连接器、私有 DNS、拆分隧道 或绕过行为、源 IP 保留、出口 IP 白名单以及站点到站点需求。
• 部署就绪：试点组/站点、并行运行期、回滚负责人、源堆栈退役标准以及监控/日志比较计划。

特定源陷阱

Zscaler ZIA / SWG

• 自定义 URL 类别通常拆分为单独的 IP、域和 URL 列表。统计生成的列表数量，而不仅仅是源类别。
• 带有 IP 的 ZIA 位置可用作源 IP 列表；它们不会自动成为用于 DNS 策略范围的 Gateway DNS 位置。
• GRE 隧道源 IP 可用于策略条件，但传输迁移是单独的 WARP Connector 或 Cloudflare WAN 工作流。
• CAUTION/warn 行为没有精确的 Gateway 等效项。将其视为明确的客户决策，而不是静默的允许/阻止选择。
• DLP 引擎和自定义正则表达式通常需要手动重新创建 Cloudflare DLP 配置文件。占位策略不能像 DLP 已完成那样启用。
• 网络应用组和不受支持的协议是部分映射。在启用前进行审查。
• 如果 SCIM 不可用，基于身份范围的源规则会变得过于宽泛，除非你添加可执行的替代方案，例如用户/电子邮件列表。在创建这些规则之前，请检查 Gateway 身份选择器。

Zscaler ZPA / 私有访问

• ZPA 应用段、服务器组和连接器组不是一对一映射的。Cloudflare 将 Access 应用、隧道路由、DNS 和策略分开。
• 通过 API 创建隧道并不能完成连接器部署。需要单独规划 cloudflared 安装、身份验证和源可达性。
• 为每个 ZPA 连接器组创建一个 Cloudflare Tunnel，无论连接器运行时状态如何（AUTHENTICATED、DISCONNECTED 或 disabled）。状态是操作性的，而非架构性的。在隧道描述中标记已断开或遗留的组，让客户在验证后决定退役哪些。
• 组内的每个 ZPA 连接器实例映射到一个针对该隧道令牌运行的 cloudflared 副本。将副本数量与每个组的连接器实例数量匹配，以保持相同的拓扑结构。单个隧道令牌支持多个同时运行的 cloudflared 进程。建议在同一数据中心但不同主机或子网上安装副本。
• 对于每个连接器组，识别所有链接到它的服务器组以及分配给这些服务器组的所有应用段。这些应用段中的 IP 地址和 CIDR 成为对应隧道上的 CIDR 路由；域名成为同一隧道上的主机名路由。如果宽泛子网覆盖所有应用段 IP，则优先使用每个子网一条 CIDR 路由，而不是每个主机 /32 路由。
• ZPA 绕过意味着 Cloudflare 中的拆分隧道绕过，而不是 Access 的 bypass 决策。绕过规则映射到 WARP 拆分隧道 排除条目。这是一个手动配置步骤，没有 API 自动化——客户必须通过仪表板将被绕过的域和 IP 添加到设备配置文件的拆分隧道排除列表中。
• 无代理/浏览器应用可能成为每个域的独立公共主机名 Access 应用。WARP 私有应用仍然是私有目标应用。
• 默认的 Cloudflare Access 应用目标限制是每个应用 5 个主机名。对于具有大型应用段的 ZPA 迁移，请在实施前联系 Cloudflare 客户团队请求增加限制（最多 50 个）。在创建应用前确认该限制在账户上已生效——如果没有，大型段必须拆分为多个具有相同策略的应用，这会显著增加对象数量。
• IP 锚定应用需要在迁移前做出明确的出口决策：通过客户出口保留源 IP，在可用时使用 Cloudflare 专用出口，或者接受目标服务必须更新以允许新的源 IP。这是一个客户决策，如果未解决则会阻碍实施。
• 解析器策略可以是账户范围的。注意跨站点或虚拟网络的重叠私有 DNS 命名空间；在进行 DNS 更改前获取 解析器策略 文档。
• 每个 ZPA 访问策略规则映射到一个 Cloudflare 可重用的 Access 策略。在将可重用策略附加到 Access 应用之前，先创建所有可重用策略。在默认拒绝的 Gateway 网络环境中，另外创建一个网络允许规则，使用选择器“存在自托管 Access 应用且具有私有地址”（wirefilter: any(access.private_app[*] in {"*"})），优先级高于任何宽泛的 L4 阻止规则——否则，Gateway 会在 Access 策略评估之前阻止私有应用流量。
• 在 ZIA 和 ZPA 组合迁移中，Gateway 网络规则可能会意外阻止 Access 私有应用流量。上述 Gateway 网络允许规则是解决方案——将其放置在比 ZIA 迁移的阻止规则更高的优先级（更低的编号）。在启用宽泛的 L4 阻止之前，添加并验证此规则。

Palo Alto / Prisma / NGFW

• 一条 Palo Alto 规则可能产生多个 Cloudflare 资源。保留规则意图，而不是规则数量。
• App-ID、URL 类别、区域、HIP、调度和解密行为很少能精确翻译。标记部分映射，而不是强制虚假对等。
• 导出地址/服务对象和组及其规则。缺少对象导出会导致看似静默的丢弃，除非明确检测到。
• 宽泛的 any 目标/服务规则和非常宽泛的 CIDR 需要手动审查。不要自动创建宽泛的全面捕获规则。
• HIP/设备检查需要 Cloudflare 设备状态 集成后才能实施。

注意事项

• 源导出通常将引用分散在多个文件中。在声明规则不可映射之前，先根据对象、服务和组文件解析 ID。
• 个人用户、本地组、部门和动态应用 ID 通常需要身份规范化。SCIM/组同步是组选择器的关键前提条件。
• Zscaler 的 caution/warn 行为、Palo Alto 的 App-ID 行为以及 TLS/解密例外可能没有精确的等效项。将其标记为决策点，而不是强制一对一映射。
• 尽可能保留源规则顺序和命中次数。仅在用户批准的情况下禁用或删除过时/无命中规则。
• 除非明确要求并有时限，否则不要创建宽泛的允许所有全面捕获规则来保持连接。

验证关卡

• 在每个迁移阶段后，比较 Cloudflare 对象计数与解析的源计数。出现不匹配时停止。
• 在启用策略之前，审查每个 unsupported、partial、unmapped、needs_identity、needs_posture 和 manual_review 项。
• 在 SCIM 同步和重新认证后，使用真实的试点用户验证组匹配。
• 在广泛启用 HTTP/DLP 阻止之前，测试 TLS 检查和“不检查”行为。
• 保持回滚路径明确：通过前缀禁用已迁移规则、恢复源路由或回滚试点组/站点。
• 在宣布完成之前，生成一个源规则核算表：已迁移对象、部分映射、未迁移原因、安全影响以及每个手动操作的所有者。

评估模板

## 迁移评估

源堆栈：
审查的工件：
假设/缺失的导出：
推荐的 Cloudflare One 目标：
映射摘要：
风险/部分映射：
未迁移：
试点计划：
验证：
回滚：