Google Cloud 靜態資料加密

本文撰寫於 2020 年 7 月,所有資訊皆以當時情況為依據。另外,我們會持續改善保護客戶的方式,因此 Google Cloud 的安全性政策和系統未來可能會改變。

「播放」按鈕

Google Cloud 靜態資料加密

資訊長層級摘要

  • Google 採用多層式加密技術,可妥善保護儲存在 Google Cloud 產品中的靜態客戶資料。
  • Google Cloud 會透過一或多項加密機制,將儲存在系統中的所有靜態客戶內容加密,客戶不需要採取任何行動。
  • 系統會將儲存的資料分割為多個區塊,每個區塊都會以專屬的資料加密金鑰進行加密。這些資料加密金鑰會與資料儲存在同一處,並以「金鑰加密金鑰」進行加密 (又稱「包裝」)。金鑰加密金鑰是 Google 金鑰管理服務內的專用金鑰,這類金鑰都會儲存於此項集中式管理服務。Google 的金鑰管理服務支援備援功能,且服務範圍遍及世界各個角落。
  • 系統會使用 AES256 金鑰,在儲存空間層級將存放於 Google Cloud Platform 的所有資料加密,不過少數在 2015 年以前建立的永久磁碟除外,系統會以 AES128 進行加密。
  • Google 使用的加密編譯資料庫是常見的 Tink,幾乎所有 Google Cloud 產品都是透過這個資料庫加密資料,而且當中包含我們已通過 FIPS 140-2 驗證的模組「BoringCrypto」。只要一律採用相同的通用資料庫,您僅須設立小型加密編譯團隊,即可實作及維護這組受到嚴密控管與審查的程式碼。

簡介

個人和公司在選擇公用雲端廠商時,安全性往往是一項決定性的因素。對 Google 而言,安全性也是我們的優先要務。無論您的資料是在網際網路上傳輸、在我們的資料中心之間移動,或儲存於我們的伺服器上,我們在安全性與隱私權方面都會特別慎重,努力不懈保護您的資料。

我們的安全性策略涵蓋範圍相當完整,但核心在於對傳輸中的資料和靜態資料進行加密,確保只有對加密金鑰具備已稽核存取權的服務和已取得授權的角色才能存取資料。本文說明 Google 如何對 Google Cloud 中的靜態資料進行加密,以及我們如何運用這項機制讓您的資訊更加安全。

本文的目標讀者為正在使用或考慮使用 Google Cloud 的資訊安全長與資訊安全作業團隊。除了簡介以外,本文假定讀者對於加密機制與密碼編譯基元有基本的瞭解。

什麼是加密機制?

加密機制是一項程序,其作用是將人類可以解讀的輸入資料 (通常稱為「明文」) 轉換並輸出為幾乎不含或完全沒有這些明文相關資訊的內容 (通常稱為「密文」)。加密演算法是公開的,例如「進階加密標準」(AES),但是加密作業的執行是採用秘密的金鑰。如要將密文解密回到原始型態,則必須使用金鑰。Google 使用加密機制保護資料時,通常會搭配完整性保護功能;即便使用者有權限存取密文,如果不知道金鑰也無法瞭解密文的內容或加以修改。如要進一步瞭解加密編譯機制,請參閱《現代密碼學》(Introduction to Modern Cryptography)。

這份白皮書著重於靜態資料加密。「靜態資料加密」是指一種加密機制,可用來保護儲存於磁碟 (含固態硬碟) 或備份媒體的資料。如要瞭解如何加密傳輸中的資料,請參閱 Google Cloud 中的傳輸加密白皮書。

加密機制為什麼有助於保護客戶資料

加密機制是多樣化安全性策略其中的一環。這項機制可增添一層深度防護,讓我們能夠妥善保護客戶資料。有了加密機制,即便資料意外落入攻擊者手中,只要他們沒有加密金鑰就無法存取資料。也就是說,儘管攻擊者取得了含有您資料的儲存裝置,他們仍無法查看或解密當中的資料。

靜態資料加密機制可有效「切除」軟硬體堆疊中的較低層級,因此能夠減少攻擊面積。即使攻擊者透過實際取得裝置或其他方式入侵這些較低層級,只要已採用適當的加密機制,裝置上的資料就不會遭駭。加密機制也可以用來當做「阻塞點」,透過集中管理加密金鑰的方式,在單一位置執行及稽核資料存取權限。

加密是 Google 確保客戶資料隱私權的重要機制,可讓系統控管資料來執行備份等作業,並方便工程師支援我們的基礎架構,而無須向他們提供內容存取權限。

何謂客戶資料

依據 Google Cloud 服務條款的定義,「客戶資料」是指 Google Cloud 客戶 (或按照這類使用者的指示) 透過其帳戶使用 Google Cloud 服務,因而直接或間接提供給 Google 的內容。客戶資料包括客戶內容與客戶中繼資料。

「客戶內容」是 Google Cloud 客戶自行產生或提供給 Google 的資料,例如儲存在 Cloud Storage 中的資料、Compute Engine 使用的磁碟快照,以及身分與存取權管理政策。靜態客戶內容加密是這份白皮書的重點。

「客戶中繼資料」構成客戶資料的其餘部分,是指無法分類為客戶內容的所有資料,當中包含系統自動產生的專案編號、時間戳記、IP 位址、Cloud Storage 物件的位元組大小,或是 Compute Engine 中的機器類型。在兼顧當前效能與作業的前提下,Google 會為中繼資料提供合理程度的保護。

Google 的預設加密機制

靜態資料加密

Google Cloud 會透過一或多項加密機制,將儲存在系統中的所有靜態客戶內容加密,客戶不需要採取任何行動。

加密層

Google 採用多層式加密技術來保護資料,這種多層式加密機制可提供備援式資料保護,讓我們能夠依據應用程式的需求採取最適當的做法。

加密層圖表

圖 1:我們採用多層式加密技術來保護儲存在 Google Cloud 中的資料。幾乎所有檔案都採用儲存裝置加密機制,並搭配分散式檔案系統加密機制或資料庫與檔案儲存空間加密機制。

儲存系統層級的加密機制

如想具體瞭解 Cloud Storage 加密機制如何運作,您必須先認識 Google 採用的客戶資料儲存方法。我們會將資料分割為多個不到一個檔案的區塊,以利儲存。每個區塊的大小可達數 GB。系統會於儲存空間層級,使用個別的加密金鑰來加密各個區塊。兩個不同的區塊不會共用同一組加密金鑰,即便這兩個區塊是同一位客戶所擁有、儲存在同一部機器中,或是隸屬於同一個 Cloud Storage 物件也不例外1。如果資料區塊經過更新,則會以新的加密金鑰進行加密處理,而非重複使用現有的金鑰。這種資料分區方法讓每一區使用不同的金鑰,換句話說,即使資料加密金鑰遭駭,影響範圍也只會限於對應的資料區塊。

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

每個資料區塊都具備一組專屬的 ID。存取控制清單 (ACL) 可確保各區塊都僅能由已獲授權的角色透過 Google 服務進行解密處理,且這類角色僅會在解密當下獲得資料存取權限。這樣一來,您就能預防未經授權的資料存取活動,進而提升資料安全性與隱私權。

各個區塊會散布於 Google 的儲存系統中,並在已加密的狀態下進行複製,以便用於備份和災難復原。如有任何惡意人士想要存取客戶資料,他們就必須知道且能夠存取 (1) 對應至所需資料的每個儲存區塊,以及 (2) 與這些區塊相對應的加密金鑰。

「儲存在加密區塊中的資料」圖片

圖 2:Google 系統中的資料會拆分為多個經過加密處理的區塊,以便儲存。

Google 會使用進階加密標準 (AES) 演算法將靜態資料加密。根據預設,系統是以 AES256 金鑰在儲存空間層級加密所有資料,不過少數在 2015 年以前建立的永久磁碟除外,系統會以 AES128 進行加密。AES 的應用範圍相當廣泛,因為 (1) AES256 與 AES128 均獲美國國家標準暨技術研究院 (National Institute of Standards and Technology,簡稱「NIST」) 推薦用於長期儲存 (截至 2019 年 3 月),以及 (2) 客戶法規遵循要求經常包含 AES。

幾乎在所有情況下,儲存於 Cloud Storage 的資料都是在 Galois/計數器模式 (GCM) 中以 AES 進行儲存空間層級加密。在特定情況下,AES 會用於含有雜湊訊息驗證碼 (HMAC) 的加密區塊鏈結 (CBC) 模式,以便進行驗證。以某些複製的檔案來說,AES 則是用於含有 HMAC 的計數器 (CTR) 模式。如要進一步瞭解演算法,請參閱本文後續段落。在其他 Google Cloud 產品/服務中,AES 用於多種模式。

儲存裝置層級的加密機制

除了上述的儲存系統層級加密之外,在多數情況下,硬碟 (HDD) 和固態硬碟 (SSD) 中的資料也會在儲存裝置層級以 AES256 金鑰進行加密。不過,系統此時使用的獨立裝置層級金鑰與用來加密儲存空間層級資料的金鑰不同。以少數舊版 HDD 來說,系統則會使用 AES128 金鑰。Google Cloud 只會使用 AES256 金鑰來加密固態硬碟中的使用者資料。

備份系統的加密機制

Google 的備份系統可確保資料在整個備份程序中皆處於已加密狀態,以免明文資料發生不必要的曝光。

另外,我們的備份系統會使用各個檔案專屬的資料加密金鑰 (DEK),以及在執行備份作業時為每個檔案隨機產生的種子,進一步將所有備份檔案個別加密。前述的 DEK 是從儲存在 Google 金鑰管理服務 (KMS) 中的金鑰衍生而來,另一組 DEK 則用於備份中的所有中繼資料 (同樣儲存在 Google 的 KMS 中)。如要進一步瞭解金鑰的管理方式,請參閱後續段落

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

在實際工作環境中,Google Cloud 會使用已通過 FIPS 140-2 驗證的加密模組 (認證編號 3318)。

金鑰管理

資料加密金鑰、金鑰加密金鑰,以及 Google 的金鑰管理服務

用來加密區塊中資料的金鑰,稱為「資料加密金鑰」(DEK)。由於 Google 擁有大量金鑰,且需提供低延遲和高可用性的服務,這些金鑰會儲存在所加密的資料附近。這些 DEK 會以「金鑰加密金鑰」(KEK) 進行加密 (又稱「包裝」)。每項 Google Cloud 服務都有一或多個 KEK。這些 KEK 會集中儲存在 Google 的「金鑰管理服務」(KMS) 中,這是我們專為儲存金鑰而打造的存放區。您只需要使用集中式金鑰管理服務並搭配少量 KEK (少於 DEK),就能輕鬆管理 Google 規模的資料儲存與加密作業,同時讓系統從中心點追蹤及控管資料的存取活動。

我們會將每位 Google Cloud 客戶的所有非共用資源2 分割為多個資料區塊,並以客戶專屬的金鑰進行加密3。即便是同一位客戶所擁有的同一筆資料,保護各部分內容的 DEK 也都不相同。

系統透過採用 Google 通用密碼編譯程式庫的儲存系統產生 DEK 之後,會將其傳送至 KMS,並使用該儲存系統的 KEK 加以包裝。接著,系統會將包裝完成的 DEK 傳回儲存系統,與資料區塊一併保存。需要擷取加密資料時,儲存系統會擷取經過包裝的 DEK 並傳送至 KMS。接著,KMS 會驗證該項服務是否已取得使用 KEK 的權限。如果驗證成功,KMS 就會解開包裝並將明文 DEK 傳回服務。最後,服務會透過 DEK 將資料區塊解密為明文並驗證完整性。

多數用於加密資料區塊的 KEK 都是在 KMS 中產生,其餘 KEK 則是在資料儲存服務中產生。為保持一致性,系統在產生 KEK 時,都是使用 Google 的通用加密編譯程式庫和 Google 打造的隨機號碼產生器 (RNG)。這個 RNG 是以 NIST 800-90Ar1 CTR-DRBG 為基礎,並會產生 AES256 KEK4。這個 RNG 的種子來源為 Linux 核心的 RNG,後者則出自多個獨立的資訊熵,當中包含資料中心環境內的熵事件,例如磁碟搜尋的精細測量結果與封包抵達間隔時間,以及 Ivy Bridge 與較新款 CPU 提供的 Intel RDRAND 指令 (若有)。

如上文中所述,儲存於 Google Cloud 的資料是以採用 AES256 或 AES128 的 DEK 進行加密。另外,Compute Engine 永久磁碟中的所有新資料則是以 AES256 金鑰進行加密。視 Google Cloud 服務而定,DEK 會以採用 AES256 或 AES128 的 KEK 來包裝。以現階段而言,我們正在嘗試將 Cloud 服務的所有 KEK 升級為 AES256 金鑰。

Google 的 KMS 專門用於管理 KEK,且設計時便已考量到安全性。KEK 無法從 Google 的 KMS 中匯出,而且這類金鑰的所有加密與解密作業都必須在 KMS 中完成,這樣的設計不僅可以預防資料外洩與濫用,也能讓 KMS 在有人使用金鑰時產生並稽核追蹤記錄。

KMS 會使用 Google 的通用密碼編譯程式庫來產生新的金鑰,並按照固定的時間間隔自動輪替 KEK。雖然我們通常只會說「一組」金鑰,但實際上是指資料會受到眾多金鑰的保護:一組現有金鑰用於進行加密,多組舊有金鑰則用於解密 (金鑰數量視「金鑰輪替時間表」而定)。KEK 的實際輪替時間表因服務而異,但標準的輪替期間是 90 天。Cloud Storage 每 90 天都會輪替一次 KEK,最多可以儲存 20 個版本,至少每隔 5 年就必須重新將資料加密 (雖然資料重新加密的次數其實更頻繁)。系統會基於災難復原的目的而備份 KMS 保管的金鑰,這類金鑰可以無限復原。

KMS 中的存取控制清單 (ACL) 會依據個別金鑰政策管理每一組 KEK 的使用情況。只有獲得授權的 Google 服務與使用者能獲准存取金鑰。系統會依據需要使用金鑰的個別作業,分別追蹤每一組金鑰的使用情況。因此,每當有人使用金鑰時,系統都會驗證該組金鑰並記錄使用情況。所有人為資料存取活動都涵蓋在 Google 的整體安全性與隱私權政策中,因此皆可稽核。

Google Cloud 的服務存取經過加密的資料區塊時,會發生下列情況:

  1. 服務會呼叫儲存系統,以便取得所需資料。
  2. 資料儲存系統會找出儲存這筆資料的區塊 (區塊 ID) 和資料的儲存位置。
  3. 針對每個區塊,資料儲存系統會提取與該區塊一同儲存的已包裝 DEK (在某些狀況下,這項程序是由服務進行),然後傳送至 KMS 解開包裝。
  4. 儲存系統會透過工作 ID 和區塊 ID,確認找到的工作能夠存取該資料區塊。同時,KMS 也會驗證資料儲存系統,是否有權使用與服務相關聯的 KEK 及解開該組 DEK 的包裝。
  5. KMS 會執行下列其中一項作業:
    • 將已解開包裝的 DEK 傳回資料儲存系統,系統會將資料區塊解密並傳送至服務。或者,在極少數情況下,採取下列做法。
    • 將已解開包裝的 DEK 傳送至服務,資料儲存系統將已加密的資料區塊傳送至服務,服務再將資料區塊解密並加以使用。

如果是在本機 SSD 等專屬儲存裝置中,這項程序會與上述情況不同,因為裝置層級的 DEK 是由裝置負責管理及保護。

資料區塊解密圖片

圖 3:將資料區塊解密時,資料儲存服務會呼叫 Google 的金鑰管理服務 (KMS),以便擷取該資料區塊已解開包裝的資料加密金鑰 (DEK)。

加密金鑰階層與信任根

Google 的 KMS 由名為「KMS 主金鑰」的根金鑰保護,這種金鑰會包裝 KMS 中的所有 KEK。這類 KMS 主金鑰採用 AES2564 標準,且金鑰本身是儲存在另一項名為「Root KMS」的金鑰管理服務中。相較之下,Root KMS 儲存的金鑰數量相當少,大約只有十二組。另外,Root KMS 並非在一般的實際工作環境機器中運作,而是僅在各間 Google 資料中心內的專屬機器中運作,因此可以進一步提升安全性。

Root KMS 也有專屬的根金鑰,稱為「Root KMS 主金鑰」。這種金鑰同樣採用 AES2564 標準,並會儲存在名為「Root KMS 主金鑰發布器」的點對點基礎架構中,而這個基礎架構會在全球範圍內複製這些金鑰。「Root KMS 主金鑰發布器」只會將金鑰保留在 Root KMS 所在的專屬機器 RAM 中,並使用記錄功能驗證使用情形是否適當。一個「Root KMS 主金鑰發布器」執行個體就能處理所有 Root KMS 執行個體的作業 (我們仍在逐步提高「Root KMS 主金鑰發布器」的使用率,希望能夠取代採用類似運作模式的非點對點系統)。

新的「Root KMS 主金鑰發布器」執行個體啟動時,會設有一組主機名稱,這組主機中已有運作中的發布器執行個體。接著,發布器執行個體就能從其他運作中的執行個體取得 Root KMS 主金鑰。除了下述的災難復原機制以外,Root KMS 主金鑰僅儲存於少數機器的 RAM 之中,且這些機器受到特殊保護。

為了因應「Root KMS 主金鑰發布器」所有執行個體同時重新啟動的狀況,Google 也會將 Root KMS 主金鑰備份到存放於實體保險箱的安全硬體裝置,並將這些保險箱安放在兩個不同位置且受到嚴密防護的 Google 據點。只有在所有發布器執行個體同時暫停服務 (例如全球性的重新啟動) 時,才會需要這個備份。能夠接觸這些保險箱的 Google 員工,全球只有不到 20 位。

「Google 加密階層」圖片

圖 4:加密金鑰階層以 DEK 保護資料區塊,並在 KMS 中以 KEK 加以包裝,再由 Root KMS 與「Root KMS 主金鑰發布器」保護 KMS。

摘要:

  • 資料分成區塊,並以 DEK 加密
  • DEK 以 KEK 加密
  • KEK 儲存在 KMS 中
  • KMS 在世界各地資料中心內的多部機器中運作
    • KMS 金鑰是以 KMS 主金鑰來包裝,KMS 主金鑰則儲存在 Root KMS 中
  • Root KMS 遠小於 KMS,而且只會在各間資料中心的專屬機器中運作
    • Root KMS 金鑰是以 Root KMS 主金鑰來包裝,Root KMS 主金鑰則儲存在「Root KMS 主金鑰發布器」中
  • 「Root KMS 主金鑰發布器」是一種點對點基礎架構,在世界各地的專屬機器 RAM 中並行執行。每部機器都會從其他運作中的執行個體取得金鑰內容
    • 如果「發布器」的所有執行個體均停止提供服務 (全部停機),我們還有儲存於其他安全硬體的主金鑰,這些安全硬體皆會存放於 Google 限定據點的實體保險箱內
    • 我們正在提高「Root KMS 主金鑰發布器」的使用率,希望能夠取代採用類似運作模式的非點對點系統

廣及全球的可用性與備援能力

在每個層級中,高可用性、低延遲,以及全球範圍的金鑰存取權限都至關重要。如要讓客戶在所有 Google 產品中都能使用金鑰管理服務,這些特性就必不可少。

基於上述原因,我們打造的 KMS 不僅具備高擴充性,也會在 Google 遍布全球的資料中心內複製數千次。KMS 是在實際工作環境中的一般 Google 機器中運作,其執行個體則遍布全球,以便支援各種 Google Cloud 作業。因此,任一金鑰作業的延遲都非常低。

Root KMS 是在各間資料中心內專門用於安全性操作的數部機器中運作。「Root KMS 主金鑰發布器」也是在這組機器中運作,與 Root KMS 呈現一對一的對應關係。「Root KMS 主金鑰發布器」可透過訊息傳遞通訊協定提供發布機制。發布器的每個執行個體每隔一段固定時間即會隨機挑選另一個執行個體來比對金鑰,並核對金鑰版本中的任何差異。在這個模式下,系統不會建立所有 Google 基礎架構共用的中心節點。這樣一來,Google 就能維護及保護具備高可用性的金鑰內容。

Google 的通用加密編譯資料庫

Google 的通用加密編譯資料庫是 Tink5,當中包含已通過 FIPS 140-2 驗證的 BoringCrypto6 模組。

所有 Google 開發人員都能使用 Tink。只要一律採用相同的通用資料庫,您僅須設立小型加密編譯團隊,即可實作這組受到嚴密控管與審查的程式碼,因此 Google 的各個團隊不需要自行實作加密編譯機制。專責的 Google 安全性團隊會維護這個通用的加密編譯資料庫,以供所有產品使用。

Tink 加密程式庫支援多種加密金鑰類型與模式,這些類型與模式會定期接受審查,以便確保能夠因應最新型的攻擊。

在發布這份說明文件時,Google 使用下列加密演算法為 DEK 與 KEK 進行靜態加密。我們會持續改善相關功能並提高安全性,因此這些項目日後可能改變。

密碼編譯基元 偏好的通訊協定 系統支援的其他通訊協定7
對稱式加密
  • AES-GCM (256 位元)
  • AES-CBC 與 AES-CTR (128 與 256 位元)
  • AES-EAX (128 與 256 位元)
對稱式簽名 (與上述 AES-CBC 與 AES-CTR 搭配使用以進行驗證)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

每項 Google Cloud 產品的加密精細程度

每項 Google Cloud 服務會以不同的精細程度分割資料進行加密。

  Google Cloud 服務 客戶資料加密作業的精細程度8 (以單一 DEK 加密的資料大小表示)
儲存空間 Cloud Bigtable 每一資料區塊 (每一資料表數個)
Datastore 每一資料區塊9
Firestore 每一資料區塊9
Cloud Spanner 每一資料區塊 (每一資料表數個)
Cloud SQL
  • 第二代:每個執行個體,同 Compute Engine (一個執行個體中可以包括多個資料庫)
  • 第一代:每個執行個體
Cloud Storage 每一資料區塊 (通常 256 KB 至 8 MB)
運算 App Engine10 每一資料區塊9
Cloud Functions11 每一資料區塊9
Compute Engine
  • 每一磁碟數個
  • 每個快照群組,個別快照的範圍由快照群組主金鑰衍生而來
  • 每一映像檔
Google Kubernetes Engine 每一磁碟數個,適用於永久磁碟
Container Registry 儲存在 Cloud Storage 中,每一資料區塊
大數據 BigQuery 每一資料集數個
Dataflow 儲存在 Cloud Storage 中,每一資料區塊
Datalab 儲存在 Cloud Bigtable 中,每一筆記本檔案
Dataproc 儲存在 Cloud Storage 中,每一資料區塊
Pub/Sub 每 30 天進行輪替9

Cloud 客戶的其他加密選項

除了 Google Cloud 預設即提供的加密機制之外,我們正努力為客戶提供其他加密和金鑰管理選項,進一步強化控管能力。

我們希望 Google Cloud 的客戶可以:

  • 繼續擔任自有資料的終極監管者,並以最精細的方式控管資料的存取與使用活動,藉此確保資料的安全性與隱私權
  • 比照內部部署的方式 (或是更好的方式) 管理雲端託管資料的加密機制
  • 擁有自有資源的信任根,並能證明其真實性及加以稽核
  • 除了使用 ACL 外,也能進一步分隔及隔離自有資料

客戶可以透過自行提供加密金鑰功能,使用自己以 Google Cloud 管理的現有加密金鑰。客戶可以在 Cloud StorageCompute Engine 中使用這項功能,以便進行儲存空間層的加密作業。

客戶也能使用 Cloud Key Management Service,管理儲存在 Google Cloud 中的自有加密金鑰。這項產品提供客戶管理的應用程式層加密功能。

密碼編譯領域中的研究與創新

為了與加密技術的演進保持同步,Google 成立了世界級的安全性工程師團隊,其任務是關注、開發及改善加密技術。我們的工程師會參與標準化程序,並維護廣為使用的加密軟體。我們會定期發布 Google 在加密技術領域中的研究成果,讓所有同業人士和一般大眾都能從我們累積的知識中獲益。舉例來說,我們在 2014 年揭露了安全資料傳輸層 (SSL) 3.0 加密技術中的重大安全漏洞 (該漏洞稱為「POODLE」),2015 年則找出了 OpenSSL 中的一個高風險安全漏洞。

在雲端服務的加密技術方面,Google 希望能持續領先業界。在新型密碼編譯技術的開發、採用與研究方面,我們的團隊成員正著眼於下列項目:

  • 部分同態密碼編譯:能對已經過加密的資料執行某些工作。這樣一來,即便是雲端服務記憶體中的資料也永遠不會處於明文狀態。這項技術目前已用於開放大眾使用的實驗性已加密 BigQuery 用戶端
  • 保留格式與順序的密碼編譯:能對已經過加密的資料執行某些比較和排名工作。
  • 後量子密碼編譯:能以後量子候選選項取代容易遭受高效量子攻擊的現有密碼編譯基元,一般認為後量子候選選項對於這類攻擊具有更強大的防禦能力。這方面的主要重點是研究以晶格為基礎的公開金鑰密碼編譯技術,並設計出這類技術的原型,當中包含對後量子演算法的 NIST 建議。以晶格為基礎的密碼編譯技術是目前公認為在後量子環境中最有可能採用的加密技術之一。不過以這項技術來說,我們在最佳演算法、具體參數和密碼分析等方面仍處於初步發展階段。雖然對稱式金鑰加密與 MAC 因受到已知量子演算法的影響而弱化,但仍可透過將金鑰大小加倍的方式,在後量子環境中升級至相仿的安全性等級。

更多參考資料

Google Cloud 安全性

如需關於 Google Cloud 安全性的一般資訊,請參閱 Google Cloud 網站的「安全性」專區

Google Cloud 法規遵循

如需 Google Cloud 法規遵循與法規遵循認證的相關資訊,請參閱 Google Cloud 網站的「法規遵循」專區,當中也提供 Google 的 SOC3 公開稽核報告

G Suite 安全性

如需 G Suite 加密與金鑰管理機制的相關資訊,請參閱 G Suite 加密機制白皮書。這份白皮書涵蓋本文中的多數內容,但著重於 G Suite。以所有 G Suite 解決方案來說,我們努力保護客戶資料,並盡可能完整公開我們確保資料安全無虞的方法。如需一般 G Suite 安全防護機制的詳細資訊,請參閱 G Suite 安全性與法規遵循白皮書

註釋

1Datastore、App Engine 和 Pub/Sub 中的資料區塊可同時包含多位客戶的資料。如有需要,請參閱這個段落,瞭解各項服務的資料加密作業精細程度。
2 Compute Engine 中的共用基本映像檔即為共用資源 (不適用於這類分割) 的一例,就算有多位客戶共用同一組資料加密金鑰 (DEK) 加密的單一副本也屬於正常情況。
3 儲存在 Datastore、App Engine 和 Pub/Sub 中的資料除外。在前述這些位置,多位客戶的資料可能會以同一組 DEK 加密。如有需要,請參閱這個段落,瞭解各項服務的資料加密作業精細程度。
4 請注意,我們先前採用的是 AES128 金鑰,目前仍有部分 AES128 金鑰用於資料解密。
5 Google 也會使用另外兩個程式庫:Keymaster 和 CrunchyCrypt。Keymaster 採用與 Tink 相同的新型密碼編譯程式碼,但使用的金鑰版本管理機制不同。另外,Keymaster 也支援較多種舊版演算法。至於 CrunchyCrypt,目前正在進行與 Tink 合併的作業。
6 我們也會使用 OpenSSL 保護 Cloud Storage 中的某些內容。
7 程式庫中還有過去曾支援的其他密碼編譯通訊協定,但這份清單僅列舉 Google Cloud 目前主要使用的通訊協定。
8 此指客戶內容加密作業的精細程度。這不包括客戶中繼資料,例如資源名稱。在某些服務中,所有中繼資料都是以同一組資料加密金鑰 (DEK) 加密。
9 不同客戶可能會共用相同的金鑰。
10 包括應用程式的程式碼與設定。在 App Engine 中使用的資料會儲存於 Datastore、Cloud SQL 或 Cloud Storage 中,實際儲存在何處取決於客戶的設定。
11 包括函式程式碼、設定與事件資料。事件資料會儲存在 Pub/Sub 中。