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