本內容最後更新於 2025 年 4 月,反映撰寫當下現況。我們會持續改善客戶保護措施,因此安全性政策和系統日後可能會有所變動。
無論您的資料是在網際網路中傳輸、在 Google 的基礎架構內移動,還是儲存於我們的伺服器,Google 的安全控管機制都會保護您的資料。Google 安全性策略的重點在於靜態資料和傳輸中資料的驗證作業、完整性和加密機制。本文說明我們如何設計Google Cloud ,加密網際網路傳輸中的資料,以及 Google 網路內傳輸中的資料。本文不適用於透過互連在客戶資料中心網路和 Google 資料中心網路之間傳輸的資料。
傳輸加密會使用各種技術保護資料,包括傳輸層安全標準 (TLS)、BoringSSL、應用程式層傳輸安全標準 (ALTS) 和 PSP 安全標準通訊協定。除了 Google 提供的預設保護措施外,您還可以新增加密選項 (例如 IPsec、代管的 TLS 憑證和 Cloud Service Mesh),進一步保護資料。
本文的目標對象為正在使用或考慮使用 Google Cloud的資訊安全長與資訊安全作業團隊。本文假定讀者對加密機制和密碼編譯基本功能有初步瞭解。
驗證、完整性和加密
Google 採用下列安全措施,協助確保資料在傳輸過程中的真實性、完整性和隱私性:
- 「驗證」會驗證連線中對等互連裝置的身分 (無論是人或程序)。
- 完整性可防止您傳送的資料在來源和目的地之間傳輸時遭到變更。
- 加密技術會使用密碼編譯,確保他人無法解讀傳輸中的資料,維護資料機密。
當資料在使用者與 Google Cloud 之間,或是兩種服務之間傳輸時,傳輸加密可在有人攔截通訊時,確保您的資料安全。傳輸加密功能會驗證端點,並在傳輸前加密資料。資料抵達目的地後,接收者會解密資料,並確認資料在傳輸過程中未遭到修改。
加密機制是廣義安全性策略中的一環。流動資料的加密機制可保護您的資料不受潛在攻擊的影響,並讓 Google、 Google Cloud 客戶或使用者不必信任網路的較低層級。
流量轉送方式
本節會說明要求如何從使用者端傳送至正確的Google Cloud 服務或客戶應用程式,並介紹流量在不同服務之間的轉送方式。
Google Cloud 服務是 Google 提供給客戶的模組型雲端服務,包含運算、資料儲存、資料分析和機器學習等服務。舉例來說,Cloud Storage 是 Google Cloud 服務。
客戶應用程式是託管於 Google Cloud 的應用程式,Google 客戶可以使用 Google Cloud服務來建構及部署這類應用程式。託管於Google Cloud 的客戶應用程式或合作夥伴解決方案不屬於 Google Cloud 服務。舉例來說,您透過 Cloud Run、Google Kubernetes Engine 或 Compute Engine 中 VM 建構的應用程式即為客戶應用程式。
下圖顯示從使用者到 Google 的流量路徑、Google 網路內的流量路徑,以及每個連線的安全防護措施。系統會顯示下列流量路徑:
- 網際網路上的使用者至 Google Cloud 服務 (圖表中的 A)
- 網際網路上的使用者至託管在Google Cloud 的客戶應用程式(圖中標示為 B)
- 虛擬機器至虛擬機器 (圖中標示為 C)
- 虛擬機器到 Google Front End (GFE) (圖中標示為 D)
- GFE 至 Google API 和服務 (圖中標示為 E)
- Google Cloud 服務到 Google Cloud 服務 (在圖表中標示為 F)
使用者與 Google 之間的傳輸中資料加密
以下各節將進一步說明上圖所示的消費者端要求路徑。
使用者至 Google Cloud 服務
Google Cloud 服務 (例如 Cloud Storage 或 Compute Engine) 是我們提供給客戶的雲端服務,並在正式環境中執行。Google Cloud 服務採用遍及全球的系統來接收世界各地傳出的要求,這個系統稱為 Google Front End (GFE)。GFE 會終止傳入的 HTTP(S)、TCP 和 TLS 連線流量,提供 DDoS 攻擊的因應措施,並將流量轉送至Google Cloud 服務,以及對傳至服務的流量進行負載平衡。世界各地都有 GFE 服務據點,且路徑是透過單點傳播或 Anycast 伺服器通告。
GFE 會透過 Google 網路將流量從使用者端轉送至Google Cloud 服務,以及從使用者端轉送至託管於 Google Cloud 並使用 Cloud Load Balancing 的客戶應用程式。
用戶端透過 HTTPS、HTTP/2 或 HTTP/3 傳送至服務的要求,都會受到 TLS 保護。 Google Cloud GFE 中的 TLS 是以 BoringSSL 實作,這是由 Google 維護的 TLS 通訊協定開放原始碼實作項目。BoringSSL 的核心「BoringCrypto」已通過 FIPS 140-3 第 1 級驗證。
GFE 會與用戶端交涉業界標準的加密參數,包括前向安全金鑰交涉。對於較舊且功能較弱的用戶端,GFE 會選擇用戶端提供的最強舊版加密基本項目。
使用者至託管在 Google Cloud
您可以透過直接連線或負載平衡器,將網際網路的流量轉送至託管在 Google Cloud 的客戶應用程式。直接轉送流量時,流量會轉送至代管應用程式的 VM 伺服器外部 IP 位址。
您可以搭配使用 TLS 和外部應用程式負載平衡器或外部 Proxy 網路負載平衡器,連線至 Google Cloud上執行的應用程式。使用第 7 層負載平衡器時,使用者與負載平衡器之間的連線預設會使用 TLS 加密 (前提是使用者的用戶端應用程式支援 TLS)。GFE 會使用自行管理或 Google 代管的 TLS 憑證,終止來自使用者的 TLS 連線。如要進一步瞭解如何自訂憑證,請參閱 SSL 憑證總覽。 如要啟用負載平衡器與代管客戶應用程式的 VM 之間的加密功能,請參閱「負載平衡器到後端的加密」。
如要設定雙向傳輸層安全標準 (mTLS),請參閱雙向傳輸層安全標準 (mTLS) 總覽。如果是 GKE 和 Compute Engine 上的工作負載,建議使用 Cloud Service Mesh,以便透過您管理的憑證,使用 mTLS 進行雙向驗證 (用戶端和伺服器),並加密傳輸中的通訊內容。
如果是 Firebase Hosting 和 Cloud Run 自訂網域,建議使用免費的自動化 TLS 憑證。使用 Cloud Run 自訂網域時,您也可以提供自己的安全資料傳輸層 (SSL) 憑證,並使用 HTTP 嚴格傳輸安全性 (HSTS) 標頭。
Google 網路內的傳輸中資料加密
Google Cloud 在 Google 網路中傳輸客戶資料時會進行加密,除非本節另有說明。
Google AI 超級電腦內的 TPU 或 GPU 互連專用超高效能互連網路,與本文所述網路不同。在 Google Cloud中,這些超高效能互連網路是 TPU 的 ICI,以及 GPU 的 NVLink。詳情請參閱 TPU 架構和 GPU 機器類型。
透過外部 IP 位址連線至 VM 的流量會離開 Google 網路。您必須自行設定這些連線的加密功能。
Google Cloud 虛擬網路驗證和加密
Google Cloud的虛擬網路會加密、保護完整性並驗證 VM 之間的流量。
在相同的虛擬私有雲,或位於 Google Cloud虛擬網路內的對等互連虛擬私有雲網路之間的私人 IP 流量,加密機制會在網路層執行。
每一對通訊主機都會透過控制頻道建立一組工作階段金鑰,並以 ALTS 提供防護機制,以便用於經過驗證、完整性受保護及加密的通訊內容。工作階段金鑰可用來加密主機之間的 VM 對 VM 通訊內容,工作階段金鑰也會定期輪替。
位於 Google 的實際工作環境網路中的虛擬私有雲網路,以及對等互連虛擬私有雲網路中的所有 VM 對 VM 連線都會經過完整性保護和加密。這些連線包括客戶 VM 之間,以及客戶與 Google 代管的 VM (例如 Cloud SQL) 之間的連線。「流量的路由方式」一文中的圖表顯示了這項互動 (標為 C 連線)。請注意,由於 Google 會根據內部 IP 位址的使用情況啟用自動加密功能,因此使用外部 IP 位址的 VM 之間的連線不會自動加密。
Google Cloud虛擬網路會驗證 VM 之間的所有流量。這項驗證作業是以安全性符記執行,可避免遭到入侵的主機在網路中以假冒的身分傳送封包。
安全性符記會封裝於通道標頭,當中包含傳送者與接收者的相關驗證資訊。傳送主機上的控制層會設定符記,接收主機則會驗證該符記。每次流程都會預先產生安全性符記,由含有傳送者資訊和主機密鑰的符記所組成。
連線到 Google API 和服務
流量處理方式會根據 Google Cloud 服務的代管位置而有所不同。
大多數的 Google API 和服務都在 GFE 中託管。從 VM 傳送至 GFE 的流量會透過外部 IP 位址傳輸至 Google Cloud 服務,但您可以設定私人存取權,避免使用外部 IP 位址。從 GFE 傳送至服務的連線會經過驗證和加密。
部分服務 (例如 Cloud SQL) 是在 Google 代管的 VM 執行個體上代管。如果客戶 VM 使用外部 IP 位址存取 Google 管理的 VM 執行個體上代管的服務,流量會留在 Google 的實際工作環境網路中,但由於使用外部 IP 位址,因此不會自動加密。詳情請參閱Google Cloud 虛擬網路驗證和加密。
使用者將要求傳送至 Google Cloud 服務時,我們會以 HTTPS 和公開網路憑證授權單位提供的憑證來證明完整性,並執行驗證和加密作業,藉此保護傳輸中的資料。使用者傳送至 GFE 的所有資料,在傳輸期間都會以 TLS 或 QUIC 加密。GFE 會依據用戶端可以支援的通訊協定,與用戶端交涉特定的加密通訊協定,並盡可能選擇採用最現代化的加密通訊協定。
服務對服務的驗證、完整性和加密機制
Google 基礎架構會使用 ALTS,驗證、加密 GFE 與 Google Cloud 服務之間的連線,以及服務與服務之間的連線,並確保連線完整性。 Google Cloud Google Cloud
ALTS 會使用以服務為準的身分進行驗證,在 Google 實際工作環境中執行的服務會取得憑證,聲明其服務身分。當以其他服務產生或接收 RPC 時,服務會使用自己的憑證進行驗證。ALTS 會驗證這些憑證是否由 Google 內部 CA 核發。Google 內部 CA 與憑證授權單位服務無關,而是獨立的憑證。
ALTS 會對從 GFE 傳輸至服務的流量,以及在 Google 正式環境中執行的服務間流量,使用加密和密碼編譯完整性保護機制。 Google Cloud
在 GFE 和 Google Cloud 服務之間的流量中,ALTS 也會用於封裝其他第 7 層通訊協定 (例如 HTTP) 的 RPC 機制。這項保護機制有助於隔離應用程式層,並移除用於維持網路路徑安全性的所有依附元件。
傳輸中資料加密方法
以下各節說明 Google 用來加密傳輸中資料的技術。
使用 PSP 進行網路加密
PSP 是一種與傳輸方式無關的通訊協定,可提供連線層級的安全性,並支援將加密作業卸載至智慧型網路介面卡 (SmartNIC) 硬體。只要有 SmartNIC,ALTS 就會使用 PSP 加密網路中傳輸的資料。
PSP 的設計宗旨是滿足大規模資料中心流量的需求。Google 基礎架構會使用 PSP 加密資料中心內和資料中心之間的流量。PSP 也支援 UDP 等非 TCP 通訊協定,並為每個連線使用專屬的加密金鑰。
應用程式層傳輸安全性
ALTS 是 Google 開發的雙向驗證和加密系統,ALTS 可為 Google 實際工作環境中執行的服務之間傳輸的資料提供驗證、機密性和完整性。ALTS 包含下列通訊協定:
握手通訊協定:用戶端會啟動橢圓曲線和量子安全金鑰交換程序。在握手程序結束時,相關服務會交換並驗證簽署的憑證,藉此驗證彼此的身分,並計算共用的流量金鑰。支援衍生共用流量金鑰的演算法包括 NIST 後量子演算法 ML-KEM (FIPS 203)。詳情請參閱後量子密碼編譯。
記錄通訊協定:服務對服務的資料在傳輸過程中會使用共用流量金鑰加密。根據預設,ALTS 會對所有流量使用 AES-128-GCM 加密。在 Google 最低層級的儲存系統中,傳輸中的資料會使用 AES-256 加密,ALTS 則提供 AES 訊息驗證。ALTS 加密機制是由 BoringSSL 或 PSP 提供。這項加密技術已通過 FIPS 140-2 第 1 級或 FIPS 140-3 第 1 級驗證。
ALTS 憑證的根簽署金鑰會儲存在 Google 內部 CA 中。
後續步驟
- 如要進一步瞭解 Google 資料中心安全措施,請參閱資料中心安全措施。
- 如要瞭解Google Cloud 與客戶資料中心網路之間互連網路的安全設定選項,請參閱「選擇網路連線產品 (IPSec)」和「Cloud Interconnect 適用的 MACsec 總覽」。
- 如需法規遵循與法規遵循認證的相關資訊,請參閱 Google Cloud 法規遵循資源中心,當中也提供我們的 SOC 3 稽核報告。
- 如需保護傳輸中資料的最佳做法,請參閱企業基礎藍圖、Google Cloud 架構架構:安全性、隱私權和法規遵循,以及決定如何符合傳輸中加密的法規要求。