Keyfactor EJBCA 参考架构

概览

此参考架构定义了在 Google Distributed Cloud (GDC) 气隙环境中将 Keyfactor EJBCA Enterprise 集成作为第三方证书授权机构 (CA) 的概念设计。

Keyfactor EJBCA Enterprise 是一个高度可伸缩、稳健且符合 FIPS 标准的证书授权机构平台，可让组织在异构环境中管理公钥基础架构 (PKI)。

GDC 网闸隔离配置包含一个 原生证书授权机构服务 ，用于在托管云边界内自动执行密钥和证书管理。对于大多数客户而言，原生 CA 服务是推荐的解决方案，可在平台内提供全代管式无缝 PKI 功能。不过，对于已针对 GDC 外部的现有工作负载将 PKI 基础架构标准化为 Keyfactor EJBCA 的组织，他们可能更愿意针对在 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 地址访问。

Keyfactor EJBCA 架构图。

此架构的关键组件包括：

  • EJBCA Enterprise 服务器：作为 Keyfactor 硬件设备或软件设备在外部部署，用于存放 CA（根 CA 和 下级 CA），并在 CC EAL4+ 认证的 HSM 内生成所有 CA 密钥材料。
  • 默认 VPC：用户工作负载部署到的 VPC，可以是标准 Kubernetes 集群，也可以是虚拟机。
  • GDC 内部 DNS：管理用于解析 ACME DNS-01 质询的本地专用 DNS 区域（使用在环境变量中配置的专用域名）。
  • GDC 出站 NAT 网关：将出站 流量从集群 pod 定向到外部 EJBCA 服务器 IP 地址。
  • Harbor 私有注册表：托管镜像的容器映像（例如 EJBCA cert-manager 颁发者），用于气隙部署。

概念和技术

本部分详细介绍了功能组件、其职责以及它们在系统内的通信方式。

基础架构和平台

  • GDC 标准集群：EJBCA 颁发者和 cert-manager pod 所在的主要计算环境，用于执行工作负载的证书自动化。
  • Harbor 注册表：GDC 中所有容器 映像的安全本地可靠来源。它提供自动扫描功能，以确保映像在部署之前不存在已知漏洞。
  • GDC 出站网关：平台原生网络 资源（子网和 CloudNATGateway），用于管理和保护从集群 pod 到外部 CA 服务器的出站 API 流量。

服务和逻辑

  • EJBCA Enterprise 服务器：外部 CA 引擎（软件或硬件 设备），负责管理 CA 层次结构（根 CA 和下级 CA）、 验证证书请求、签署证书和记录审核 记录。
  • 硬件安全模块 (HSM)：符合 CC EAL4+ 标准的加密 模块，用于处理密钥生成和证书签署，保证 CA 私钥绝不会泄露。
  • GDC 内部 DNS: 管理 ACME 质询 验证服务使用的专用 DNS 区域 (ManagedDNSZone 和 ResourceRecordSet)，以通过临时 TXT 记录验证网域所有权。
  • 带有 EJBCA 颁发者的 cert-manager: Kubernetes 原生证书 控制器，用于拦截证书请求，并利用 EJBCA 颁发者将其转换为安全的 EJBCA API 调用。

数据传输和接口

  • ACME 协议：标准 API 接口，用于使用 DNS-01 质询自动颁发经过 网域验证的服务器证书。
  • EJBCA REST API：用于管理 引导和编程操作（例如 CSR 签署和 撤消）的 RESTful 接口。
  • mTLS 客户端身份验证： cert-manager 集成的主要身份验证机制，通过使用 专用客户端证书的双向 TLS 验证客户端身份。

注意事项

  • 可扩缩性和性能:
    • 必须扩缩外部 EJBCA 服务器（CPU、内存、HSM 容量），以处理并发验证和签署请求，尤其是在突发颁发配置文件期间。
    • 必须调整 GDC 出站网关资源的大小，以确保到外部 CA 服务器的延迟最小，防止在 cert-manager 验证周期内发生超时。
  • 安全性和合 1 规性:
    • 在外部 HSM 中隔离 CA 根密钥符合高安全性和合规性标准（例如 BSI VS-NfD）。
    • 应使用基于角色的访问控制 (RBAC) 严格限制对 EJBCA 的管理访问权限，并将其映射到唯一的客户端证书序列号。
  • 可用性和可靠性:
    • 建议在多个可用区中以高可用性方式部署外部 EJBCA 服务器（使用主动-被动或集群配置），以确保持续运行并避免单点故障。
    • 在 GDC 内部署多个 cert-manager 控制器副本可确保集群端自动证书颁发保持弹性。
  • 运营管理：
    • 客户保留 EJBCA 服务器的所有权，包括系统补丁、HSM 密钥轮替和 CRL 发布。
    • 客户的 GDC 平台管理员负责维护集群内 cert-manager 和 EJBCA 颁发者控制器，并管理 GDC 端专用 DNS 记录。

设计决策

此解决方案的主要架构选择侧重于在自动化与气隙环境的限制之间取得平衡。

EJBCA 集成选项

对于大多数客户而言，GDC 的原生证书授权机构服务是推荐的 PKI 解决方案，可在 GDC 网闸隔离配置环境中提供全代管式无缝 PKI 功能。不过，对于已针对 GDC 外部的工作负载将 PKI 基础架构标准化为 Keyfactor EJBCA 的组织，系统会提供集成其现有外部 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，以及相应的最终实体配置文件。
  • 提供了一种安全机制（例如堡垒主机节点或离线传输工作流），用于将 EJBCA 颁发者容器映像发布到 GDC Harbor 注册表。
  • GDC 内的标准 Kubernetes 集群已预安装或配置 cert-manager 以进行运营。

限制

  • 外部 HSM 和 EJBCA 维护 ：GDC 控制平面不管理外部 EJBCA 服务器或其后备 HSM；生命周期运营（备份、升级、密钥轮替）由客户的 PKI 运营团队处理。
  • DNSSEC 验证限制：由于使用了专用内部 DNS， 因此必须在 ACME 配置中停用服务器端 DNSSEC 验证，以 避免本地专用网域的解析失败。
  • 出站连接依赖项：自动证书颁发 服务取决于 GDC 机架与外部 EJBCA 服务器之间的网络链接的可用性和延迟。