總覽
本參考架構定義了概念設計，說明如何將 Keyfactor EJBCA Enterprise 整合為 Google Distributed Cloud (GDC) 實體隔離方案的第三方憑證授權單位 (CA)。
Keyfactor EJBCA Enterprise 是高度可擴充、強大且符合 FIPS 規範的憑證授權單位平台，可讓組織在異質環境中管理公用金鑰基礎架構 (PKI)。
GDC 實體隔離方案包含原生憑證授權單位服務，可在託管雲端邊界內自動管理金鑰和憑證。原生 CA 服務是大多數客戶的建議解決方案，可在平台內提供全代管、流暢的 PKI 功能。不過，如果組織已針對 GDC 以外的現有工作負載，在 Keyfactor EJBCA 上標準化 PKI 基礎架構，則可能偏好針對在 GDC 環境中執行的工作負載，採用相同的一致 CA 架構和管理政策。
特點與功能
這項解決方案提供多項核心功能元件，可用於管理憑證生命週期：
- 自動化憑證生命週期管理：運用 GDC 標準叢集內的自訂 EJBCA 核發者，透過 cert-manager 自動佈建、更新及撤銷伺服器憑證。
- 標準化 ACME 自動化：支援使用 DNS-01 驗證的自動化憑證管理環境 (ACME) 通訊協定，讓平台服務能順暢要求及更新憑證。
- 安全整合 HSM：在通過 CC EAL4+ 認證的硬體安全模組 (HSM) 中，直接對所有 CA 私密金鑰進行密碼編譯保護，確保金鑰內容絕不會離開實體安全邊界。Keyfactor EJBCA Enterprise 可使用自行管理的 HSM，或連線至外部 HSM。
- 實體隔離相容性：專門的工作流程，可將 EJBCA cert-manager 核發者映像檔從公開註冊資料庫鏡像至 GDC 私人 Harbor 註冊資料庫，確保離線可用性。
- 輸出流量隔離：使用 GDC 子網路和 CloudNATGateway 資源設定傳出網路，將 GDC API 流量直接限制在外部 EJBCA 伺服器 IP 位址。
架構原則
- 共同責任模式：客戶負責操作外部 EJBCA 伺服器和 HSM，擁有實體 PKI 基礎架構和 CA 根金鑰，而 GDC 則在標準叢集內提供運算、內部 DNS 和自動化用戶端層。
- 以安全性為主的設計：採用本機容器映像檔鏡像，並強制執行嚴格的輸出閘道，盡可能縮小網路攻擊面，符合實體隔離安全性規定。
- 通訊協定標準化：優先使用標準通訊協定 (ACME 和 mTLS REST) 進行 CA 互動，避免依賴專屬 API，並允許彈性的用戶端整合。
架構
這個架構採用外部憑證授權單位模型，EJBCA 伺服器及其支援的硬體安全模組 (HSM) 託管於實體 GDC 邊界外，但可透過網路存取。EJBCA 伺服器可以部署在外部，做為硬體或軟體設備。本指南所述的核心整合，只需要外部 EJBCA 伺服器可透過穩定的 IP 位址連線。
這個架構的主要元件包括：
- EJBCA Enterprise Server：以 Keyfactor 硬體設備或軟體設備的形式部署於外部，用於存放 CA (根和下層)，並在 CC EAL4+ 認證的 HSM 內產生所有 CA 金鑰內容。
- 預設虛擬私有雲：部署使用者工作負載的虛擬私有雲，無論是在標準 Kubernetes 叢集或虛擬機器中。
- GDC 內部 DNS：管理本機私人 DNS 區域 (使用環境變數中設定的私人網域名稱)，用於解析 ACME DNS-01 驗證。
- GDC 輸出 NAT 閘道：將叢集 Pod 的傳出流量導向外部 EJBCA 伺服器 IP 位址。
- Harbor 私人登錄檔：託管鏡像容器映像檔 (例如 EJBCA cert-manager 核發者)，用於實體隔離部署。
概念和技術
本節將詳細說明功能元件、其職責，以及元件在系統中的通訊方式。
基礎架構和平台
- GDC Standard 叢集：主要的運算環境，EJBCA 核發者和 cert-manager Pod 位於此處，負責執行工作負載的憑證自動化作業。
- Harbor Registry：GDC 中所有容器映像檔的安全本機可靠資料來源。這項服務提供自動掃描功能，確保映像檔在部署前沒有已知安全漏洞。
- GDC 輸出閘道：平台原生網路資源 (子網路和 CloudNATGateway)，可控管及保護從叢集 Pod 到外部 CA 伺服器的傳出 API 流量。
服務和邏輯
- EJBCA Enterprise Server：外部 CA 引擎 (軟體或硬體設備)，負責管理 CA 階層 (根和下層)、驗證憑證要求、簽署憑證，以及記錄稽核記錄。
- 硬體安全模組 (HSM)：符合 CC EAL4+ 規範的密碼編譯模組，可處理金鑰產生和憑證簽署作業，確保 CA 私密金鑰不會外洩。
- GDC 內部 DNS：管理 ACME 驗證服務使用的私人 DNS 區域 (
ManagedDNSZone和ResourceRecordSet)，透過臨時 TXT 記錄驗證網域擁有權。 - cert-manager 搭配 EJBCA 核發者：Kubernetes 原生憑證控制器，可攔截憑證要求，並利用 EJBCA 核發者將要求轉譯為安全的 EJBCA API 呼叫。
資料流程和介面
- ACME 通訊協定：標準 API 介面，用於使用 DNS-01 驗證自動核發網域驗證伺服器憑證。
- EJBCA REST API：用於管理啟動程序和程式輔助作業 (例如 CSR 簽署和撤銷) 的 RESTful 介面。
- mTLS 用戶端驗證：cert-manager 整合的主要驗證機制，使用專屬用戶端憑證，透過相互 TLS 驗證用戶端身分。
注意事項
- 擴充性和效能：
- 外部 EJBCA 伺服器必須擴充 (CPU、記憶體、HSM 容量)，才能處理並行驗證和經簽署的要求，尤其是在大量核發設定檔期間。
- GDC egress 閘道資源必須調整大小，確保與外部 CA 伺服器的延遲時間降到最低，避免在 cert-manager 驗證週期內發生逾時。
- 安全性與法規遵循：
- 將 CA 根金鑰隔離在外部 HSM 中，可滿足高安全性和法規遵循標準 (例如 BSI VS-NfD)。
- EJBCA 的管理員權限應使用角色式存取控管 (RBAC) 嚴格限制，並對應至不重複的用戶端憑證序號。
- 可用性和穩定性：
- 建議您在多個可用區中，以高可用性部署外部 EJBCA 伺服器 (使用主動-被動或叢集設定)，確保持續運作並避免單點故障。
- 在 GDC 部署多個 cert-manager 控制器副本，可確保叢集端自動核發憑證作業保持彈性。
- 營運管理：
- 客戶保留 EJBCA 伺服器的擁有權，包括系統修補、HSM 金鑰輪替和 CRL 發布。
- 客戶的 GDC 平台管理員負責維護叢集內 cert-manager 和 EJBCA 核發者控制器，以及管理 GDC 端私人 DNS 記錄。
設計決策
這項解決方案的主要架構選擇著重於平衡自動化與實體隔離環境的限制。
EJBCA 整合選項
GDC 的原生憑證授權單位服務是大多數客戶推薦的 PKI 解決方案，可在 GDC 實體隔離方案環境中提供全代管、流暢的 PKI 功能。不過，如果組織已在 Keyfactor EJBCA 上標準化 PKI 基礎架構，用於 GDC 以外的工作負載，則可選擇整合現有的外部 CA 伺服器。這樣一來，他們就能重複使用既有的 PKI 範本、安全性政策和作業模式，不必重新設計信任階層或遷移核心工作流程。
ACME 驗證選項
系統完整支援 HTTP-01 和 DNS-01 ACME 驗證通訊協定。雖然本架構指南著重介紹使用 GDC 內部 DNS 的 DNS-01 驗證 (適合無法支援傳入公開 HTTP 流量的隔離私人環境)，但客戶可以根據特定網路拓撲、安全性政策和工作負載需求，選擇任一驗證方法。
mTLS 管理管道建議
建議使用相互傳輸層安全標準 (mTLS)，做為 cert-manager 和整合用戶端的強大驗證方式。mTLS 利用用戶端憑證，提供高度安全的加密驗證用戶端身分，但客戶可以根據企業安全政策，選擇設定 EJBCA 執行個體支援的其他驗證機制。
假設和限制
假設
- 外部 EJBCA 伺服器已部署、設定，且可透過穩定的 IP 位址連線。
- EJBCA 伺服器已預先設定必要的根 CA 和從屬 CA，以及適當的 End Entity 設定檔。
- 提供安全機制 (例如堡壘節點或離線移轉工作流程)，將 EJBCA 核發者容器映像檔發布至 GDC Harbor 登錄檔。
- GDC 中的標準 Kubernetes 叢集已預先安裝或設定 cert-manager。
限制
- 外部 HSM 和 EJBCA 維護：GDC 控制層不會管理外部 EJBCA 伺服器或其支援的 HSM；生命週期作業 (備份、升級、金鑰輪替) 由客戶的 PKI 作業團隊處理。
- DNSSEC 驗證限制：由於使用私人內部 DNS，因此必須在 ACME 設定中停用伺服器端 DNSSEC 驗證，以免本機私人網域解析失敗。
- 輸出連線依附元件：自動核發憑證服務取決於 GDC 機架與外部 EJBCA 伺服器之間的網路連結可用性和延遲時間。