pki-design

PKI 设计

公钥基础设施（PKI）负责颁发和管理数字证书，为身份验证、加密和签名提供基础。在以 Azure 为中心的混合环境中，这意味着要结合可信 CA 层级、Key Vault 存储、自动化生命周期管理和基于证书的身份验证。

适用场景

为以下场景设计证书的颁发、分发和生命周期管理：Entra 防钓鱼 CBA、服务的 TLS / mTLS、设备身份（Wi-Fi 802.1x、VPN）、代码签名和 S/MIME。当问题是“证书从哪里来，如何续期”时，请使用此技能；如果问题是“如何存储一个机密”，则不适用。

请勿将此技能用于 Key Vault 机密/密钥（azure-key-vault）或 Entra ID 模型（entra-id）。

根据使用场景选择 CA 策略

使用场景是……	CA 选择	说明
面向互联网的 TLS（网站、API）	公有 CA（DigiCert、GlobalSign、Let's Encrypt）	必须使用；浏览器不信任私有 CA
内部应用 TLS、mTLS、服务间通信	内部颁发 CA（AD CS 或托管 CA）	内部信任私有 CA 链
Entra 基于证书的身份验证	将内部 CA 发布到 Entra 信任存储	配合强绑定策略使用
设备身份（Wi-Fi 802.1x、VPN）	AD CS 或第三方 PKI + Intune SCEP/PKCS	自动注册至关重要
代码签名	公有 CA 的 EV 代码签名证书	使用硬件令牌；严格保护
S/MIME 电子邮件签名/加密	第三方公有 CA（DigiCert、Sectigo）	外部收件人不信任内部 CA
短期工作负载证书（Kubernetes）	使用 ACME 或内部颁发者的 cert-manager	TTL 为几分钟到几小时

**经验法则：**切勿将私有 CA 用于面向互联网的服务，也切勿大规模使用公有 CA 颁发内部证书（成本 + 灵活性）。应使用两条不同的证书链。

方法

1. 设计 CA 层级 — 离线根 CA + 一个或多个在线签发 CA。 根 CA 为签发 CA 证书签名（有效期较长，例如 10-20 年），签发 CA 为终端实体 证书签名（有效期为 1-2 年）。 验证：除 CRL 签名和签发 CA 续期外，根 CA 主机应关机或处于气隙隔离状态。

2. 使用 HSM 保护密钥 — 根 CA 私钥存储在 HSM 中（FIPS 140-2 Level 2+）。 云原生环境使用 Azure Managed HSM；AD CS 使用本地 HSM。切勿存放在未受保护的 文件系统中。 验证：certutil -getreg ca\CSP\Provider 显示 HSM 提供程序，而不是 "Microsoft Software Key Storage Provider"。

3. 使用 Key Vault 管理存储和生命周期 — 所有服务证书都使用 Azure Key Vault 证书。与受支持的签发 CA（DigiCert、GlobalSign，以及通过 Key Vault Acmebot 或合作伙伴连接器接入的内部 CA）集成，实现自动续期。 验证：证书对象已配置 lifetime_actions，在有效期达到 75% 时自动续期；仅新签发证书需要手动操作。

4. 为设备和用户证书启用自动注册 — 通过 GPO 为域成员启用 AD CS 自动注册；对于云管理设备，使用 Intune SCEP 或 PKCS connector。切勿通过电子邮件发送 PFX 文件。 验证：Intune 证书配置文件报告的部署成功率 > 95%；用户/设备证书显示在个人存储区中。

5. 规划吊销机制 — 将 CRL（证书吊销列表）发布到 HTTP 终结点；设置 OCSP 响应程序以支持实时查询。二者都必须具备高可用性；如果无法访问 CRL，高保证级别证书的现代客户端会默认拒绝。使用 CDN 托管 CRL HTTP 终结点。 验证：从公共互联网（如果是外部证书）和所有内部客户端均可访问 CRL 终结点；OCSP 响应程序正常运行时间 > 99.9%。

6. 监控到期时间 — Key Vault 会针对即将到期的证书发送事件。将事件流式传输到仪表板。对于 AD CS，按计划运行脚本（certutil -view）。跟踪证书到期前 90/60/30/7 天的情况。 验证：生产环境中没有未受监控的即将到期证书；到期前 60 天会触发警报。

7. 遵守轮换规范 — 应在签发前规划轮换，而不是等到临近到期时才处理。服务团队负责续期自动化；PKI 团队负责 CA 和警报基础设施。

防护措施

• 根 CA 必须始终离线。 根 CA 一旦遭到入侵，它曾经或将来签发的所有证书都会受到影响。关机 > 气隙隔离 > 网络隔离的虚拟机。
• 签发 CA 密钥必须使用 HSM。 存储在软件中的签发 CA 密钥是导致信任体系彻底失效的单点故障。
• 绝不允许生产证书在无声无息中到期。 这会在最糟糕的时刻导致服务中断。应自动续期或提前 60 天发出警报。
• 在依赖证书前规划吊销机制。 没有可用 CRL/OCSP 的证书系统无法真正吊销证书，这意味着被入侵的证书会一直有效到期。
• 面向互联网的 TLS 始终使用公共 CA。 浏览器不会信任私有证书链。
• 不要在不同安全域之间共用通配符证书。 一处遭到入侵，所有子域名都会受影响。应为每项服务单独签发证书并自动续期。
• 代码签名密钥应使用硬件令牌。 软件存储的代码签名密钥一旦被盗，往往会出现在恶意软件中。

常见反模式

• “我们刚把 PFX 通过电子邮件发给开发人员”——密钥暴露。使用 Key Vault + 托管标识 / SCEP。
• “我们的根 CA 在线，因此可以轻松续订颁发证书”——这种便利会危及整个信任链。根 CA 应离线。
• “颁发 CA 使用软件 CSP——HSM 太贵了”——与 CA 密钥被盗后的事件响应成本相比，硬件成本更低。
• “终端实体证书有效期设为 5 年，因为续订很麻烦”——证书遭到泄露时，长期有效的证书会带来风险。缩短有效期并实现自动化。
• “CRL 放在公司网络内的一台服务器上”——外部用户无法验证；CRL 服务中断会导致身份验证失败。使用 CDN 分发。
• “颁发证书后我们再设置监控”——证书过期事故总是在监控就位前发生。
• “所有环境（dev/test/prod）都使用同一张证书”——开发环境证书泄露会影响生产环境。按环境分别使用证书。

提示词示例

• 设计一个采用离线根 CA、两个颁发 CA 和 HSM 密钥保护的 PKI 层级结构。
• 通过 Azure Key Vault 为我们的 App Service 工作负载颁发并自动轮换证书。
• 使用我们的内部 CA 和强绑定设置 Entra 基于证书的身份验证。
• 规划通过 Intune 为 Wi-Fi 802.1x 部署 SCEP/PKCS 证书。
• 为我们的内部 CA 配置 CRL 和 OCSP，并使用 CDN 支持的 CRL 终结点。
• 监控 Key Vault 和 AD CS 中的证书过期情况，并自动发送警报。

Microsoft Learn

• Key Vault 证书：https://learn.microsoft.com/azure/key-vault/certificates/about-certificates
• Key Vault Managed HSM：https://learn.microsoft.com/azure/key-vault/managed-hsm/overview
• Entra 基于证书的身份验证：https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication
• CBA 强身份验证绑定：https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive
• Intune 证书配置文件：https://learn.microsoft.com/mem/intune/protect/certificates-configure
• Intune SCEP：https://learn.microsoft.com/mem/intune/protect/certificates-scep-configure
• AD CS 设计指南：https://learn.microsoft.com/windows-server/identity/ad-cs/active-directory-certificate-services-overview
• Key Vault 中的证书生命周期：https://learn.microsoft.com/azure/key-vault/certificates/create-certificate