本文詳細說明 Google Distributed Cloud (GDC) 實體隔離方案的傳輸加密。
資訊長層級摘要
- GDC 採用多種安全措施，協助確保資料在傳輸過程中的真實性、完整性和機密性。
- 視連線情況而定，GDC 可能會對 GDC 元件的流動資料套用預設的安全防護措施。舉例來說，我們會使用 TLS 保護使用者與 GDC Cloud Service Mesh Ingress Gateway 之間的通訊內容。
簡介
選擇雲端服務供應商時，安全性往往是一項決定性因素。對 Google 而言，安全性也是我們的優先要務。無論您的資料是在網路上傳輸、在 Google 的基礎架構內移動，還是儲存於我們的伺服器，我們都會努力不懈地保護。
Google 安全性策略的重點在於靜態資料和傳輸中資料的驗證作業、完整性和加密機制。本文說明 Google Distributed Cloud 氣隙隔離環境 (GDC) 的流動資料加密機制。
如需靜態資料的相關資訊，請參閱靜態資料加密。如想瞭解 Google 安全防護措施的基本資訊，請參閱 Google 基礎架構安全性設計總覽一文。
目標對象：本文的目標對象為正在使用或考慮使用 GDC 的資訊安全長與安全性作業團隊。
前提說明：我們假定您在閱讀本文以前，對加密機制和密碼編譯基元已有基本認識。
驗證、完整性和加密
GDC 採用多種安全措施，協助確保資料在傳輸過程中的真實性、完整性和機密性。
- 驗證：我們會在網路層驗證資料目的地。來源會由 GDC 管理的 AIS 進行驗證。
- 完整性：我們會確保您所傳送的資料保持未受變更的狀態，平安傳輸至目的地，並防止未經授權的變更。
- 加密：我們會確保他人無法解讀傳輸中的資料，維護資料機密。加密程序的作用是將可以輕易解讀的資料 (明文) 轉換為無法理解的文字 (密文)，其目標為確保只有資料擁有者授權的實體才能存取資料明文。雖然加密程序採用的是公開演算法，但解開密文所需的金鑰為私密金鑰。流動資料的加密作業通常會使用非對稱式金鑰交換機制 (例如橢圓曲線型的 Diffie-Hellman 金鑰)，藉此建立用來加密資料的共用對稱式金鑰。如要進一步瞭解加密機制，請參閱《現代密碼學》(Introduction to Modern Cryptography)。
資料加密可用來在以下多個階段保護資料：
- 靜態資料加密：對儲存的資料套用加密保護，確保資料不會因為系統遭駭或他人竊取受到影響。進階加密標準 (AES) 通常用於靜態資料的加密。
- 傳輸加密：當資料在您的網站與雲端供應商之間，或是兩種服務之間傳輸時，傳輸加密可在有人攔截通訊時，確保資料安全無虞。這種保護機制會將傳輸前的資料加密，然後驗證端點，並在資料抵達目的地時解密並驗證資料是否遭到修改，透過這種方式來達到目標。舉例來說，傳輸層安全標準 (TLS) 通常是為了達到傳輸安全性，而用於流動資料加密上，而安全/多用途網際網路郵件延伸標準 (S/MIME) 則通常用於加密電子郵件訊息。
加密機制是廣義安全性策略中的一環。在系統建立並驗證連線之後，流動資料的加密機制會透過下列方式保護您的資料不受潛在攻擊的影響：
- 停止信任第三方常用的較低層網路
- 減少潛在的受攻擊面
- 若通訊遭到攔截，可阻擋攻擊者存取資料
在驗證程序、加密機制與完整性均完備的情況下，即便處於惡劣的環境中，在使用者、裝置或程序之間傳輸的資料仍能受到妥善保護。本文後續章節將說明 GDC 的傳輸中資料加密方法和應用實例。
GDC 網路基礎架構
實體邊界
實體界限是 Google 控制或與 Google 協調的實體空間屏障，我們可保證在此設下了嚴謹的安全保護措施。我們會嚴加限制並監控這類位置的實體權限，只有少數獲得核准的人員可以存取硬體。在這些實體界限內，傳輸中的資料通常會經過驗證和加密。
如果通訊內容跨越 GDC 的實體界限，我們會採用嚴格的驗證和加密機制，保護傳輸中的資料。
流量轉送方式
如要瞭解 GDC 的流動資料加密機制，必須先說明流量如何轉送至 GDC，以及如何透過 GDC 轉送。本節會說明要求如何從使用者端傳送至正確的 GDC 服務或客戶應用程式，並介紹流量在跨網站服務之間的轉送方式。
GDC 管理的服務是模組化私人雲端服務。包括運算、儲存空間和機器學習。舉例來說，GDC 物件儲存空間是 GDC 管理的服務。客戶應用程式是託管於 GDC 的應用程式，GDC 客戶可以使用各項 GDC 服務來建構及部署這類應用程式。託管於 GDC 的客戶應用程式或合作夥伴解決方案不屬於 GDC 代管服務。舉例來說，您使用 GDC VM、Database Service 和 Vertex AI 建構的應用程式即為客戶應用程式。
圖 1 顯示不同類型的轉送要求。圖 1 顯示不同網路元件之間的互動，以及每個連線設有的安全防護措施。
圖 1：跨網站連線基礎架構
使用者 (客戶網路) 至 GDC API 和代管服務
如果代管服務是託管在 Cloud Service Mesh Ingress Gateways 上，這些服務會使用 Cloud Service Mesh Ingress Gateway 接受來自客戶網路的要求。Cloud Service Mesh Ingress Gateway 會將傳入的 HTTP(S) 流量以 Proxy 的方式轉送至 GDC 管理的服務，並進行負載平衡。另一層防火牆則提供入侵偵測和防禦功能，可有效防範 DDoS 攻擊。從 Cloud Service Mesh Ingress Gateway 到 GDC 管理服務前端的連線會經過驗證和加密。圖 1 顯示了這項互動 (標為 A 連線)。
大多數 GDC API 和代管服務都託管在 Cloud Service Mesh Ingress Gateways。不過，部分服務是直接在 GDC 代管的第 4 層負載平衡器上代管。舉例來說，DBS 資料庫是代管在 GDC 外部負載平衡器上。這些服務已設為在應用程式層使用 TLS 驗證及加密連線。圖 1 顯示了這項互動 (標為 B 連線)。
使用者 (客戶網路) 至託管在 GDC 上的客戶應用程式
您可以透過多種方式，將客戶網路的流量轉送至 GDC 上託管的客戶應用程式。流量的轉送方式取決於設定。
透過客戶 API 閘道公開客戶應用程式
GDC 支援透過客戶 API 閘道公開客戶應用程式。客戶 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 Gateway 的加密
目前有許多系統在網際網路中使用 HTTPS 來進行通訊。HTTPS 會使用傳輸層安全標準 (TLS) 連線來確保安全性，藉此保障要求和回應的真實性、完整性和機密性。為接收 HTTPS 要求，接收者必須取得公開/私密金鑰組和 X.509 憑證，以便用於憑證授權單位 (CA) 規定的伺服器驗證程序。金鑰組和憑證可用來證明接收者擁有要求傳送目標的網域名稱，這樣即可在應用程式層 (第 7 層) 驗證使用者的要求。以下小節會說明使用者至 Cloud Service Mesh Ingress Gateway 的加密作業元件，包括傳輸層安全標準 (TLS)、BoringSSL 和 GDC 可設定的憑證授權單位。
傳輸層安全標準 (TLS)
您將要求傳送至 GDC 服務時，我們會以 HTTPS 和信任的憑證授權單位提供的憑證來證明完整性，並執行驗證和加密作業，藉此保護傳輸中的資料。使用者傳送至 Cloud Service Mesh Ingress Gateway 的 GDC 管理服務資料，在傳輸期間都會以傳輸層安全標準 (TLS) 加密。Cloud Service Mesh Ingress Gateway 會依據用戶端可以支援的通訊協定，與用戶端交涉特定的加密通訊協定。GDC Cloud Service Mesh Ingress Gateway 只會強制執行 FIPS 核准的演算法，以提供更強大的安全性。
BoringSSL
BoringSSL 是由 Google 維護的傳輸層安全標準 (TLS) 通訊協定開放原始碼實作項目。這個項目是 OpenSSL 的分支版本，因此與 OpenSSL 的介面大多相容。Google 將 BoringSSL 從 OpenSSL 中獨立出來是為了簡化 OpenSSL。這麼做不僅可以方便內部使用，也能更充分支援 Chromium 和 Android 開放原始碼計畫。BoringSSL 的核心「BoringCrypto」已通過 FIPS 140-2 第 1 級驗證。
Cloud Service Mesh Ingress Gateway 中的 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：Cloud Service Mesh Ingress Gateway 中採用的加密機制 (適用於 GDC 服務)，以及在 BoringSSL 密碼編譯資料庫中實作的加密機制
GDC 可設定的憑證授權單位
伺服器隸屬於傳輸層安全標準 (TLS)，因此伺服器收到連線要求時，必須向使用者證明其身分。為了在傳輸層安全標準 (TLS) 通訊協定中驗證伺服器的身分，伺服器必須提出含有其宣稱身分的憑證。這組憑證中包含伺服器的 DNS 主機名稱與公開金鑰。提出憑證後，該憑證就會由簽發憑證的憑證授權單位 (CA) 簽署，該憑證授權單位必須是要求連線的使用者信任的單位。因此，向伺服器提出連線要求的使用者只需要信任根 CA。如果使用者希望能隨時隨地存取該伺服器，則所有潛在的用戶端裝置都必須取得其根 CA。用戶端瀏覽器和裝置會根據運作環境，設定一組信任的根 CA。
GDC 的根 CA 取決於部署環境，以及該環境中客戶的需求。
Cloud Service Mesh Ingress Gateway 到應用程式前端
兩種情況：
- Cloud Service Mesh Ingress Gateway 會終止 TLS，並使用 Cloud Service Mesh Istio 憑證重新加密 mTLS
- 從 Ingress Gateway 到 Istio Sidecar 應用程式前端的 mTLS
- Cloud Service Mesh Ingress Gateway 會終止 TLS，並使用已設定的 CA 將 TLS 重新加密至其他伺服器。
儲存空間流量的網路加密
在 GDC 檔案和區塊儲存系統中，流量會在應用程式 (使用儲存空間) 和儲存服務之間路由傳輸。該資料在傳輸過程中會使用 IPSec 進行驗證和加密。儲存空間流量的用戶端加密功能即將推出。 檔案和區塊流量會使用 IPSec 傳輸模式，傳輸至需要存取儲存空間的主機。驗證作業會使用在航班上產生的預先共用金鑰，並安全地儲存在 GDC 中。IPSec SA 建立完成後，資訊就會透過 IPSec 通道交換。封包會使用 IPSec SA 中指定的 FIPS 相容加密編譯進行加密及解密。
服務對服務的驗證、完整性和加密機制
在 GDC 基礎架構中，我們在應用程式層 (第 7 層) 使用 mTLS 或 TLS，確保從 Cloud Service Mesh Ingress Gateway 到服務，以及從一個 GDC 服務到另一個 GDC 服務的 RPC 呼叫，均能經過驗證及加密，並保障其完整性。每項在 GDC 執行的服務，均會以含有相關加密編譯憑證的服務帳戶身分來執行。透過 Cloud Service Mesh 使用 mTLS 通訊時，GDC 服務會使用用戶端憑證向其他服務進行驗證。Cloud Service Mesh 會使用內部憑證授權單位驗證這些憑證。透過 TLS 通訊時 (例如與 GDC Kubernetes API 伺服器通訊)，GDC 服務會使用 Kubernetes 服務帳戶權杖向服務進行驗證。系統會使用 Kubernetes API 伺服器權杖簽發者的公開金鑰，驗證 Kubernetes 服務帳戶權杖。