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