证书固定：TLS 安全的双刃剑

1. 理解证书链
2. 跨平台的证书固定
3. 固定困境：固定什么
4. 公钥固定：推荐方法
5. 通用名称陷阱：不要通过 CN 固定
6. 真实世界的固定失败
7. 险些失误：测试拯救了一切
8. 测试证书固定：不要走捷径
9. 何时使用证书固定
10. 证书固定的替代方案
11. 结论

证书固定作为一种安全技术应运而生，用于对抗中间人攻击和流氓证书颁发机构。通过将预期的证书信息硬编码到应用程序中，开发人员可以确保只有在与合法服务器通信时连接才会成功。然而，这种增强的安全性伴随着显著的运营复杂性和风险。配置错误的固定或过期的证书可能会导致应用程序无法使用，需要紧急更新并让用户感到沮丧。

本文探讨了跨浏览器、移动应用程序和后端服务的证书固定。我们将剖析证书链层次结构，评估要固定的元素，并理解安全性与运营灵活性之间的权衡。通过真实事件和行业实践，我们揭示了为什么证书固定既强大又危险。

理解证书链

在深入研究固定策略之前，理解证书链结构至关重要。TLS 证书不是孤立存在的——它们形成了从服务器证书到受信任根证书颁发机构的分层信任链。

三层层次结构

TLS 证书链通常由三个级别组成，每个级别都有不同的用途：

🔗 证书链结构

叶证书（终端实体证书）

• 安装在 Web 服务器或应用程序上的证书
• 包含你的域名（例如 example.com）
• 有效期最短（目前最长 398 天，到 2029 年将缩短至 47 天）
• 由中间证书签名
• 链中最频繁更换的证书

中间证书

• 由根 CA 颁发用于签署叶证书
• 充当根证书和叶证书之间的缓冲
• 典型有效期：3-10 年
• 可以在不影响根证书信任的情况下被吊销
• 链中可能存在多个中间证书

根证书

• 位于链顶部的自签名证书
• 嵌入在操作系统和浏览器中
• 有效期极长：15-25 年
• 由于分发挑战很少更改
• 被攻破需要操作系统/浏览器更新才能移除

证书链通过加密签名工作。根 CA 签署中间证书，中间证书签署你的叶证书，客户端验证链上的每个签名，直到到达其证书存储中的受信任根证书。

为什么存在这种层次结构

三层结构不是任意的——它提供了关键的运营和安全优势：

🛡️ 层次结构优势

根证书保护

• 根私钥保存在安全设施的离线环境中
• 最大限度地减少被攻破的风险
• 减少频繁签名操作带来的运营风险

运营灵活性

• 中间证书可以在不更换根证书的情况下被吊销
• 可以在不需要操作系统/浏览器更新的情况下颁发新的中间证书
• 允许 CA 分段运营（地理位置、产品线）

风险隔离

• 中间证书被攻破限制了损害范围
• 叶证书被攻破只影响特定域名
• 分层安全减少了单点故障

在决定固定什么时，这种层次结构变得至关重要。每个级别在安全性和运营灵活性之间提供不同的权衡。

跨平台的证书固定

证书固定的实现在浏览器、移动应用程序和后端服务之间存在显著差异。每个平台都有不同的能力、约束和用例，影响固定策略。

浏览器固定：有限且衰落

现代浏览器在很大程度上已经放弃了对 Web 应用程序自定义证书固定的支持：

⚠️ 浏览器固定现实

HTTP 公钥固定（HPKP）- 已弃用

• 2015 年引入，允许网站指定固定的证书
• Chrome 在 2017 年弃用，2018 年移除
• Firefox 和其他浏览器也纷纷效仿
• 原因：太危险——配置错误可能永久破坏网站

当前浏览器方法

• 浏览器为高价值域名维护自己的固定列表
• Google 固定自己的域名（google.com、gmail.com 等）
• 预加载的固定编译到浏览器代码中
• 不适用于第三方网站

HPKP 失败的原因

• 配置错误的固定将用户锁定在网站之外
• 攻击者可以使用 HPKP 进行勒索攻击
• 没有损坏固定的恢复机制
• 运营负担超过了安全优势

对于 Web 应用程序，证书固定实际上不可用。浏览器依赖标准的 CA 信任模型以及证书透明度等额外保护。

移动应用程序固定：常见但有风险

移动应用程序代表了当今证书固定的主要用例：

📱 移动固定特征

iOS 实现

• 通过 NSURLSession 和应用传输安全提供原生支持
• 可以固定证书或公钥
• 在应用程序代码中实现
• 需要应用更新才能更改固定

Android 实现

• 网络安全配置（Android 7.0+）
• 声明式 XML 配置
• 可以固定证书或公钥
• 也需要应用更新才能更改固定

常见用例

• 银行和金融应用程序
• 处理敏感数据的医疗保健应用
• 具有高安全要求的企业应用程序
• 与已知受控服务器通信的应用

当你控制客户端和服务器、可以协调更新并且安全优势证明运营复杂性合理时，移动固定是有意义的。

后端服务固定：受控环境

后端服务与其他后端服务通信代表了另一种固定场景：

🔧 后端固定优势

受控环境

• 客户端和服务器都在你的控制之下
• 可以协调证书更新
• 自动化部署减少更新摩擦

微服务通信

• 服务到服务的身份验证
• 带固定的双向 TLS（mTLS）
• 零信任架构实现

API 客户端库

• 与特定 API 通信的 SDK
• 已知的证书基础设施
• 可以将固定与库更新捆绑在一起

后端固定的风险低于移动固定，因为更新可以快速部署而无需用户参与。

固定困境：固定什么

选择固定什么涉及在安全性和运营灵活性之间取得平衡。每个选项——根证书、中间证书或叶证书——都呈现出不同的权衡。

固定叶证书：最大安全性，最大风险

固定服务器的叶证书提供最强的安全性，但会带来重大的运营挑战：

🚫 叶证书固定风险

需要频繁轮换

• 叶证书在 398 天后过期（很快将缩短至 47 天）
• 每次证书续订都需要应用程序更新
• 使用 47 天证书：每年至少需要 7-8 次更新

紧急情况

• 私钥被攻破需要立即更换证书
• 在部署新证书之前需要应用程序更新
• 使用旧应用版本的用户无法连接
• 没有优雅的迁移路径

运营负担

• 协调证书更新与应用发布
• 在部署前测试固定更新
• 管理具有不同固定的多个应用版本
• 破坏连接的高风险

除非在可以管理运营复杂性的极高安全场景中，否则很少推荐叶证书固定。

固定中间证书：平衡方法

固定中间证书提供了一个中间地带：

⚖️ 中间证书权衡

优势

• 中间证书持续 3-10 年
• 需要更少的应用程序更新
• 叶证书轮换不影响固定
• 相比不固定有合理的安全改进

劣势

• CA 可以使用相同的中间证书为你的域名颁发证书
• 不能防止 CA 被攻破
• 中间证书轮换时仍需要更新
• 可能存在多个中间证书（需要固定所有）

最佳实践

• 固定当前中间证书加备份中间证书
• 监控 CA 关于中间证书更改的公告
• 在中间证书过期之前做好更新计划
• 首先使用暂存中间证书进行测试

中间证书固定是移动应用程序最常见的方法，在安全性和运营可行性之间取得平衡。

固定根证书：最小安全优势

固定根证书提供的安全改进最少：

⚠️ 根证书固定限制

有限的安全价值

• 根 CA 可以为任何域名颁发证书
• 不能防止 CA 被攻破攻击
• 相比标准信任模型提供最小保护
• 只能防止使用不同根 CA 的攻击

运营优势

• 根证书持续 15-25 年
• 需要非常不频繁的更新
• 叶证书和中间证书轮换不影响固定

何时有意义

• 限制到特定 CA（例如，只信任 DigiCert 根证书）
• 减少被攻破的 CA 的攻击面
• 符合 CA 限制的合规要求

考虑到最小的安全改进，根证书固定很少值得实施。

公钥固定：推荐方法

与其固定整个证书，固定公钥提供了更好的灵活性：

✅ 公钥固定优势

证书轮换无需更改固定

• 新证书可以使用相同的密钥对
• 固定在证书续订期间保持有效
• 减少更新频率

备份密钥支持

• 提前生成备份密钥对
• 固定当前和备份公钥
• 如果主密钥被攻破，切换到备份密钥
• 提供紧急恢复路径

实现

• 从证书中提取公钥
• 对公钥进行哈希（通常是 SHA-256）
• 将哈希存储在应用程序中
• 在 TLS 握手期间进行比较

公钥固定是行业推荐的方法，在保持运营灵活性的同时提供安全优势。

实现公钥固定

技术实现涉及提取和哈希公钥：

# 从证书中提取公钥
openssl x509 -in certificate.pem -pubkey -noout > pubkey.pem

# 生成公钥的 SHA-256 哈希（SPKI 格式）
openssl x509 -in certificate.pem -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

生成的 base64 编码哈希就是你在应用程序中固定的内容。在 TLS 握手期间，提取服务器的公钥，对其进行哈希，并与你固定的哈希进行比较。

🔑 密钥管理最佳实践

始终固定多个密钥

• 当前生产密钥
• 备份密钥（预先生成，安全存储）
• 可选：中间 CA 公钥

密钥轮换策略

• 部署新固定时生成备份密钥
• 将备份密钥安全地离线存储
• 轮换时，备份变为主密钥，生成新备份
• 在轮换前更新固定以包含新备份

紧急程序

• 记录密钥被攻破响应程序
• 保持快速部署应用更新的能力
• 考虑终止开关或远程固定更新机制
• 定期测试紧急程序

通用名称陷阱：不要通过 CN 固定

一些开发人员试图通过验证证书的通用名称（CN）或主题备用名称（SAN）来实现固定。这种方法从根本上是有缺陷的：

🚫 为什么 CN 固定失败

没有加密绑定

• CN 只是证书中的一个文本字段
• 任何 CA 都可以使用你的域名颁发证书
• 不验证证书实际上是你的
• 不提供任何安全优势

攻击场景

• 攻击者攻破任何受信任的 CA
• 为你的域名（victim.com）请求证书
• 证书具有正确的 CN 但错误的公钥
• 你的 CN 验证通过，攻击者拦截流量

你实际上在验证什么

• 标准 TLS 库已经验证 CN/SAN
• 你在重复现有验证
• 没有添加任何安全层
• 为没有好处创建维护负担

CN 验证不是证书固定——它是不提供安全改进的冗余验证。

什么真正提供安全性

真正的证书固定验证加密属性：

✅ 加密验证

公钥固定

• 验证实际的加密密钥
• 没有私钥访问权限无法伪造
• 提供针对 CA 被攻破的真正安全性

证书固定

• 验证包括签名在内的整个证书
• 确保精确的证书匹配
• 比公钥固定更强但灵活性较差

证书链固定

• 验证中间证书或根证书
• 限制哪些 CA 可以颁发有效证书
• 平衡安全性和运营灵活性

关键见解：固定加密材料（密钥、证书），而不是元数据（CN、组织名称）。

真实世界的固定失败

证书固定失败导致了高调的中断，说明了运营风险：

⚠️ 著名的固定事件

移动银行应用

• 证书续订被遗忘，固定未更新
• 在部署新证书之前需要应用更新
• 数千用户无法访问银行服务
• 紧急应用更新匆忙通过审批流程

企业应用程序

• CA 轮换了中间证书
• 已部署应用程序中的固定未更新
• 整个移动劳动力无法连接
• 需要紧急证书回滚

API 客户端库

• 固定的叶证书过期
• 使用该库的所有应用程序都损坏
• 开发人员被迫更新和重新部署
• 整个客户群的服务中断

这些事件有共同的主题：证书轮换计划不足、缺乏备份固定，以及低估了证书和应用程序更新之间所需的协调。

险些失误：测试拯救了一切

我曾经通过严格的轮换前测试——以及在被驳回时的坚持——险些避免了一次灾难性的中断。我们的移动应用程序使用了混合固定方法：它将通用名称映射到特定的公钥固定。虽然从纯安全角度来看并不理想，但这种设计提供了运营灵活性——只要公钥保持固定，我们就可以在不更新应用的情况下使用相同的 CN 轮换证书。

在一次例行证书轮换期间，我的团队遵循了我们的标准程序：在部署到生产环境之前，在暂存环境中测试新证书。测试失败了。连接被拒绝，应用无法与我们的服务器通信。

当测试团队说"太难了"

测试团队报告了失败，但很快就驳回了它。"证书固定很难测试，"他们说。“我们在 UAT 中禁用了固定——这就是我们看到失败的原因。这可能只是一个配置问题。我们已经测试了其他所有内容，它工作正常。”

这个回应让我深感不安。他们因为"固定失败太常见"而在 UAT 中禁用了证书固定，这意味着他们的测试没有验证实际的生产行为。距离计划的生产发布只剩下两个小时，我决定亲自调查，而不是接受驳回。

UAT 固定缺口

测试团队的轻视态度揭示了一个危险的做法：他们在 UAT（用户验收测试）环境中禁用了证书固定。他们的理由是务实的但有缺陷的——固定使测试更难，所以他们移除了它。

🚫 禁用固定陷阱

他们为什么在 UAT 中禁用固定

• "证书固定太难测试"
• UAT 证书经常更改或过期
• 用于测试的自签名证书
• 测试团队缺乏更新固定的权限
• "它减慢了我们的测试周期"
• "我们会在生产监控中捕获真正的问题"

危险的后果

• UAT 测试没有验证任何关于证书固定的内容
• 所有与固定相关的问题只会出现在生产环境中
• "成功"的 UAT 测试带来的虚假信心
• 生产环境成为真正的测试环境
• 用户会遇到测试从未捕获的失败

实际发生的情况

• 测试团队在 UAT 中运行完整的测试套件
• 所有测试都通过了（因为固定被禁用）
• 他们报告"准备好生产发布"
• 证书轮换会破坏生产环境
• 只有我启用固定的暂存测试捕获了问题

我坚持维护一个启用证书固定的单独暂存环境，正是为了捕获这些问题。测试团队认为这是多余的和过度谨慎的。这次事件证明了相反的情况。

我打开代码并开始逐行检查。固定逻辑、CN 映射、公钥验证——每个组件都需要仔细审查。时间在流逝，但在不理解失败的情况下匆忙发布将是鲁莽的。

经过一个小时的调查，我发现了问题：新证书的通用名称结构与预期不同。

🔍 发现（发布前 2 小时）

我在代码中发现的内容

• 证书提供商在续订期间更改了 CN 格式
• 旧证书：CN=api.example.com
• 新证书：CN=*.example.com（通配符）
• 应用的 CN 到固定映射逻辑期望精确匹配
• 通配符 CN 与硬编码映射不匹配
• 所有连接都会被拒绝

如果部署的影响

• 整个移动用户群无法连接
• 没有应用更新就没有立即修复
• 应用商店审批流程：最少 1-3 天
• 潜在的收入损失和声誉损害
• 紧急回滚将是唯一选择

时间线

• 测试团队报告失败但驳回了它
• 距离计划发布还有 2 小时
• 逐行代码调查揭示了根本原因
• 发布在剩余 1 小时时被取消
• 通过坚持和调查避免了灾难

我立即取消了证书轮换，距离计划的发布窗口只剩一个小时。我们与证书提供商合作，颁发了一个具有原始 CN 格式的新证书，保持与已部署应用程序的一致性。轮换被重新安排，并在彻底测试确认 CN 符合我们的期望后成功完成。

险些失误的教训

这次经历强化了几个关键原则，特别是关于组织文化以及调查失败而不是驳回失败的重要性：

✅ 测试最佳实践

永远不要在 UAT 中禁用固定

• 如果生产环境中启用了固定，则必须在 UAT 中启用
• "太难测试"意味着你会在生产环境中发现问题
• UAT 必须完全镜像生产行为
• 在 UAT 中使用类似生产的证书
• 跨环境维护固定同步
• 接受运营负担作为必要的验证
• 如果你不能测试它，你就不能安全地部署它

永远不要驳回测试失败

• 证书固定失败是信号，不是噪音
• "太难测试"不是可接受的回应
• 调查每个失败到根本原因
• 不要假设"它会在生产环境中工作"
• 坚持理解为什么测试失败

在轮换前始终测试

• 在暂存环境中测试新证书
• 使用实际的应用程序构建，而不是模拟器
• 验证所有证书属性：CN、SAN、公钥、链
• 如果可能，使用多个应用版本进行测试
• 记录预期的证书属性
• 如有必要，逐行调查

为运营灵活性而设计

• CN 到固定映射为密钥轮换提供了灵活性
• 可以在不更新应用的情况下更新公钥（在相同 CN 内）
• 减少所需应用更新的频率
• 平衡安全性与运营现实

保持协调

• 清楚地记录证书要求
• 向证书提供商传达要求
• 在接受交付之前验证证书属性
• 准备好回滚程序
• 安排有足够测试时间的轮换

混合方法——使用 CN 映射到公钥固定——代表了一种务实的妥协。纯公钥固定会更安全，但每次密钥轮换都需要应用更新。纯 CN 验证不会提供任何安全性。我们的方法允许我们在 CN 保持一致的情况下轮换密钥而无需应用更新，同时仍然通过固定的公钥验证加密属性。

🎯 设计考虑

适当的设计降低风险

• 将证书身份（CN）与加密验证（公钥）分开
• 允许每个 CN 有多个固定以实现优雅轮换
• 在初始部署中包含备份固定
• 为证书提供商更改而设计
• 为紧急情况做计划

环境配置

• 在包括 UAT 在内的所有环境中启用固定
• 如果测试团队禁用固定，维护启用它的单独暂存环境
• 如有必要，使用特定于环境的固定
• 将固定配置与证书基础设施一起维护
• 不要为了方便而牺牲测试覆盖率
• 接受适当的测试需要努力
• 如果你不能在启用固定的情况下测试，你就不能安全地部署

文档至关重要

• 记录固定架构和理由
• 维护固定的 CN 和公钥列表
• 记录证书提供商要求
• 为轮换程序创建运行手册
• 在团队成员之间共享知识

文化考虑

• 培养调查而不是驳回测试失败的文化
• 授权工程师在发现问题时取消发布
• 在发布前分配适当调查的时间
• 不要接受"太难测试"作为有效理由
• 将证书轮换视为高风险更改

这次事件表明，适当的设计和严格的测试不是可选的奢侈品——它们是防止自我造成的中断的基本保障。更重要的是，它暴露了测试团队方法中的关键缺陷：他们因为"太难测试"而在 UAT 中禁用了证书固定，这意味着他们的测试没有验证任何关于生产行为的内容。

测试团队运行了他们的完整测试套件并报告"准备好生产"。所有测试都通过了——因为固定被禁用了。他们通过不反映现实的测试创造了虚假的安全感。只有我坚持维护启用固定的单独暂存环境才捕获了问题。没有它，证书固定的第一次测试将在生产环境中进行，数千用户无法连接。

这次事件验证了一个有争议的决定：维护启用固定测试的运营负担。许多组织因为"失败太常见"而在测试环境中禁用固定，但这会创建一个危险的缺口，生产环境成为真正的测试环境。启用固定测试的困难不是一个错误——它是一个功能，强制执行适当的证书管理实践并在问题到达用户之前捕获它们。

花费两个小时调查节省了数天的危机管理、紧急应用更新和潜在的业务影响。每次证书轮换都应被视为高风险操作，需要与主要代码部署相同的谨慎和验证。每次测试失败都值得调查，而不是驳回——特别是在处理证书固定时，失败的后果是立即和严重的。

测试证书固定：不要走捷径

在非生产环境中禁用证书固定的诱惑很强，但它破坏了测试的整个目的：

🚫 适得其反的捷径

在 UAT 中禁用固定的常见理由

• "证书固定太难测试"
• "我们在 UAT 中使用自签名证书"
• "固定失败在测试中太常见"
• "它减慢了我们的测试周期"
• "生产证书无论如何都是不同的"

为什么这些理由失败

• 测试应该验证生产行为
• 如果难以测试，就难以操作
• 常见的失败表明真正的问题
• 缓慢的测试优于生产中断
• 不同的证书仍应遵循相同的固定规则

✅ 适当的测试方法

在所有环境中维护固定

• 在 UAT 中使用类似生产的证书
• 跨环境保持固定同步
• 首先在 UAT 中测试证书轮换程序
• 验证固定逻辑正常工作
• 在生产之前捕获配置问题

接受运营负担

• 是的，在 UAT 中管理证书更难
• 是的，它需要团队之间的协调
• 是的，它减慢了一些测试场景
• 但它防止了生产灾难
• 困难就是重点——它强制执行适当的实践

在 UAT 中禁用固定的组织通常只在生产环境中发现问题，在那里影响是严重的，恢复选项是有限的。在测试环境中维护固定的运营负担远小于影响数千或数百万用户的生产中断的成本。

何时使用证书固定

考虑到风险，证书固定何时有意义？

✅ 良好的固定用例

高价值移动应用程序

• 银行和金融服务
• 具有 PHI 的医疗保健应用程序
• 政府和国防应用程序
• 当安全性证明运营复杂性合理时

受控环境

• 后端服务到服务通信
• 具有托管部署的企业应用程序
• 具有更新机制的物联网设备
• 当客户端和服务器都在你的控制之下时

威胁模型要求

• 防止 CA 被攻破至关重要
• 监管合规要求固定
• 针对性攻击风险很高
• 标准 TLS 信任模型不足

❌ 不良固定用例

公共网站

• 浏览器不支持自定义固定
• HPKP 因风险而被弃用
• 证书透明度提供替代保护

没有更新机制的应用程序

• 无法从固定失败中恢复
• 永久损坏的风险
• 没有优雅的迁移路径

快速变化的基础设施

• 频繁的证书轮换
• 多个证书提供商
• 动态基础设施（CDN、负载均衡器）
• 运营负担太高

实施固定的决定应基于仔细的威胁建模和对运营能力的诚实评估。

证书固定的替代方案

在实施固定之前，考虑替代安全措施：

🔒 替代安全措施

证书透明度

• 所有颁发证书的公共日志
• 检测你域名的未授权证书
• 监控 CT 日志以查找意外颁发
• 应用程序没有运营负担

CAA DNS 记录

• 指定哪些 CA 可以为你的域名颁发证书
• 防止未授权的 CA 颁发证书
• 简单的 DNS 记录，无需应用程序更改
• 所有主要 CA 都支持

双向 TLS（mTLS）

• 用于身份验证的客户端证书
• 比固定更强的服务到服务通信
• 双方相互认证
• 在零信任架构中很常见

增强监控

• 通过 CT 日志监控证书颁发
• 对意外的证书更改发出警报
• 在没有固定风险的情况下检测攻击
• 提供可见性而没有运营负担

这些替代方案通常提供比证书固定更好的安全性与复杂性比率。

结论

证书固定代表了一种强大的安全技术，但伴随着重大的运营风险。通过将预期的证书或公钥硬编码到应用程序中，你可以防止 CA 被攻破和中间人攻击。然而，这种保护是以运营灵活性和自我造成的中断风险为代价的。

证书固定中的关键决策围绕固定什么以及如何管理生命周期。固定叶证书提供最大的安全性，但随着证书轮换需要频繁更新。固定中间证书平衡了安全性和运营可行性，使其成为移动应用程序最常见的方法。固定根证书提供最小的安全优势，很少有理由。公钥固定提供了最佳平衡，允许证书轮换而无需固定更新，同时保持加密验证。

通用名称陷阱说明了对证书安全性的根本误解。验证 CN 或 SAN 字段不提供安全优势——这些是任何 CA 都可以在证书中包含的元数据。真正的安全来自验证加密属性：公钥、证书签名和链验证。CN 验证与标准 TLS 验证是冗余的，并创造了虚假的安全感。

真实世界的固定失败展示了运营风险。被遗忘的证书续订破坏的移动银行应用、被 CA 中间证书轮换中断的企业应用程序，以及被过期固定使无用的 API 库都有共同的主题：计划不足、缺乏备份固定，以及低估协调复杂性。这些事件通常造成的损害比固定旨在防止的攻击更大。

实施固定的决定应基于仔细的威胁建模。受控环境中的高价值移动应用程序和托管部署代表良好的用例。公共网站、没有更新机制的应用程序和快速变化的基础设施是不良候选者。替代安全措施——证书透明度、CAA 记录、双向 TLS 和增强监控——通常提供更好的安全性与复杂性比率。

证书固定是一把双刃剑。在具有强大运营流程的受控环境中适当使用时，它可以增强针对复杂攻击的安全性。在不适当的场景中粗心使用时，它会创建运营脆弱性和自我造成的中断。行业向更短证书有效期的趋势使固定越来越具有挑战性，强化了公钥固定优于证书固定的重要性以及替代安全措施的价值。

在实施证书固定之前，问问自己：我的威胁模型是否证明运营复杂性合理？我是否有可靠管理固定更新的流程和工具？你能在包括 UAT 在内的所有环境中保持启用固定吗？是否有提供类似保护但风险较小的替代安全措施？这些问题的答案应该指导你的固定策略——或者你完全避免固定的决定。

如果你确实实施了固定：永远不要仅仅因为"太难"而在测试环境中禁用它。这种困难是你的早期预警系统，在问题到达生产环境之前捕获它们。接受运营负担作为适当安全验证的代价。