理解PKI（八）：CA 如何安全运营——密钥保护、CP/CPS 与业务连续性

前七篇从密码学、证书结构、签发、验证一直讲到 TLS、数字信封和时间戳，似乎已经走完了一张证书的技术旅程。但对 CA 来说，真正困难的部分才刚刚开始。

一次正确的签发并不难。难的是十年后仍能回答：根密钥有没有被复制，谁批准了这张证书，吊销服务中断时依赖方看到了什么，异地恢复有没有丢失签发状态，某次制度变更又从哪一天开始生效。

CA 运营的目标不是让一台签名服务器永不宕机，而是让每一次信任状态变化都经过授权、受到保护、能够恢复并留下证据。

这篇文章不再重复第五篇的系统模块，而是完成整个系列的最后一块拼图：怎样长期守住一个已经建立起来的信任体系。

一、运营安全不是设备清单，而是控制闭环

机房、HSM、防火墙、双人门禁和审计平台都只是控制手段。真正需要保护的是几类不同资产：

关键资产	失败后果	主要控制	应保留的证据
CA 私钥	可伪造证书或状态信息，可能摧毁整条信任链	HSM、分权、用途隔离、密钥仪式	仪式脚本、见证记录、设备和密钥清单
签发状态	序列号重复、错误回滚、无法证明签发历史	事务一致性、不可变日志、对账	申请、批准、签发和发布记录
CRL/OCSP	依赖方无法及时获知吊销状态	冗余发布、预生成、容量和故障策略	状态对象、发布时间、监控与告警记录
身份材料	错误签发、隐私泄露、争议时无法追溯	RA 审核、最小收集、访问控制	原始材料、核验方式、操作者和时间
CP/CPS 与策略	依赖方不知道证书能用于什么、CA 如何担责	版本管理、发布、审批和变更映射	生效版本、差异、批准人、适用证书范围
恢复能力	备份存在但无法恢复，灾难后产生第二套事实	异地副本、恢复脚本、定期演练	演练报告、RTO/RPO 实测值、遗留问题

这些控制必须形成闭环：

政策定义 ─► 权限与技术控制 ─► 业务执行 ─► 日志和证据
   ▲                                           │
   └──────── 审计、演练、事件复盘与策略更新 ◄──┘

如果 CPS 写着“双人控制”，系统却允许一个管理员独立调用签名接口，文件与实践已经分离；如果每天都做数据库备份，却从未在隔离环境恢复 HSM 密钥和签发状态，备份也还不是恢复能力。

二、网络分区要围绕信任边界，而不是照抄四个区

书中用公共区、服务区、管理区和核心区描述 CA 机房，这个模型至今仍有解释力，但区的数量不是答案。设计时真正要问的是：谁能到达什么系统，哪条路径可以触发签名，哪条路径只能发布已经签好的对象。

互联网 / RA
     │
     ▼
接入与服务区 ─────► Repository / CRL / OCSP
     │ 受控请求
     ▼
签发与管理区 ─────► 审核、策略、证书管理
     │ 最小协议
     ▼
密码核心区 ───────► HSM、CA 数据库、审计汇聚

离线根 CA ──仅在批准的仪式窗口激活──► 签下级 CA、根 CRL 或必要对象

离线根 CA 用降低可达性换取更小的攻击面。它不承担日常终端证书签发；平时断开业务网络，只在经过批准的密钥仪式中签署下级 CA、根 CRL 或其他明确允许的对象。在线签发 CA 则要面对自动化、高可用和更频繁的状态变化，因此需要更严格的接口授权、监控和快速吊销能力。

分区设计至少要验证四件事：

公共服务被攻破后，攻击者不能沿同一身份和管理面进入签发核心；
管理员终端不是直通 HSM 的万能跳板，管理操作经过专用通道和强认证；
证书、CRL、OCSP 响应从核心向外发布，但外部输入不能原路变成未审核的签名请求；
日志流向独立审计域，业务管理员不能同时操作系统并删除自己的痕迹。

云和容器不会取消这些边界，只会把物理网线变成账号、项目、租户、服务身份、策略和 API。把所有组件放进同一个云账号和管理员角色，并不比放在同一个二层网络更安全。

三、HSM 保护密钥，但不能替 CA 做决定

HSM 的核心价值是把私钥生成、保存和运算限制在经过验证的密码边界内，并对导入、备份、激活、使用和销毁提供受控接口。但它不能判断一次签发是否合理，也不能自动阻止权限配置错误。

HSM 能限制“密钥怎样被使用”，前提是 CA 已经正确决定“谁可以在什么条件下要求它做什么”。

根密钥仪式就是把这个前提变成可审计过程。以公共 TLS CA 为例，CA/Browser Forum《Baseline Requirements》2.2.8 要求相关 CA 密钥生成遵循书面的 Key Generation Script；特定根和下级 CA 的仪式要由合格审计员见证或完整录像，并由审计员出具报告。所有 CA 密钥生成还要在物理安全环境中，由可信角色按多人控制和知识分割原则执行，并记录活动。

一份可执行的密钥仪式通常包含：

冻结输入：批准仪式脚本、软件和固件版本、设备序列号、算法参数、证书 Profile 与参与人名单；
确认环境：清场、门禁、录像、时间源、网络隔离和防篡改封条检查；
建立多人控制：分别交付激活材料或密钥份额，任何单人都不能独立激活或恢复根密钥；
生成并核对：在目标密码模块中生成密钥，核对公钥、证书请求、指纹和用途；
备份与封存：按批准方案创建受保护备份，分别封装、登记并移送不同地点；
签署输出：只生成脚本列明的证书或状态对象，进行双人复核；
结束仪式：清除临时材料、关闭设备、核对清单，由参与人和见证者签署记录。

“三个人各拿一张卡”本身不等于多人控制。还要验证阈值是否真的生效、卡与 PIN 是否分离保管、替补和离岗流程是否存在，以及系统管理员能否通过重置角色绕过分权。

四、密钥备份、密钥托管和高可用是三件事

这三个概念经常被混为“密钥有副本”：

能力	解决的问题	典型方式	主要风险
密钥备份	原设备损坏后恢复同一 CA 能力	加密备份、HSM 克隆、分割份额	备份泄露、长期不可读、从未验证恢复
密钥托管	业务需要时恢复特定加密私钥	KMC、授权恢复流程	越权恢复、把签名私钥也纳入托管
高可用	单个节点故障时继续提供服务	HSM 集群、双机、跨故障域	一次错误同步到所有节点，误当作备份

CA 私钥通常需要可恢复，否则设备损坏可能迫使整个层级换根或换发证书；但恢复副本必须受到与生产密钥等强度的保护。用户加密私钥是否托管取决于业务和政策，用户签名私钥则强调签名者专有控制，不能因为“方便找回”就默认由 CA 留存。这个边界在第五篇已经详细说明。

恢复演练不能只验证“备份文件能解密”，还要在隔离环境完成一条最小闭环：

取出异地材料 → 达到多人阈值 → 恢复到目标密码模块
      → 核对公钥和对象标识 → 生成测试签名 → 验证签名
      → 清理演练密钥 → 记录时间、人员、偏差和整改

云 KMS 把设备外包，不把责任外包

托管 HSM 或云 KMS 可以降低硬件维护负担，但 CA 仍要决定：密钥位于哪个地域和租户，谁能管理策略，谁能调用签名，谁能禁用或销毁密钥，日志保存多久，服务中断和供应商退出时怎样迁移。

Google Cloud KMS 的官方文档就明确把 IAM、轮换计划、密钥版本启停与销毁等控制留给客户。它还建议把密钥和受保护数据放在不同项目，并避免使用无法区分“管理密钥”和“使用密钥”的宽泛项目角色。这类产品能力可以帮助落实分权，却不会自动生成符合 CA 业务语义的审批链。

评估云密码服务时至少确认：

密码模块的认证范围是否覆盖实际服务、固件和运行模式，而不只是同系列硬件；
CA 私钥能否导入、导出、复制或迁移，退出供应商时是否必须换钥；
管理面、调用面、审计面能否由不同身份和组织控制；
SLA 覆盖的是 API 可用性还是端到端签发能力，赔偿条款是否远低于业务损失；
密钥删除是否有等待期、双人批准和依赖扫描，密文或历史签名是否仍依赖旧版本；
供应商事件通报、取证材料、地域切换和子处理者责任是否写进合同。

以 Google Cloud 为例，Cloud HSM 文档当前说明多租户 HSM 采用通过 FIPS 140-2 Level 3 验证的模块，但项目仍要核对验证证书覆盖的硬件、固件、算法和服务模式。Cloud KMS/Cloud HSM SLA 只覆盖约定的加密、解密和签名请求，以服务抵扣作为救济，并不承诺 CA 从受理到签发的端到端可用性。其数据处理附录要求在获知 Data Incident 后及时通知客户，但这个定义不一定覆盖所有密钥服务异常；通知范围、时限、渠道、取证协助和升级联系人仍应落实到实际合同或订购文件，不能从产品介绍自行推定。

五、人员分权要覆盖正常流程和紧急流程

CA 常见的可信角色包括安全负责人、系统管理员、业务审核员、密码管理员、审计员和密钥分管者。分权的目标不是增加签字数量，而是消除一个人可以独立完成的危险闭环。

动作	发起	批准或复核	执行	独立证据
修改证书 Profile	策略或产品负责人	安全与合规角色	CA 管理员	变更单、测试结果、版本差异
签发高权限下级 CA	业务负责人	多方审批/审计见证	密钥仪式参与者	脚本、录像、证书指纹
吊销证书	订户、RA 或监控系统	按原因和风险分级	状态服务	请求、身份核验、CRL/OCSP 发布时间
恢复加密私钥	获授权业务方	合规与密钥管理角色	KMC 操作员	依据、份额参与者、交付记录
紧急停签	监控或事件响应人员	事后规定时限内复核	值班人员	触发证据、影响范围、恢复批准

紧急账号尤其容易破坏日常分权。它必须有明确启用条件、短时凭证、全程记录、使用后轮换和事后复核。一个封在保险柜里、十年没人测试过的“救火账号”，可能在真正事故中既登不上去，也说不清谁用过。

人员控制还应覆盖背景调查、岗位培训、定期轮换、休假代理和离岗回收。最危险的时刻往往不是员工在岗，而是职责变更后旧证书、门禁卡、HSM 角色和云 IAM 权限没有同步撤销。

六、CP、CPS 和证据把承诺连到现实

RFC 3647 把 Certificate Policy（CP） 定义为证书适用于特定群体或应用的一组规则，把 Certification Practice Statement（CPS） 定义为 CA 在签发、管理、吊销、续期或换钥时采用的实践。

两者最重要的区别不是文档名称，而是回答的问题：

层次	回答什么	典型内容	变化速度
CP	证书可以信到什么程度、适用于什么范围	身份保证等级、适用对象、策略 OID、依赖方边界	较稳定
CPS	这家 CA 怎样满足策略	身份核验、密钥控制、签发、吊销、审计、灾备	随实践更新
程序与记录	这一次具体做了什么	操作手册、工单、日志、仪式记录、演练报告	持续产生

RFC 3647 提供九类框架：介绍，信息发布，身份标识与鉴别，证书生命周期，设施/管理/操作控制，技术安全控制，证书与状态 Profile，合规审计，以及业务与法律事项。它是写作框架，不是把标题复制九遍就自动合规。

一份可审计的 CPS 应做到：

每个承诺都能映射到责任人、系统控制和证据；
公开版本不泄露门禁细节、网络地址和恢复秘密，敏感程序可由受控内部文件承接；
变更有版本、生效时间和适用范围，能判断某张历史证书受哪一版规则约束；
证书策略 OID、证书 Profile、订户协议和依赖方条款不互相冲突；
实际无法满足的条款及时修订或整改，而不是让文档长期描述一个不存在的系统。

CP 是信任承诺，CPS 是实现说明，日志和记录才是承诺已经被执行的证据。

七、RA 运营是一条有证据的状态机

RA 不只是收表格。它把现实身份、业务授权和证书生命周期连接起来，任何一个模糊状态都会变成错误签发或无法吊销。

申请 → 身份核验 → 业务审核 → 批准 → 制证/交付 → 使用
  │        │           │         │                    │
  └拒绝────┴补正───────┴撤回─────┴失败回滚            ├更新/换钥
                                                     ├信息变更
                                                     └吊销/暂停（仅在策略允许时）

更新、换钥、信息变更、暂停和吊销不能共用一个“重新申请”按钮。更新可能沿用部分已验证信息，换钥产生新的公钥绑定，主体信息变更需要重新核验，吊销则改变所有依赖方看到的状态。某些体系允许临时暂停，另一些证书 Profile 或根计划只接受永久吊销；RA 必须按适用规则映射，不能把内部“冻结”直接当成通用 X.509 语义。

如果适用策略确实支持暂停，恢复或解冻也必须是一条独立的受控迁移：重新认证请求者，核对暂停原因是否消失，按风险级别审批，并记录外部状态何时恢复。采用 X.509 certificateHold 的体系还要按适用 Profile 正确发布解除状态；不能只把业务库中的 frozen 改回 active，让 CRL、OCSP 与内部记录出现两个事实。

查询和客户服务同样属于状态机入口。证书内容、历史业务记录和当前状态应分别由 Repository、受控业务查询以及 CRL/OCSP 等权威来源提供，并记录查询范围和访问权限。客服受理补正、介质丢失、密钥疑似泄露或紧急吊销时，应先完成请求者认证和工单分级，再进入相应业务流程；电话或即时消息可以作为入口，但不能绕过正式审批和留痕直接改变证书状态。

每次状态迁移至少记录：请求者和代理关系、认证方式、目标证书、理由、材料版本、操作者、批准者、时间、结果，以及何时对外发布。批量签发和自动化 ACME 也不能丢掉这些字段，只是把人工工单变成机器可验证的授权记录。

身份材料、联系方式、设备信息和日志可能包含个人信息或重要业务数据。《个人信息保护法》要求目的明确、范围最小；《网络数据安全管理条例》自 2025 年起进一步要求网络数据安全制度以及加密、备份、访问控制、安全认证和事件处置。CA 因“以后可能审计”无限收集、无限保存材料，同样不是合规策略。保存期限应同时满足法定和业务追溯要求，到期后执行可证明的删除或匿名化。

八、业务连续性先区分哪些服务真的不能停

CA 的不同组件不应共享一个笼统的“全年可用率”：

服务	中断影响	连续性重点	恢复时必须核对
离线根签名	通常不影响日常终端签发	安全可用窗口、备用设备和材料	根密钥、公钥指纹、仪式授权
在线签发 CA	新证书、续期和换钥停止	事务一致性、队列和幂等	最后序列号、已签未发布对象、审批状态
CRL/OCSP	依赖方可能无法取得状态	多地域发布、预生成、缓存和容量	最新状态、CRL Number、thisUpdate/nextUpdate
RA 与客户服务	无法申请、核验或报告泄露	替代受理通道、身份认证和工单	未完成申请、紧急吊销请求、通知记录
审计与时间源	操作可能失去可信时间或追溯	独立日志、时间同步和缓冲	日志连续性、时间偏差、补传完整性

RTO 回答服务中断后多久恢复，RPO 回答最多允许丢失多少状态。对普通网页，丢失几分钟缓存也许可接受；对 CA，丢失一段已经完成的签发记录可能导致序列号重用、证书存在但数据库不知道，或恢复后错误撤销状态。因此 CA 的 RPO 不能只按数据库备份频率填写，还要考虑 HSM 计数、签发事务、发布队列和不可变审计记录怎样对账。

CA/Browser Forum 2.2.8 要求公共 TLS CA 维护事件响应与灾难恢复计划，每年测试、复核和更新，内容包括激活条件、应急/回退/恢复程序、责任、RTO、备份频率和异地密码材料。自 2025 年 12 月 1 日起，公共 TLS CA 还必须维护可执行的大规模吊销计划，每年通过桌面推演、模拟、并行测试或受控环境进行演练，并把经验反馈进计划。

这些要求不应被机械套到所有私有 CA，但揭示了一个通用原则：

连续性计划只有在演练中产生了实测时间、失败点和改进责任人，才从文档变成能力。

九、真正的灾难不是都切到备用机

不同事件需要不同恢复策略：

事件	第一动作	不能草率做什么	后续决策
单台 HSM 故障	停止该节点、核对集群和审计日志	立即认定密钥泄露	从健康节点继续或受控恢复
CA 私钥疑似泄露	隔离签名能力、保全证据、启动事件计划	用同一密钥在灾备端继续签发	判断妥协范围、吊销下级/终端证书、换钥和通知
签发数据库损坏	停签、冻结发布队列、对账不可变记录	直接恢复旧快照后重新开放	重建真实状态，处理已签未记或已记未发对象
RA 账号被接管	禁用身份、暂停相关申请、追查审批链	只改密码后继续处理原工单	撤销错误签发、重新核验申请、修复权限
OCSP/CRL 中断	切换只读发布节点、检查缓存和 nextUpdate	临时发布不一致的“good”状态	恢复权威状态源，通知依赖方并复盘容量
全站灾难	启动异地计划和指挥体系	把“能启动”当成“状态正确”	核对密钥、数据库、日志、状态对象后分级恢复

尤其要区分设备故障和密钥妥协。前者可能从受保护副本恢复，后者必须假设攻击者也能签名，通常涉及停止使用、通知、吊销、换钥和大规模重签。把二者都处理成“切换备用 HSM”，会把一次安全事件变成持续伪造能力。

演练场景也不应永远是“主机宕机”。至少轮换测试密钥份额持有人缺席、云 KMS 地域不可用、错误 Profile 批量签发、CRL 发布延迟、时间源漂移、审计平台写满和供应商停止服务。

十、书中建议、现行要求与待确认项要分开

《PKI、CA 与数字证书技术大全》出版于 2015 年。它对控制目标仍有价值，但许可名称、办理路径、标准版本和具体数字不能直接作为 2026 年结论。

主题	书中建议（历史线索）	截至 2026-08-06 的现行要求	项目必须确认
公众电子认证服务	准备法人、人员、资金、场所、检测和运行材料，申请电子认证服务许可	《电子签名法》规定第三方认证由依法设立的提供者提供；工信部《电子认证服务管理办法》规定许可、业务规则/证书策略、内部审计和服务承接	业务是否属于面向社会公众的第三方电子认证；最新办事指南、许可状态和变更事项
电子认证使用密码	申请“电子认证服务使用密码许可证”，完成安全审查和互联互通测试	国家密码管理局令第 6 号已于 2026-07-01 施行，明确许可证、技术评审、系统安全性审查、互联互通测试和实地查勘；持证机构每年至少开展一次密码应用合规性评估，及时整改，并向属地密码管理部门报送评估报告	采用的密码产品/服务、系统境内部署、技术材料、管理体系、年度评估与整改责任和申请路径
电子政务电子认证	通过能力评估并进入目录，跨区域备案	国家密码管理局令第 4 号自 2024-11-01 施行：需取得资质，公布并备案业务规则和证书策略；认证信息至少保存至证书失效后 5 年，每年至少一次合规评估，暂停/终止前 60 日报告	是否服务政务活动、委托 RA 范围、互信接入、属地备案和承接安排
商用密码应用安全性评估	用机房、系统和密码产品检测材料证明安全性	国家密码管理局令第 3 号要求适用的重要网络与信息系统同步规划建设运行密码保障系统，运行前评估，运行后每年至少一次评估	系统是否落入法定适用范围、等级与指标、评估机构资质、整改周期
公共 TLS CA	以安全机房、HSM、多人分权和灾备支撑公众信任	CA/Browser Forum BR 2.2.8 对公共 TLS CA 规定密钥仪式、密码模块、日志、年度灾备和大规模吊销演练；浏览器根计划还会增加独立要求	是否申请公共信任、目标根计划、审计准则、证书类型和生效日期
企业私有 CA	参考 CA/KMC 机房和运营规范建设	不会因为使用 X.509 就自动适用公共 TLS 根计划或公众电子认证许可；仍需按系统、行业、数据和密码使用场景判断	信任边界、行业监管、等保/密评、个人信息与重要数据、合同责任
HSM 与云 KMS	根密钥进入硬件密码设备，份额异地保管	应使用满足目标制度和技术标准的密码产品/模块；云服务不能替代客户的 IAM、用途、轮换、删除、审计和退出责任	认证证书及覆盖版本、密钥可迁移性、地域/租户、SLA、事件通知和退出方案

这些制度并不一定互斥：同一机构可能因同时提供公众电子认证、使用商用密码或服务电子政务而叠加满足多组要求。表格不是法律意见，也不能替代主管部门办事指南；它的作用是阻止团队把“书里写过”“拿到过某张许可证”或“产品通过某项认证”误当成整个 CA 项目已经合规。

十一、用一次审计追问检验 CA 是否真的可运营

设计评审或年度复核时，可以连续追问：

根和签发 CA 私钥分别在哪里，哪些人组合起来才能激活？
上一次密钥仪式使用哪版脚本，输出对象和设备序列号能否复核？
HSM 损坏、密钥疑似泄露和管理员误删密钥分别走什么流程？
CP/CPS 的当前版本、生效时间和适用证书能否从证书反查？
RA 如何证明申请者身份、代理权限、审核结论和用户意愿？
一个错误签发从发现到停止签发、吊销、通知和替换需要多久？
OCSP、CRL 和 Repository 中断时，依赖方会看到失败、旧状态还是错误的成功？
从异地备份恢复后，怎样证明没有序列号回退、状态丢失和日志断点？
云 KMS 或外部 RA 退出时，密钥、数据、日志、责任和服务由谁承接？
最近一次演练暴露了什么问题，谁在什么期限内完成整改？

如果这些问题只能得到“有 HSM”“每天备份”“通过了认证”这样的回答，说明团队拥有设备和证书，却还没有形成运营能力。

十二、总结

CA 的信任不是在根证书生成那天一次性铸成的。它每天都在身份核验、审批、密钥调用、证书签发、状态发布、人员变更、日志保存和故障恢复中被重新证明。

HSM 把密钥限制在密码边界内，密钥仪式和人员分权限制谁能使用它；网络分区限制攻击路径，CP/CPS 公开信任承诺和实践，RA 状态机保留每次业务决定，审计证据让外部能够复核，灾备与事件演练则证明这套体系在异常时仍不会产生第二套事实。

一张证书的可信度，最终不会高于签发它的组织在最混乱时仍能遵守的那套流程。

至此，“理解 PKI”系列从密码学原理走到了信任运营。证书只是公开可见的结果；真正托住它的，是背后长期运行的人员、制度、设备、证据和责任。

参考资料

法规、标准和产品资料核验于 2026-08-06。不同类型 CA 的适用制度不同，公共 TLS、公众电子认证、电子政务电子认证和企业私有 PKI 不能互相套用；生产与合规决策应再次核对主管部门现行文本、办事指南和目标根计划。

系列文章

笔记整理自《PKI、CA 与数字证书技术大全》第 23～26 章，并按现行中国法律法规、RFC 3647、CA/Browser Forum 2.2.8、NIST 与云 KMS 官方文档校正和补充。