本文上次更新於 2024 年 5 月，內容反映截至撰文時的情況。我們會持續改善保護客戶的方式，因此 Google 的安全性政策和系統未來可能會改變。
Google 的全面安全性策略包括靜態資料加密，有助於保護客戶資料免於遭受攻擊。我們會使用一或多項加密機制，將所有 Google 客戶的靜態內容加密，您不需要採取任何行動。這份文件說明我們如何對 Google 基礎架構和 Google Cloud中的靜態資料進行預設加密，以及如何運用這項機制提高客戶內容安全性。
本文適用於目前使用或考慮使用 Google 的安全架構師和安全團隊。本文假定讀者對加密機制和密碼編譯基本功能有初步瞭解。如要進一步瞭解密碼編譯，請參閱《現代密碼學》(Introduction to Modern Cryptography)。
靜態資料加密是一種加密機制，可用來保護儲存於磁碟 (含固態硬碟) 或備份媒體的資料。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 |
客戶 |
客戶 |
|
系統會自動建立及指派金鑰。完全支援客戶手動控制。 |
客戶，僅限手動控制 |
||
支援客戶管理金鑰的法規要求 |
是 |
是 |
否 |
車鑰共用 |
客戶專屬 |
客戶專屬 |
多位客戶的資料通常會受到共用金鑰加密金鑰 (KEK) 保護。 |
金鑰輪替控制項 |
是 |
是 |
|
是 |
是 |
否 | |
是 |
是 |
否 |
|
透過加密進行邏輯資料分離 |
是 |
是 |
|
定價 |
多樣性 | 免費 |
1 金鑰擁有者：表示金鑰的權利持有人。您擁有的金鑰存取權受到嚴格限制，或 Google 無法存取。
2 金鑰管理包括下列工作：
- 建立金鑰。
- 選擇金鑰的保護等級。
- 指派金鑰管理權限。
- 控管金鑰存取權。
- 控管金鑰的使用權限。
- 設定及修改金鑰的輪替週期，或觸發金鑰輪替。
- 變更金鑰狀態。
- 刪除金鑰版本。
3 控管按鍵是指設定按鍵類型和使用方式的控制項、偵測差異，以及視需要規劃修正措施。您可以控管金鑰，但將金鑰管理權委派給第三方。
靜態加密如何保護資料安全
靜態加密是多樣化安全性策略其中的一環。加密有以下優點：
- 確保攻擊者即使手握資料存取權，也必須同時取得加密金鑰，才能讀取資料。即使攻擊者取得含有顧客資料的儲存裝置，也無法瞭解或解密當中的資料。
- 可切除軟硬體堆疊中的較低層級，減少攻擊面積。
- 可做為阻塞點，因為集中管理的加密金鑰會建立單一位置，強制執行資料存取權並進行稽核。
- 有助於縮小攻擊面，因為企業不必保護所有資料，而是將防護策略著重於加密金鑰。
- 為客戶提供重要的隱私權機制。靜態資料加密可限制系統和工程師存取資料的權限
什麼是顧客資料？
如《Google Cloud 服務條款》所定義，「客戶資料」是指客戶或使用者透過帳戶下的服務提供給 Google 的資料。
客戶內容是指您自行產生或提供給我們的資料，例如儲存在 Cloud Storage 值區中的資料、永久磁碟磁碟區，以及 Compute Engine 使用的磁碟快照。本文著重說明這類客戶資料的預設靜態加密。
客戶中繼資料是與客戶內容相關的資料，包括系統自動產生的專案編號、時間戳記、IP 位址、Cloud Storage 物件的位元組大小，或是 Compute Engine 中的機器類型。在不影響當前效能與作業的前提下，Google 會以適當方式保護客戶中繼資料。本文不著重於中繼資料的保護措施。
客戶內容和客戶中繼資料共同構成客戶資料。
預設靜態資料加密
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 只會使用 AES-256 金鑰來加密固態硬碟中的使用者資料。
備份系統的加密機制
我們的備份系統可確保資料在整個備份程序中皆處於已加密狀態，以免明文資料發生不必要的曝光。
此外，備份系統會使用各個檔案專屬的 DEK，進一步將大多數備份檔案個別加密。DEK 是從儲存在 KeyStore 中的金鑰，以及在執行備份作業時為每個檔案隨機產生的種子衍生而來。另一組 DEK 則用於備份中的所有中繼資料 (同樣儲存在 Keystore 中)。
靜態資料的 FIPS 法規遵循情況
在正式環境中，Google 會使用通過 FIPS 140-2 驗證的加密模組(認證編號 4407)。
金鑰管理
由於 Google 擁有大量金鑰，且需提供低延遲和高可用性的服務，因此 DEK 會儲存在加密的資料附近。DEK 會使用「金鑰加密金鑰」(KEK) 進行加密 (或稱為「包裝」)，此方法稱為「信封式加密」。這些 KEK 並非專為客戶而設，而是每項服務都有一或多組 KEK。
這些 KEK 會集中儲存在 Keystore 中，這是專為儲存金鑰而打造的存放區。您只需要使用集中式 Keystore 並搭配少量 KEK (少於 DEK)，就能輕鬆管理 Google 規模的資料儲存與加密作業，同時讓系統從中心點追蹤及控管資料的存取活動。
在 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 則是在資料儲存服務中產生。為保持一致性，系統在產生 KEK 時，都是使用 Google 的通用加密編譯程式庫和 Google 打造的隨機號碼產生器 (RNG)。這個 RNG 是以 NIST 800-90Ar1 CTR-DRBG 為基礎，並會產生 AES-256 KEK。(先前採用的是 AES-128，目前仍有部分 AES-128 金鑰用於資料解密)。
如果是 Intel 和 AMD 處理器，RNG 的種子來源為 RDRAND 指令和 Linux 核心的 RNG。Linux 核心的 RNG 則出自多個獨立的資訊熵來源，包括 RDRAND 和資料中心環境的資訊熵事件 (例如磁碟搜尋與封包抵達間隔時間的精密計算結果)。如果是 Arm 處理器，RNG 的種子來源為 Linux 核心的 RNG。
視Google Cloud 服務而定，DEK 會以採用 AES-256 或 AES-128 標準的 KEK 來包裝。我們目前正努力將Google Cloud 服務的所有 KEK 升級為 AES-256。
KEK 管理
Keystore 專門用於管理 KEK。根據設計，儲存系統使用的 KEK 無法從 KeyStore 匯出，且這類金鑰的所有加密與解密作業都必須在 KeyStore 中完成。這不僅能預防資料外洩與濫用，也能讓 Keystore 在有人使用金鑰時產生稽核追蹤記錄。
Keystore 會使用 Google 的通用密碼編譯程式庫來產生新的金鑰，並按照固定的時間間隔自動輪替 KEK。雖然我們通常只會說「一組」金鑰，但實際上是指資料會受到眾多金鑰的保護：一組現有金鑰用於進行加密，多組舊有金鑰則用於解密。歷史記錄金鑰的數量取決於金鑰輪替排程。系統會基於災難復原的目的而備份 KEK，這類金鑰沒有復原期限。
Keystore 中的 ACL 會依據個別金鑰政策管理每一組 KEK 的使用情況。只有獲得授權的 Google 服務與使用者能獲准存取金鑰。系統會依據需要使用金鑰的個別作業，分別追蹤每一組金鑰的使用情況。因此，每當使用者使用金鑰時，系統都會驗證該組金鑰並記錄使用情況。所有使用者資料存取活動都涵蓋在 Google 的整體安全性與隱私權政策中，因此皆可稽核。
存取加密資料區塊的程序
Google 服務存取加密資料區塊時，會發生下列情況：
- 服務會呼叫儲存系統，以便取得所需資料。
- 資料儲存系統會找出儲存這筆資料的區塊 (區塊 ID) 和資料的儲存位置。
- 針對每個區塊，資料儲存系統會提取與該區塊一同儲存的已包裝 DEK (在某些狀況下，這項程序是由服務進行)，然後傳送至 Keystore 解開包裝。
- 儲存系統會透過工作 ID 和區塊 ID，確認找到的工作能夠存取該資料區塊。Keystore 會驗證儲存系統是否有權使用與服務相關聯的 KEK，以及解開該組 DEK 的包裝。
- Keystore 會執行下列其中一項作業：
- 將解開包裝的 DEK 傳回儲存系統，儲存系統會將資料區塊解密，並傳送到服務。
- 在極少數情況下，會將已解開包裝的 DEK 傳送至服務。儲存系統會將加密的資料區塊傳送至服務，服務再將資料區塊解密並加以使用。
如果是在專屬儲存裝置中，這項程序會與上述情況不同，因為裝置層級的 DEK 是由裝置負責管理及保護。
下圖呈現此程序。如要解密資料區塊，儲存服務會呼叫 Keystore，以擷取該資料區塊的未封裝 DEK。
加密金鑰階層與信任根
Keystore 由名為「Keystore 主金鑰」的根金鑰保護，這種金鑰會包裝 Keystore 中的所有 KEK。這類 KeyStore 主金鑰採用 AES-256 標準，且金鑰本身是儲存在另一項名為「Root Keystore」的金鑰管理服務中。(過去金鑰儲存區主金鑰為 AES-128，目前仍有部分金鑰用於資料解密)。為進一步提升安全性，根金鑰儲存庫並非在一般的實際工作環境機器中運作，而是僅在各間 Google 資料中心內的專屬機器中運作。
根金鑰儲存區也有專屬的根金鑰，稱為「根金鑰儲存區主金鑰」。這種金鑰同樣採用 AES-256 標準，並會儲存在名為「根金鑰儲存區主金鑰發布器」的點對點基礎架構中，而這個基礎架構會在全球範圍內複製這些金鑰。(過去，根金鑰儲存區主金鑰是 AES-128，目前仍有部分這類金鑰用於資料解密)。「根金鑰儲存庫主金鑰發布器」只會將金鑰保留在根金鑰儲存庫所在的專屬機器 RAM 中，並使用記錄功能驗證使用情形是否適當。
新的「根金鑰儲存區主金鑰發布器」執行個體啟動時，會以一組主機名稱進行設定，這組主機上已有運作中的發布器執行個體。接著，發布器執行個體就能從其他運作中的執行個體取得根金鑰儲存庫主金鑰。除了「全球可用性和複製」一節所述的災難復原機制以外，根金鑰儲存區主金鑰僅儲存於少數機器的 RAM 之中，且這些機器受到特殊保護。
為了因應某個區域中，根金鑰儲存庫主金鑰發布器的所有執行個體同時重新啟動的狀況，Google 也會將根金鑰儲存庫主金鑰備份到存放於實體保險箱的安全硬體裝置，並將這些保險箱安放在多個地理位置分散且受到嚴密防護的據點。只有在某個區域的所有發布器執行個體同時暫停服務時，才會需要這個備份。只有少數 Google 員工可以接觸這些保險箱。
下圖顯示加密金鑰階層。加密金鑰階層會以 DEK 保護資料區塊，並在 Keystore 中以 KEK 加以包裝，再由 Root Keystore 與「Root Keystore 主金鑰發布器」保護 Keystore。
金鑰管理摘要
以下是 Google 的金鑰管理摘要：
- 資料分為多個區塊，並以 DEK 加密。
- DEK 以 KEK 加密。
- KEK 儲存在 Keystore 中。
- Keystore 在世界各地的資料中心內的多部機器上運作。
- Keystore 金鑰是以 Keystore 主金鑰來包裝，Keystore 主金鑰則儲存在 Root Keystore 中。
- Root Keystore 遠小於 Keystore，而且只會在各間資料中心的專屬機器中運作。
- 根 KeyStore 金鑰是以根 KeyStore 主金鑰來包裝，根 KeyStore 主金鑰則儲存在根 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 搭配使用以進行驗證) | HMAC-SHA256 |
|
程式庫中還有過去曾支援的其他密碼編譯通訊協定，但這份表格僅列舉 Google 目前常用的通訊協定。
密碼編譯領域中的研究與創新
為了與加密技術的演進保持同步，我們成立了世界級的安全性工程師團隊，其任務是關注、開發及改善加密技術。我們的工程師會參與標準化程序，並維護廣為使用的加密軟體。我們會定期發布 Google 在加密技術領域中的研究成果，讓所有同業人士和一般大眾都能從我們累積的知識中獲益。
舉例來說，在後量子密碼編譯研究方面，我們著重於下列領域：
標準化：我們共同設計了無狀態的雜湊式數位簽章機制，並將其標準化為 FIPS 205。我們是國際標準化組織 (ISO) 標準的編輯者，負責後量子密碼編譯雜湊式簽章，並在 IETF 協助制定雜湊式簽章的狀態管理指南。
啟用：我們已在內部傳輸層安全通訊協定中推出後量子密碼編譯。我們已在 Chrome 中啟用後量子密碼編譯支援功能。我們在 Tink 密碼編譯程式庫中新增了幾種後量子密碼編譯演算法。這項程式碼仍在實驗階段，旨在協助社群瞭解各種方法。
出版品：我們在《Nature》上發布了「Transitioning organizations to post-quantum cryptography」。這份報告概略說明後量子密碼編譯遷移作業的挑戰。我們也發布了研究論文，說明如何在安全金鑰中導入後量子密碼技術。
請注意，對稱式加密 (使用 AES-128 以上版本) 仍可抵禦量子攻擊。
後續步驟
如要瞭解如何在Google Cloud中使用自己的加密金鑰，請參閱客戶自行管理的加密金鑰 (CMEK)。
如需安全性的一般資訊，請參閱 Google Cloud 網站 Google Cloud 的「安全性」專區。
如需法規遵循與法規遵循認證的相關資訊，請參閱 Google Cloud 網站 Google Cloud 的「法規遵循」專區，當中也提供 Google 的 SOC3 公開稽核報告。
如需 Google Workspace 加密與金鑰管理機制的相關資訊，請參閱「Google Workspace 如何使用加密技術保護您的資料」，這份文件涵蓋的內容與本文大致相同，但僅著重於 Google Workspace。