Comodo 表明证书颁发风险亦是通知与执行风险

摘要

• Comodo 表示一个注册机构账户于 2011 年 3 月 15 日遭入侵，并被用于为七个域名颁发九张欺诈证书；公开记录支持这是一次委托颁发失败，而非 Comodo 根密钥或硬件安全模块被盗。
• 问责问题不仅限于这九张证书。这些证书针对的是主要的登录、邮件、浏览器扩展和通信目的地，因此每个依赖的浏览器、平台、企业和公共部门网络都必须相信吊销和紧急不信任措施确实能到达用户。
• Mozilla 和 Microsoft 并未将颁发者的吊销视为充分对策。由于 CRL 和 OCSP 行为无法在所有网络条件下保证保护，Mozilla 发布了黑名单更新，Microsoft 将这些证书放入 Windows 的不受信任证书存储中。
• Comodo 控制了委托颁发模式、合作伙伴认证和事件证据；浏览器和操作系统供应商控制了紧急执行；根计划控制了持续信任；域名所有者和公共机构在没有见到注册机构账户或颁发者日志的情况下承担了下游风险。
• 持久的教训是，Web PKI 问责必须衡量通知、执行和修复，而不仅仅是证书数量。证书颁发机构可以快速吊销证书，但如果用户无法观察到和强制执行不信任，依赖方仍可能暴露于风险之中。

证据记录及其使用方式

本文将公开记录视为层级证据。事件报告、标准、浏览器或路由测量、监管或政策文件以及当前的运营者指南被用于不同的主张。由公司编写的来源被标注为公司立场。标准和后续指南用于解释控制措施并呈现问责期望，而非在公开记录不支持的情况下虚构私人事实或追溯性地施加后来的义务。

少量证书背后隐藏着大型委托问题

Comodo 事件之所以有价值，恰恰因为它按原始数量计并非一次巨大的泄露。九张证书足够少，可以一一列出、审视和推理。它们也足以展示，集中的证书颁发机构权力如何通过一个委托账户转化为生态系统风险。Comodo 表示，故障源自一个注册机构账户，而非通过窃取 CA 基础设施或受 HSM 保护的密钥。这一区别缩小了密码学主张，但没有缩小问责主张。如果一个委托账户能为主要域名获取浏览器信任的证书，那么颁发的实际权力就已经从企业根仪式扩散到用户从未见过的运营渠道中了。

在证书市场中，委托并非偶然。注册机构、经销商、企业工作流和自动颁发路径之所以存在，是因为证书颁发必须规模化。如果每一个证书请求都作为定制仪式来处理，网络就无法运转。但规模化改变了治理单元。CA 不仅负责保护其根私钥；它还负责颁发面，正是通过这个面，证书变得被浏览器信任。该面包括合作伙伴账户、角色权限、域名验证工作流、异常检测、高价值域名关卡、审计记录、紧急吊销、公开披露和根计划报告。

受影响的名称使问题显而易见。一个针对登录端点、邮件端点或浏览器扩展目的地的证书，当与路由控制、本地网络控制、DNS 干扰、恶意软件、强制门户或国家级网络访问结合时，就可能支持钓鱼攻击或中间人攻击。证书之所以危险，不是因为它是一个文件。它危险，是因为它能让未授权方呈现一个浏览器和用户可能接受为目标网站的加密身份。错误的一方可以借用域名的声誉和根存储的信任。

这就是为什么该事件属于 DNS 委托权力范畴，尽管直接故障是证书颁发。DNS 和 TLS 是分开的系统，但用户同时体验它们，作为关于他们在互联网上所处位置的声明。DNS 可以将用户引导至一个地址。TLS 告诉浏览器该端点是否被允许以某个名称说话。当证书颁发通过薄弱的控制被委托时，域名所有者可能在完全没有更改自己的 DNS、服务器或私钥的情况下，失去实际的身份保证。

公共部门连续性问题源于相同的结构。政府机构、学校、医院和市政服务通常依赖普通的浏览器、受管证书存储和供应商运营的 TLS 端点。它们无法独立检查每一个 CA 的委托路径。如果某关键登录或更新服务的证书变得可疑，公共部门的响应将取决于平台供应商能否发布不信任、端点设备群能否收到更新、检查网关行为是否正确，以及管理员能否辨别哪些用户仍处于暴露之中。因此，一个小的证书事件可能成为从未向该涉事颁发者购买过服务的组织的连续性难题。

吊销是必要的，但还不够

Comodo 表示，欺诈证书在发现后立即被吊销。这一事实很重要，不应被轻视。吊销是错误颁发后的第一个正式紧急动作。问题在于，吊销是一个控制面，而不是魔法橡皮擦。依赖方客户端必须检查状态、到达 CRL 或 OCSP 服务、解释结果、在结果不可用时安全地失败，并且要赶在攻击者能够利用该证书之前完成所有这些。真实的客户端、中间盒和网络并非那么一致。

Microsoft 在其公告中解释了实践上的差距。即使颁发者已吊销了证书并将其列入吊销机制，Microsoft 还是发布了一个更新，将这些证书添加到本地的“不受信任证书”存储中。这一举措使得对于已打补丁的 Windows 系统，不信任成为本地且确定性的。它还操作性地承认，实时吊销检查并非完整的执行叙事。如果攻击者能拦截状态检查，如果客户端软失败，如果设备离线，或者如果企业检查改变了证书行为，吊销在最为需要的时刻仍可能是一个微弱的信号。

Mozilla 通过浏览器黑名单更新表达了同样的观点。本地黑名单是粗暴的，但它无需对颁发者进行成功的网络查找即可生效。它将一个生态系统事件转变为一场软件更新竞赛：浏览器和操作系统能多快发布不信任，用户和企业能多快接收到它？那场竞赛是问责的一部分。CA 事件不在颁发者更新其数据库时被修复；它在依赖方在现实条件下不再能被该错误证书欺骗时被修复。

这一区别对执行政策很重要。如果根计划只衡量颁发者是否快速吊销，它们就错过了紧急不信任的下游成本。浏览器团队必须分类处理证书列表、编写或更新黑名单逻辑、测试版本、发布公告并承受用户风险问题。操作系统团队必须维护不信任存储和补丁分发路径。域名所有者必须监控可能的滥用。企业团队必须核实受管客户端是否收到更新。是颁发者制造了紧急情况，但其他方完成了大部分可见的执行工作。

证书透明度后来改变了可见性环境，使得已颁发的证书对域名所有者和监控者来说更易观察。它并未追溯解决 Comodo 2011 的问题，也不消除吊销或本地不信任的需要。然而，它确实转移了检测负担。当证书可以且应当被快速记录、监视和挑战时，一个隐藏的委托颁发路径就更不可接受了。Comodo 的记录解释了为什么 CT 不是装饰性的透明度；它是一种让私人颁发权力在滥用变成不可见损害之前就能被公开审计的方式。

通知必须触达不同职责的各方

证书事件中的通知不是面向一类受众的一条消息。CA 必须用足以行动的细节通知根计划和浏览器厂商。浏览器和平台厂商必须用解释是否需要软件更新的语言通知用户和管理员。域名所有者必须知道他们的名称是否被作为目标。公共机构和企业必须知道受管设备、检查设备或旧系统是否需要特殊处理。安全研究人员需要足够的证据来检验主张，而不把猜测变成事实。

按当时 Web PKI 事件的标准，Comodo 的记录异常具体。该公司列出了受影响的证书和域名，指出了委托账户路径，宣称立即吊销，区分了根密钥边界，并在后来一次被拦截的入侵企图后更新了报告。Mozilla 和 Microsoft 发布了各自的公告。这种分层之所以重要，是因为没有哪个单一行动者拥有全部受众。CA 报告对根计划和安全团队有用。浏览器公告触达浏览器用户。Windows 公告触达平台管理员。域名所有者和公共部门团队通常需要全部三者。

好的通知还必须将证据与保证分开。Comodo 声明 CA 基础设施和 HSM 密钥未被入侵是有用的，因为这防止了对链中每一个证书的过度恐慌。同样必要的是声明委托颁发失败了，因为否则用户和购买者可能推断，根密钥未被盗就意味着信任系统运行良好。正确的信息更为狭窄且更为严肃：数学上的根可能保持安全，而行政管理上的颁发边缘却制造了欺诈身份。

公共部门连续性依赖于那种精确性。一个政府网络团队不需要因为存在九张欺诈证书就更换全国所有的证书。它的确需要知道：它的浏览器和操作系统是否拥有相关的不信任更新，高风险用户是否可能通过敌对网络而暴露，证书检查工具是否会尊重平台不信任，以及那些仍未收到更新的旧设备是否仍然脆弱。含糊的安慰会造成运营瘫痪。具体的证书序列号、域名、更新渠道和残余未知因素才会产生行动。

这一通知问题也是一个执行问题。如果公开记录缺少证书详情，浏览器厂商就无法快速执行。如果根计划只收到私下保证而公众几乎什么也看不见，信任就会变得不透明，怀疑就会增长。如果域名所有者从新闻而非直接渠道得知消息，他们就会失去时间。Comodo 事件因此是一个关于证据路由的警告：每一必须采取行动的方，都需要在事件被视作已被遏制之前，得到正确形式和正确事实的信息。

根存储是私人计划，却产生公共后果

该事件还暴露了根存储的治理角色。用户并不自行组装自己信任的证书颁发机构列表。浏览器和操作系统供应商交付那个列表。信任决策被预载到用于银行、医疗、教育、公共服务、企业接入和个人通信的软件中。这赋予了私人根计划公共基础设施级别的后果。它们可以继续信任、限制、不信任或要求 CA 进行补救，而每一个选项都附带着可用性和安全成本。

在事件后继续信任并非赦免。这是一个前瞻性的风险决策。根计划可能判定一个颁发者已发现问题、吊销了证书、充分披露并纠正了控制措施。它们也可能判定该模式揭示了不可接受的风险。无论何种方式，决策都应基于证据。委托颁发失败应该引发关于合作伙伴清单、账户认证强度、高价值名称控制、异常检测、事件响应、外部审计和复发防范的问题。

不信任的成本是真实的。将一个主要 CA 从根存储中移除可能会破坏网站、企业应用、公共门户、嵌入系统和旧设备。这种成本可能让根计划变得谨慎。但错误信任的成本同样是真实的：用户可能遭到拦截或钓鱼，尽管已经做了常规安全培训告知他们应做的一切。成熟的治理必须避免戏剧性的惩罚和无原则的容忍。它应该公布期望，要求有用的事件报告，跟踪补救措施，并使执行足够可预测，以便 CA 能在用户受损之前作出改进。

当前 CA/浏览器论坛要求、Mozilla 政策、Chromium 政策、Apple 计划材料、Microsoft 要求和 CCADB 协调，都代表了一个比 2011 年更为明确的治理环境。不应将它们误用为追溯性证据，去证明某个旧有的控制措施违反了某条当前条款。它们的相关性是前瞻性的：它们表明生态系统已学会将浏览器信任表达为有条件的运营信任，而非永久的声誉。

对客户而言，实际的教训是询问一个 CA 如何控制委托颁发，又如何证明修复。对公共部门购买者而言，这个问题应成为采购和连续性规划的一部分。一个证书颁发机构可能是离机构远隔数层的供应商，但其故障仍能影响认证、软件分发和公民服务。一份覆盖服务器却不覆盖证书信任的连续性计划是不完整的。

执行记录应该是可验证的

最强的事件后记录不需要公布秘密。它应该展示受影响的证书序列号、确切的吊销时间、状态服务的可用性、浏览器和平台不信任状态、委托账户权限已被限制的证据、已添加的高价值域名控制、已审查的合作伙伴账户以及被通知的根计划。它还应该区分什么是观察到的，什么是推断的。Comodo 提供了其中若干事实，而其他事实仍为私人所有或分散于各个供应商的渠道中。

可验证的修复之所以是标准，是因为证书信任对大多数用户是不可见的。一个访问登录页面的人无法知道一张欺诈证书是否五分钟前被吊销，无法知道自己的浏览器是否收到了黑名单，也无法知道某个企业代理是否有着异常的行为。他们只能依赖于系统。因此，系统欠他们证据，证明执行已经到达了那些要紧的端点。

用于现代 CA 事件的一个有用的问责仪表盘将包含：证书数量、受影响名称、颁发路径、验证方法、从发现到吊销的时间、从发现到浏览器通知的时间、CT 日志可见性、状态服务行为、根计划事件工单状态、合作伙伴账户补救以及复发控制措施。重点不是公开羞辱，而是为依赖方提供一种方式，使其能分辨紧急情况是否已从宣告走向执行。

Comodo 事件还应改变组织思考“第三方”风险的方式。一个域名所有者可能从未与涉事 CA 签订合同，然而如果浏览器信任了该链，来自该 CA 的一张证书就能冒充该域名。这是一种不同的供应商暴露：信任存储的纳入为整个网络创建了一个共享的供应商池。域名所有者可以通过 CT 监控、CAA 记录、事件联络人和快速升级来降低风险，但他们无法完全从公共信任生态系统中选择退出。

总而言之，Comodo 事件是对委托权威的一次问责测试。攻击者造成了入侵。颁发者控制了委托模型和第一步修复步骤。浏览器和操作系统供应商控制了面向用户的执行。根计划控制了持续信任。公有的和私有的依赖方承担了他们无法直接观察的风险。一个成熟的 Web PKI 记录必须让所有这些角色都可见。

执行是一条链，而非单一吊销事件

应对证书事件常常被描述成似乎颁发者拥有整套修复方案。颁发者吊销证书，发布报告，事件即被视为关闭。Comodo 的记录说明了为什么这个模型过于狭隘。执行必须经过在操作上互相独立的多个层面。Comodo 能够吊销和通知。Mozilla 能够发布浏览器黑名单。Microsoft 能够更新 Windows 不受信任存储。根计划能够评估是否继续信任。域名所有者能够监控他们的名称。企业能够为受管设备打补丁。公共部门网络能够检查旧客户端或检查设备是否仍接受这些证书。如果目标是实际的用户保护，这些步骤中没有一步是可选的。

链式结构改变了“快速响应”的含义。仅仅询问 Comodo 何时按下吊销按钮或更新了 OCSP 是不够的。更好的问题是，在何种现实客户端上，一个身处风险中的用户何时被保护，免受该欺诈证书之害。该用户可能在一台延迟打补丁的企业机器上，在一台公共图书馆的计算机上，在一个老操作系统上，在一个锁定的机构工作站上，或在一个依赖平台信任存储的移动设备上。从 CA 发现到端点不信任所经过的时间，就是真正的执行窗口。公开记录通过 Comodo、Mozilla 和 Microsoft 的材料提供了这一窗口的部分片段，但没有给出一个可以合并的、单一的端点保护指标。

这种缺失并不罕见。Web PKI 事件设计上就是分布式的。浏览器厂商并不总是知道哪些用户在何时收到了更新。一个 CA 可能知道吊销状态，但不知道端点上的执行。一个域名所有者可能看到 CT 日志或 OCSP 流量，但看不到每一次被尝试的拦截。然而，完美可见性的缺失不应成为缺少有用指标的借口。根计划和 CA 仍然可以公布证书序列号、吊销时间、披露时间、浏览器通知时间、CT 日志引用、受影响的验证路径和补救类别。这些指标允许依赖组织判定它们自身的风险窗口是否仍旧打开。

执行链也为本地不信任机制创造了一个政策理由。实时吊销检查依赖于网络足够诚实，以到达状态服务。在中间人攻击场景中，这个假设是脆弱的。本地不信任存储、浏览器黑名单和硬失败行为都是减少对一个自身可能正遭受攻击的网络路径的依赖的方法。Comodo 事件使这一点具体化了：Microsoft 的公告讨论了 CRL 和 OCSP 的限制，但仍然交付了一个平台不信任更新。这就是在实践上承认，吊销是一个必要的信号，但不是充分的执行。

对公共部门连续性而言，这条链必须被排练。机构通常拥有补丁窗口、兼容性测试、遗留系统和证书检查设备。一次紧急的浏览器或操作系统不信任更新可能会与这些流程冲突。如果更新被推迟，机构可能在维持应用兼容性的同时延长了暴露。如果更新被仓促推进，它可能破坏旧服务。正确的准备不是恐慌；而是清点。哪些端点自动接收浏览器更新？哪些系统依赖嵌入式信任存储？哪些代理终结 TLS？哪些面向公众的服务被监控着未经授权的证书？谁能批准一次紧急信任存储更新？这些问题应该在下一次证书事件之前就存在。

委托颁发将合作伙伴安全转变为公共基础设施

那个被入侵的 RA 账户不仅是内部访问控制的一次失败。它是一次展示：当合作伙伴拥有实际的颁发权力时，合作伙伴安全就能成为公共基础设施。一个经销商或注册机构可能在经济上处于 CA 的下游，但它的账户可能导致全球依赖方软件接受一张证书。这种不对称性应该改变 CA 治理合作伙伴的方式。合作伙伴的准入、认证强度、最小权限、颁发限制、高风险名称审查、异常检测和注销，都不是后台细节。它们是信任产品的一部分。

高价值名称需要特殊处理。为一个受小客户控制的域名颁发的常规证书，与为主要的网页邮件、身份、软件分发或浏览器扩展端点颁发的证书，其风险并不相同。Comodo 证书列表说明了这种差别。如果一个委托账户突然请求为其没有正常关系的全球敏感品牌颁发证书，这应该触发额外的审查。控制可以采取多种形式：预加载高价值名称名单、品牌所有者预先授权、域名所有者确认、延迟颁发以待人工审查、针对特定合作伙伴的限制，或对 CA 安全团队的实时告警。具体设计可以变化，但在类似这样的事件之后，缺少差异化的风险处理是难以辩护的。

委托颁发也引发了审计问题。如果年度审计和合规声明只关注中央 CA 系统，而合作伙伴账户却拥有宽泛的操作权力，那么它们就可能错过真实存在的风险。一次有用的审计将抽样调查委托账户，审查它们所附带的颁发权限，测试高风险域名控制，检查认证要求，验证监控覆盖范围，并检查近期的异常请求。它还将检查对一个合作伙伴账户的紧急禁用是否能够快速奏效。Comodo 描述的 3 月 26 日被拦截的企图是相关的，因为它暗示攻击者回到了委托边缘。事件后的控制不得不承受重复的压力，而不仅仅是修复一个单一账户。

公开市场应当关心，因为委托颁发对购买者来说大多是看不见的。一个网站所有者可能基于价格、自动化和支持来选择 CA，而非基于每一个委托渠道的安全状况。用户的选择甚至更少。因此，根计划是最有能力通过政策、事件报告预期和对反复控制薄弱之处的后果来强制纪律的各方。CA/浏览器论坛、Mozilla、Chromium、Apple、Microsoft 和 CCADB 生态系统之所以存在，正是因为信任必须在个体购买者层面之上进行治理。

这一教训有着建设性的版本。当委托被设定边界并受到监控时，它可以是安全的。当域名控制被强有力地验证时，自动化可以改善证书部署。当经销商的权限受到约束并受到审计时，它们可以很好地服务客户。Comodo 事件不应被解读为每个委托渠道本质上都是鲁莽的论据。它应被解读为证据，证明每当委托颁发能够产生公共信任的证书时，就必须被当作一项公共信任职能来对待。

一份更强的现代事后分析将包含什么

对一起类似 Comodo 的事件，一份现代事后分析将从一张简洁的证据表开始：证书序列号、主题名称、颁发链、颁发时间戳、吊销时间戳、CT 日志状态、验证方法、委托账户或渠道、发现来源、浏览器通知时间以及已知被使用证据。这张表不会暴露秘密。它将使域名所有者、浏览器厂商、研究人员和企业能够回答第一个运营问题：存在哪些信任物件，它们何时存在，又已经做了什么来消除它们？

第二层将在不披露超出有用范围的攻击者技法的情况下，解释控制失败。委托账户是否受单因素认证保护？它是否被允许请求任何域名？高价值域名是否被标记？监控是否在外部通知之前检测到了异常颁发？合作伙伴权限在发现后是否被缩减？类似的合作伙伴账户是否被审查？现在哪项控制防止了相同的路径？这些不是惩罚性问题。它们是修复性问题。如果答案仍然不公开，外部人士就无法区分一次性账户入侵和系统性的委托权限薄弱。

第三层将衡量生态系统层面的执行。Mozilla、Microsoft、Apple、Chromium 和其他相关根计划或平台计划是何时获得通知的？交付了哪些更新或不信任机制？CA 是否验证了吊销响应器拥有足够的容量和正确的状态？OCSP 和 CRL 响应在吊销后是否被监控到尝试使用？域名所有者是否收到了直接通知？公共部门和企业管理员是否得到了可行动的指导？在一次证书事件中，直到能够执行不信任的各方向拥有足够的证据去这样做之前，它都算不上被修复。

第四层将以诚实的方式处理残余风险。如果公开记录显示没有大规模使用，那就说出来。如果只有一张证书被观察到是存活的，那就说出来并解释观察方法。如果 OCSP 流量在吊销后没有显示出使用，那就说出来，同时注意到 OCSP 作为可见性机制的局限。如果在更新之前是否有用户在敌对网络上接受了证书仍存在未知，那也说出来。成熟的保证不是对不确定性的否认；而是对尚属未知之事物的、有纪律的指明。

最后，事后分析应将事件学习与治理联系起来。哪些根计划要求改变了？哪些合作伙伴控制改变了？哪些检测规则现在能捕获高风险名称？哪些审计将核实那些变化？哪些指标将由领导层审查？没有那层治理，事件就变成了一则历史轶事。有了它，事件就变成了为下一次委托颁发失败准备的一份可重用的控制地图。

关于证书信任的读者决策

读者不应带着“证书颁发机构应当小心”这一模糊教训离开 Comodo 的记录。可行动的决策更为尖锐：任何依赖于公共 TLS 的组织都应知道，它将如何发现和响应一张针对其域名的未经授权证书，即使该证书是由它未曾选择的某个 CA 颁发的。这意味着监控证书透明度日志，维护当前的安全联络方式，在适当之处使用 CAA，测试通往 CA 和浏览器厂商的事件升级路径，并知晓在一次信任存储紧急事件中哪些内部系统会受到影响。

对证书服务的购买者而言，问题应该超越价格和自动化。委托账户如何被认证？经销商和 RA 的权限是否被设定边界？哪些高价值名称需要额外审查？在错误颁发之后提供哪些证据？根计划被通知得有多快？吊销服务如何受监控？当吊销还不够时，通往浏览器不信任的、经过测试的路径是什么？一旦证书被理解为身份基础设施而非日历上的续期时，这些问题就是普通的供应商治理问题。

对根计划而言，Comodo 事件依然是一则提醒：公共信任应当是有条件的、依据证据的。一个 CA 可以快速响应一起事件，却仍然需要对合作伙伴权限进行更深的审查。执行不应个案临时拼凑；它应当与已公布的政策、事件报告期望和复发证据挂钩。公众不需要每一个保密的审计细节，但确实需要足够多的模式，以便知晓委托颁发在事件之后是否比事件之前更安全。

对公共部门运营者而言，决策是面向连续性的。机构的浏览器、代理、移动设备和遗留系统是否足够快速地接收紧急证书不信任更新？管理员能否识别一张未经授权的证书是否与机构服务相关？如果一张受信任证书变成可疑，是否有一种与用户沟通的方式？一个公共机构无法检查整个 Web PKI，但它可以准备好本地的响应面。

因此，Comodo 事件至今仍具现实意义，因为它将一个信任抽象转变成了运营问题。谁能颁发？谁能看见？谁能吊销？谁能执行？谁能证明执行已到达？任何无法回答这些问题的组织，都还没有为下一次证书信任失败做好准备。

最后一项实际测试是，组织能否指认其证书信任的负责人。如果答案分散在采购、基础设施、安全运营、网络工程和法务之间，却没有事件负责人，那么一起类似 Comodo 的事件将通过临时即兴发挥来处理。负责人不需要控制每一个根计划，但必须知道证据如何从 CT 监控器流向 CA 联络人，流向浏览器厂商，流向企业端点。这种责任归属正是吊销作为一种声明与吊销作为保护之间的区别。

该负责人还应为高价值名称维护一份证据行动手册。手册应写明哪些域名受监控，哪些名称对于普通委托颁发来说过于敏感，哪些 CA 账户是经批准的，哪些联络人可以要求吊销，以及如果 CA 响应不足，应通知哪些浏览器根渠道。它还应保存行动后的证据：证书何时出现，域名所有者何时知晓，CA 何时吊销，平台更新何时到达，以及在执行触达之前哪些用户仍可能已经接受了证书。Comodo 的记录表明为什么这种细节至关重要。一张欺诈证书可以在几秒内数清，但其风险是通过可见性、通知、执行以及对同一委托路径已被关闭的信心来衡量的。

排版

底线

问责标准是实际控制与公开证据的结合。最强的记录并不会假装每个行动者都控制了每个结果。它会指明谁能预防该失败，谁能检测到它，谁能限制受影响范围，谁能通知受影响的各方，谁能修复信任关系，以及什么证据能证明修复到达了依赖它的系统和人员。