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；請參考 Network VPN migration design guide 與 Replace your 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 或停用）。狀態屬於營運問題，而非架構問題。在通道描述中標記已斷線或舊版群組，讓客戶在驗證後決定是否除役。
• 群組內的每個 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 網路環境中，另外建立一條網路允許規則，使用選擇器「Self-hosted Access App with Private Address is Present」（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 目標：
對應摘要：
風險/部分對應：
未遷移項目：
試行計畫：
驗證方式：
復原方式：