訂閱以接收新文章的通知:

Cloudflare One 是第一個在整個平台上提供現代化後量子加密的 SASE 解決方案

2026-02-23

閱讀時間:11 分鐘
本貼文還提供以下語言版本:EnglishItalianoPortuguêsEspañol (Latinoamérica)Tiếng Việt简体中文

在 2025 年 Security Week 期間,我們推出了業界首個雲端原生後量子安全 Web 閘道 (SWG) 與 Zero Trust 解決方案,這是保護企業網路流量(從終端使用者裝置傳送至公用與私人網路)的一大進展。

但這只是等式的一部分。要真正確保企業網路的未來安全,您需要一套完整的安全存取服務邊緣 (SASE)

今天,我們補齊了等式的其餘部分:Cloudflare One 是第一個在我們的安全 Web 閘道中支援符合現代標準的後量子 (PQ) 加密,並涵蓋 Zero Trust 與廣域網路 (WAN) 使用案例的 SASE 平台。更具體地說,Cloudflare One 現在在所有主要的入口與出口點,提供後量子混合 ML-KEM(基於模組晶格的金鑰封裝機制)。

為了補齊方程式,我們將後量子加密支援新增至我們的 Cloudflare IPsec(我們的雲端原生 WAN 即服務)與 Cloudflare One Appliance(我們用於建立 Cloudflare IPsec 連線的實體或虛擬 WAN 裝置)。Cloudflare IPsec 使用 IPsec 通訊協定,從客戶的網路建立加密通道到 Cloudflare 的全球網路,同時使用 IP Anycast 將該通道自動路由到最近的 Cloudflare 資料中心。Cloudflare IPsec 簡化了設定並提供高可用性;如果特定資料中心無法使用,流量會自動重新路由到狀況最佳的最近資料中心。Cloudflare IPsec 在我們全球網路的規模上執行,並支援跨 WAN 的站點到站點以及對網際網路的對外連線。

Cloudflare One Appliance 升級已於設備版本 2026.2.0 起全面提供。Cloudflare IPsec 升級目前處於封閉測試階段,您可以將您的名字加入我們的封閉測試名單以請求存取權限。

後量子加密現在就很重要

量子威脅並非「下個十年」才需面對的問題。以下是我們的客戶如今正優先考慮採用後量子加密 (PQC) 的原因:

期限正在逼近。2024 年底,美國國家標準與技術研究院 (NIST) 釋出明確訊號(其他機構也紛紛響應):傳統公開金鑰密碼學的時代即將結束。NIST 已設下 2030 年的期限,屆時將淘汰 RSA 與 Elliptic Curve Cryptography (ECC),全面轉向無法被強大量子電腦破解的 PQC。尚未開始遷移的組織,可能面臨不合規風險,並在期限接近時暴露於安全漏洞之中。

升級歷來都是個棘手的問題。。雖然 2030 年看似還很遙遠,但升級密碼演算法一向極具挑戰性。歷史告訴我們,淘汰一項加密技術可能需要數十年的時間:我們發現,像是 MD5 這樣已被棄用的演算法,在停用 20 年後仍在造成問題。這種缺乏「密碼敏捷性」(也就是無法輕易替換加密演算法的能力)正是當前的一大瓶頸。藉由將後量子加密直接整合進我們的 SASE 平台 Cloudflare One,我們內建了密碼敏捷性,大幅簡化組織提供遠端存取網站對網站連線的方式。

資料現在就可能已經暴露在風險之中。「先竊取、後解密」是一項當前持續存在的威脅,攻擊者現在就開始蒐集敏感的網路流量,並將其儲存起來,直到量子電腦足夠強大、能夠成功解密這些資料為止。如果您的資料保存期限超過幾年(例如財務資訊、醫療資料、國家機密),且並未採用後量子加密進行保護,則這些資料現在就已經處於風險之中。

量子安全之路上的兩大遷移:金鑰協議與數位簽章

要將網路流量全面過渡到後量子密碼學 (PQC),必須徹底改變兩項基礎密碼元件:金鑰協議與數位簽章。

遷移一:金鑰建立。金鑰協議讓兩方能在不安全的通訊通道上建立共用金鑰,此共用金鑰隨後用於加密網路流量,形成所謂的後量子加密。業界目前普遍認可 ML-KEM(模組晶格密鑰封裝機制)作為標準的後量子金鑰協議通訊協定。

ML-KEM 已被廣泛應用於 TLS 中,通常與經典的 Elliptic Curve Diffie Hellman (ECDHE) 一同部署,這種方式是將 ML-KEM 與 ECDHE 金鑰協議的輸出混合,來推導出用於加密網路流量的金鑰。(這也稱為「混合式 ML-KEM」。)目前,傳送至 Cloudflare 網路的人類產生 TLS 流量中,已有超過六成受到混合式 ML-KEM 的保護。遷移至混合式 ML-KEM 之所以成功,是因為它能:

  • 阻止「先竊取、後解密」攻擊

  • 不需要專用硬體或用戶端與伺服器之間的特殊實體連線,相較於量子金鑰分發 (QKD) 等做法更為可行

  • 對效能影響甚微,即使是短暫的 TLS 連線也一樣

由於 ML-KEM 是與傳統 ECDHE 平行運作,因此相較於僅使用經典 ECDHE 的方法,並不會降低安全性與合規性。

遷移二:數位簽章。另一方面,數位簽章與憑證主要用於確保真實性,防止主動攻擊者偽冒伺服器欺騙用戶端。然而,目前的後量子簽章演算法在大小上仍比傳統的 ECC 演算法龐大,這也延緩了其普及速度。所幸,遷移至後量子簽章的急迫性相對較低,因為這類簽章主要是用來防禦配備強大量子電腦的主動攻擊者,而這樣的敵手目前尚不存在。因此,雖然 Cloudflare 正積極參與後量子數位簽章的標準制定與推廣,但本次 Cloudflare IPsec 的升級重點仍放在將金鑰建立機制升級為混合式 ML-KEM。

網路安全和基礎架構安全局 (CISA) 在其 2026 年 1 月發布的報告「Product Categories for Technologies That Use Post-Quantum Cryptography Standards」(使用後量子密碼標準的技術產品分類)中,也明確指出了這兩項遷移工作的性質與重要性。

利用 IPsec 開闢新天地

為了打造一套全面以後量子加密保護的 SASE 解決方案,我們已升級 Cloudflare IPsec 產品,使其可在 IPsec 通訊協定中支援混合式 ML-KEM。

IPsec 社群向後量子密碼學的邁進,與 TLS 的發展路徑截然不同。TLS 是在第 4 層用於加密公眾網際網路流量(例如從瀏覽器到內容傳遞網路 (CDN) 的通訊)的事實標準,因此其設計重點在於安全性與廠商互通性。相對而言,IPsec 是第 3 層通訊協定,常用於連接相同廠商所製造的設備(例如兩台路由器),因此互通性在過去並非首要考量。有了這樣的背景,讓我們一起看看 IPsec 如何走向量子安全未來。

預先共用金鑰?還是量子金鑰分發?

RFC 8784 於 2020 年 5 月發布,旨在作為 IPsec 的網際網路金鑰交換第二版(Internet Key Exchange v2,IKEv2)的後量子升級方案,用於建立加密 IPsec 網路流量所需的對稱金鑰。RFC 8784 提出了兩種選項:長期使用的預先共用金鑰 (PSK),或是量子金鑰分發 (QKD)。然而,這兩種方法都不太理想。

RFC 8784 提議將 PSK 與從 Diffie Hellman Exchange (DHE) 衍生的金鑰混合,本質上是讓 PSK 與 DHE 以混合模式執行。這種方法可以防範「先竊取、後解密」的攻擊者,但無法針對擁有量子運算能力的攻擊者提供前向保密

前向保密是金鑰協議通訊協定的標準要件。它能確保即使長期金鑰遭到洩漏,系統仍能維持安全。RFC 8784 中的 PSK 方法容易受到「先竊取、後解密」攻擊者的威脅,如果該攻擊者同時也取得了長期 PSK 的副本,那麼一旦強大的量子電腦出現,他們就能在未來解密流量(透過破解 DHE 金鑰協議)。

為了解決這個前向保密問題,RFC 8784 可以改用另一種方式:將來自經典 DHE 的金鑰,與從 QKD 通訊協定新產生的金鑰混合。

QKD 利用量子力學在兩方之間建立共用且保密的密碼編譯金鑰。重要的是,QKD 要能運作,雙方必須具備專屬硬體,或透過專用的實體連線連接。這是一個重大的限制,使得 QKD 對於常見的網際網路使用案例(例如透過 Wi-Fi 將筆記型電腦連接到遠端伺服器)毫無用武之地。這些限制也正是我們從未投資將 QKD 部署於 Cloudflare IPsec 的原因。美國國家安全局 (NSA)德國聯邦資訊安全辦公室 (BSI) 以及英國國家網路安全中心也警告過,不應單純依賴 QKD。

那互通性呢?

RFC 9370 於 2023 年 5 月正式發布,其中指定使用混合式金鑰協議,而非 PSK 或 QKD。但與 TLS 不同的是,TLS 只支援將後量子 ML-KEM 與傳統的 DHE 平行使用,而這份 IPsec 標準允許最多七種不同的協議同時與傳統的 Diffie-Hellman 平行運作。此外,該標準並未明確規定這些金鑰協議應為哪些,而是留給廠商自行選擇其演算法與實作方式。舉例來說,Palo Alto Networks 就非常重視此一彈性,在其新一代防火牆 (NGFW) 中實作了超過七種不同的 PQC 密碼套件,但其中大多數無法與其他廠商互通,甚至有些尚未被 NIST 標準化。

多年來,TLS 的發展方向恰恰相反,其註冊的密碼套件數量從 TLS 1.2 的數百種減少到 TLS 1.3 的約五種。這種減少「密碼套件臃腫」的理念也與 NIST 2019 年發布的 SP 800 52 一致。減少「密碼套件臃腫」的理由包括:

  • 提高跨廠商和跨地區的互通性

  • 降低攻擊者利用弱密碼套件進行降級攻擊的風險

  • 降低因設定錯誤而導致的安全性問題風險

  • 透過縮小程式碼庫規模,降低實作瑕疵的風險

這也是我們最初沒有立即支援 RFC 9370 的原因。

終於步入正軌的標準

也正因如此,當 IPsec 社群提出 draft-ietf-ipsecme-ikev2-mlkem 草案時,我們感到十分振奮。這份網際網路草案為 IPsec 制定了與 TLS 廣泛部署後量子金鑰交換類似的做法:採用混合式 ML-KEM。此一新草案填補了 RFC 9370 的不足,明確定義如何在 IKEv2 中,將 ML-KEM 作為額外的金鑰交換演算法,與傳統的 Diffie-Hellman 平行運作。

如今,這項規範已然成形,我們也已正式在我們的 Cloudflare IPsec 產品中支援後量子 IPsec。

Cloudflare IPsec 現已整合後量子加密

Cloudflare IPsec 是一種廣域網路即服務 (WAN-as-a-Service) 解決方案,透過將資料中心、分支機構和雲端 VPC 連接到 Cloudflare 的全球 IP Anycast 網路,來取代傳統的私有網路架構。

使用 Cloudflare IPsec 時,Cloudflare 的網路扮演 IKEv2 回應者的角色,等待來自 IPsec 發起者的連線請求,而發起者通常是客戶網路中的分支機構連接裝置。Cloudflare IPsec 支援由多種分支連接器發起的 IPsec 工作階段,包括我們自己的 Cloudflare One Appliance,以及來自眾多不同供應商的裝置,例如 Cisco、Juniper、Palo Alto Networks、Fortinet、Aruba 等。

我們已按照 draft-ietf-ipsecme-ikev2-mlkem 的規範,在 Cloudflare IPsec 的 IKEv2 回應者中實作了生產環境級的混合式 ML-KEM 支援。該草案要求首先使用傳統 Diffie-Hellman 金鑰交換來執行第一次金鑰交換。由此得來的金鑰會被用來加密第二次金鑰交換,而第二次交換則是使用 ML-KEM 進行。最後,將兩次交換產生的金鑰混合,其結果用於保護 IPsec ESP(封裝安全負載)模式中的資料平面流量。ESP 模式使用對稱式加密,因此無需任何額外升級,本身就已經具備量子安全性。我們已針對 strongswan 參考實作中的 IPsec 發起者測試了我們的實作。

您可以透過檢視 Cloudflare IPsec 記錄,瞭解 IKEv2 協商中所使用的密碼套件。

我們選擇實作混合式 ML-KEM 而非「純」ML-KEM(即僅執行 ML-KEM 而不並行 DHE),有兩個原因。首先,我們在所有其他 Cloudflare 產品中都採用了混合式 ML-KEM,因為這是整個 TLS 社群共同採用的方法。其次,它提供了「雙重保障」的安全性:ML-KEM 提供針對量子「先竊取、後解密」攻擊的防護,而 DHE 則提供了一個經過考驗的演算法來應對非量子威脅。

邀請各界共同測試互通性

此項實作的完整價值唯有透過互通性才能實現。為此,我們邀請其他正在根據 draft-ietf-ipsecme-ikev2-mlkem 規範,在其分支連接器中建置 IPsec 發起者支援的供應商,來與我們的 Cloudflare IPsec 實作進行測試。有意在我們封閉測試期間,測試與第三方分支連接器互通性的 Cloudflare 客戶,可以在此處註冊。我們計劃隨著越來越多供應商開始上線支援 draft-ietf-ipsecme-ikev2-mlkem,逐步實現全面上市 (GA),並建立與其他供應商的互通性。

量子安全硬體:Cloudflare One Appliance

我們的許多客戶是直接向 Cloudflare 購買分支連接器(硬體或虛擬化形式),而非向第三方供應商購買。因此,Cloudflare One Appliance,這款可即插即用、將您的本地網路連接至 Cloudflare One 的設備,也已同步升級,具備後量子加密能力。

Cloudflare One Appliance 不使用 IKEv2 進行金鑰協議或工作階段建立,而是改為依賴 TLS。該裝置會定期與 Cloudflare 邊緣發起 TLS 交握,透過建立的 TLS 連線分享一個對稱金鑰,然後將該對稱金鑰插入 IPsec 的 ESP 層,接著 ESP 層便會加密並驗證 IPsec 的資料平面流量。這樣的設計使我們得以避免建立 IKEv2 發起者的邏輯,並能利用我們現有的 TLS 函式庫,讓連接器的維護工作更加容易。

因此,將 Cloudflare One Appliance 升級至 PQ 加密,只需將 TLS 1.2 升級至支援混合式 ML-KEM 的 TLS 1.3 即可——這是我們在 Cloudflare 不同產品上已執行過多次的操作。

如何啟用?費用為何?

與以往相同,這次的 Cloudflare IPsec 升級對我們的客戶完全免費。我們相信,安全且私密的網際網路應該讓所有人都能使用,因此我們致力於將 PQC 納入所有產品,無需特殊硬體,也不對客戶和終端使用者收取額外費用

使用 Cloudflare One Appliance 的客戶已在 2026 年 2 月 11 日發布的 2026.2.0 版本中獲得此次 PQC 升級。該升級會根據每台設備設定的維護時段自動推送,無需客戶手動操作。

對於使用其他廠商分支連接器搭配 Cloudflare IPsec 的客戶,我們將在更多廠商開始支援 draft-ietf-ipsecme-ikev2-mlkem 後,陸續實現互通性。您也可以直接與我們聯絡,申請加入封閉測試,並請我們與特定廠商的分支連接器進行互通性測試。

完整圖像:後量子 SASE

後量子 SASE 的價值主張十分明確:組織可以將私人網路流量,透過受混合式 ML-KEM 保護的通道進行傳輸,從而立即獲得端對端的保護。即使企業網路中的個別應用程式尚未升級至 PQC,此舉也能保護流量免受「先竊取、後解密」攻擊。

上方圖表展示了後量子混合式 ML-KEM 在各種 Cloudflare One 網路組態中的應用方式。其中包括以下連接入口:

以及以下連接出口:

下方圖表展示了一個使用 Cloudflare One Client 作為連接入口,將裝置連接至位於 Cloudflare One Appliance 出口後方的伺服器的網路設定範例。終端使用者的裝置透過 MASQUE 搭配混合式 ML-KEM 連接至 Cloudflare 網路(連結 1)。接著,流量在 Cloudflare 的全球網路上透過 TLS 1.3 搭配混合式 ML-KEM 傳輸(連結 2)。之後,流量透過一條後量子的 Cloudflare IPsec 連結(連結 3)離開 Cloudflare 網路,並終止於一台 Cloudflare One Appliance。最後,流量進入客戶內部環境中的伺服器。整段在公共網際網路上傳輸的路徑皆受到後量子密碼學保護,即便該伺服器本身不支援後量子加密也一樣。

最後,我們也指出,進入 Cloudflare One 後再輸出至公共網際網路的流量,也可透過我們的後量子 Cloudflare Gateway(即安全 Web 閘道,SWG)進行保護。以下圖表展示了 SWG 的運作方式:

先前部落格文章中所述,我們的 SWG 已可支援從 SWG 到來源伺服器之間的流量使用混合式 ML-KEM(前提是來源伺服器也支援混合式 ML-KEM),以及從用戶端到 SWG 的流量(如果用戶端支援混合式 ML-KEM,大多數現代瀏覽器都支援)。重要的是,任何透過安裝了 Cloudflare One Client 的裝置進入 SWG 的流量,即使網頁瀏覽器本身尚未支援後量子加密,仍然會受到混合式 ML-KEM 的保護。這得益於 Cloudflare One Client 與 Cloudflare 全球網路之間建立的後量子 MASQUE 通道。同樣地,透過後量子 Cloudflare IPsec 通道進入 SWG 的流量也是如此。

總而言之,Cloudflare One 現已在 TLS、MASQUE 與 IPsec 的各種連接入口與出口上提供後量子加密,涵蓋私人網路流量,以及透過我們的 SWG 流向公共網際網路的流量。

未來是量子安全的

透過將 Cloudflare IPsec 與 Cloudflare One Appliance 納入後量子 SASE 的最後一塊拼圖,我們已將後量子加密擴展至所有主要的連接入口與出口。我們刻意選擇了以互通性與簡潔性為核心的路線——採用 IETF 與 NIST 所推崇的混合式 ML-KEM 方法,而非將客戶鎖定在特定廠商的專有實作、「密碼套件臃腫」或不必要的硬體升級上。

這就是 Cloudflare One 的承諾:一套不僅比它所取代的傳統架構更快、更可靠的 SASE 平台,更提供真正的後量子加密保護。無論您是在保護一位遠端工作者的瀏覽器,還是一條多 GB 的資料中心連線,現在都可以放心地確保您的資料免受「先竊取、後解密」攻擊以及其他前瞻性的威脅。

在此註冊,觀看我們在整個 Cloudflare One SASE 平台上後量子能力的完整展示;或在此報名,加入 Cloudflare IPsec 封閉測試名單。我們很自豪能引領業界邁入這個密碼學的新紀元,並誠摯邀請您一同參與,打造一個可擴展、符合標準,且具備後量子安全性的網際網路。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
後量子Zero Trust密碼編譯Cloudflare OneIPsec VPN

在 X 上進行關注

Sharon Goldberg|@goldbe
Cloudflare|@cloudflare

相關貼文

2026年4月14日 下午1:00

Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP

We share Cloudflare's internal strategy for governing MCP using Access, AI Gateway, and MCP server portals. We also launch Code Mode to slash token costs and recommend new rules for detecting Shadow MCP in Cloudflare Gateway. ...

2026年4月14日 下午1:00

保護一切私人網路:使用者、節點、代理程式、Workers — 隆重推出 Cloudflare Mesh

Cloudflare Mesh 為使用者、節點和自發 AI 智慧體提供安全的私人網路存取。透過與 Workers VPC 整合,開發人員現在可授予 AI 智慧體對私人資料庫和 API 限定範圍的存取權,而無需手動通道。 ...