本文詳細說明 Google Distributed Cloud (GDC) 實體隔離方案的傳輸中資料加密機制。
資訊長層級摘要
- GDC 採用多項安全措施，確保傳輸中的資料真實、完整且保密。
- GDC 會根據建立的連線，對 GDC 元件傳輸中的資料套用預設保護措施。舉例來說，我們會使用 TLS 保護使用者與 GDC Cloud Service Mesh Ingress 閘道之間的通訊。
簡介
安全性通常是選擇雲端服務供應商的決定性因素。對 Google 而言，安全性也是我們的優先要務。無論資料是在網路上傳輸、在 Google 基礎架構中移動，還是儲存在我們的伺服器上，我們都會不遺餘力地保護資料。
Google 安全策略的核心是驗證、完整性和加密，適用於靜態和傳輸中的資料。本文說明我們如何對 Google Distributed Cloud 實體隔離方案 (GDC) 的傳輸中資料進行加密。
如要瞭解靜態資料，請參閱「靜態資料加密」。如想瞭解 Google 安全防護措施的基本資訊，請參閱 Google 基礎架構安全性設計總覽一文。
適用對象：本文件適用於使用或考慮使用 GDC 的資訊安全長和資安營運團隊。
前提說明：我們假定您在閱讀本文以前，對加密機制和密碼編譯基元已有基本認識。
驗證、完整性和加密
GDC 採用多項安全措施，確保傳輸中的資料真實、完整且保密。
- 驗證：我們會在網路層驗證資料的目的地。來源會由 GDC 代管的 AIS 驗證。
- 完整性：確保傳送的資料在抵達目的地時未經竄改，也就是防止未經授權的變更。
- 加密：我們會在傳輸過程中將資料轉換為無法讀取的格式，確保資料機密性。加密是指將可讀資料 (明文) 轉換為不可讀資料 (密文) 的程序，目的是確保只有資料擁有者授權的人員才能存取明文。加密程序中使用的演算法是公開的，但解密密文所需的金鑰是私密的。傳輸中資料加密通常會使用非對稱式金鑰交換 (例如以橢圓曲線為基礎的 Diffie-Hellman)，建立用於資料加密的共用對稱式金鑰。如要進一步瞭解加密，請參閱「現代密碼學簡介」。
加密技術可用於保護多種狀態的資料：
- 靜態資料加密：在儲存資料時加密，防止系統遭到入侵或資料遭竊。高級加密標準 (AES) 常用於加密靜態資料。
- 傳輸中資料加密：當資料在您的網站與雲端服務供應商之間，或是在兩種服務之間傳輸時，傳輸中資料加密可在有人攔截通訊時，確保您的資料安全。這種保護機制會將傳輸前的資料加密，然後驗證端點，並在資料抵達目的地時解密並驗證資料未經修改，透過這種方式來達到目標。舉例來說，傳輸層安全標準 (TLS) 通常用於加密傳輸中的資料，以確保傳輸安全；安全/多用途網際網路郵件延伸標準 (S/MIME) 則常用於加密電子郵件訊息。
加密機制是廣義安全性策略中的一環。連線建立並通過驗證後，傳輸中資料加密功能會採取下列措施，保護資料不受潛在攻擊者侵害：
- 不必信任通常由第三方提供的網路底層
- 減少潛在的受攻擊面
- 若通訊遭到攔截，可阻擋攻擊者存取資料
只要有適當的驗證、完整性和加密機制，在惡劣環境中，使用者、裝置或程序之間傳輸的資料就能受到保護。本文其餘部分將說明 GDC 如何加密傳輸中的資料，以及這項機制的應用範圍。
GDC 網路基礎架構
實體邊界
實體界限是指由 Google 控制或與 Google 協調的實體空間屏障，我們可確保該空間採取嚴密的安全防護措施。這些地點的實體存取權受到限制，並受到嚴密監控和稽核。只有少數核准人員可以存取硬體。在這些實體範圍內傳輸中的資料，通常會經過驗證和加密。
對於進出 GDC 實體邊界的通訊，我們會採用強大的驗證和加密機制，保護傳輸中的資料。
流量轉送方式
如要瞭解 GDC 如何加密傳輸中的資料，必須先說明流量如何轉送至 GDC 及透過 GDC 轉送。本節說明要求如何從使用者傳送至適當的 GDC 服務或客戶應用程式，以及流量如何在跨站點服務之間轉送。
GDC 代管服務是模組化私有雲服務。這些服務包括運算、儲存和機器學習。例如，GDC 物件儲存庫是 GDC 代管服務。「客戶應用程式」是託管於 GDC 的應用程式，身為 GDC 客戶，您可以使用 GDC 服務建構及部署這類應用程式。託管於 GDC 的客戶應用程式或合作夥伴解決方案，不屬於 GDC 代管服務。舉例來說，您使用 GDC VM、資料庫服務和 Vertex AI 建構的應用程式，就是客戶應用程式。
圖 1 顯示不同類型的轉送要求。圖 1 顯示各種網路元件之間的互動，以及各個連線的安全防護機制。
圖 1：站點間連線基礎架構
使用者 (客戶網路) 到 GDC API 和代管服務
如果代管服務託管於 Cloud Service Mesh 輸入閘道，則會使用 Cloud Service Mesh 輸入閘道接受來自客戶網路的要求。Cloud Service Mesh Ingress 閘道會代理傳入的 HTTP(S) 流量，並將流量轉送及負載平衡至 GDC 代管服務本身。另一個防火牆層則提供 DDoS 攻擊防範措施，以及入侵偵測和防護功能。這項連線會從 Cloud Service Mesh Ingress 閘道，向 GDC 代管服務的前端進行驗證及加密。圖 1 將這項互動顯示為連線 A。
大多數 GDC API 和代管服務都託管於 Cloud Service Mesh Ingress 閘道。不過，部分服務會直接託管於 GDC 代管的第 4 層負載平衡器。舉例來說，DBS 資料庫託管於 GDC 外部負載平衡器。這些服務會設為使用 TLS，在應用程式層驗證及加密連線。圖 1 將這項互動顯示為連線 B。
使用者 (客戶網路) 到託管於 GDC 的客戶應用程式
您可以透過多種方式，將流量從客戶網路轉送至託管於 GDC 的客戶應用程式。流量的轉送方式取決於您的設定。
透過客戶 API Gateway 公開客戶應用程式
GDC 支援透過客戶 API Gateway 公開客戶應用程式。客戶 API Gateway 服務可讓使用者視需要開發、部署、保護、管理及擴充 API。圖 1 將這項互動顯示為連線 C。
透過客戶外部負載平衡器，公開容器化客戶工作負載
GDC 支援透過外部負載平衡器，公開客戶代管的容器化工作負載。GDC 可讓相關人員設定輸入和輸出政策。圖 1 將這項互動顯示為連線 E。
公開虛擬機器工作負載
GDC 支援向使用者公開客戶建立的虛擬機器。GDC 可讓您為相應人員設定輸入和輸出政策。圖 1 將這項互動顯示為連線 F。
GDC 跨地點互連網路服務
從一項代管服務轉送至另一項代管服務時，通常完全在 GDC 的實體邊界內進行。在某些情況下 (例如跨站點備份)，資料會轉送至 GDC 的實體界限之外。在這種情況下，資料會在應用程式層 (例如 TLS) 和網路層加密。圖 1 將這項互動顯示為連線 G。
虛擬機器對虛擬機器
GDC 內 VM 對 VM 的連線不會在網路層級加密。客戶有責任使用適當的加密通訊協定或特定技術 (例如 IPSec 通道) 加密資料。
預設在會議內容傳輸過程進行加密
GDC 會使用各種預設和使用者可設定的加密方法，保護傳輸中的資料。使用的加密類型取決於 OSI 層、服務類型和基礎架構的實體元件。本節說明 Google 用於保護傳輸中資料的預設保護機制。
本節其餘部分將說明 Google 用於保護傳輸中資料的預設保護機制。
使用者到 Cloud Service Mesh Ingress 閘道加密
目前許多系統都使用 HTTPS 透過網際網路通訊。HTTPS 透過 TLS 連線提供安全性，確保要求和回應的真實性、完整性和機密性。如要接受 HTTPS 要求，接收端需要一組公開/私密金鑰組，以及憑證授權單位 (CA) 核發的 X.509 憑證，用於伺服器驗證。金鑰組和憑證可證明接收者擁有要求指定的網域名稱，有助於在應用程式層 (第 7 層) 驗證使用者要求。下列子節將討論使用者到 Cloud Service Mesh Ingress Gateway 加密機制的元件，也就是 TLS、BoringSSL 和 GDC 可設定的憑證授權單位。
傳輸層安全標準 (TLS)
當您向 GDC 服務傳送要求時，我們會保護傳輸中的資料，並使用 HTTPS 搭配信任憑證授權單位核發的憑證，提供驗證、完整性和加密功能。使用者傳送至 Cloud Service Mesh Ingress 閘道，用於 GDC 代管服務的任何資料，都會在傳輸過程中以傳輸層安全標準 (TLS) 加密。Cloud Service Mesh Ingress 閘道會根據用戶端支援的加密通訊協定，與用戶端協商特定加密通訊協定。GDC Cloud Service Mesh Ingress 閘道只會強制執行 FIPS 核准的演算法，提供更強大的安全性。
BoringSSL
BoringSSL 是 Google 維護的開放原始碼 TLS 通訊協定實作，衍生自 OpenSSL，且大部分介面與 OpenSSL 相容。Google 從 OpenSSL 分支出 BoringSSL，以簡化 OpenSSL，供內部使用，並更妥善支援 Chromium 和 Android 開放原始碼專案。BoringSSL 的核心 BoringCrypto 已通過 FIPS 140-2 第 1 級驗證。
Cloud Service Mesh Ingress 閘道中的 TLS 是透過 BoringSSL 實作。表 1 顯示 GDC 與用戶端通訊時支援的加密通訊協定。
| 通訊協定 | 驗證 | 金鑰交換 | 加密 | 雜湊函式 |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
表 1：在 GDC 服務的 Cloud Service Mesh Ingress 閘道中實作，以及在 BoringSSL 密碼編譯程式庫中實作的加密機制
GDC 可設定的憑證授權單位
在 TLS 協定中，伺服器收到連線要求時，必須向使用者證明其身分。在 TLS 通訊協定中，伺服器會出示包含其聲稱身分的憑證，藉此驗證身分。憑證包含伺服器的 DNS 主機名稱和公開金鑰。出示後，憑證會由核發憑證授權單位 (CA) 簽署，該單位須由要求連線的使用者信任。因此，要求連線至伺服器的使用者只需要信任根 CA。如果伺服器希望隨處都能存取，則任何潛在用戶端裝置都必須知道根 CA。用戶端瀏覽器和裝置會根據用戶端運作環境，設定一組信任的根 CA。
GDC 的根 CA 取決於部署環境，以及該環境中的客戶需求。
Cloud Service Mesh Ingress 閘道至應用程式前端
兩種情況：
- Cloud Service Mesh Ingress 閘道會終止 TLS，並使用 Cloud Service Mesh Istio 憑證重新加密 mTLS
- 從 Ingress 閘道到 Istio Sidecar 應用程式前端的 mTLS
- Cloud Service Mesh Ingress 閘道會終止 TLS，並使用設定的 CA 將 TLS 重新加密至其他伺服器。
儲存空間流量的網路加密
在 GDC 檔案和區塊儲存空間系統中，流量會在應用程式與儲存服務之間轉送。資料在傳輸過程中會使用 IPSec 進行驗證和加密。儲存空間流量的用戶端加密功能即將推出。IPSec 傳輸模式用於檔案和區塊流量，傳輸至需要存取儲存空間的主機。驗證作業會透過預先共用金鑰完成，該金鑰會即時產生並安全地儲存在 GDC 中。建立 IPSec SA 後，系統會使用 IPSec 通道交換資訊。封包會使用 IPSec SA 中指定的 FIPS 相容加密演算法進行加密和解密。
服務對服務的驗證、完整性和加密機制
在 GDC 基礎架構中，我們在應用程式層 (第 7 層) 使用 mTLS 或 TLS，對從 Cloud Service Mesh Ingress 閘道到服務，以及從一個 GDC 服務到另一個 GDC 服務的 RPC 呼叫進行驗證、完整性檢查和加密。在 GDC 執行的每項服務，都會以服務帳戶身分執行，並具備相關聯的加密編譯憑證。透過 Cloud Service Mesh 進行 mTLS 通訊時，GDC 服務會使用用戶端憑證向其他服務進行驗證。Cloud Service Mesh 會使用內部憑證授權單位驗證這些憑證。透過 TLS 通訊時 (例如與 GDC Kubernetes API 伺服器通訊)，GDC 服務會使用 Kubernetes 服務帳戶權杖向服務進行驗證。Kubernetes 服務帳戶權杖會使用 Kubernetes API 伺服器權杖核發者的公開金鑰進行驗證。