Certificate Manager 的最佳实践

本页面介绍了使用 Certificate Manager 和 Certificate Authority Service (CA Service) 配置和管理 证书的各种最佳实践。 Google Cloud 本页面介绍了如何设计证书管理架构。

在阅读本页面之前,请确保您熟悉 Certificate Manager 概览 和 Certificate Authority Service 概览 页面。

设计证书管理架构

在设计企业证书管理策略时,您必须考虑组织的主要使用场景以及证书的整个生命周期。 这些决策会影响证书管理功能(例如颁发、吊销和轮替)的成本、运营开销和易用性。

以下部分介绍了我们针对每种设计选择的建议。

选择证书类型

创建证书时,您必须根据应用要求和组织的安全政策,确保选择适合您的使用场景的证书类型。

如需分析哪种类型的证书最适合您,请参阅以下流程图:

评估要选择的证书类型。
评估要选择哪种证书类型(点击可放大)。

以下是一些关于流程图中提及的主题的实用文档链接:

简化私有 CA Service 层次结构

我们建议您尽可能简化 CA Service 的层次结构,以确保顺利运营和问题排查。您必须将根证书授权机构 (CA) 存储在自己的 Google 项目中。根 CA 会对一些中间 CA 进行签名,然后这些 CA 会颁发最终证书。

这种扁平的层次结构可提高透明度、简化证书吊销流程,并降低配置错误的几率。虽然 CA Service 是一项区域级服务,但一个区域中的根 CA 可以对位于其他区域的从属 CA 进行签名。

在 CA Service 层次结构中遵循以下最佳实践,如图所示:

  • 将根 CA 隔离在自己的 Google Cloud 项目中,以对颁发 CA 进行签名。
  • 在托管在单独项目中的 CA 池中创建颁发 CA。将这些池托管在单独的项目中,并按地理位置(区域)、软件开发生命周期(开发、生产、测试)或特定使用场景对其进行细分。

  • 将 Certificate Manager 配置为使用可以为受支持的资源颁发私有信任证书的颁发 CA 池。

推荐的 CA 层次结构设计。
CA 层次结构的推荐设计(点击可放大)。

使用全面的主机名覆盖范围

我们建议您确保证书为服务需要保护的所有网域和子网域提供足够的主机名覆盖范围。 主机名覆盖范围不足可能会导致用户收到安全警告、服务中断,并给用户带来负面体验。

避免对多个网域使用单个证书。如果单个证书未能续订或被意外删除,则其涵盖的所有网域都会变得不安全。我们建议您为不同的网域创建不同的证书。

如果您计划稍后添加新的子网域或服务,请从一开始就使用通配符将子网域或服务纳入证书中。例如,*.myorg.example.com 的通配符证书仅保护第一个子网域级别,而不保护更深层的子网域级别,例如 sub.subdomain.myorg.example.com。

使用 Google 管理的证书

为了实现高效的公共证书管理和易用性,我们建议您使用 Google 管理的证书。这种方法可以显著减少运营开销,自动执行证书轮替等任务,并消除与手动续订相关的风险。

此外,Google 管理的证书还与其他 Google Cloud 服务无缝集成。Certificate Manager 仅支持 Public Certificate Authority (pki.goog) 和 Let's Encrypt CA (letsencrypt.org) 颁发公开可信的 Google 管理的 证书。Certificate Manager 预配的 Google 管理的证书的有效期为 45 天或 90 天,具体取决于颁发 CA:

  • 由 Public CA 颁发的证书正逐渐从 90 天有效期过渡到 45 天有效期。现有 90 天有效期证书在下次续订之前仍保持 90 天有效期。
  • 由 Let's Encrypt CA 颁发的证书的有效期为 90 天。

当证书的有效期剩余大约三分之一时,Certificate Manager 会自动开始续订流程。对于 45 天有效期证书,续订会在到期前大约 15 天开始;对于 90 天有效期证书,续订会在到期前大约 30 天开始。

扩缩并提升证书性能

以下部分介绍了扩缩证书的最佳实践,以及如何提升证书相关操作(例如预配和续订)的性能。

为 Certificate Manager 应用去中心化部署

按项目和位置使用 Certificate Manager,这意味着您的证书与同一区域中的关联资源存储在同一项目中。此策略可防止跨不同区域重复使用证书,从而提高可靠性,并有效减少在不太可能发生的区域服务中断事件中的影响。

此外,由于 配额和限制 是 在 Google Cloud 项目级应用,因此跨多个项目部署 Certificate Manager 会增加您的 总体配额。这是因为在一个项目中使用资源不会影响您在另一个项目中的可用配额。

使用带有 ECDSA 密钥的证书

本部分探讨了为什么我们建议将 ECDSA 而不是 RSA 作为证书签名密钥的最佳实践。

要使用哪种密钥类型

对于大多数 TLS 证书,建议选择 ECDSA P-256 作为密钥类型,因为 ECDSA P-256 可提供强大的加密安全性,在签名操作方面具有出色的性能,并能高效利用网络带宽。

使用其他证书密钥类型的一些可能原因如下:

  • 如果您需要支持不支持 ECDSA 证书的旧版客户端,则除了 ECDSA P-256 证书之外,您还可以提供 RSA-2048 证书。
  • 如果您有特定的合规性要求,需要您使用更大的密钥大小或特定的密钥类型,则可以使用 ECDSA P-384、RSA-2048、RSA-3072 和 RSA-4096 密钥。

为何选择 ECDSA 而不是 RSA

与 RSA 相比,ECDSA 的主要优势在于,它能够以明显更小的密钥提供同等的加密安全级别。 这种效率可以转化为切实的性能和资源优势。较小的密钥并不意味着安全性较弱,ECDSA 基于椭圆曲线离散对数问题,与 RSA 相比,可提供更强的每单位密钥安全性,并且在某些情况下提高了计算效率。

例如:

  • 256 位 ECDSA 密钥提供的安全等级与 RSA-3072 密钥类似。
  • 384 位 ECDSA 密钥提供的安全级别高于任何广泛支持的 RSA 密钥大小。

ECDSA 的主要优势:

  • 性能:与提供同等安全级别的 RSA 操作相比,ECDSA 签名操作的计算强度要低得多。这有助于降低 CPU 负载和延迟,对于高吞吐量或对延迟敏感的系统至关重要。

  • 效率:较小的密钥和签名需要更少的带宽和 存储空间,这对于资源受限的环境 (例如移动设备和 IoT 设备)尤其有利。

您可以创建以下自定义组织政策,以强制在证书中使用特定密钥类型 。这仅适用于 CA Service 中的 Google 管理的证书(私有信任管理的证书),而不适用于自行管理的证书和公开信任的 Google 管理的证书。

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

使用 CA 池从私有 CA 颁发证书

我们建议您为颁发 CA 使用 CA 池。CA 池是包含多个 CA 的集合,它具有通用证书颁发政策和 Identity and Access Management (IAM) 政策。使用 CA 池可以通过负载均衡和将传入的证书请求分配到池中的所有已启用 CA,来提高每秒查询次数总数 (QPS)。这可以提升性能,而不会影响工作负载或客户端更改。

CA 池为证书颁发和检索提供单个端点。您可以使用 CA 池安全地轮替 CA,而不会因证书过期或泄露而导致停机。

使用证书映射

为确保最佳可伸缩性,我们建议您将 证书映射与 受支持的资源搭配使用。证书映射旨在扩缩,默认支持数千个证书条目,并且能够处理数百万个证书。当负载均衡器使用证书映射时,证书映射条目的优先级高于其他证书,例如 Compute Engine SSL 证书。

证书映射还允许您配置证书选择逻辑。例如,在握手期间,如果客户端的主机名与预配的证书映射中的任何条目都不匹配,则负载均衡器会返回主证书。

选择正确的网域授权类型

如需颁发 Google 管理的证书,您 可以使用 负载均衡器授权 或 DNS 授权来证明您的网域所有权。

下表介绍了每种方法的注意事项:

功能 负载均衡器授权 DNS 授权
设置复杂性 不需要任何额外的配置步骤或 对 DNS 配置进行更改。 需要您创建 DNS 授权,并将其 对应的 CNAME 记录添加到 DNS 配置。
网络安全 负载均衡器必须完全可访问,方法是在端口 443 上使用互联网,包括证书所服务的所有网域的 DNS 配置。负载均衡器 授权不适用于其他配置。 DNS 授权适用于高度复杂的 配置,例如 443 以外的端口,以及目标代理前面的 CDN 层。
预配速度 预配速度更快。只有在负载均衡器完全设置完毕并提供网络流量后,您才能预配证书。 您可以在目标代理准备好提供网络流量之前提前预配证书。
通配符证书 不受支持。 受支持。

自动轮替自行管理的证书

与 Google 管理的证书不同,自行管理的证书需要在过期之前手动替换。我们建议您使用您选择的证书生命周期管理 (CLM) 产品来自动执行此流程。 这有助于减少错误和停机时间,并确保运营效率。

您还可以使用证书映射来编排无缝的证书轮替。此过程包括以下步骤:

  1. 使用 Cloud Monitoring 和提醒监控证书到期情况。 我们建议您为在未来 15 到 30 天内到期的证书创建提醒。
  2. 生成证书签名请求 (CSR) 和私钥,以提交给 CA。
  3. 将 CSR 和私钥提交给 CA,然后检索新证书。
  4. 将新证书上传到 Certificate Manager 中的相应证书映射。

    重要提示:您必须通过一次 API 调用完成此过程,而不会导致任何 停机。

应用适当的访问权限控制

我们建议您在配置访问权限控制时考虑最小权限原则和职责分离原则。以下部分将更详细地介绍这些建议。

遵循最小权限原则

在分配管理证书的权限时,请遵循最小权限原则并授予执行任务所需的最低权限。我们强烈建议您避免使用基本 IAM 角色。应授予预定义或自定义的 Certificate Manager 和 CA Service 角色,以降低与权限过高的访问权限相关的安全事件风险。

规划职责分离

我们建议您为证书管理员以及具有证书颁发者或证书请求者角色的用户维护不同的身份和权限。为此,请在资源层次结构的顶部为用户创建单独的管理员和请求者群组。

确保管理员群组负责执行以下操作:

  • 管理和维护证书基础架构,例如 CA 预配。
  • 配置证书模板。
  • 管理证书吊销列表 (CRL) 和在线证书状态协议 (OCSP) 响应程序。
  • 为 CA 实现安全政策。

对于托管根 CA 的项目,避免向任何用户或群组分配基本角色,例如所有者 (roles/owner)、编辑者 (roles/editor) 和 CA Service 管理员 (roles/privateca.admin)。这种做法可以防止意外删除、配置错误和过度暴露。相反,在安装和配置根 CA 后,根据需要使用 Privileged Access Manager (PAM) 进行即时 (JIT) 访问,并提供理由和审批。

确保请求者群组负责处理证书请求和根据预定义模板颁发证书的日常运营。

下表列出了通常与各种工作职能相关的 IAM 角色:

角色 说明 IAM 角色
证书管理员 设置和管理 CA 和证书基础架构。 Certificate Manager 所有者 (roles/certificatemanager.owner),
CA Service 管理员 (roles/privateca.admin)
证书请求者 为工作负载请求证书。 Certificate Authority Service 证书请求者 (roles/privateca.certificateRequester)
工作负载(自动化服务账号) 由工作负载或流水线用于请求证书。 Certificate Authority Service 工作负载证书请求者 (roles/privateca.workloadCertificateRequester)
安全工程师或 PKI 所有者 管理证书政策、吊销和生命周期。 CA Service 运营经理 (roles/privateca.caManager), Certificate Authority Service Certificate Manager (roles/privateca.certificateManager)
DevOps 或平台工程师 管理负载均衡器上证书的部署 等。 Certificate Manager 编辑者 (roles/certificatemanager.editor)
审核员或合规人员 监控证书及其使用情况。 Certificate Manager 查看者 (roles/certificatemanager.viewer), Certificate Authority Service 审核员 (roles/privateca.auditor)

针对多区域和多云部署使用每个项目的 DNS 授权

我们建议您使用 每个项目的 DNS 授权 方法,以便独立管理跨 多个区域、多个云和整个软件开发生命周期 (SDLC) 的项目的多个授权。

对 DNS 授权进行隔离有助于确保每个项目都维护自己的一组不同的 DNS 记录和权限。通过这种控制级别,每个项目都可以自主管理其 DNS 配置,而不会干扰其他项目的运营或受到其他项目运营的影响。例如,开发团队可以针对其特定应用尝试新的 DNS 配置,而不会对生产系统或其他正在进行的项目造成任何不利影响。

使用 CAA 记录保护您的网域

证书授权机构授权 (CAA) 记录是域名系统 (DNS) 中的一种安全机制。CAA 记录为网域所有者提供了完全控制权,可以配置哪些公共证书授权机构 (CA) 可以为其网域颁发证书。这种控制对于防止未经授权颁发证书非常重要。有了 CAA,欺诈性证书的攻击面就会缩小,从而有效地提高网站的安全性。

对于 Google 管理的证书,我们建议您手动授权以下内容,以确保证书颁发和续订请求的最佳可靠性:

Cloud Logging、Cloud Monitoring 和可见性

以下部分介绍了审核日志记录的最佳实践,以及如何监控证书使用情况和到期情况。

启用和汇总审核日志记录

如需监控组织的所有资源,请将所有服务(包括 Certificate Manager)的 管理员活动审核日志 汇总到一个 集中位置。

这样,您的安全团队或审计者就可以在一个位置查看与创建或修改 Certificate Manager 和 CA Service 资源相关的所有活动。如需详细了解如何配置汇总日志, 请参阅汇总和存储组织的日志。

监控证书使用情况和到期情况

我们建议您为重要的 Certificate Manager 事件(例如根 CA 使用情况、证书到期和证书删除)设置基于日志的提醒。这些提醒有助于您对操作进行分类,例如证书创建失败率高,并且可以触发下游流程来请求新证书或增加配额。

为与权限相关的操作配置以下日志提醒和政策:

合规要求

通常,合规性框架会指定证书管理的高级预期和目标,而不是针对特定产品或配置。

例如,支付卡行业数据安全标准 (PCI DSS) 和美国国家标准与技术研究院 (NIST) 要求组织记录和实施签名密钥的轮替周期。它们还要求持续监控库存以及保护持卡人数据的所有可信签名密钥和证书。

如需详细了解 Google Cloud 服务如何帮助满足各种 合规性框架要求,请参阅以下资源:

后续步骤