預設靜態資料加密

本文上次更新於 2024 年 5 月，內容反映截至撰文時的情況。我們一向持續提升客戶保護措施，因此安全性政策和系統日後可能會有所變動。

Google 的全面安全策略包括靜態資料加密，有助於保護客戶資料免受攻擊者侵害。我們會透過一或多項加密機制，將所有 Google 客戶的靜態內容加密，客戶不需要採取任何行動。這份文件說明我們如何對 Google 基礎架構中的靜態資料進行預設加密，以及如何運用這項機制提高客戶內容的安全性。 Google Cloud

本文件適用於目前使用或考慮使用 Google 的安全架構師和安全團隊。本文假設您對加密和密碼編譯基本體有基本瞭解。如要進一步瞭解密碼學，請參閱「現代密碼學簡介」。

靜態資料加密是一種加密機制，可保護儲存在磁碟 (包括固態硬碟) 中的資料，或是備份媒體資料。Google 儲存的所有資料都會在儲存層使用進階加密標準 (AES) 演算法 AES-256 加密。我們使用通用加密編譯程式庫 Tink，其中包含通過 FIPS 140-2 驗證的模組 (名為 BoringCrypto)，為各項 Google Cloud一致導入加密功能。

我們擁有並管理預設靜態資料加密機制中使用的金鑰。如果您使用Google Cloud，Cloud Key Management Service 可讓您建立自己的加密金鑰，用於為資料新增信封加密。您可以使用 Cloud KMS 建立、輪換、追蹤及刪除金鑰。詳情請參閱「Cloud Key Management Service 深入介紹」。

「 Google Cloud」中的金鑰

下表說明 Google Cloud中金鑰的不同屬性。

金鑰類型 Cloud KMS Autokey Cloud KMS 客戶自行管理 (手動) Google-owned and Google-managed encryption key (Google 預設加密機制)

可查看重要中繼資料

是

是

否

金鑰擁有權1

客戶

客戶

Google

可管理2及控管3金鑰

系統會自動建立及指派金鑰。完全支援客戶手動控制。

客戶，僅限手動控制

Google

符合客戶自管金鑰的法規要求

是

是

否

車鑰分享

客戶專屬

客戶專屬

多位客戶的資料通常會以共用金鑰加密金鑰 (KEK) 保護。

金鑰輪替控制項

是

是

否

CMEK 組織政策

是

是

 否

記錄管理和資料存取加密金鑰的活動

是

是

否

透過加密邏輯區隔資料

是

是

否

定價

多樣性

 多樣性

免費

1 金鑰擁有者代表誰擁有金鑰權利。Google 對您擁有的金鑰存取權受到嚴格限制，或完全無法存取。

2 金鑰管理包含下列工作：

  • 建立金鑰。
  • 選擇金鑰的保護層級。
  • 指派金鑰管理權限。
  • 控管金鑰存取權。
  • 控管金鑰使用情形。
  • 設定及修改金鑰的輪替週期，或觸發金鑰輪替。
  • 變更金鑰狀態。
  • 刪除金鑰版本。
  • 刪除金鑰版本、金鑰和金鑰環。

3 控管金鑰是指設定金鑰類型和使用方式的控管機制、偵測差異，並在必要時規劃修正措施。您可以控管金鑰，但將金鑰管理作業委託給第三方。

靜態資料加密如何保護資料

靜態資料加密是更廣泛安全性策略的一部分。加密有以下優點：

  • 確保攻擊者即使取得資料，也必須同時擁有加密金鑰，才能讀取資料。即使攻擊者取得含有客戶資料的儲存裝置，也無法解讀或解密資料。
  • 切除軟硬體堆疊中的較低層級，有助於減少攻擊途徑。
  • 做為「瓶頸」，藉由集中管理加密金鑰，在單一位置強制執行及稽核資料存取權。
  • 有助於縮小攻擊面，因為企業不必保護所有資料，而是可以將保護策略重心放在加密金鑰上。
  • 為客戶提供重要的隱私權機制。靜態資料加密後，系統和工程師對資料的存取權就會受到限制

什麼是客戶資料？

如《Google Cloud 服務條款》所定義，「客戶資料」是指客戶或使用者透過帳戶下的服務提供給 Google 的資料。

客戶內容是指您自行產生或提供給我們的資料，例如儲存在 Cloud Storage bucket、Persistent Disk 磁碟區和 Compute Engine 所用磁碟快照中的資料。本文著重於這類客戶資料的預設靜態資料加密。

客戶中繼資料是與客戶內容相關的資料，包括自動生成專案編號、時間戳記、IP 位址、Cloud Storage 中物件的位元組大小，或 Compute Engine 中的機型。客戶中繼資料的保護程度，足以確保持續運作和效能。本文不著重於中繼資料的保護措施。

客戶內容和客戶中繼資料合稱為客戶資料。

預設靜態資料加密

Google 會透過一或多項加密機制，將儲存在系統中的所有靜態資料加密，您不需要採取任何行動。以下章節說明我們用來加密客戶內容的機制。

加密層

Google 採用多層加密技術來保護資料。使用多層加密技術可增加備援資料保護，並可讓我們根據應用需求選擇最合適的做法。

下圖顯示 Google 正式環境資料中心通常會使用多層加密技術，保護使用者資料。所有使用者資料都採用分散式檔案系統加密或資料庫和檔案儲存空間加密，而 Google 正規作業資料中心的所有資料都採用儲存裝置加密。

多層加密。

基礎架構層加密

Google 的所有儲存系統都採用類似的加密架構，但實作細節因系統而異。資料會拆分為邏輯區塊進行儲存，每個區塊的大小最多可達數 GB。每個區塊都會在儲存層級使用個別的資料加密金鑰 (DEK) 加密：即使兩個區塊屬於同一位客戶或儲存在同一部機器上，也不會有相同的 DEK。

如果資料區塊更新，系統會使用新金鑰加密，而非重複使用現有金鑰。這種資料分區方式 (每個分區使用不同的金鑰) 可將資料加密金鑰遭駭的風險限制在該資料區塊。

Google 會先加密資料，再寫入資料庫儲存系統或硬體磁碟。加密功能是我們所有儲存系統的固有功能，而非事後添加。

每個邏輯資料區塊都有專屬 ID。存取控管清單 (ACL) 有助於確保每個區塊只能由具備授權角色的 Google 服務解密，且這些服務僅在該時間點獲得存取權。這項存取限制有助於防止未經授權存取資料，強化資料安全性和隱私權。

每個區塊都會分散在我們的儲存系統中，並以加密形式複製，用於備份和災難復原。如果攻擊者想存取客戶資料，必須知道並存取兩項資訊：與所需資料對應的所有儲存空間區塊，以及與這些區塊對應的所有加密金鑰。

下圖顯示資料如何上傳到我們的基礎架構，然後拆分成加密區塊進行儲存。

資料上傳方式。

我們採用 AES 演算法加密靜態資料。儲存裝置層級的所有資料都會由 DEK 加密，預設使用 AES-256，但 2015 年前建立的少數永久磁碟使用 AES-128。AES 廣受歡迎，因為 AES-256 和 AES-128 都是美國國家標準暨技術研究院 (NIST) 推薦用於長期儲存的標準，且 AES 通常是客戶法規遵循要求的一部分。

一個邏輯資料區塊可能包含多位客戶的資料。如要透過加密達成邏輯資料區隔，必須啟用 Cloud Key Management Service。

儲存裝置層級的加密機制

除了儲存系統層級加密，系統也會在儲存裝置層級使用 AES-256 加密資料，適用於硬碟 (HDD) 和固態硬碟 (SSD)，並使用個別的裝置層級金鑰 (與用於儲存層級加密資料的金鑰不同)。少數舊版 HDD 則使用 AES-128。Google 使用的 SSD 僅針對使用者資料實作 AES-256。

備份系統的加密機制

備份系統可確保資料在整個備份過程中保持加密狀態。以免明文資料發生不必要的曝光。

此外，備份系統會進一步使用專屬 DEK，獨立加密大多數備份檔案。DEK 是從 Keystore 中儲存的金鑰，以及備份時隨機產生的每個檔案種子衍生而來。備份中的所有中繼資料都會使用另一個 DEK，這個 DEK 也會儲存在 Keystore 中。

靜態資料的 FIPS 法規遵循情況

在正式環境中，Google 使用通過 FIPS 140-2 驗證的加密模組(認證編號 4407)。

金鑰管理

由於 Google 的金鑰數量龐大，且需要低延遲和高可用性，因此 DEK 會儲存在加密資料附近。DEK 會使用金鑰加密金鑰 (KEK) 進行加密 (封裝)，這個技術稱為「信封式加密」。這些 KEK 並非客戶專屬，而是每項服務都有一或多個 KEK。

這些 KEK 會集中儲存在 Keystore 中，這是專門用於儲存金鑰的存放區。KEK 的數量比 DEK 少，且使用中央金鑰存放區，因此能以我們的規模管理資料儲存和加密，並從中央追蹤及控管資料存取權。

在 Google Cloud中，每位客戶都可以擁有共用和非共用資源。舉例來說，Compute Engine 中的共用基礎映像檔就是共用資源。如果是共用資源，多位客戶會參照單一副本，並由單一 DEK 加密。非共用資源會分割成資料區塊，並使用與其他客戶不同的金鑰加密。這些金鑰甚至與保護同一位客戶擁有的其他資料片段的金鑰不同。不過也有例外情況 (例如 Datastore、App Engine 或 Pub/Sub)，多位客戶的資料可能會使用相同的 DEK 加密。

生成 DEK

儲存系統會使用 Google 的通用加密編譯程式庫產生 DEK。一般來說，DEK 會傳送至 Keystore，並以該儲存系統的 KEK 包裝，包裝後的 DEK 會傳回儲存系統，與資料區塊一起保留。儲存系統需要擷取加密資料時，會擷取包裝的 DEK 並傳遞至 Keystore。接著，Keystore 會驗證這項服務是否有權使用 KEK，如果可以，就會解開並將明文 DEK 傳回服務。接著，服務會使用 DEK 將資料區塊解密為明文，並驗證其完整性。

所有 Google Cloud 儲存系統都遵循這項金鑰管理模式，但大多數系統也會實作額外的儲存端 KEK 層級，以建立金鑰階層。這樣一來，系統就能以最高層級的 KEK (儲存在 KeyStore 中) 做為信任根，同時提供低延遲。

產生 KEK

用於加密資料區塊的大多數 KEK 都是在 Keystore 中產生，其餘則是在儲存服務中產生。為求一致，所有 KEK 都是使用 Google 的通用加密編譯程式庫，並透過 Google 建構的隨機號碼產生器 (RNG) 產生。這個 RNG 以 NIST 800-90Ar1 CTR-DRBG 為基礎，會產生 AES-256 KEK。(過去為 AES-128，其中部分金鑰仍可用於解密資料)。

如果是 Intel 和 AMD 處理器，RNG 會從 RDRAND 指令和 Linux 核心的 RNG 播種。Linux 核心的 RNG 則會從多個獨立的熵來源播種，包括 RDRAND 和資料中心環境的熵事件 (例如磁碟搜尋的精細測量結果，以及封包間的抵達時間)。如果是 Arm 處理器，RNG 會從 Linux 核心的 RNG 播種。

DEK 會使用 AES-256 或 AES-128 (視Google Cloud 服務而定) 以 KEK 包裝。我們目前正在將所有Google Cloud 服務的 KEK 升級至 AES-256。

KEK 管理

Keystore 專為管理 KEK 而建。根據設計，儲存系統使用的 KEK 無法從 Keystore 匯出；使用這些金鑰的所有加密和解密作業都必須在 Keystore 中完成。這有助於防止洩漏和濫用，並讓金鑰庫在金鑰使用時建立稽核追蹤記錄。

Keystore 可定期自動輪替 KEK，並使用 Google 的通用加密編譯程式庫產生新金鑰。雖然我們通常只提到單一金鑰，但實際上是指使用金鑰組保護資料：一組金鑰用於加密，一組歷史金鑰用於解密。歷史金鑰數量取決於金鑰輪替時間表。KEK 會備份以用於災難復原，且可無限期復原。

每個金鑰的 Keystore 存取控制清單 (ACL) 會管理 KEK 的使用情形，並採用個別金鑰政策。只有獲得授權的 Google 服務和使用者可以存取金鑰。 系統會追蹤每個需要金鑰的個別作業，因此使用者每次使用金鑰時，系統都會驗證並記錄使用者身分。根據 Google 的整體安全性和隱私權政策，使用者存取的所有資料都可供稽核。

存取加密資料區塊的程序

當 Google 服務存取加密資料區塊時，會發生下列情況：

  1. 這項服務會呼叫儲存系統，取得所需的資料。
  2. 資料儲存系統會找出儲存這筆資料的區塊 (區塊 ID) 和資料的儲存位置。
  3. 儲存系統會針對每個區塊，提取與該區塊一併儲存的包裝 DEK (在某些情況下，這項作業是由服務執行)，並傳送至 Keystore 進行解包裝。
  4. 儲存系統會根據工作 ID 和區塊 ID，驗證指定工作是否可以存取該資料區塊。Keystore 會驗證儲存系統是否有權使用與服務相關聯的 KEK，以及解開特定 DEK。
  5. Keystore 會執行下列其中一項操作：
    • 將解開的 DEK 傳回儲存系統，儲存系統會解密資料區塊，並將其傳遞至服務。
    • 在極少數情況下，會將未包裝的 DEK 傳遞至服務。儲存系統會將加密資料區塊傳遞給服務，服務會解密資料區塊並使用。

專用儲存裝置的程序不同，因為裝置會管理及保護裝置層級的 DEK。

下圖顯示這項程序。如要解密資料區塊，儲存空間服務會呼叫 Keystore，以擷取該資料區塊的未包裝 DEK。

加密資料區塊的程序。

加密金鑰階層結構和信任根

Keystore 會受到名為「Keystore 主金鑰」的根金鑰保護，該金鑰會包裝 Keystore 中的所有 KEK。這個金鑰庫主金鑰為 AES-256，本身儲存在另一個金鑰管理服務中，稱為根金鑰庫。(過去，金鑰庫主金鑰為 AES-128，其中部分金鑰仍可用於解密資料)。為進一步確保安全性，Root Keystore 不會在一般實際執行機器上執行，而只會在每個 Google 資料中心的專用機器上執行。

根 KeyStore 本身也有自己的根金鑰，稱為「根 KeyStore 主金鑰」，同樣是 AES-256，並儲存在對等互連基礎架構中，稱為「根 KeyStore 主金鑰分配器」，可在全球複製這些金鑰。(過去，根金鑰儲存區主金鑰是 AES-128，其中部分金鑰仍可解密資料。)根金鑰儲存庫主金鑰分配器只會將金鑰保留在與根金鑰儲存庫相同的專用電腦上，並使用記錄檔驗證是否正確使用。

啟動新的根金鑰儲存區主金鑰分配器執行個體時，系統會使用已執行的分配器執行個體主機名稱清單進行設定。接著，發布者執行個體可以從其他執行中的執行個體取得根金鑰庫主金鑰。除了「全球可用性和複製」一文所述的災害復原機制外，根金鑰儲存區主金鑰只會存在於少數特別安全機器的 RAM 中。

為因應某個區域中所有根金鑰庫主金鑰發布者執行個體同時重新啟動的情況，根金鑰庫主金鑰也會備份在安全硬體裝置上，這些裝置存放在多個地理位置分散的高度安全區域中的實體保險箱。只有在某個區域的所有發布者執行個體同時停止運作時，才需要這個備份。只有少數 Google 員工可以存取這些保險箱。

下圖顯示加密金鑰階層結構。加密金鑰階層結構會使用 DEK 保護資料區塊，並在 Keystore 中使用 KEK 包裝 DEK，而 KEK 則由 Root Keystore 和根金鑰庫主金鑰發布者保護。

加密金鑰階層結構。

金鑰管理摘要

以下列出 Google 的金鑰管理重點：

  • 資料分為多個區塊，並以 DEK 加密。
  • DEK 以 KEK 加密。
  • KEK 會儲存在 Keystore 中。
  • Keystore 在全球資料中心的多部機器上運作。
  • 金鑰庫金鑰會以金鑰庫主金鑰包裝，並儲存在根金鑰庫中。
  • Root Keystore 的規模遠小於 Keystore，且只在各資料中心的專用機器上執行。
  • 根 KeyStore 金鑰會以根 KeyStore 主金鑰包裝，並儲存在根 KeyStore 主金鑰發布者中。
  • 根金鑰儲存庫主金鑰發布者是一種點對點基礎架構，在全球專用機器的 RAM 中同時執行。每部機器都會從區域中其他執行個體取得金鑰材料。
  • 如果某個區域中的所有發布者執行個體都停止運作，系統會將主金鑰儲存在不同安全硬體中，並存放在 Google 某些地點的實體保險箱中。

全球可用性和複製

無論在哪個層級，高可用性、低延遲和全域金鑰存取權都至關重要。這些特性是 Google 內部金鑰管理服務的必要條件。

因此，Keystore 具備高度擴充性，並在全球資料中心複製了數千次。Keystore 在我們正式環境機群中的一般機器上執行，且 Keystore 執行個體在全球各地執行，以支援 Google 作業。因此，任何單一鍵作業的延遲時間都非常短。

Root Keystore 在每個資料中心內，由多部專門用於資安營運的機器執行。Root Keystore 主金鑰發布者會在這些機器上執行，與 Root Keystore 一對一。Root Keystore 主金鑰發布者會使用八卦通訊協定提供發布機制。在固定時間間隔內，每個經銷商執行個體會隨機挑選其他執行個體來比較金鑰，並協調金鑰版本的所有差異。在這個模型中，沒有任何中央節點是所有基礎架構都依賴的。這種發布方式可讓我們維護及保護重要素材，並確保高可用性。

Google 的通用密碼編譯程式庫

Google 的通用加密編譯程式庫是 Tink，其中整合了通過 FIPS 140-2 驗證的 BoringCrypto 模組。所有 Google 開發人員都能使用 Tink。一致使用通用程式庫，表示只需一個小型密碼專家團隊，即可導入這類受到嚴密控制且經過審查的程式碼，Google 的每個團隊不必獨立開發自己的密碼學。Google 專責安全團隊負責維護所有產品的通用加密程式庫。

Tink 加密程式庫支援多種加密金鑰類型和模式，且會定期接受審查，確保能防範最新的攻擊。

目前，我們使用下列加密演算法，對 DEK 和 KEK 進行靜態資料加密。隨著我們持續提升功能和安全性，這些限制可能會有所變動。

加密基本元素 偏好的通訊協定 其他支援的通訊協定
對稱式加密 AES-GCM (256 位元)
  • AES-CBC 與 AES-CTR (128 與 256 位元)
  • AES-EAX (128 與 256 位元)
對稱簽章 (與上述 AES-CBC 和 AES-CTR 搭配使用，用於驗證) HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

程式庫中還有其他密碼編譯通訊協定，且過去曾支援這些通訊協定，但本表涵蓋 Google 的主要用途。

密碼學研究與創新

為了跟上加密技術的演進，我們有一支世界級的資安工程師團隊，負責追蹤、開發及改進加密技術。我們的工程師會參與標準化程序，並維護廣為使用的加密軟體。我們會定期發布加密領域的研究成果，讓一般大眾等所有人都能從中獲益。

舉例來說，在後量子密碼編譯演算法研究方面，我們正致力於以下領域：

請注意，對稱式加密 (使用 AES-128 以上版本) 仍可抵禦量子攻擊。

後續步驟