Snowflake 将可验证修复作为共享云责任的试金石

摘要

• Mandiant 报告称，其直接处理的每起 Snowflake 事件活动均可追溯至客户凭证被盗，且未发现任何证据表明未经授权的访问源于 Snowflake 企业环境遭到入侵。其活动报告见https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion。
• 该活动仍考验了供应商责任，因为 Snowflake 控制着认证界面、产品默认设置、安全指南、账户遥测、网络策略工具、Trust Center 检查以及任何单个客户无法独立完成的后续变更。
• 可验证修复意味着可衡量的改变：新账户中默认对人为用户启用 MFA、更严格的密码规则、泄露密码自动禁用、客户证据包、网络来源控制以及显示整个安装基数风险降低的采用指标。
• 客户责任依然重大。客户控制着用户创建、角色授予、密码轮换、现有账户的 MFA 注册、承包商访问、网络允许列表、数据最小化、导出权限以及调查准备。

并未证明平台遭到入侵；但基线显示配置过于宽松

首要准则是保持活动边界的准确性。Mandiant 2024 年 6 月的报告指出，其所处理事件中的未经授权访问来自被盗客户凭证，且未发现任何证据表明 Snowflake 企业环境遭到入侵。CISA 在https://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access上放大了 Snowflake 的客户指南，同样指导客户调查未经授权的用户访问并加强身份和网络控制。经审查的记录并未证实存在 Snowflake 平台漏洞利用、跨租户逃逸或供应商主凭证被盗的情况。

这一否定发现意义重大，因为它决定了即时响应措施。如果当前问题是有效用户凭证没有 MFA、无网络允许列表且角色权限过宽，那么客户不应等待供应商修补程序。客户需要轮换凭证、禁用账户、检查登录和查询历史、限制来源网络、审查角色、保存日志并在必要时通知受影响人员或监管机构。

相反的错误是声称供应商没有责任，因为第一个秘密属于客户。Snowflake 运营着接受这些密码的认证端点。它提供了 MFA 功能，并选择了何时更改默认行为。它决定公开或隐藏遥测字段。它提供了网络策略控制和 Trust Center 调查结果。它能看到单个租户看不到的跨客户信号。它本可以在事后将泄露密码保护功能内置到服务中。这些都是实际的控制能力，即使账户属于客户。

Snowflake 在https://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htm上的 2025 财年年度申报声明了该公司的共同责任立场，并描述了 2024 年活动后的法律、监管和声誉后果。申报是公司声明，而非裁定。但它仍然相关，因为 Snowflake 自己披露该活动影响了超出任何单一客户租户的业务风险。共同责任变成了一个上市公司的问题。

因此，本文的视角不是“Snowflake 被入侵”或“只有客户自身失败”。而是可验证修复。在一次活动利用可预见的仅密码访问、过时信息窃取凭证以及缺失的网络限制模式之后，供应商和客户都需要证据证明：下一次类似活动将拥有更少的可用凭证、更少的仅密码会话、更少的无限制来源、更好的警报以及更快的证据传递。

攻击路径利用正常功能，却使用恶意身份

Mandiant 描述了一条实用的攻击链。凭证被信息窃取恶意软件从非 Snowflake 所有的系统中盗取，某些情况下包括用于个人活动的承包商计算机。这些凭证持续有效，有时长达数年。账户缺乏 MFA。客户实例没有网络允许列表。攻击者使用标准客户端和工具连接，执行侦察，选择数据，暂存结果，压缩文件并取回。这一模式使用了受支持的数据库功能，但身份未经授权。

这一区别对修复至关重要。静态加密并非决定性的障碍。Snowflake 在https://docs.snowflake.com/en/user-guide/security-encryption-end-to-end上的端到端加密文档描述了静态和传输中的加密，但也说明在表操作期间必须使用数据，并且授权用户可以卸载和下载数据。一个满足账户认证并继承角色的攻击者，可以向服务请求可读结果。加密不能替代身份保证、角色设计、导出控制和检测。

访问控制决定了登录后的破坏范围。Snowflake 在https://docs.snowflake.com/en/user-guide/security-access-control-overview上的访问控制概述描述了角色、权限、所有权和层次结构。一个被盗凭证被分配了狭窄访问权限，与分配了广泛读取权限或账户管理权限的凭证完全不同。为管道构建的服务账户不同于承包商管理员。最小权限不是口号；它意味着恶意会话是返回一个视图，还是浏览主要的客户表。

数据分类和遮蔽可以减少后果。Snowflake 在https://docs.snowflake.com/en/user-guide/classify-intro上的敏感数据分类文档将敏感列的发现与遮蔽和行访问策略联系起来。这并不证明受影响的客户具有此类控制。它展示了一条修复路径：客户应识别个人和受监管字段，在可能的情况下公开视图而非原始表，并将导出角色与普通读取角色分开。

观察到的渗漏路径也使导出本身成为一个控制点。批量卸载在数据平台中是合法的。它们支持分析、备份、下游处理和模型工作流。但一个异常会话创建临时暂存区、导出大量结果并从陌生来源下载它们，不仅仅是“一个查询”。它是一个数据移动事件。修复应该使此类事件可测量、可归因，并且对于高风险数据集，应可中断。

MFA 的可用性变成了 MFA 的结果

MFA 在活动之前就已可用。Mandiant 报告中成功的账户却缺乏 MFA。这一差距是共同责任争议的核心。客户管理员可以启用 MFA，而许多人没有这样做。供应商可以说控制是可用的。但看到许多高价值账户仍仅通过密码可达的供应商，尚未实现安全结果，只是提供了设置。

Snowflake 2024 年 9 月在https://www.snowflake.com/en/blog/multi-factor-identification-default/上的公告改变了产品姿态。它表示，自 2024 年 10 月起创建的账户中，将默认对人为用户执行 MFA，服务用户不受该特定要求约束。它还宣布了对新创建和修改的用户密码实施更严格的密码要求。这是有意义的修复，因为它改变了未来账户的默认路径。

新账户和现有账户之间的区别同样重要。对未来账户的默认设置不会自动消除安装基数中的每个仅密码路径。现有客户可能存在遗留用户、服务账户、承包商、紧急账户和较旧的客户端。因此，一个可验证的修复记录应直接衡量遗留风险：无 MFA 的人为用户数量和比例、无 MFA 的特权人为用户、最后登录日期陈旧的密码用户、已知凭证遭泄露的用户、使用密码而非更强工作负载认证的服务账户，以及带有业务负责人和到期日期的例外情况。

Snowflake 在https://docs.snowflake.com/en/user-guide/authentication-policies上的认证策略文档为管理员提供了对认证方法、客户端、身份提供商和 MFA 注册的控制。其在https://docs.snowflake.com/en/user-guide/key-pair-auth上的密钥对认证文档为服务账户提供了静态密码的替代方案。这些控制将责任置于客户身上，但也定义了供应商的修复范围：产品应使良好的模式更容易，不良的例外更可见，迁移风险更小。

NIST 数字身份指南在https://pages.nist.gov/800-63-4/sp800-63b.html上有助于阐述结果。密码不具备重放抵抗性。防钓鱼或密码学绑定的方法降低了被盗密码的价值。对于 Snowflake 客户，这意味着人管理员应通过联合身份或强 MFA 进行认证，而服务用户应使用范围受限、可轮换且无需模仿自然人的工作负载凭证。

泄露密码拦截使共同责任可衡量

在凭证盗窃活动之后，最直接的供应商修复不是关于密码重用的说教。而是让已知被盗的密码停止工作。Snowflake 2024 年 12 月在https://www.snowflake.com/en/blog/leaked-password-protection/上的公告表示，它将通过隐私保护流程，在确认密码已泄露且仍然有效时，自动禁用在暗网发现的密码。这一控制解决了活动的核心优势：早在 2024 年之前就被盗的凭证仍被服务接受。

泄露密码保护并未消除客户责任。客户仍然需要端点安全、承包商治理、密码轮换、联合、服务用户设计和最小权限。但这改变了劳动分工。单个客户通常无法像云供应商那样全面了解全球信息窃取市场。供应商可以购买或接收威胁情报，以受控方式匹配暴露的凭证，并在每个客户独立发现之前禁用密码。这就是那种供应商级别的控制，它将共同责任从条款转变为系统行为。

证据问题是采纳和表现。发现了多少有效的泄露密码？它们被禁用有多快？有多少属于特权用户？有多少账户从密码转向了密钥对或联合访问？有多少密码禁用事件导致了支持摩擦或不安全的变通方案？有多少客户仍然存在例外？没有度量标准，泄露密码保护就只是一个好的公告。有了度量标准，它就成了可验证的修复。

CISA 的“设计安全”承诺在https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf上构建了这一区别。它要求制造商从可选控制转向可衡量的结果，如默认 MFA 和采用指标。Snowflake 2024 年 7 月在https://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/上的承诺公告将公司置于这一公共承诺之内。该承诺是自愿的，并非对活动的法律裁决。它之所以相关，是因为它确定了事件发生后客户应期待的证据类型。

网络策略是第二道门

Mandiant 将缺少网络允许列表确定为一个反复出现的因素。Snowflake 在https://docs.snowflake.com/en/user-guide/network-policies上的网络策略文档阐述了实际默认情况：没有策略，用户可以从任何计算机或设备连接。客户可以通过允许或阻止的网络位置限制访问，并使用私有连接模式实现更强的边界。

客户是最佳定位角色，了解合法来源：办公室、VPN、云工作负载、受管理的承包商桌面和经批准的集成提供商。Snowflake 无法在不破坏服务的情况下猜测每条有效路径。但 Snowflake 控制着无限制的公共访问是静默还是可见。一个可验证的修复计划应报告哪些账户缺乏网络策略，哪些特权用户绕过策略，内部暂存区访问是否被覆盖，以及策略是否实际与业务批准的来源匹配。

网络控制单独是不够的。攻击者可能使用经批准的 VPN，入侵已在允许列表中的承包商计算机，或在认证后窃取令牌。然而防御应该是分层的。被盗密码、没有 MFA、没有网络限制、广泛角色和不受监控的导出构成一条链。打破任何一个环节都可能起作用。修复是减少仍然同时打开所有环节的客户环境数量的过程。

供应商还应使锁定管理安全。管理员可能因担心阻止业务用户或服务作业而回避网络策略。模拟、分阶段推出、紧急联系人、临时例外和清晰的日志可以减少这种恐惧。迁移路径越好，将缺失的策略视为正常就越难。

遥测是证据边界

在数据盗窃活动之后，客户需要的不仅仅是笼统的保证。他们需要知道谁登录了、从哪里、使用哪种认证因素、使用哪种客户端、在哪个角色下、执行了哪些查询、触及了哪些对象、卸载了哪些数据、使用了哪些暂存区以及移动了多少数据。Snowflake 当前的文档描述了多个可以支持此类工作的视图。

https://docs.snowflake.com/en/sql-reference/account-usage/login_history上的 LOGIN_HISTORY 提供登录尝试信息，包括来源 IP、客户端、成功和认证因素信息。https://docs.snowflake.com/en/sql-reference/account-usage/query_history上的 QUERY_HISTORY 提供查询活动、用户、角色、查询文本、结果大小、卸载行数和通过网络发送的字节数。https://docs.snowflake.com/en/sql-reference/account-usage/access_history上的 ACCESS_HISTORY 可以帮助重建合格版本的对象和列访问。https://docs.snowflake.com/en/user-guide/trust-center/overview上的 Trust Center 文档描述了针对 MFA、网络策略、风险登录、异常 IP 地址和大型传输的姿态检查和检测。

这些是能力。能力不等同于调查准备。客户必须有权查询这些视图，将其导出到持久的安全存储中，理解延迟和保留期，并将其与身份提供商、端点和工单数据相关联。版本差异可能改变字段级范围的精度。供应商视图可能存在对主动遏制至关重要的延迟。仅查询文本可能无法告诉隐私团队涉及哪些个人，除非客户拥有数据地图。

因此，可验证的修复应包括证据包。当 Snowflake 通知潜在受影响的客户时，客户应收到账户标识符、用户、时间戳、来源网络、第一和第二因素状态、客户端标识符、会话和查询标识符、角色、触及的对象、暂存区名称、卸载量、置信度以及建议的遏制措施。像“潜在受影响”这样的标签作为开端是可接受的，但必须随后提供足够的数据，以便客户自行决定是否涉及个人信息。

供应商干预还需要事先授权。云供应商可能在客户之前发现可疑活动，但自动阻止会话可能会中断生产。不采取行动可能允许盗窃。修复应定义临时暂停的阈值、紧急客户联系、证据保存和覆盖。客户应指定能够在任何时间采取行动的安全联系人。Snowflake 应衡量从跨客户信号到客户通知的时间，以及从通知到遏制的时间。

数据本地性终止于访问

Snowflake 区域选择对延迟、弹性、隐私和采购可能很重要。https://docs.snowflake.com/en/user-guide/intro-regions上支持区域的文档指出，账户托管在一个区域，数据保留在那里，除非用户明确复制、移动或复制它。它还指出了关键限制：区域选择不限制用户对 Snowflake 的访问。

这次活动将这一限制变成了主权问题。客户的表可能存储在已获批准的区域。一个有效身份仍然可以从其他地方连接，查询数据，将其卸载到暂存区，并下载副本。源账户的位置并未阻止远程访问或导出。公开的活动记录并未确定每个受害者的来源国和目的地国，因此无法得出普遍的跨境法律结论。架构教训依然存在：存储本地性不是访问本地性。

Snowflake 在https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.html上的跨区域共享指南警告客户，在将数据复制到另一个区域或国家之前，应确认法律和监管限制。该指南涉及已批准的移动。凭证驱动的导出则不同，因为它可以在不更改源账户区域的情况下，在选定区域之外创建不受控制的副本。仅记录源区域的数据清单可能是准确的，但在导出后仍不完整。

因此，数据主权修复需要四个层面：权威数据托管在何处，哪些身份可以从哪些设备和司法管辖区连接，哪些移动功能可以创建副本，以及事件后存在哪些证据。Snowflake 控制区域供应、认证、网络工具、导出机制和遥测。客户控制合法基础、数据字段、角色授予、移动批准和通知分析。双方都需要在其边界上获得证据。

客户案例显示了后果，而非单一总计数

活动的公开形态受到受影响公司披露的影响。每条记录都必须停留在其自身的事实之内。

Live Nation 2024 年 5 月在https://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htm上提交的文件称，该公司发现了一个第三方云数据库环境中的未授权活动，该环境主要包含 Ticketmaster 数据，后来一个犯罪者声称出售了据称属于公司的用户数据。该文件未点名 Snowflake，也未提供确认的受影响人数。

Ticketmaster 加拿大在https://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incident上的事件页面描述了一个孤立的第三方云数据库，可能包含某些北美购票者的字段，并指出 Ticketmaster 客户账户未受影响。加拿大隐私专员后来在https://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/上的议会简报中确定 Snowflake 是 Ticketmaster 的供应商，同时表示调查仍在进行，Ticketmaster 加拿大仍是受审查的控制者。

AT&T 2024 年 7 月在https://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htm上提交的文件描述了第三方云平台上 AT&T 工作区的非法访问以及通话和短信交互记录的渗漏。该文件未点名 Snowflake。它有助于理解一个已披露的第三方云工作区事件及其字段边界，而非作为独立归因。

这些例子并未创建活动范围内的人员计数。Mandiant 估计的大约 165 个潜在受影响组织是通知群体，而非确认的受害者数量、记录数量或受影响个人数量。每个客户持有不同的数据、角色、保留期、区域和通知职责。可验证的修复必须帮助每个客户界定其自身的事实，而不是让单一的平合计数值承担所有工作。

关于证据包的一条排版注释

当客户收到高严重性的云安全证据时，布局可能决定正确的人是否迅速行动。包含会话、因素、角色、对象和传输的表格必须在压力下可读。以下排版块属于公共正文，因为证据设计是修复的一部分。

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

• 排版起源于 15 世纪约翰内斯·古腾堡发明的活字印刷。
• 关键要素包括字体选择、字距调整、字偶间距和行距。
• 良好的排版增强可读性，并在设计中传达情绪或基调。

对于 Snowflake 客户，可读的证据意味着时间戳采用同一时基、清晰的用户和角色标签、分离经确认的活动与怀疑、可见的 MFA 状态以及查询、暂存区、传输量和受影响数据存储之间的直接链接。密集的日志导出可能完整但难以使用。简洁的证据包可能是快速遏制决策与延迟隐私分析之间的区别。

根据实际控制分配责任

攻击者控制了犯罪活动：使用盗取的凭证进入客户环境，暂存数据，取走数据，并尝试出售或勒索。他们对这些行为负责。

客户控制了许多失效的门。他们创建用户、分配角色、选择人为用户是否可以仅用密码登录、保留过期凭证、允许承包商访问、让某些账户没有网络策略、授予数据访问权限并管理导出。一个高价值仓库接受来自陌生来源的旧密码，且没有 MFA 或狭窄角色的客户，不能将所有责任推给供应商。

Snowflake 控制了基线和修复工具。它控制了新人为用户是否默认具有 MFA、泄露密码是否在供应商端禁用、风险配置是否出现在 Trust Center 中、哪些遥测字段可用、如何通知客户、如何编写指南以及活动后控制措施的交付速度。一个看到跨租户相同模式的供应商，有责任大规模减少该模式，而不仅仅是告诉每个客户阅读手册。

身份提供商、承包商和端点所有者控制了相邻条件。跨客户的承包商设备使用，可以将一个信息窃取事件传播到多个云租户。身份提供商可以强制执行更强的因素和条件访问。受管理的端点可以将凭证保留在个人计算机之外。这些角色很重要，但它们不会消除客户和供应商对 Snowflake 账户本身的责任。

监管机构、保险公司和采购团队控制着激励措施。NIST 在https://csrc.nist.gov/pubs/sp/1305/final上的供应链指南支持定义与关键性成比例的供应商要求。对于数据仓库，这意味着合同和续约应询问 MFA 采用指标、泄露密码响应、证据包字段、保留期保证、通知时间、支持升级和区域移动控制。在此次活动之后，仅询问 MFA 是否存在已过于肤浅。

什么将证明持久修复

修复记录应包括至少十项成果。

首先，所有新人为用户默认使用 MFA 或更强的联合访问，且安装基数显示受保护的人为和特权人为账户比例不断上升。其次，服务用户从静态密码转向密钥对、OAuth 或其他带轮换的范围受限工作负载凭证。第三，泄露密码保护报告确认的禁用事件和平均禁用时间。第四，网络策略覆盖率提高，特别是对于特权账户和内部暂存区。

第五，Trust Center 调查结果不仅仅是显示，而是与例外负责人和到期日期一起得到修复。第六，遥测保留和导出足以支持延迟发现和隐私范围界定。第七，大规模卸载和异常来源检测得到调优，并路由给能够采取行动的人。第八，供应商通知包括具体的会话、查询、角色、对象和传输证据。第九，受影响客户可以将查询映射到个人和受监管的数据类别。第十，客户合同和续约审查纳入证据，而不是依赖共同责任的措辞。

诉讼可能会影响记录，但不应取代控制证据。Snowflake 多地区诉讼在https://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdf上的诉状阶段命令允许某些指控继续进行，同时根据程序标准进行处理。这不是最终的责任认定。但它确实表明，即使公开报道始于客户凭证，法院仍可能审查供应商的默认设置、可预见性和因果关系。

安装基数问题

安全默认设置在创建时最有效。在客户已经拥有自动化、服务用户、承包商、身份提供商、旧客户端和紧急账户的安装基数中，它们更难实施。Snowflake 对新账户的默认 MFA 更改是实质性的步骤，但活动的风险主要存在于具有现有习惯的现有账户中。因此，可验证的修复需要一个针对安装基数的迁移故事，而不仅仅是一个新账户故事。

安装基数问题有几个层面。首先，旧的人为用户可能仍然直接使用密码进行认证，因为联合从未完成。其次，特权用户可能拥有例外，因为管理员害怕被锁定。第三，服务用户可能被错误分类为人，或者人可能使用服务风格的凭证。第四，承包商可能在项目结束后保留访问权限。第五，休眠账户可能仍然拥有能够访问敏感数据的角色。第六，如果密码规则或网络策略突然改变，集成可能会失败。

供应商可以在不接管客户租户的情况下减少这种摩擦。它可以向管理员显示按特权和数据覆盖范围分割的风险身份优先级列表。它可以提供试运行策略，显示谁将被 MFA 或网络限制阻止。它可以要求例外负责人和到期日期。它可以区分紧急账户和普通遗留账户。它可以为转向密钥对或 OAuth 模式的服务用户提供迁移辅助。它可以发送与实际风险相关而不是通用横幅的重复产品提示。

然后客户必须采取行动。收到一个显示特权仅密码用户的仪表板并数月保持不变的客户，承担了该剩余风险。一个无法判断承包商账户是否仍然需要的客户，拥有一个身份治理失败。一个因为“管道过去需要它”而让服务账户读取整个原始表的客户，拥有过度的角色范围。当供应商展示证据，客户要么修复要么记录负责任例外时，共同责任就变得具体。

修复记录应区分三种状态：已修复、例外和未知。已修复意味着风险条件消除。例外意味着业务负责人接受了它，并有补偿控制和复审日期。未知意味着没有人承担责任。一个成熟的计划将未知计数推向零。公开保证通常跳过这一区别；可验证的修复则依赖它。

客户证据必须将技术日志与人员联系起来

Snowflake 可以公开丰富的技术遥测，但隐私和法律响应需要从技术对象到人员和义务的桥梁。查询标识符、角色名称或暂存区路径只是开始。客户必须知道哪个表包含哪些个人字段、代表了哪些数据主体、适用哪些国家或州规则、存在哪些合同通知义务以及哪些下游系统接收了副本。没有这座桥梁，客户可能知道字节离开了，但不知道通知谁。

这座桥梁应在事件之前准备好。数据所有者应维护受监管数据的字段清单、业务目的、保留期、遮蔽策略和经批准的导出路径。安全团队应知道 Snowflake 日志在平台外部保留的位置以及多长时间。隐私团队应能够要求提供受影响的表列表，并接收与人员类别和字段的映射。法律团队应知道哪些区域和客户合同附加到这些记录。

供应商证据可以使这种情况更容易。如果通知包括确切的角色、对象、暂存区和数量，客户可以避免广泛而缓慢的搜索。如果供应商还标记是否存在 MFA、来源是否异常以及泄露密码保护后来是否禁用了凭证，客户可以了解原因和遏制。如果供应商仅提供一般性建议，客户必须在通知和勒索响应时钟已经开始运行时重建证据。

此次活动还暴露了遥测本身的一个保留问题。原生历史可能涵盖一年，但法律纠纷、延迟发现和监管机构问询可能延长更久。高风险客户应将日志流式传输到独立的、保留期与其义务相符的安全存储中。供应商应使此类导出实用且文档化。客户应通过定期重建从登录到查询再到数据类别的示例访问路径来证明它有效。

修复不能依赖客户蒙羞

在凭证活动之后，很容易将没有 MFA 的客户视为故事的教训。这部分正确，但仍然不足。公开羞辱客户并不能禁用泄露密码、重新设计默认值或提供证据包。它甚至可能使客户隐藏薄弱配置，直到事件迫使披露。

更好的模式是渐进式加固。供应商从可见性开始，然后是更强的默认值，然后是有针对性的警告，然后是例外治理，然后对后果足以证明其合理性的风险类别实施强制执行。客户获得迁移时间和工具，但他们也失去了让高风险缺口隐藏的能力。然后，采购团队要求采用指标和例外计数，而不仅仅是功能列表。

这种方法认识到，云平台是业务数据的共享操作系统。一个使更安全默认设置的供应商可能会短暂增加客户摩擦，但也减少了犯罪集团可用的目标池。接受强制执行的客户可能需要更新脚本或身份，但获得了针对监管机构、保险公司和数据主体的更强叙述。当双方都能指向已改变的条件，而不是已改变的信息传递时，修复就有效了。

采购应要求提供修复遥测

高价值数据平台的购买者应将活动后遥测视为采购要求。问题不仅在于供应商现在是否提供 MFA、网络策略、泄露密码控制和 Trust Center 调查结果。问题在于购买者是否能够收到证据，证明这些控制是活跃的、完整的，并且在购买者自己的账户中经过测试。功能可用性是供应商语言。控制覆盖是操作语言。

采购记录应要求提供身份覆盖报告，包括人为用户、特权用户、服务用户、休眠账户、外部承包商、联合状态、MFA 状态和密码例外。应要求按账户、用户类别、内部暂存区和私有端点提供网络覆盖。应询问泄露密码保护是否启用，它产生什么事件通知，以及禁用的密码如何反映在审计记录中。应询问在合同层级可获得哪些 Trust Center 调查结果，以及相关历史保留多长时间。

事件条款应同样具体。一个通用的通知条款在此次活动之后很薄弱。客户需要高严重性通知的时间表、将包含的证据字段、紧急联系人、支持升级、日志保存和数据主体范围界定的合作。持有受监管个人数据的客户应在续约之前要求提供样本证据包，而不是在盗窃之后。一次桌面演练可以测试供应商和客户能否在必要的窗口内从可疑登录移动到受影响字段分析。

这并没有将所有工作转移给 Snowflake。客户必须维护自己的映射，保留日志，并了解其隐私义务。但供应商控制着确保映射变得可用的许多事实。一个仅要求保证的采购过程将错过运营问题。一个要求修复遥测的采购过程将揭示共同责任是否已为下一次活动做好准备。

相同的证据应出现在续约中。如果客户在活动一年后仍然依赖密码密集型访问，续约应强制要求指明例外或资助的迁移。如果客户由于版本原因无法收到 ACCESS_HISTORY 级别的详细信息，续约应记录该限制对于存储的数据是否可接受。如果缺少网络策略，续约应明确识别运营障碍。应在杠杆作用在另一个合同期限内消失之前审查修复。

续约证据还应将平台变更与租户变更分开。Snowflake 可以提供更强的默认设置，但客户的账户可能仍包含仅密码用户、广泛角色、过期承包商和未审查的暂存区。购买者应要求提供账户自身的例外分类账，而不仅仅是供应商的产品路线图。这一区别防止了熟悉的事件后漂移：供应商宣布一项控制，客户认为风险已转移，而安装基数仍实质上暴露。

对于董事会和隐私团队而言，该租户级别的记录是技术修复与法律信心之间的桥梁。一个声称“MFA 可用”的说法并不能回答受影响账户是否使用了它。一个声称“存在网络策略”的说法并不能回答被盗凭证是否能够从不寻常来源到达数据。一个声称“遥测被保留”的说法并不能回答组织是否可以将查询映射到受监管字段。可验证的修复存在于这些特定于账户的答案中。

不应得出的推论

一份克制的说明应避免四个跳跃。首先，该活动并未证明 Snowflake 的生产平台被入侵。其次，它并未证明每个被通知的组织都丢失了数据。第三，它并未证明每个受影响的客户都有相同的字段、人员或法律义务。第四，活动后的产品变更本身并不证明变更前的疏忽。安全产品在事件后因多种原因而演变，包括更好的威胁情报和变更的标准。

同时，克制并不要求对供应商责任保持沉默。供应商可能没有平台入侵的发现，但仍然应对默认设计、遥测质量和跨客户警告负责。客户可能因薄弱的身份控制而有过错，但仍然需要供应商的数据来调查。诉讼命令可能是非最终的，但仍然表明默认 MFA 和可预见性将受到审查。平衡的责任问责同时维持所有这些命题。

最终评估是高影响和高置信度。经确认的证据支持客户凭证活动，而非 Snowflake 平台入侵。但证据也表明，为什么供应商的默认设置、遥测和跨客户安全自动化是责任的一部分。只有当双方都能展示他们关闭的门时，共同责任才是可信的。在这次活动之后，Snowflake 的考验不是它能否说 MFA 存在过。而是更少的被盗密码能够成为会话，更少的会话能够触及广泛的数据，更多的客户能够在数据离开之前准确证明发生了什么。