啟用 Cloud Key Management Service (Cloud KMS) 和 Cloud External Key Manager (Cloud EKM) 後，您就能使用透過外部金鑰管理合作夥伴代管的金鑰，保護Google Cloud中的資料。本文說明適用於 Google Cloud 客戶的架構，這些客戶想透過 Cloud KMS 和 Cloud EKM 部署高可用性外部金鑰管理工具 (EKM) 服務。
搭配 EKM 服務使用 Cloud EKM 時，您必須在雲端工作負載可靠性和資料保護控制項之間，明確權衡風險。使用雲端外的加密金鑰加密雲端中的靜態資料，會增加新的失敗風險，可能導致 Google Cloud 服務資料無法存取。為因應這些風險，您必須將高可用性和容錯能力納入 Cloud EKM 架構。
總覽
透過 Cloud EKM，您可以使用位於 Google Cloud 外部的金鑰素材，控管儲存在支援 Google Cloud服務中的資料存取權。Cloud EKM 金鑰是客戶管理的加密金鑰 (CMEK)。您可以使用 EXTERNAL 和 EXTERNAL_VPC 保護層級，透過 Cloud EKM 建立及管理 Cloud KMS 金鑰資源。啟用 Cloud EKM 後，每項加密編譯作業要求都會導致外部金鑰的加密編譯作業。初始要求作業是否成功，取決於外部金鑰的加密作業結果。
Cloud KMS 會使用專用 API 對外部金鑰執行作業，該 API 會與外部金鑰管理系統整合。本文將提供此 API 的服務稱為 EKM 服務。
如果 EKM 服務無法使用，整合式 Google Cloud 服務的資料平面讀取和寫入作業可能會失敗。如果相依的 Cloud KMS 金鑰處於無法使用的狀態 (例如已停用)，就會發生類似的失敗情形。錯誤訊息會說明錯誤來源和建議採取的行動。此外，Cloud KMS 資料存取稽核記錄會記錄這些錯誤訊息，以及說明錯誤類型。詳情請參閱 Cloud EKM 錯誤參考資料。
Cloud EKM 架構的最佳做法
Google 的網站可靠性工程書籍說明瞭最佳做法，可協助您開發及維護可靠的系統。本節將說明這些做法，以及 EKM 服務與 Google Cloud的整合方式。下列最佳做法適用於 Cloud EKM 參考架構：
- 設定低延遲且可靠的網路連線
- 啟用高可用性設定
- 快速偵測並減輕故障影響
設定低延遲且可靠的網路連線
Cloud KMS 會使用虛擬私有雲 (VPC) 網路或網際網路連線至 EKM 服務。虛擬私有雲解決方案通常會使用混合式連線，在地端部署資料中心代管 EKM 服務。Google Cloud 與資料中心之間的連線必須快速且穩定。使用網際網路時，您需要穩定且不間斷的連線能力，以及快速可靠的 DNS 解析。從 Google Cloud的角度來看，任何中斷都可能導致 EKM 服務無法使用，且可能無法存取 EKM 保護的資料。
當 Google Cloud 服務的資料層與 EKM 服務通訊時，每個繫結至 EKM 服務的呼叫都有定義的逾時時間 (150 毫秒)。逾時時間是從 Cloud KMS 服務開始計算，該服務位於 Cloud KMS 金鑰的 Google Cloud 位置。如果Google Cloud 位置是多區域，則逾時時間會從 Cloud KMS 收到要求的區域開始計算，通常是發生 CMEK 保護資料資源作業的區域。這個逾時時間足以讓 EKM 服務處理來自附近Google Cloud 區域的要求。
逾時有助於防止依附外部金鑰的下游服務發生連鎖故障。在較高層級的應用程式中，尾端延遲問題通常會導致不良的使用者體驗，但實際上可能會導致無法存取外部金鑰，進而導致較高層級的邏輯作業失敗。
如要盡量縮短延遲時間並建立可靠的網路，請考慮下列事項：
- 盡量縮短與 Cloud KMS 的往返通訊延遲時間： 設定 EKM 服務，盡可能在 Google Cloud 對應於 Cloud KMS 金鑰的位置處理要求，這些金鑰已設定為使用 EKM 服務。詳情請參閱「選擇 Compute Engine 區域的最佳做法」和「區域和可用區」。
- 盡可能使用 Cloud Interconnect： Cloud Interconnect 會使用虛擬私有雲網路，在 Google Cloud和您的資料中心之間建立高可用性、低延遲的連線，並協助移除對網際網路的依附元件。
- 視需要，在距離 EKM 服務最近的區域部署 Google Cloud 網路解決方案：理想情況下，Cloud KMS 金鑰會儲存在距離 EKM 服務最近的區域。如果 EKM 服務所在的Google Cloud 區域比 Cloud KMS 金鑰所在的區域更近，請在 EKM 服務所在的區域使用 Google Cloud 網路解決方案，例如 Cloud VPN。這個選項可確保網路流量盡可能使用 Google 基礎架構，減少對網際網路的依賴。
- 當 EKM 流量透過網際網路傳輸時，請使用進階級網路： 進階級會盡可能透過 Google 基礎架構，經由網際網路傳輸流量，以提升可靠性並減少延遲。
- 使用適當的用戶端期限：如果您直接呼叫 Cloud KMS API API 取得 Cloud EKM 金鑰，請將用戶端期限設為至少 10 秒，確保外部金鑰作業有足夠的時間完成。
啟用高可用性設定
EKM 服務中的單點故障會導致依附資源的可用性降低至單點故障的程度。 Google Cloud 這類故障點可能位於 EKM 服務的重要依附元件，以及底層的運算和網路基礎架構。
如要啟用高可用性，請考慮下列事項：
- 在獨立故障網域中部署副本：至少部署兩個 EKM 服務副本。如果您使用多區域 Google Cloud
位置，請在至少兩個不同的地理位置部署 EKM，且每個位置至少有兩個副本。確保每個副本不僅代表 EKM 服務的複製資料平面，還要盡量減少並強化跨副本的失敗向量。請參考以下範例：
- 設定生產環境變更 (包括伺服器二進位檔和設定推送)，一次只修改一個副本。確認所有變更都在監督下執行，且隨時可測試復原。
- 瞭解並盡量減少基礎架構造成的跨副本故障模式。舉例來說，請確保副本依附於獨立且備援的電源饋送。
確保副本可因應單一機器故障：確認服務的每個副本至少包含三部設備、機器或 VM 主機。這項設定可讓系統在某部機器因更新而停機，或發生意外中斷時，繼續提供流量服務 (N+2 佈建)。
限制控制層問題的影響範圍：設定 EKM 服務的控制層 (例如金鑰建立或刪除)，以便在副本之間複製設定或資料。這些作業通常較為複雜，因為需要同步處理，且會影響所有副本。問題可能會迅速擴散，影響整個系統。以下列舉幾項策略，可減少問題造成的影響：
- 控管傳播速度：根據預設，請確保變更傳播速度盡可能緩慢，以符合可用性和安全性需求。視需要設定例外狀況，例如允許快速傳播金鑰的存取權，讓使用者復原錯誤。
- 將系統分割為分片：如果許多使用者共用 EKM，請將他們分割為完全獨立的邏輯分片，這樣一個分片中的使用者觸發的問題就不會影響其他分片中的使用者。
- 預覽變更效果：盡可能讓使用者先查看變更效果，再套用變更。舉例來說，修改金鑰存取政策時，EKM 可以確認在新政策下，近期有多少要求會遭到拒絕。
- 導入資料 Canary 測試：首先，只將資料推送至系統的一小部分。如果子集保持正常，請將資料推送至系統的其餘部分。
實作全方位健康狀態檢查：建立健康狀態檢查，評估整個系統是否正常運作。舉例來說，如果健康狀態檢查只會驗證網路連線，就無法協助解決許多應用程式層級的問題。理想情況下，健康狀態檢查應與實際流量的依附元件密切相關。
設定跨副本的容錯移轉：在 EKM 服務元件中設定負載平衡，以便使用健康狀態檢查，並主動從健康狀態不佳的副本排空流量，安全地容錯移轉至健康狀態良好的副本。
納入安全機制，管理過載情形並避免連鎖性故障： 系統過載的原因有很多種。舉例來說，如果部分副本健康狀態不良，重新導向至健康副本的流量可能會導致副本過載。如果系統收到的要求超出負荷，應嘗試安全快速地處理要求，同時拒絕過多的流量。
確保資料耐久性：如果 Google Cloud 中的資料是透過 EKM 服務中的外部金鑰加密，就必須使用該外部金鑰才能復原。因此，金鑰耐久性是 EKM 服務的核心設計需求之一。設定 EKM 服務，在多個實體位置安全備份金鑰材料的備援副本。為高價值金鑰設定離線備份等額外保護措施。請確保刪除機制允許在發生意外和錯誤時進行復原。
快速偵測並減輕故障影響
EKM 服務每停機一分鐘，相依的 Google Cloud資源就可能無法存取，這可能會進一步提高基礎架構其他相依元件發生連鎖故障的機率。
如要快速偵測及減輕故障影響，請考慮下列事項：
- 設定 EKM 服務，回報會危及可靠性的事件指標：設定回應錯誤率和回應延遲等指標，以便快速發現問題。
- 建立作業實務，以便及時通知及緩解事件：追蹤平均偵測時間 (MTTD) 和平均復原時間 (MTTR) 指標，量化作業實務的成效，並根據這些指標定義目標。您可以運用這些指標找出目前程序和系統的模式和缺點，以便快速回應事件。
Cloud EKM 參考架構
下列架構說明如何使用Google Cloud 網路和負載平衡產品部署 EKM 服務。
透過 Cloud VPN 或 Cloud Interconnect 直接連線
在Google Cloud 上執行高輸送量應用程式，且 EKM 服務在單一資料中心執行時，建議您在 Google Cloud 和地端部署資料中心之間建立直接連線。下圖呈現了這個架構。
在這個架構中，Cloud EKM 會透過區域中的混合式連線存取位於地端部署資料中心的 EKM 服務，而 Google Cloud中不會有任何中繼負載平衡。
盡可能使用單一區域應用程式的可用性 99.9% 設定，將 Cloud EKM 部署至 EKM 服務連線。可用性 99.99% 的設定需要使用多個 Google Cloud區域的 Cloud Interconnect，如果貴商家需要區域隔離，可能無法滿足需求。如果連線至地端部署資料中心時使用網際網路，請改用高可用性 VPN，而非 Cloud Interconnect。
這種架構的主要優點是 Google Cloud沒有中間躍點，可減少延遲和潛在瓶頸。如果 EKM 服務託管於多個資料中心，且您想設定直接連線，則必須在所有資料中心設定負載平衡器，並使用相同的 (任播) IP 位址。如果使用這項設定，資料中心之間的負載平衡和容錯移轉僅限於路徑可用性。
如果您設定虛擬私有雲網路，透過虛擬私有雲網路存取的外部金鑰必須使用 Cloud KMS 中的區域位置。金鑰無法使用多區域位置。詳情請參閱「外部金鑰管理工具和區域」。
從網際網路平衡負載 Google Cloud
需要多區域 Cloud KMS 金鑰時，建議在 Google Cloud 使用負載平衡器並連上網際網路。下圖呈現了這個架構。
在這個架構中，EKM 在兩個地端部署網站中都有副本。每個後端都以 Google Cloud 混合式連線網路端點群組 (NEG) 表示。這個部署作業會使用外部 Proxy 網路負載平衡器，將流量直接轉送至其中一個副本。與其他方法不同，外部 Proxy 網路負載平衡器依賴虛擬私有雲網路，具有外部 IP 位址，流量來自網際網路。
每個混合式連線 NEG 可能包含多個 IP 位址，讓外部 Proxy 網路負載平衡器直接將流量平衡至 EKM 服務的執行個體。地端部署資料中心不需要額外的負載平衡器。
外部 Proxy 網路負載平衡器不會綁定特定區域。可將傳入流量導向最近的正常區域，因此適用於多區域 Cloud KMS 金鑰。不過，負載平衡器不允許設定主要和容錯移轉後端。流量會平均分配到區域中的多個後端。
在虛擬私有雲網路中平衡負載 Google Cloud
建議您在虛擬私有雲網路中使用負載平衡器，適用於部署 EKM 的大多數 EKM 服務。 Google Cloud 下圖呈現了這個架構。
在這個架構中，Cloud EKM 會透過混合式連線存取 EKM 服務，該服務會在兩個地端資料中心之間複製，並在 Google Cloud 區域中進行多層中間負載平衡。如果連線至地端部署資料中心時使用網際網路，則可改用高可用性 VPN，而非 Cloud Interconnect。
內部直通式網路負載平衡器提供單一 IP 位址，資源可使用虛擬網路傳送流量。負載平衡器會根據後端的健康狀態容錯移轉至備份資料中心。
由於內部負載平衡器無法直接將流量路由至地端部署後端，因此必須使用 VM 執行個體群組做為流量的 Proxy。您可以部署負載平衡器 Proxy，在執行個體群組中執行 Cloud Marketplace 的 Nginx Docker 映像檔。您可以將 Nginx 設為 TCP 負載平衡器。
由於這種方法會使用 Google Cloud中的負載平衡器，因此您不需要使用地端部署負載平衡器。負載平衡器可直接連線至 EKM 服務的執行個體，並在這些執行個體之間平衡負載。 Google Cloud 如果移除地端部署負載平衡器，設定會更簡單，但 EKM 服務的彈性會降低。舉例來說，如果某個 EKM 執行個體傳回錯誤，地端部署 L7 負載平衡器可以自動重試要求。
如果您設定虛擬私有雲網路，透過虛擬私有雲網路存取的外部金鑰必須使用 Cloud KMS 中的區域位置。金鑰無法使用多區域位置。詳情請參閱「外部金鑰管理工具和區域」。
參考架構比較
下表比較 Cloud EKM 的參考架構選項。表格也包含合作夥伴管理的 EKM 架構資料欄。在這個情境中，合作夥伴負責部署及管理 EKM，並以服務的形式提供給客戶。
| 選項 | 直接連線 | 從網際網路平衡負載 | 在虛擬私有雲網路中平衡負載 | 合作夥伴提供的全代管 EKM |
|---|---|---|---|---|
網際網路或虛擬私有雲網路 |
虛擬私有雲 |
網際網路 |
虛擬私有雲 |
網際網路 |
負載平衡器 Google Cloud |
否 |
是 |
是 |
否 |
必須使用地端部署負載平衡器 |
是 |
否 |
否 |
會 (由合作夥伴管理) |
支援多區域 Cloud KMS 位置 |
否 |
是 |
否 |
是 |
適合 |
高處理量應用程式，其中 EKM 服務在單一網站中執行。 |
需要多區域 Cloud KMS 金鑰時。 |
您部署自有 EKM 的大多數 EKM 服務。 |
您可以改用合作夥伴的 EKM，不必自行部署。 |