Google Cloud 後量子密碼路線圖:2029 全面轉型，企業現在能做的三件事

Posted On 2026 年 8 月 19 日

Google Cloud 在 2026 年 8 月公布了完整的後量子密碼(Post-Quantum Cryptography， PQC)遷移路線圖，目標是在 2029 年前完成基礎設施的量子安全轉型。多數報導會停在「Google 訂出時間表」這件事上，但對正在用 Google Cloud 的企業來說，真正該問的問題不是「Google 什麼時候做完」，而是「我自己的風險現在就存在，我在等什麼」。

什麼是後量子密碼，為什麼不是遙遠的未來式

後量子密碼要解決的問題，是現有的非對稱加密演算法(像 RSA、橢圓曲線加密)在夠強大的量子電腦出現後會被破解。這件事本身還沒發生，但攻擊手法已經在發生——也就是所謂的 Store Now， Decrypt Later(SNDL，先竊取、後解密):攻擊者現在就攔截並儲存加密流量，等量子電腦成熟後再回頭解密。

這代表一個容易被忽略的邏輯:你今天傳輸的敏感資料，防禦強度是用「解密發生的那一天」的技術水準來決定，而不是今天的技術水準。如果你的資料有 5 到 10 年的機密性要求(合約、病歷、智慧財產、國防或金融相關資料)，那麼即使量子電腦還沒出現，風險已經在累積。這也是為什麼美國國安局的 CNSA 2.0 標準與 NIST IR 8547 都把 2030 至 2035 年設為淘汰舊有演算法的終點——留給企業的緩衝期，其實比表面上看到的短。

Google Cloud 的三條防線

Google 把整個 PQC 遷移拆成三個風險領域，各自有不同的完成時程:

1. Store Now Decrypt Later 防護(目標 2027 年底)

保護今天正在傳輸的資料不被未來解密，涵蓋客戶工作負載的 TLS 連線、管理員與開發者的存取路徑(Cloud VPN、Interconnect、SDK)、以及資料傳輸管線(Cloud Storage、BigQuery 等)。

2. 完整性與防偽造(目標 2028 年底)

確保數位簽章與憑證無法被偽造，涵蓋軟體供應鏈簽章(Binary Authorization)、憑證機構(CA)發行 ML-DSA / SLH-DSA 憑證，以及 IAM 身分驗證機制。

3. 基礎建設與金鑰治理(目標 2028 年底)

底層能力，包括 Cloud KMS 的 PQC 演算法(ML-KEM、ML-DSA、SLH-DSA 已全面上線)、硬體層的量子安全信任根(如 OpenTitan)，以及金鑰主權與外部金鑰管理的支援。

已完成項目(2025-2026)	進行中(2027-2028)
API 端點(google.com、*.googleapis.com)支援 ML-KEM 混合金鑰交換	Cloud VPN、Interconnect、GKE service mesh 等管理路徑
應用與 Proxy 負載平衡器支援 X25519MLKEM768	憑證機構全面轉換為 ML-DSA / SLH-DSA
Cloud KMS 的 PQC 簽章與加密演算法全面上線	Cloud IAM 的量子安全身分驗證
內部 ALTS 協定的量子機密性保護	Cloud HSM(FIPS 140-3 L3)量子安全版本

2029 是 Google 基礎設施的時程，不是你的資安時程

Google 這份路線圖有個容易被誤讀的地方，描述的是 Google 對自己基礎設施的承諾，而不是「你的資料到 2029 年才需要開始擔心」。文章裡明確寫出「雲端安全共同責任」的分界 : Google 負責的是雲端本身的安全(網路、加密傳輸、伺服器硬體)，但客戶端的應用程式更新、金鑰生命週期管理、服務設定，責任在企業自己身上。

換句話說，即使 Google 的負載平衡器已經在 2026 年支援量子安全金鑰交換，如果你的應用程式、SDK、內部工具沒有跟著更新去協商 PQC 連線，這條防線對你來說形同虛設。

這也是為什麼 Google 自己把「Update」(更新你的開發與維運團隊使用的軟體)列為三步驟裡的第二步，而不是最後一步，因為基礎設施就緒和企業實際受保護之間，中間隔著一個經常被低估的執行落差。

對於處理長效期敏感資料的企業(金融、醫療、政府相關、任何有長期保密義務的合約資料)，SNDL 風險是現在進行式，不是 2029 年的待辦事項。等 Google 完成部署再行動，等於把自己的資安時程外包給供應商的產品發布節奏。

企業現在能做的三件事

Google 在文章中給出的三步驟，拆解後其實對應到三個不同的責任歸屬，值得分開理解:

盤點(Inventory):

確認開發與 SRE 團隊使用的工具鏈(BoringSSL、Chrome、各語言 SDK)支援 PQC 演算法。這一步的重點是「協商能力」——就算後端支援 PQC，前端協商不出來，連線還是會退回舊演算法

更新(Update):

用 Cloud Asset Inventory 或第三方工具(如文中提到的 Wiz)找出組織內所有的金鑰與憑證使用情況。沒有盤點，就無法排出遷移優先順序——這是多數企業實際卡關的第一步，而不是技術本身。

驗證(Validate):

用 Google 已經上線的量子安全 API 與負載平衡器實際測試現有應用程式的行為，提早找出效能瓶頸或相容性問題，而不是等正式切換時才發現。

這三步驟本身沒有捷徑，但排序有意義:沒做完盤點就直接更新工具鏈，常常會漏掉分散在各團隊、各服務裡的舊金鑰;沒做驗證就直接上線，則容易在憑證鏈驗證的效能問題上摔跤——文章裡也提到，PQC 簽章尺寸偏大，對憑證鏈驗證的效能影響是 Google 自己都還在用 Merkle Tree Certificates 等新方法解決的問題。

產品優勢對比：

評估維度	傳統內部自行開發/手動升級	導入專業企業級 PQC 軟體系統
盤點效率	耗時數月，容易遺漏隱藏於設備韌體或第三方服務的加密點。	具備自動化盤點工具，數週內即可生成完整的企業密碼資產拓撲圖。
密碼敏捷性	演算法寫死在底層架構中，未來若需再次更換標準將面臨重構風險。	支援隨插即用的演算法模組，未來可快速適應國際標準的任何變動。
營運衝擊	需經歷長時間的停機測試，嚴重影響B2B客戶的服務連續性。	提供混合模式（Hybrid Mode），可同時相容傳統與PQC演算法，確保零停機。
法規遵循	缺乏標準化的報表，難以向監管機關證明已具備足夠的量子資安韌性。	內建符合金管會等監理機關要求的稽核報表，輕鬆滿足合規性審查。

總結

Google Cloud 的 PQC 路線圖提供了明確的基礎設施時程，這是好消息。但這份時程表能保護你多少，取決於你自己的盤點、更新、驗證有沒有跟上而這部分完全不在 Google 的時程表裡。如果你的組織處理長效期敏感資料，現在就該啟動盤點，而不是把「2029」當成截止日期記在行事曆上。

訂閱偉康科技洞察室部落格，掌握最新科技趨勢！

Tags:FIDO, FIDO2, PQC, 實體安全金鑰, 後量子, 資安

About The Author

naomi