教學目標

學習 Google Cloud Platform 的心得分享,初步了解有關 Cloud KMS 雲端服務的重點概念。

重點概念

首先 Cloud KMS 是雲端託管型金鑰管理服務,將能夠比照內部部署方式,管理雲端服務的加密金鑰,並且整合 Cloud IAM 和 Cloud 稽核記錄功能,因此我們將能夠管理個別金鑰的權限,並且監控其使用狀況。此外 Cloud KMS 主要能夠實施信封式加密,在應用程式層管理用來加密資料的金鑰。更進一步滿足法規遵循需求,Cloud KMS 主要能夠使用客戶代管的加密金鑰 (CMEK),針對用於保護 GCP 機密之留存資料的加密金鑰進行管理,並且 Cloud KMS 與 Cloud HSM 整合之後,建立受 FIPS 140-2 第 3 級裝置保護的金鑰就更加簡單容易,並且符合在同一硬體環境中執行金鑰和加密操作的法規遵循要求,當然更能夠設定金鑰自動定期輪替,使用新推出的主要版本加密資料,並且限制單一金鑰版本能夠存取的資料範圍,不需額外負擔管理費用,就能夠時常的輪替金鑰將能夠符合我們內部法規遵循要求。至於 Cloud KMS 的計費方式主要是根據啟用金鑰版本的數量,金鑰版本的加密安全等級,以及金鑰操作的使用費率,如果非對稱式金鑰和對稱式金鑰的加密安全等級皆為軟體,則兩者價格相同,主要為一個月 $0.06 美元,但是如果加密安全等級採用硬體,主要為一個月 $1.00 美元,但是若是採用 RSA 3072 加密安全等級以上的非對稱加密金鑰,則為一個月會需要支費更高的費用。

接著儲存和加密資料在 Google Cloud 中需要使用集中加密金鑰管理服務中的多層金鑰用於已被加密的資料,其中多層金鑰又稱為信封式加密,簡單來說,就是透過另一個金鑰加密金鑰。我們會在應用層中加密資料,並且在儲存層提供實體資料儲存,此時預設情況下 Google Cloud 就會使信封式加密的方式透過內部金鑰管理服務集中的金鑰針對儲存內容進行加密保護,而相同的概念我們則能夠使用 Cloud KMS 金鑰集金鑰管理服務集中的金鑰針對應用程式中資料進行加密。在 Google Cloud 中的資料主要會分為多個子檔案區塊以進行儲存,並且每個區塊在儲存層級中皆會以個別加密金鑰進行加密處理,此時用於加密區塊中的資料所使用的金鑰稱為資料加密金鑰 (Data Encryption Key,DEK),此外金鑰將會儲存在所加密資料的附近,DEK 主要會使用金鑰加密金鑰 (Key Encyrption Key,KEK) 進行加密。此外在Cloud KMS 主要是使用物件階層來設定金鑰屬於金鑰環和儲存在特定區域,並且我們主要透過以下四個步驟建立對稱金鑰和非對稱金鑰,分別為:

  1. 建立金鑰環。
  2. 建立金鑰。
  3. 設定金鑰輪替週期和開始時間。
  4. 手動建立金鑰的版本。

其中所謂金鑰環主要是針對組織目前的金鑰群組,金鑰主要會繼承金鑰環的權限,透過金鑰環將能夠允許我們授予、撤消或修改權限,而不需要額外的操作行為。而所謂金鑰主要是針對用於特定目的之加密金鑰,目前所有金鑰皆支援 AES-256 的進階加密標準,而且每次的變更皆會建立新的金鑰版本,所謂金鑰版本主要是在某個時間點與金鑰相關的金鑰內容,並且每個金鑰可以有任意數量的版本,但是必須至少有一個版本,系統會從 1 開始,依序編號各個版本,請注意僅有啟用的版本才需要付費,未啟用的版本無需付費。至於在專案中 Cloud KMS 的金鑰資源主要會被建立在多個地區 (location),這代表地理資料中心所請求 Cloud KMS 的資源會被控管,並且會將相對應的金鑰相關資源儲存在資料中心中,此外當設定全域 (global),則代表 Cloud KMS 資源將會來自於多個資料中心,所以我們需要考慮不同區域的網路延遲的效能,目前僅有區域地區和多區域地區皆支援 Cloud HSM 硬體加密,但是雙區域地區和全域地區目前還未支援 Cloud HSM 硬體加密,至於 Cloud HSM 主要使用 Cloud KMS 主要控台進行金鑰管理操作

再來 Cloud KMS 主要是以階層結構設計的方式儲存加密金鑰,以利透過 Cloud IAM 進行存取控制管理和治理,其中主要有五個階層,分別為專案、位置、金鑰環、金鑰和金鑰版本,Cloud KMS 資源屬於專案,這代表 Cloud IAM 原生角色權限將會對應至 Cloud KMS 資源,基於這個理由,所以建議在不同的專案中執行 Cloud KMS,並且建議不要設定專案層級的 Owner 角色,而是建議設定組織層級的 Organization Admin 角色,該角色無法管理或使用金鑰,但是能夠授予金鑰管理相關的權限,這種執行方式為權責劃分的概念,主要確保沒有個別使用者有所有執行惡意行為的權限,像是在 Cloud KMS 中使用者直接存取金鑰去解密已經加密之後的資料,這是很不正常存取方式,通常權責劃分的最佳實務主要用於大型企業組織中,以利避免發生安全或隱私的意外和錯誤。然而對於小型組織而言,三個原生角色 Owner、Editor 和 Viewer 已經提供足夠的金鑰管理權限,但是對於大型企業組織而言,則建議使用預定義角色、客製角色和服務帳號,主要有三種類型,針對系統管理員則建議設定 Organization Admin 角色,金鑰管理員則建議設定預定義角色 Project Editor 和客製角色 Cloud KMS Admin ,開發使用者則建議使用專案層級的服務帳號和設定 Encrypter/Decrypter 的權限,如果服務僅需要加密資料,則能夠僅設定 Encypter 加密者服務帳號的權限,以及僅需要解密資料,則能夠僅設定 Decypter 解密者服務帳號的權限。

最後 Google Cloud 主要會為客戶所儲存的靜態資料進行加密,此時無需採取任何行動,但是為了滿足資料保護的資訊安全需求, Google Cloud 主要提供一系列加密金鑰管理選項,使用者將能夠選擇適合的金鑰管理解決方案進行管理,其中解決方案主要有三種,分別為預設採用加密機制、使用 Cloud KMS 管理客戶加密金鑰 (Customer-Managed Encryption Keys,CMEK) 和由客戶提供的加密金鑰 (Customer-Supplied Encryption Keys,CSEK)。所謂預設採用加密機制主要是指所有 Google Cloud 中的所有靜態資料皆會經過加密處理,所謂使用 Cloud KMS 管理客戶加密金鑰主要是將金鑰儲存在雲端中,以利雲端服務直接使用,所謂由客戶提供的加密金鑰主要是將金鑰主要是將金鑰儲存在內部部署系統中,以利提供的金鑰用於 API 服務呼叫使用,主要用於 Cloud Storage 和 Compute Engine,請注意 Google 主要會在記憶體中使用金鑰,而不會將金鑰寫入至儲存空間中。所以當建立了一個每天執行的作業工作,先將高度敏感的資料從本地位置導入至 Cloud Storage 中,像是當我們需要在 Compute Engine 實體上執行串流資料的處理,我們需要進行資料加解密的處理,但是加密金鑰不能夠儲存在 Google Cloud 雲端服務中,以及不建議將金鑰儲存在 Compute Engine 中,此時我們就能夠採用由客戶提供的加密金鑰的解決方案,在 Compute Engine 中透過 API 服務呼叫進行資料加解密的處理。

相關資源