Microsoft Storm-0558 使对令牌危害的运营控制成为公共问责考验

摘要

• Storm-0558 利用 Microsoft 消费者签名密钥和验证缺陷访问企业版 Exchange Online 邮件。这使得运营危害控制主要成为供应商方的责任，因为客户无法轮换 Microsoft 的密钥、修补 Microsoft 的令牌验证程序，或检查 Microsoft 的内部签名环境。
• 最重要的公共问责考验出现在信任失效之后：Microsoft 能多快识别伪造令牌路径、停止令牌续订、阻止接受该密钥、更换签名材料、扩大客户日志，并解释仍未知的部分。
• 网络安全审查委员会（CSRB）后来认定该事件本可预防，并批评了 Microsoft 的安全文化、密钥管理、验证控制、日志访问权限以及对此前密钥获取解释的修正。Microsoft 接受了 CSRB 的调查结果，并宣布了“安全未来计划”（Secure Future Initiative），但许多实施证据仍由供应商自行报告。
• 悬而未决的密钥获取途径至关重要。在 Microsoft 表示未发现包含受影响密钥的崩溃转储之后，其崩溃转储说法缩减为一个主要假设。因此，问责建立在已证实的控制失败和残余不确定性之上，而非完全证实的失窃链条。

证据图

令牌危害是一种由供应商控制的故障模式

Storm-0558 通常通过最引人注目的对象来描述：一个于 2016 年创建的 Microsoft 消费者签名密钥。该密钥至关重要。一个私有签名密钥允许攻击者创建令牌，如果验证规则失效，服务可能接受这些令牌。但问责考验比密钥失窃更大。它包括密钥被信任了多久、服务如何验证令牌的颁发者和范围、续订路径的行为、是否检测到不可能的令牌组合，以及客户能否看到邮箱访问证据。这些控制权绝大多数在 Microsoft 手中。

这就是为什么对危害的运营控制是核心透镜。客户可以强化账户、要求多因素认证、降低权限、监控日志并快速响应。他们无法轮换 Microsoft 的内部签名密钥。他们无法更改 Exchange Online 的服务器端验证代码。他们无法看到每一个内部令牌颁发路径。他们无法保留 Microsoft 的内部崩溃转储或签名环境日志。当云提供商的信任基础设施失效时，客户预防初始危害的能力受到严重限制。

CISA-FBI 的咨询特别明确了这种分配。它表示，对该活动的缓解措施是 Microsoft 的责任，因为受影响的基础设施基于云。这句话很重要。它并不意味着客户在检测或响应中没有作用。美国国务院的检测至关重要。它意味着决定性的遏制行动是供应商方的：停止接受伪造路径、阻止该密钥、更换签名材料并扩大证据。这就是对危害的运营控制。

该事件并非普通的邮箱失陷。Storm-0558 无需钓鱼每个目标的密码。它滥用了云身份信任决策。这使得危害的公共性超出了受害组织。政府、受监管的企业和公众依赖供应商的身份平面作为共享基础设施。如果供应商控制的令牌边界失效，问责不能简化为客户配置的问题。

公共记录也需要精确。该事件主要是保密性和可信通信失败，而不是 Exchange Online 的可用性中断。邮件继续运作。危害在于对消息的静默访问，以及对服务身份边界已受损失去信心。公共部门的连续性包括此类危害。一个外交邮箱可保持可访问，而其内容被泄露。

密钥获取故事仍未解决

Microsoft 2023 年 9 月的密钥获取文章最初提供了一个详细的崩溃转储说明。它描述了一个 2021 年 4 月在消费者签名系统中的崩溃，一个转移到公司调试环境的崩溃转储，漏掉了密钥材料的凭证扫描，以及后来一个工程师账户的失陷。这个故事成为了公共根本原因叙述。2024 年 3 月，Microsoft 添加了一个修正收窄了该说法。它表示未找到包含受影响的密钥的崩溃转储，崩溃转储路径仍是一个主要假设，而不是已证实的事实。

CSRB 将这种不确定性作为核心。它报告说，Microsoft 调查了许多假设，但仍不知道 Storm-0558 究竟如何或何时获得了 2016 年的 MSA 私钥。这条未解决的路径不是一个旁注。如果获取途径未知，供应商就无法公开证明同一条路径已被完全关闭。它可以强化密钥管理、隔离签名系统、改进日志、自动化轮换并减少未来影响范围。这些都是真实存在的控制措施。它们不能追溯性地确立失窃链条。

因此，问责应基于两个类别。第一类是已证实或有强有力支持的故障：一个陈旧的密钥仍被信任，验证在消费者-企业边界失败，增强日志未广泛提供给客户，且 Microsoft 早期的公开解释夸大了获取路径的确定性。第二类是残余不确定性：密钥究竟如何脱离 Microsoft 控制，是否有任何相关敏感材料被暴露，以及是否曾存在完整的内部证据踪迹。

这种区分并非学究之举。客户使用根本原因解释来决定补救措施是否与故障匹配。如果崩溃转储路径被证实，那么崩溃转储处理和公司调试访问就成为直接的关闭点。如果路径未知，那么补救措施必须更广泛：密钥隔离、轮换、盘点、日志记录、令牌验证、最小权限、开发者环境控制以及独立挑战。当路径未解决时，公开保证的责任更高。

Microsoft 的修正也因为时间线而成为问责记录的一部分。CSRB 报告称，Microsoft 在 3 月公开修正之前就已意识到 9 月的解释不准确。供应商可能在对事件解释中犯下善意错误。发现错误后的责任是尽快且清晰地更正。在云信任基础设施中，一个不准确的根本原因故事可能误导客户，让他们以为核心危害路径已被关闭。

危害控制从验证和密钥操作开始

公开的缓解序列表明，抑制并非单一开关。Microsoft 表示，它停止了 OWA 接受 GetAccessTokenForResource 颁发的令牌进行续订，阻止了 OWA 使用由获取的 MSA 密钥签名的令牌，更换了密钥，撤销了在事件期间有效的 MSA 签名密钥，从强化的系统颁发了新密钥，并为受影响的消费者客户阻止使用，以防止以前颁发的令牌被利用。这是一个分阶段的危害控制计划。

该序列说明了令牌危害。一个伪造令牌活动可以通过续订行为、缓存的元数据、下游服务、以前颁发的令牌以及消费者-企业信任边界持续存在。供应商必须找到每个不良信任决策存续的地方。阻止一条路径可能阻止未来的铸造，但现有令牌仍可能有效。如果服务缓存密钥或令牌，轮换密钥可能不会立即使每件工艺品无效。如果不关闭，续订端点可能会延长危害。

客户需要了解这一序列，因为它影响调查。在密钥更换之前被访问的邮箱，即使路径后来被关闭，可能仍需要审查。被一个服务接受但未被另一个服务接受的令牌可以缩小范围。续订路径改变了访问的持续时间。因此，公开披露不仅应描述问题已缓解，还应说明哪些信任决策被改变、剩余哪些客户证据仍然相关。

Microsoft 的技术报告确实提供了比许多事件披露更清晰的缓解序列。这是一个优点。公开的限制是，客户仍需依赖 Microsoft 提供服务侧证明。他们无法独立验证每个内部验证更改或密钥撤销效果。这就是云信任基础设施的本质。它增加了供应商发布精确、可测试和更正后的解释的责任。

该事件也说明了为什么密钥年龄不仅作为加密卫生，而且作为运营风险很重要。一个在计划生命周期之后仍被信任的长期密钥，为攻击者提供了一个更大的价值目标和更长的潜在效用窗口。CSRB 发现，Microsoft 消费者签名密钥轮换已成为手动流程，并在一次故障担忧后暂停，没有完成自动化替代。这是一个可用性-安全性权衡，其延迟的成本在一次保密事件中出现。对危害的运营控制包括使密钥轮换足够常规，以确保故障恐惧不会冻结安全生命周期。

日志记录是公共问责的枢纽

美国国务院通过增强的邮箱访问日志检测到可疑活动。这一事实改变了事件。它表明即使供应商控制缓解措施，客户也能提供关键信号。它还暴露了一个许可问题。当时，CISA-FBI 咨询强调了 MailItemsAccessed 审计事件的重要性，并指出相关的日志记录与更高层次的许可绑定。CISA 后来公开赞扬 Microsoft 承诺在无需额外费用的情况下扩展重要日志。

日志记录不仅是客户功能。它是危害控制基础设施。如果客户无法看到邮箱项目访问日志，他们无法可靠地检测到供应商发起的令牌故障被滥用。如果日志保留时间过短，事后发现受限于仍存在的内容。如果将关键事件作为高级功能定价，较低层次客户可能在最需要供应商问责时拥有更弱的证据。

Microsoft 2023 年 7 月的日志记录公告承诺为标准客户扩展访问详细电子邮件访问日志以及 30 多项其他审计事件，并将默认审计标准保留期从 90 天增加到 180 天。CISA、OMB、ONCD 和 Microsoft 随后宣布为联邦机构扩展日志记录，并实现自动启用和 180 天默认保留期。这些改变是实质性的，因为它们将证据从付费附加功能转向了基线安全预期。

问责的教训超出了单一日志类型。云供应商应将检测供应商侧控制故障所需的日志视为服务安全层的一部分。客户不应为了发现供应商密钥或验证缺陷被滥用而购买高级可见性。供应商可以对高级分析、存储和托管检测收费。但重建对客户数据访问所需的原始安全事件应更接近基线。

该事件还表明，检测可能来自客户，在供应商了解故障之前。美国国务院看到了异常。Microsoft 随后调查并确定了伪造令牌路径。这种顺序只有在客户拥有足够的日志来发出警报并拥有足够的渠道来升级时才健康。没有美国国务院的增强日志记录和调查，公共时间线可能会更糟。供应商控制的缓解措施并未抹杀客户检测的成功。

公共部门连续性包括可信通信

受影响的账户包括公共部门和政府相关的邮箱。美国国务院后来表示，从 10 个账户下载了大约 6 万封邮件，受影响的系统是非机密性的，机密邮件未被黑客入侵。CSRB 确定了全球 22 个组织和 500 多名个人受到影响。这些细节谨慎地框定了危害：它不是政府电子邮件可用性的崩溃，且公共记录未披露消息内容。但这仍是一次严重的可信通信失败。

现代公共部门的工作依赖云电子邮件进行外交、商务、政策、日程安排、谈判和行政协调。保密性丧失即使服务保持在线也能改变行为。官员可能需要假设通信被阅读，信源或计划可能需要保护，未来的通信可能转移到不同渠道。服务无需宕机就能施加运营成本。

这就是为什么 Storm-0558 既属于网络安全，也属于公共部门连续性。连续性通常通过可用性来定义：机构能否继续运作？一个更成熟的模型包括可信运营：机构能否继续使用该服务实现其预期的公共功能，而不受对手的视线影响？一个技术上有效但能被对手默默阅读的邮箱是降级的基础设施。

公共问责问题变得更加尖锐，因为政府是依赖的客户。他们可以设定采购要求、要求日志记录、进行监督，并在理论上迁移工作负载。实际上，他们依赖少数几个云供应商来实现核心身份和通信。这种依赖意味着供应商的补救措施不仅是客户服务。这是公共基础设施的修复。

国会信函、听证会和 CSRB 审查反映了这种依赖。它们没有建立法院判决或监管责任认定，但它们确实使供应商的安全文化、密钥管理和日志记录选择公开化。这对于由公共机构使用的共享云身份基础设施的故障是适当的。

安全文化成为一项运营控制

CSRB 的报告并未局限于一个代码缺陷。它批评 Microsoft 的安全文化，并描述了一系列可避免的故障。这种框架很重要，因为签名密钥生命周期、令牌验证、日志记录默认设置、公司网络失陷、根本原因修正和客户可见性并非孤立的缺陷。它们是组织优先级、工程系统、风险接受度和治理的结果。

安全文化听起来可能模糊。在这一事件中，它有具体的形式。一个手动密钥轮换流程因故障担忧被暂停，没有完成自动化替代。一个验证假设跨越了消费者-企业边界。高级日志限制了客户可见性。早期的公开解释在知道需要更正之后，仍太确定而维持了太长时间。这些不是态度；它们是运营决策和控制状态。

Microsoft 以安全未来计划和后续扩展做出回应。公司描述了自动化密钥管理、硬件安全模块、机密计算、标准身份 SDK、有状态验证、密钥分区、扩展日志、治理变革、副首席信息安全官、业绩评估变革以及高管薪酬关联。Brad Smith 的国会证词接受了 CSRB 提出的每一个问题，并描述了实施建议的步骤。

这些承诺是实质性的。在本文审查的公开资料中，它们也主要由供应商自行报告。因此，问责标准应区分已宣布的项目和经独立验证的运营有效性。客户和政府应要求证据表明：密钥已盘点、轮换、隔离并具有紧急轮换能力；验证库强制执行颁发者和范围边界；服务无法绕过标准验证；日志被保留且可用；当证据变化时，根本原因修正被及时发布。

供应商自我报告并非无用。这是许多云控制首次可见的方式。但当一次可预防的信任基础设施故障后，自我报告应成熟为可衡量的保证。公众不需要每一个内部细节。他们确实需要足够的证据来知道事故后命名的控制措施正在运营、测试和治理中。

令牌验证必须变得平常、集中且难以绕过

一个技术教训是，令牌验证不应依赖于每个服务团队独立记住每个边界条件。Microsoft 事件后的解释描述了一个通用元数据端点和在受影响路径中未能正确验证颁发者或范围的故障。现代身份系统很复杂，但正是这种复杂性说明验证应在维护良好的库和强化的服务模式中集中化。

Microsoft 当前身份文档解释了诸如颁发者、受众、签名密钥、发现元数据、访问令牌和密钥轮换等概念。这些文件是面向客户的参考，而不是 2023 年代码状态的证明。它们仍然显示了控制逻辑：一个有效的签名并不足够，如果令牌是为不同的身份领域、受众、租户或服务颁发的。密码有效性回答了一个问题。授权上下文回答了另一个问题。

供应商的工作是使安全路径成为容易之路。如果一个服务需要接受身份令牌，它应使用一个标准库，强制实施颁发者、受众、租户、范围、密钥来源和元数据刷新规则。偏离应罕见、经审查、记录并测试。紧急密钥轮换应进行演练。服务应默认拒绝不可能的令牌组合。监控应检测那些签名密钥、颁发者、资源和租户关系毫无意义的令牌。

当供应商验证变得平常时，客户受益。他们不应需要询问每个 Microsoft 服务团队是否正确实现了令牌验证。他们应能够依赖中央身份控制和独立保证。Storm-0558 事件显示了当一个本应系统化的边界变得特定于服务，以至于一个缺陷足以产生影响时会发生什么。

这个教训超越了 Microsoft。每个大型云供应商都运营着跨越产品、租户、身份领域和 API 的令牌基础设施。集中验证、自动化密钥生命周期和客户可见的证据是共同的安全要求。这一事件使这些要求公开化，因为该故障涉及了政府邮件。

残余不确定性改变了保证负担

一些事件以精确的根本原因和精确的关闭结束。至少根据公开记录，Storm-0558 并非如此。密钥获取路径仍未解决。CSRB 报告称，Microsoft 无法确定密钥是如何或在何时被获取的。这种不确定性并不阻止补救。它改变了保证负担。

当失窃路径未知时，供应商必须假设更广泛的可能故障类别。密钥材料可能通过操作失误离开签名环境。它可能通过公司失陷暴露。它可能被一个未在存活日志中捕获的过程错误处理。答案是不在证据之外公开猜测。答案是加固全生命周期：生成、存储、使用、轮换、退役、日志记录、调试、备份、事件响应和特权访问。

残余不确定性也影响客户信任。客户可以接受并非每个事实都可恢复。他们不应被要求接受模糊的关闭。供应商应说明仍未知之处、缺失的证据、尽管不确定仍加强的控制措施，以及未来如何保存证据。一个透明的未知数可能比一个后来需要更正的过于自信的故事建立更多信任。

CSRB 流程通过强制的公共区分已证实事实和假设，帮助创造了这种透明性。它也显示了对于证据大多位于供应商内部的云事件进行独立审查的价值。客户无法对自己的 Microsoft 签名环境进行全面调查。一个独立的公私审查不是一个法庭，但它能使供应商控制的事实足够可见，以实现公共问责。

未来的保证应是持续的。一次重大事件后的一次性报告是有用的，但密钥生命周期和令牌验证是持续的控制措施。政府和企业客户应要求获得关于紧急密钥轮换测试、验证库采用、日志覆盖和根本原因修正流程的周期性证据。控制失败不是静态的；保证也不应是静态的。

证据不对称定义了客户的上限

Storm-0558 也暴露了客户侧调查的硬上限。客户可以检查邮箱审计事件、关联可疑访问、保留租户日志，并向 Microsoft 升级。它无法检查签名环境、列出每个内部 Microsoft 密钥信任决策、证明密钥是否已被用于其他服务，或确定攻击者是否通过崩溃转储、公司失陷或其他途径获得密钥。最重要的证据存在于供应商内部。

这种不对称性是云服务固有的，但当故障涉及供应商身份基础设施时变得尤为尖锐。在普通账户失陷中，客户可能能够审查用户设备、钓鱼消息、MFA 提示、条件访问策略和本地日志。在 Storm-0558 中，决定性的问题是为何 Microsoft 服务接受了伪造令牌，以及攻击者如何获得了 Microsoft 控制的签名材料。这一问题超出了客户的能力范围。

因此，随着客户可见性降低，供应商的证据责任增加。Microsoft 必须调查内部系统、保留可用证据、解释空白、更正公开声明，并使面向客户的日志更易访问。客户必须依赖 Microsoft 获取内部另一半故事。CSRB 审查通过将独立公共审查引入供应商持有的事实，减少了这种信任差距，但并未消除每一个未知。它只能报告 Microsoft 和其他参与者能重建的内容；它无法制造不存在的日志。

证据不对称应作为设计输入。云供应商应足够长地保留安全相关的内部日志，以支持对缓慢发现的身份滥用的调查。他们应维护密钥保管记录、签名系统访问日志、调试环境控制和紧急轮换记录。他们应给予客户足够检测滥用供应商起源的信任制品的租户日志。当日志缺失或保留期已过时，他们也应当发布限制说明。对证据限制的沉默让客户要么假设信心，要么假设隐瞒；两者都无益。

客户可以通过将证据预期写入采购和风险审查来回应。他们应询问默认包含哪些审计事件、供应商侧日志保留多久、在供应商控制失败后将分享哪些事件摘要，以及对于重大信任事件是否有独立审查可用。答案永远不会给客户完整的内部访问权。它们仍能确定供应商是否将证据视为产品的一部分。

紧急密钥轮换是一项连续性能力

密钥轮换常被讨论为一个加密维护任务。Storm-0558 显示它也是一项连续性能力。如果签名密钥被怀疑或已证实泄露，供应商必须轮换或撤销它，而不至于在不可接受的规模上破坏合法身份验证。这意味着应用程序、服务、元数据端点、缓存、客户端和验证库必须容忍密钥更改。如果轮换路径脆弱，安全团队可能会犹豫、延迟，或使旧密钥被信任的时间超过应有。

CSRB 对消费者签名密钥轮换的讨论使这一点具体化。Microsoft 在故障担忧后暂停了手动轮换，未完成自动化替代。这一决定可能降低了即时可用性风险，但它使一个陈旧密钥被信任。更深层的失败不仅仅是密钥的年龄。而是缺乏一个安全、自动化、可衡量的轮换路径，既能处理常规变更，也能处理紧急变更。

当前 Microsoft 面向客户的签名密钥轮换指南强调以编程方式处理密钥变更、元数据刷新和标准库。相同的工程原则适用于供应商内部。服务应预期密钥变更，验证库应安全刷新，紧急轮换应在现实条件下测试。如果轮换被视为故障触发器而令人恐惧，系统已将安全控制转化为可用性风险。成熟的基础设施使轮换变得足够平常以便执行。

紧急轮换也包含客户沟通组件。当供应商在怀疑泄露后轮换密钥时，客户可能需要知道他们的应用程序或集成是否需要采取行动、令牌缓存是否受影响、是否预期身份验证失败，以及旧令牌是否仍然有效。在 Storm-0558 期间，Microsoft 控制了受影响的 Exchange Online 路径，但更广泛的原则适用于整个云身份领域。密钥安全和客户连续性必须联结在一起。

这就是为什么密钥管理应作为弹性指标报告。供应商可以在汇总层面披露：密钥是否已盘点、已分配负责人、按计划轮换、受硬件支持的控制措施保护、接受紧急演练，并监控年龄或政策偏差。客户无需私钥材料来评估成熟度。他们需要证据表明密钥没有被允许成为被遗忘的信任锚点。

基线日志记录改变了谁为不确定性买单

在 Microsoft 扩展日志记录之前，最有用的邮箱访问证据并非对所有客户同等可用。这不仅仅是一个产品包装细节。它分配了不确定性。一个没有相关日志的客户可能不得不假设失陷、在外部调查上多花钱，或接受一个较弱的结论。拥有日志的客户可以识别可疑访问、缩小范围，并使用证据升级。

美国国务院拥有检测异常邮箱访问所需的增强日志。这一成功显示了良好遥测能做什么。它也提出了公平问题：为什么检测供应商起源的身份故障的能力依赖于许可等级？CISA 公开声明重要日志应无需额外费用即可用，将产品决策转变为问责议题。

因此，Microsoft 承诺扩展审计标准事件和保留期不仅仅是客户成功的姿态。它改变了危害分配模型。如果基线客户获得更多日志，他们就可以在供应商控制失败时参与检测和范围确定。如果联邦机构获得自动启用和更长保留期，他们就较少依赖事后重建。更多日志不会阻止密钥泄露，但它们减少了客户处于盲区的时期。

日志记录也影响法律和运营确定性。一个能够证明哪些邮件项目被访问的组织可以定制通知、内部补救、外交回应或业务连续性措施。一个没有日志的组织可能不得不将更广泛的人群视为可能受影响。从这个意义上说，日志减少了二次危害。它们不仅有助于找到攻击者；它们有助于避免过度宽泛的不确定性。

基线标准应明确：检测对客户数据的未经授权访问所需的事件，特别是当根本原因可能位于供应商控制的基础设施中时，应作为服务的一部分包含在内。高级关联、托管检测、长期存档和分析可以保持为高级产品。了解客户数据是否被访问所需的最低证据不应是一个奢侈功能。

供应商纠正是事件响应的一部分

Storm-0558 也使公开纠正成为运营问责的一部分。Microsoft 发布了初始事件通知、技术分析，然后是密钥获取调查文章。9 月的文章提供了一个详细的解释，该解释后来不得不被收窄。2024 年 3 月的修正不仅编辑了一个历史脚注。它改变了客户负责任地能相信的根本原因。

事件响应通常将公开沟通视为与技术补救分离。在云信任事件中，它们是关联的。一个正在决定是否信任供应商关闭措施的客户需要准确了解哪些控制措施失效。如果获取路径被描述为崩溃转储，客户期望崩溃转储和调试环境控制措施来关闭问题。如果获取路径未知，客户期望更广泛的密钥生命周期加固和更强的证据保存。言辞决定了保证需求。

因此，更正应快速、可见且明确。供应商不应在一个版本化的帖子中掩埋改变的根因置信度，而不清楚说明什么改变了以及原因。Microsoft 确实添加了 2024 年 3 月的更新，CSRB 后来讨论了更正的时间选择和重要性。问责的教训是，根本原因置信度本身是一个应被披露的事实。当置信度从“这发生了”下降到“这仍是我们的主要假设”时，客户需要知道。

这一标准同时保护了供应商和客户。诚实地更正防止公共记录围绕一个错误解释固化。它允许补救适当扩大。它信号表明供应商愿意区分证据和叙事便利。在高信任云基础设施中，这种区分是服务信誉的一部分。

共享责任需要控制面地图

Storm-0558 是对模糊的共享责任语言的一剂有效解药。“共享责任”一词如果不指出控制面，可能变成迷雾。在这一事件中，Microsoft 控制了密钥生命周期、令牌验证、服务侧缓解、基线日志可用性、内部证据保存和大部分根因证明。客户控制了租户监控、事件升级、邮箱审查、账户卫生和策略配置。政府控制了采购压力、监督和公共审查机制。这些角色各不相同。

控制面地图防止两个坏论点。第一个坏论点说客户对自己的云安全负责，因此应预防该事件。这失败是因为客户无法阻止 Microsoft 服务接受由 Microsoft 控制材料签名的伪造令牌。第二个坏论点说供应商控制了根本原因，因此客户没有任何有意义的作用。这同样失败，因为美国国务院的检测、客户日志和升级实质性地改变了公共回应。

更好的模型提出四个问题。谁能预防此类故障？谁能首先检测到它？谁能遏制它？谁能证明范围？对于 Storm-0558，Microsoft 拥有最强的预防和遏制控制。一个客户，在本例中是美国国务院，因为拥有并使用了增强的邮箱日志而发挥了关键的检测作用。范围证明是共享的但不对称：如果日志存在，客户可以检查自己的租户，而 Microsoft 必须解释供应商侧的信任和密钥证据。

采购应反映该地图。一个正在购买云电子邮件和身份的客户，不仅应询问正常运行时间和合规认证，还应询问密钥轮换、令牌验证、颁发者边界测试、默认审计事件、供应商侧日志保留、事件更正政策以及独立审查选项。这些不是深奥的控制措施。它们是决定当供应商信任结构失效时会发生什么的控制措施。

公共机构承担额外责任，因为它们的依赖可以塑造市场标准。当政府客户坚持关键日志应为基线时，供应商可能为更广泛的人群改变产品。后 Storm-0558 日志扩展表明，公共问责可以改善默认的安全态势。挑战在于使这种改进系统化而非事件驱动。

排版与可读性注释

排版是安排字体以使书面语言清晰、可读且视觉上吸引人的艺术与技术。它涉及选择字体、字号、行长、行间距和字间距。

• 排版起源于 15 世纪 Johannes Gutenberg 发明的活字印刷。
• 关键元素包括字体选择、字距调整、字偶距和行距。
• 良好的排版增强可读性并在设计中传达情绪或基调。

问责考验

Microsoft Storm-0558 使对令牌危害的运营控制成为公共问责考验，因为决定性的控制措施存在于 Microsoft 云内部。客户可以检测、升级并调查自己的邮箱，但只有 Microsoft 能够更换密钥、纠正验证、改变令牌续订行为、扩展基线日志，并解释内部证据缺口。

更好的标准是供应商可验证的危害控制。一个云身份供应商应知道每一个活跃的签名密钥，通过自动化且经过测试的路径轮换密钥，通过标准库强制执行令牌验证，检测不可能的令牌使用，足够长时间地保留证据以支持回顾性分析，并给予客户检测供应商发起的控制故障所需的基线日志。当根本原因假设变化时，供应商应快速纠正记录。

未解决的密钥获取路径是教训的一部分，而非要掩盖的尴尬。云客户可以接受诚实的不确定性，如果供应商证明整个类别的危害正在减少。他们不能安全地生活在一个其最特权故障仅在被客户发现损害后才会得到解释的信任系统下。