企業級 SASE 與零信任資安：Cloudflare One 與 Magic Transit 零信任網路實踐

VPN 那套「進了門就是自己人」的邏輯，放在混合辦公、外包協作、甚至 AI Agent 都要存取內部系統的今天，風險其實愈來愈大。Cloudflare 把這個問題拆成兩塊解決：Cloudflare One 是一套統一的 SASE 平台，把零信任存取、安全網頁閘道、資料外洩防護等多項服務收進同一個控制平面，取代 VPN 一進內網就全部信任的做法；Magic Transit 顧的是網路層，用 BGP 宣告企業自有 IP 網段，在流量真正抵達企業機房之前，就在 Cloudflare 全球節點上完成清洗。

前者解決「人與應用程式之間該不該信任」，後者解決「攻擊流量該在哪裡被擋下」，兩者處理的是不同層次的問題，適合的企業樣態也不完全一樣。這篇把兩者的角色，以及 2026 年幾個值得留意的變化整理一遍。

零信任要解決的問題很單純：不要讓「進了門」這件事，等於「什麼都能碰」。下面拆開來看這兩個產品各自解決什麼。

VPN 那套信任模型，為什麼在今天站不住腳？

傳統 VPN 的邏輯是驗證一次身分，之後就把使用者放進整個內網，能不能碰到哪些系統，很大程度取決於網路本身有沒有分區。

問題是現在的辦公型態早就不是「所有人都在同一棟大樓」，任何一個環節被入侵，攻擊者都可能在內網裡橫向移動很久才被發現：

• 混合辦公：員工在家、在咖啡廳連進內網，網路邊界本身已經模糊，不能再靠「連了公司網路就信任」判斷。
• 外包與第三方廠商：這些帳號往往權限給得比實際需要寬，一旦外洩，攻擊者拿到的是一整片內網。
• AI Agent 呼叫內部工具：Agent 本身也是一種身分，若比照人類帳號一次性授權，風險敞口會比想像中大。

零信任架構要處理的正是這件事：不再假設「連進來的就是自己人」，而是每一次存取都重新檢查身分與情境，這也是 SASE（安全存取服務邊緣）這個架構分類存在的原因。

Cloudflare One 到底整合了哪些安全服務？

Cloudflare One 是官方對這套零信任平台的統稱，定位是「連結並保護組織的員工、AI Agent 與基礎設施」的統一 SASE 平台。

• ZTNA 零信任網路存取：取代傳統 VPN，依身分與情境逐次授權存取內部應用程式。
• SWG 安全網頁閘道：檢查對外的網頁流量，過濾惡意內容與不當存取。
• CASB 雲端存取安全代理：監控員工對第三方雲端服務（例如各種 SaaS）的使用情況。
• DLP 資料外洩防護：偵測敏感資料是否被不當傳輸或外洩。
• RBI 遠端瀏覽器隔離：把瀏覽風險隔離在雲端沙盒，降低瀏覽器成為攻擊入口的機會。

官方特別強調這些服務是「原生整合」而非拼湊多家廠商產品，控制平面統一的好處是設定規則不必在好幾套系統之間重複維護，稽核也比較容易對得起來。

ZTNA 具體上怎麼取代 VPN？

零信任存取的核心邏輯，是把「連進內網」拆成「存取單一應用程式」這樣的細粒度單位。每一次存取都要重新驗證身分與裝置狀態，而不是連上一次就整晚暢通無阻。

細粒度規則實務上長什麼樣子：業務部門的帳號只能存取 CRM 相關應用，工程部門的帳號只能存取內部程式碼倉庫與部署系統，兩邊的授權範圍互不重疊，就算其中一組帳號外洩，波及的也只是那一小塊。

這種做法對混合辦公特別有感，員工不管在家、在咖啡廳還是在辦公室，存取內部系統的驗證邏輯是一致的，不必再靠「有沒有連公司網路」這種粗糙的判斷方式。

Magic Transit 怎麼保護企業自己的網路層？

Cloudflare One 顧的是人與應用程式之間的存取，Magic Transit 顧的則是更底層的網路本身，服務對象是擁有自有 IP 位址網段的企業。

• 透過 BGP 把客戶的 IP 網段宣告出去，讓進入這個網段的流量先繞經 Cloudflare 全球網路。
• 搭配 Anycast 把流量導向距離攻擊來源最近的 Cloudflare 節點，在流量抵達企業自己的機房之前就完成過濾。
• 運作在網路層（Layer 3），檢查封包、過濾惡意流量，只把合法流量轉發回企業的原始基礎設施。
• 同時支援純輸入方向的流量清洗，也支援輸入與輸出雙向都經過 Cloudflare 網路的架構，後者需要額外設定路由策略。

常見會被這層防禦擋下的攻擊型態，包括流量灌爆頻寬的容量型攻擊、針對協定弱點的技術型攻擊，以及鎖定特定服務埠口的定向攻擊。這些如果沒有在骨幹層先擋掉，光是攻擊流量本身就可能把企業的對外頻寬占滿，讓正常使用者連不進來。

AI Agent 為什麼也要納入零信任治理？

隨著企業開始讓 AI Agent 直接呼叫內部工具與資料，零信任治理的對象已經不只是人類員工。官方把 Cloudflare One 定位為第一批把 MCP 伺服器連線與 AI Agent 身分，一併納入零信任規則管理的 SASE 平台。

做法上是把 Agent 當成一種可授權、可稽核的身分來對待，而不是為了方便，另外開一條沒有規則管控的捷徑：

• 每個 Agent 有自己的憑證與可存取範圍，不與人類帳號共用一組金鑰。
• Agent 發出的每一次呼叫都留下稽核紀錄，出事時能回溯是哪個 Agent、在什麼情境下觸發。
• 資料外洩防護規則同樣套用在 Agent 的請求上，防止 Agent 被誘導把敏感資料回傳給不該接收的對象。

這塊還在快速演進，實際能做到多細的授權粒度、能不能覆蓋所有內部工具，會因團隊採用的 Agent 架構而異，導入前務必實際測試，不要只看行銷文案就假設涵蓋範圍。

導入前該想清楚的幾件事

1. 盤點現有應用程式與身分系統：零信任存取的細粒度授權，建立在既有身分系統（例如 SSO）之上，先確認整合狀況再估算導入時程。
2. 確認是否需要網路層防禦：如果企業有自有 IP 網段與混合式架構，Magic Transit 才會是相關選項，純雲端架構的團隊可能用不到這一塊。
3. 不要只比價格：Cloudflare 在免費層級與定價上有優勢，但 2026 年 Gartner 排名把其他廠商列在更前面，實際選型要看自己需要的細部功能，不是只看排名或報價。
4. 把 AI Agent 當成新身分規劃：Agent 存取內部系統的權限，建議比照新進員工的最小權限原則設計，而不是給一組萬用金鑰。

零信任跟網路層防禦解決的是不同層次的問題，不必為了趕流行一次全上，先從風險最高的那一塊開始，通常是比較務實的順序。