預設靜態資料加密

本文上次更新於 2024 年 5 月，內容反映截至撰文時的情況。我們會持續改善客戶保護措施，因此 Google 的安全性政策和系統未來可能會改變。

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、永久磁碟磁碟區，以及 Compute Engine 使用的磁碟快照中的資料。本文著重於這類客戶資料的預設靜態資料加密。

顧客中繼資料是顧客內容的相關資料，包括系統自動產生的專案編號、時間戳記、IP 位址、Cloud Storage 物件的位元組大小，或是 Compute Engine 中的機型。我們會以合理的程度保護客戶中繼資料，確保持續的效能和作業。本文並未著重於中繼資料的保護措施。

客戶內容和客戶中繼資料共同構成客戶資料。

預設靜態資料加密

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

加密層

Google 採用多層加密技術來保護資料。使用多層加密機制可提供多餘的資料保護，並讓我們根據應用程式需求選擇最佳做法。

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

多層加密。

基礎架構層級的加密機制

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

如果資料區塊經過更新，則會以新的加密金鑰進行加密處理，而非重複使用現有的金鑰。這種資料分區方法讓每一區使用不同的金鑰，換句話說，即使資料加密金鑰遭駭，影響範圍也只會限於對應的資料區塊。

Google 會先加密資料，再將資料寫入資料庫儲存系統或硬體磁碟。加密是所有儲存系統的固有機制，並非系統建立完成後才附加的功能。

每個邏輯資料區塊都具備一組專屬的 ID。存取控制清單 (ACL) 可確保各區塊都僅能由已獲授權的角色透過 Google 服務進行解密處理，且這類角色僅會在解密當下獲得資料存取權限。這項存取限制有助於防止未經授權存取資料，進而提升資料安全性及隱私權。

各個區塊會散布於我們的儲存系統中，並在已加密的狀態下進行複製，以便用於備份和災難復原。如有任何攻擊者想要存取客戶資料，他們必須知道並能取得兩項資訊：對應至所需資料的每個儲存區塊，以及與這些區塊相對應的加密金鑰。

下圖顯示資料如何上傳至基礎架構，然後拆分成加密區塊儲存。

資料上傳方式。

我們使用 AES 演算法加密靜態資料。根據預設，系統會以採用 AES-256 標準的 DEK，在儲存空間層級加密所有資料，不過少數在 2015 年以前建立的永久磁碟除外，系統會以 AES-128 進行加密。AES 廣為使用，是因為 美國國家標準與技術研究院 (NIST) 建議長期儲存時使用 AES-256 和 AES-128，且 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，且使用中央 Keystore，可讓我們以可管理的方式儲存及加密資料，並從中央位置追蹤及控管資料存取權。

在 Google Cloud中，每位客戶都可以有共用和非共用資源。 共用資源的例子是 Compute Engine 中的共用基本映像檔。如果是共用資源，多位客戶會參照單一副本，並由單一 DEK 加密。非共用資源會分割成資料區塊，並使用與其他客戶不同的金鑰加密。即便是同一位客戶所擁有的同一筆資料，保護各部分內容的金鑰也都不相同。例外狀況包括 Datastore、App Engine 或 Pub/Sub，在這些服務中，多位客戶的資料可能會以同一組 DEK 加密。

生成 DEK

儲存系統會使用 Google 的通用加密編譯程式庫產生 DEK。一般來說，DEK 會傳送至 Keystore，並以該儲存系統的 KEK 包裝，包裝後的 DEK 會傳回儲存系統，與資料區塊一起保留。儲存系統需要擷取加密資料時，會擷取經過包裝的 DEK 並傳送至 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。

視Google Cloud 服務而定，DEK 會以採用 AES-256 或 AES-128 標準的 KEK 來包裝。我們目前正努力將所有服務的 KEK 升級為 AES-256。Google Cloud

KEK 管理

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

Keystore 會使用 Google 的通用密碼編譯程式庫來產生新的金鑰，並按照固定的時間間隔自動輪替 KEK。雖然我們經常只提及單一金鑰，但是我們真正的意思是資料的保護措施是以金鑰組合為主，其中有一個金鑰用於加密，另有一組歷史記錄金鑰則用於解密。歷史記錄金鑰的數量取決於金鑰輪替排程。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 標準，且金鑰本身是儲存在另一項名為「Root Keystore」的金鑰管理服務中。(過去，金鑰儲存區主金鑰為 AES-128，其中部分金鑰仍可解密資料。)為進一步提升安全性，Root Keystore 並非在一般的實際工作環境機器中運作，而是僅在各座 Google 資料中心內的專屬機器中運作。

Root Keystore 本身也有自己的根金鑰，稱為「root keystore master key」，同樣採用 AES-256 標準，並儲存在點對點基礎架構中，也就是「root keystore master key distributor」，這項基礎架構會在全球複製這些金鑰。(過去，根金鑰儲存區主金鑰是 AES-128，其中部分金鑰仍有效，可用於解密資料)。根金鑰儲存庫主金鑰分配器只會將金鑰保留在與根金鑰儲存庫相同的專用機器的 RAM 中，並使用記錄檔驗證是否正確使用。

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

為解決某個區域中，所有根金鑰儲存區主金鑰分配器執行個體同時重新啟動的情況，根金鑰儲存區主金鑰也會備份到安全硬體裝置，並存放在多個地理位置分散區域的高度安全區域中。只有在某個區域的所有分配器執行個體同時停止運作時，才需要這個備份。只有少數 Google 員工可以接觸這些保險箱。

下圖顯示加密金鑰階層。加密金鑰階層以 DEK 保護資料區塊，並在 Keystore 中以 KEK 加以包裝，再由 Root Keystore 與「Root Keystore 主金鑰發布器」保護 Keystore。

加密金鑰階層結構。

金鑰管理摘要

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

  • 資料分為多個區塊，並以 DEK 加密。
  • DEK 以 KEK 加密。
  • KEK 儲存在 Keystore 中。
  • Keystore 會在全球資料中心的多部機器上執行。
  • 金鑰庫金鑰是以金鑰庫主金鑰來包裝，金鑰庫主金鑰則儲存在 Root Keystore 中。
  • 根 Keystore 遠小於 Keystore，且只會在每一間資料中心的專屬機器上運作。
  • Root Keystore 金鑰是以 Root Keystore 主金鑰來包裝，Root Keystore 主金鑰則儲存在 Root Keystore 主金鑰發布器中。
  • Root Keystore 主金鑰發布器是一種點對點基礎架構，在世界各地的專屬機器 RAM 中並行運作。每部機器都會從該區域的其他執行個體取得金鑰內容。
  • 如果某個區域的發布器執行個體全部停止運作，我們還有儲存於其他安全硬體的主金鑰，這些安全硬體皆會存放於 Google 限定據點的實體保險箱內。

全球可用性和備援能力

在每個層級，高可用性、低延遲和金鑰的全球存取權都至關重要。Google 各項服務都必須具備這些特性，才能使用金鑰管理服務。

因此，Keystore 具有高度擴充性，並在全球資料中心複製了數千次。這項服務在生產機群的常規機器上執行，Keystore 執行個體則在全球各地運作，支援 Google 營運。因此，任一金鑰作業的延遲都非常低。

根金鑰儲存區是在各資料中心內專門用於資安營運的數部機器中運作。「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 以上版本) 仍可抵禦量子攻擊。

後續步驟