摘要
- Storm-0558 使用了 Microsoft 消费者签名密钥和验证失败来访问企业 Exchange Online 邮件。这使得操作危害控制主要成为服务提供方的责任,因为客户无法轮换 Microsoft 的密钥、修补 Microsoft 的令牌验证器,或检查 Microsoft 的内部签名环境。
- 信任失效后最重要的公共问责测试是:Microsoft 能够多快识别伪造令牌路径、停止令牌续用、阻止密钥接受、替换签名材料、扩展客户日志,并解释尚不明确的问题。
- Cyber Safety Review Board(CSRB)后来得出结论,该事件本可避免,并批评了 Microsoft 的安全文化、密钥管理、验证控制、日志访问以及早期密钥获取说明的更正。Microsoft 接受了 CSRB 的调查结果,并宣布了 Secure Future Initiative 工作,但许多实施证据仍由服务商自行报告。
- 未解决的获取路径很重要。Microsoft 的崩溃转储叙述在表示未找到包含受影响密钥的崩溃转储后被缩小为主要假设。因此,责任在于已被证实的控制失败和剩余的不确定性,而非完全证实的盗窃链条。
证据图谱
| # | 公开来源 | 本文使用方式 |
|---|---|---|
| 1 | Microsoft 2023 年 7 月 11 日 Storm-0558 事件通知 | 公司的初步披露、早期范围、伪造令牌机制和客户通知。 |
| 2 | Microsoft Storm-0558 技术分析 | OWA 和 GetAccessTokenForResource 流程、令牌验证缺陷及缓解措施。 |
| 3 | Microsoft 密钥获取调查文章 | 原始崩溃转储假设、2024 年 3 月更正、通用元数据端点及验证说明。 |
| 4 | CSRB 对 Microsoft Exchange Online 入侵事件的审查 | 独立重建、可避免性结论、密钥生命周期、日志记录、文化及建议。 |
| 5 | CISA CSRB 发布页面 | 独立审查的政府发布背景。 |
| 6 | CISA-FBI 公告 AA23-193A | 增强监控指南、MailItemsAccessed 日志作用及服务商的缓解责任。 |
| 7 | CISA 日志政策声明 | 重要安全日志不应要求高级许可的公共政策立场。 |
| 8 | Microsoft 扩展云日志声明 | Microsoft 承诺为标准客户扩展审计事件和保留期。 |
| 9 | CISA、OMB、ONCD 和 Microsoft 联邦日志声明 | 确认联邦机构扩展日志记录和 180 天默认保留期。 |
| 10 | 美国国务院简报 | 受影响机构描述:从 10 个 State 账户下载了约 60,000 封电子邮件。 |
| 11 | 众议院监督调查 | 国会监督背景和受影响机构的担忧。 |
| 12 | 参议员 Wyden 调查请求 | 要求联邦调查和问责审查的公开请求。 |
| 13 | 众议院国土安全听证会记录 | 关于安全失败、联邦依赖和补救措施的公开听证记录。 |
| 14 | Brad Smith 书面证词 | Microsoft 证词接受 CSRB 问题并描述 Secure Future Initiative 工作。 |
| 15 | Microsoft Secure Future Initiative 启动 | 初步补救计划、自动化密钥管理和加固签名承诺。 |
| 16 | Microsoft 扩展 Secure Future Initiative | 密钥隔离、轮换、SDK 验证、日志、治理和激励目标。 |
| 17 | Microsoft SFI 2024 年 9 月进度更新 | 自行报告的安全文化进度、治理和文化变化。 |
| 18 | Microsoft 身份平台访问令牌文档 | 令牌受众、发行者、签名和验证的当前技术背景。 |
| 19 | Microsoft OpenID Connect 文档 | 发现元数据、签名密钥和令牌验证的技术背景。 |
| 20 | Microsoft 签名密钥轮换指南 | 定期和紧急密钥轮换的工程背景。 |
| 21 | CISA 云身份基础设施后续 | 关于令牌验证和机密管理的更广泛云身份教训。 |
| 22 | CISA Cyber Safety Review Board 概览 | CSRB 角色的机构背景。 |
令牌危害是服务商控制的故障模式
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 个其他审计事件,并将 Audit Standard 默认保留从 90 天增加到 180 天。CISA、OMB、ONCD 和 Microsoft 后来宣布扩展联邦机构日志,包括自动启用和 180 天默认保留。这些变化意义重大,因为它们将证据从付费附加项移向基线安全期望。
问责教训比一种日志类型更广泛。云服务商应将检测服务商侧控制失败所需的日志视为服务安全层的一部分。客户不应被迫购买高级可见性以发现服务商密钥或验证缺陷被滥用。服务商可以为高级分析、存储和托管检测收费。但重建客户数据访问所需的原始安全事件应更接近基线。
该事件还表明检测可能来自客户,早于服务商理解失败。国务院看到异常。Microsoft 随后调查并识别了伪造令牌路径。这个序列只有在客户有足够日志发起警报和有足够渠道上报时才是健康的。没有国务院的增强日志和调查,公开时间线可能更糟。服务商控制的缓解不抹杀客户检测的成功。
公共部门连续性包括可信通信
受影响账户包括公共部门和政府相关邮箱。国务院后来表示从 10 个账户下载了约 60,000 封邮件,且受攻击系统为非机密系统,机密邮件未被黑。CSRB 识别出全球 22 个组织和超过 500 个受影响个人。这些细节审慎地框定了危害:并非政府邮件可用性崩溃,公开记录未披露消息内容。但这仍是严重的可信通信失败。
现代公共部门工作依赖云邮件进行外交、商业、政策、日程、谈判和行政协调。机密性丧失可以改变行为,即使服务在线。官员可能需要假设通信已被阅读,来源或计划需要保护,未来通信可能转移到不同渠道。服务不需要下线就造成运营成本。
这就是 Storm-0558 既属于网络安全也属于公共部门连续性的原因。连续性通常通过可用性定义:机构能否继续运行?更成熟的模型包括可信操作:机构能否在无对手可见性的情况下继续将服务用于其预期公共功能?一个技术上工作但可被对手静默读取的邮箱是退化的基础设施。
公共问责问题因政府作为依赖型客户而变得更加尖锐。他们可以制定采购要求、要求日志、进行监督并在理论上移动工作负载。实际上,他们依赖少数云服务商提供核心身份和通信。这种依赖意味着服务商补救不仅是客户服务,更是公共基础设施修复。
国会信件、听证会和 CSRB 审查反映了这种依赖。它们未建立法庭判决或监管责任认定,但它们将服务商的安全文化、密钥管理和日志选择带入公众视野。这对于公共机构使用的共享云身份基础设施的失败是适当的。
安全文化成为操作控制
CSRB 的报告未局限于一个代码缺陷。它批评了 Microsoft 的安全文化,并描述了一系列可避免的失败。这种框架很重要,因为签名密钥生命周期、令牌验证、日志默认值、企业网络泄露、根因更正和客户可见性并非孤立的缺陷。它们是组织优先级、工程系统、风险接受和治理的结果。
安全文化听起来可能模糊。在此事件中,它有具体形式。手动密钥轮换流程在停机担忧后暂停,未完成自动替换。一个验证假设跨越了消费者-企业边界。高级日志限制了客户可见性。一个早期公开说明在 Microsoft 知道需要更正后仍过于确定地保持了太长时间。这些并非态度;它们是操作决策和控制状态。
Microsoft 以 Secure Future Initiative 及其后续扩展作为回应。公司描述了自动化密钥管理、硬件安全模块、机密计算、标准身份 SDK、有状态验证、密钥分区、扩展日志、治理变更、副 CISO、绩效审查变更和高管薪酬挂钩。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 扩展 Audit Standard 事件和保留期的承诺因此不仅仅是客户成功的姿态。它改变了危害分配模型。如果基线客户获得更多日志,他们可以在服务商控制失败时参与检测和范围界定。如果联邦机构获得自动启用和更长保留,他们较少依赖事后重建。更多日志不防止密钥泄露。它们减少客户盲目的时间。
日志记录还影响法律和运营确定性。一个能证明哪些邮件项目被访问的组织可以定制通知、内部补救、外交响应或业务连续性措施。没有日志的组织可能必须将更广泛人群视为可能受影响。在这个意义上,日志减少次级危害。它们不仅帮助发现攻击者,也帮助避免过度广泛的不确定性。
基线标准应明确:检测未授权客户数据访问、特别是当根因可能位于服务商控制基础设施时所需的事件,应作为服务的一部分包含。高级关联、托管检测、长期存档和分析可保持高级产品。客户数据是否被访问所需的最小证据不应是奢侈品。
服务商更正是事件响应的一部分
Storm-0558 还使公开更正成为运营问责的一部分。Microsoft 发布了初始事件通知、技术分析和密钥获取调查文章。9 月的文章提供了详细说明,后来不得不缩小。2024 年 3 月的更正不仅编辑了历史脚注。它改变了客户能负责任地相信的关于根因的内容。
事件响应常将公开沟通视为独立于技术补救。在云信任事件中,它们相连。决定是否信任服务商关闭的客户需要准确了解哪些控制失败。如果获取路径被描述为崩溃转储,客户期望崩溃转储和调试环境控制关闭问题。如果获取路径未知,客户期望更广泛密钥生命周期加固和更强证据保存。措辞决定了保证需求。
更正因此应快速、可见且明确。服务商不应将根因信心水平的变化埋藏在版本更新中,而不明确说明变化内容和原因。Microsoft 确实添加了 2024 年 3 月更新,CSRB 后来讨论了更正的时间和意义。问责教训是根因信心本身是一个已披露事实。当信心从“这发生了”降到“这仍是我们主要假设”时,客户需要知道。
这种标准保护服务商和客户。诚实更正防止公开记录围绕错误解释固化。它允许补救适当扩大。它表明服务商愿意区分证据和叙事便利。在高信任云基础设施中,这种区分是服务可信度的一部分。
共担责任需要控制面地图
Storm-0558 是模糊共担责任语言的有用解毒剂。“共担责任”这个词如果不命名控制面可能变成迷雾。在此事件中,Microsoft 控制密钥生命周期、令牌验证、服务侧缓解、基线日志可用性、内部证据保存和大部分根因证明。客户控制租户监控、事件上报、邮箱审查、账户卫生和策略配置。政府控制采购压力、监督和公开审查机制。这些角色不同。
控制面地图防止两种糟糕论点。第一种糟糕论点说客户自担云安全责任,因此应已防止事件。这失败,因为客户无法阻止 Microsoft 服务接受使用 Microsoft 控制材料签名的伪造令牌。第二种糟糕论点说服务商控制根因,因此客户没有有意义角色。这也失败,因为国务院的检测、客户日志和上报实质性地改变了公开响应。
更好的模型问四个问题。谁能防止此类失败?谁能首先检测?谁能遏制?谁能证明范围?对于 Storm-0558,Microsoft 有最强预防和遏制控制。客户,此处国务院,有关键检测角色,因为它拥有并使用增强邮箱日志。范围证明共享但不对称:客户可以检查租户(如果日志存在),而 Microsoft 必须解释服务商侧信任和密钥证据。
采购应反映该地图。购买云邮件和身份的客户应不仅问正常运行时间和合规认证,还问密钥轮换、令牌验证、发行者边界测试、默认审计事件、服务商侧日志保留、事件更正政策和独立审查选项。这些并非深奥控制。它们是当服务商信任结构失败时决定发生了什么控制。
公共机构有额外责任,因为它们的依赖可塑造市场标准。当政府客户坚持关键日志是基线时,服务商可能为更广泛人群改变产品。Storm-0558 后日志扩展表明公共问责可改善默认安全态势。挑战是使这种改进系统化而非事件驱动。
问责测试
Microsoft Storm-0558 使对令牌危害的操作控制成为公共问责测试,因为决定性控制位于 Microsoft 云内部。客户可以检测、上报和调查自己的邮箱,但只有 Microsoft 能替换密钥、纠正验证、改变令牌续用行为、扩展基线日志和解释内部证据缺口。
更好的标准是服务商可验证的危害控制。云身份服务商应知道每个活动签名密钥,通过自动化和测试路径轮换密钥,通过标准库强制令牌验证,检测不可能令牌使用,保存证据足够长以进行回顾分析,以及向客户提供检测服务商发起控制失败所需的基线日志。当根因假设变化时,服务商应快速更正记录。
未解决的密钥获取路径是教训的一部分,而非需掩盖的尴尬。云客户可以接受诚实的不确定性,如果服务商证明整个危害类别正在减少。他们无法安全地生活在一个其最特权失败仅在客户发现损害后才被解释的信任系统中。

