Certificate Manager 的最佳实践

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

在阅读本页面之前，请确保您熟悉证书管理器概览和证书授权机构服务概览页面。

设计证书管理架构

在设计企业证书管理策略时，您必须考虑组织的主要使用情形和证书的整个生命周期。这些决策会影响费用、运营开销以及实现证书管理功能（例如颁发、撤消和轮换）的难易程度。

以下部分将针对每种设计选择提供建议。

选择证书类型

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

如需分析哪种类型的证书可能最适合您，请参阅以下流程图：

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

以下是一些实用文档链接，可帮助您了解流程图中提及的主题：

• Google 管理的证书
• 证书授权机构池
• Certificate Authority Service 概览
• 自行管理的证书

简化私有 CA 服务层次结构

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

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

在 CA 服务层次结构中遵循以下最佳实践（如图所示）：

• 将根 CA 隔离在自己的 Google Cloud 项目中，以对签发 CA 进行签名。

• 在托管于不同项目中的 CA 池中创建签发 CA。将这些池托管在不同的项目中，并按地理位置（区域）、软件开发生命周期（开发、生产、测试）或特定使用情形进行细分。

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

建议的 CA 层次结构设计（点击可放大）。

重要提示： 即使您使用的是与证书管理器集成的区域 CA 池，也可以使用该 CA 池在任何区域中签发全球 Google 管理的 TLS 证书。

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

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

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

如果您日后打算添加新的子网域或服务，请从一开始就使用通配符将子网域或服务纳入证书中。例如，针对 *.myorg.example.com 的通配符证书仅保护第一级子网域，而不保护更深层的子网域（例如 sub.subdomain.myorg.example.com）。

使用 Google 管理的证书

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

此外，Google 管理的证书还可与其他Google Cloud 服务无缝集成。Google 管理的证书有效期为 90 天，续订流程会在证书到期前一个月左右开始。

重要提示： 您可以通过实现 constraints/compute.disableGlobalSelfManagedSslCertificate 政策限制来防止在组织中创建自行管理的全球 TLS 证书。

扩大规模并提升证书效果

以下部分介绍了扩展证书和提升证书相关操作（例如配置和续订）性能的最佳实践。

为 Certificate Manager 应用分散式部署

按项目和位置使用证书管理工具，这意味着证书会存储在同一项目中，并与同一区域中的关联资源位于同一位置。此策略可防止在不同区域重复使用证书，从而提高可靠性，并有效降低区域服务中断（可能性很小）的影响。

此外，由于配额和限制是在 Google Cloud 项目级层应用的，因此在多个项目中部署证书管理服务会增加您的总体配额。这是因为在一个项目中使用资源不会影响您在另一个项目中的可用配额。

将证书与 ECDSA 密钥搭配使用

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

要使用哪种密钥类型

ECDSA P-256 是推荐用于大多数 TLS 证书的密钥类型，因为 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 池可通过以下方式提高总有效每秒查询次数 (QPS)：在池中的所有已启用 CA 之间进行负载均衡并分配传入的证书请求。这样可以提高性能，而不会影响工作负载或客户端更改。

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. 向 CA 提交 CSR 和私钥，然后检索新证书。

4. 将新证书上传到 Certificate Manager 中的相应证书映射。

   • 如果新证书中的域名与即将过期的证书中的域名一致，请对现有证书资源使用 UpdateCertificate 方法。
   • 如果新证书具有不同的域名，请先使用包含新 PEM（增强型隐私邮件）文件的 CreateCertificateRequest 方法来创建该证书。然后，使用 UpdateCertificateMapEntry 方法将证书映射中对旧证书的引用替换为对新证书的引用。

   重要提示：您必须通过一次 API 调用完成此流程，且不得导致任何停机时间。

应用适当的访问权限控制

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

应用最小权限原则

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

规划职责分离

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

确保您的管理员群组负责执行以下操作：

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

重要提示： 请确保您的管理员群组包含少量用户，以降低配置错误或滥用的风险。

对于托管根 CA 的项目，请避免向任何用户或群组分配 Owner (roles/owner)、Editor (roles/editor) 和 CA Service Admin (roles/privateca.admin) 等基本角色。这种做法可防止意外删除、错误配置和过度曝光。请改用 Privileged Access Manager (PAM) 在安装并配置根 CA 后，根据需要通过正当理由和审批来获得即时 (JIT) 访问权限。

确保请求者群组负责处理证书请求的日常操作，并根据预定义的模板签发证书。

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

角色	说明	IAM 角色
证书管理员	设置和管理 CA 及证书基础架构。	Certificate Manager Owner (roles/certificatemanager.owner)、 CA Service Admin (roles/privateca.admin)
证书请求者	为工作负载请求证书。	Certificate Authority Service Certificate Requester (roles/privateca.certificateRequester)
工作负载（自动化服务账号）	由工作负载或流水线用于请求证书。	Certificate Authority Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester)
安全工程师或 PKI 所有者	管理证书政策、撤消和生命周期。	CA Service Operation Manager (roles/privateca.caManager)、 Certificate Authority Service Certificate Manager (roles/privateca.certificateManager)
DevOps 或平台工程师	管理负载平衡器上的证书部署等。	Certificate Manager Editor (roles/certificatemanager.editor)
审计员或合规性	监控证书及其使用情况。	Certificate Manager Viewer (roles/certificatemanager.viewer)、 Certificate Authority Service Auditor (roles/privateca.auditor)

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

我们建议您使用按项目进行 DNS 授权的方法，以便在多个区域、多个云平台以及整个软件开发生命周期 (SDLC) 中独立管理项目的多项授权。

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

使用 CAA 记录保护您的网域

证书授权机构授权 (CAA) 记录是域名系统 (DNS) 中的一种安全机制。借助 CAA 记录，网域所有者可以完全控制哪些公共证书授权机构 (CA) 可以为其网域颁发证书。此控制措施对于防止未经授权的证书签发至关重要。启用 CAA 后，欺诈性证书的攻击面会缩小，从而有效提高网站的安全性。

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

• pki.goog
• letsencrypt.org

Cloud Logging、Cloud Monitoring 和可见性

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

启用并汇总审核日志记录

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

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

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

我们建议您针对重要的证书管理器事件（例如根 CA 使用情况、证书过期和证书删除）设置基于日志的提醒。这些提醒有助于您对操作进行问题排查，例如证书创建失败率过高，并且可以触发下游流程来请求新证书或增加配额。

针对与权限相关的操作配置以下日志提醒和政策：

• 即将过期的证书
• 过期的公开证书
• CA 将在 30 天后过期
• 证书创建失败率高
• 过期的 CA 证书
• CA Service KMS 密钥问题

合规要求

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

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

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

• Google Cloud 合规性产品与服务
• CA Service 安全合规性
• PCI 数据安全标准合规性

后续步骤

• Certificate Authority Service 最佳实践
• mTLS 部署的架构