摘要
- Mandiant 报告称，其直接处理的所有 Snowflake 活动事件均源于客户凭证泄露，且未发现未经授权的访问源于 Snowflake 企业环境被攻破的证据。其活动报告见https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion。
- 该活动仍然考验了提供商的责任，因为 Snowflake 控制着认证界面、产品默认设置、安全指南、账户遥测、网络策略工具、信任中心检查以及事后变更，这些是任何单个客户都无法单独完成的。
- 可验证修复意味着可衡量的变革：新账户中人类用户的默认多因素认证、更强的密码规则、自动禁用泄露密码、客户证据包、网络来源控制以及显示已安装基础上风险降低的采用指标。
- 客户责任仍然重大。客户控制着用户创建、角色授权、密码轮换、现有账户的多因素认证注册、承包商访问、网络允许列表、数据最小化、导出权限以及调查准备能力。
平台未显示被攻破；但基线显示过于宽松
第一项纪律是保持活动边界准确。Mandiant 2024 年 6 月的报告称，其处理的事件中的未授权访问来自受损的客户凭证，且未发现 Snowflake 企业环境被攻破的证据。Snowflake 的客户指南（由 CISA 在https://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access放大）同样指示客户调查未授权的用户访问并加强身份和网络控制。审查的记录并未确立 Snowflake 平台漏洞、跨租户逃逸或提供商主凭证被窃取。
这一负面发现很重要，因为它塑造了即时响应。如果当前问题是有效用户凭证没有多因素认证、无网络允许列表和广泛角色权限，客户不应等待提供商的补丁。客户需要轮换凭证、禁用账户、检查登录和查询历史、限制来源网络、审查角色、保留日志并在必要时通知受影响的人员或监管机构。
相反的错误是说提供商没有责任，因为第一个秘密属于客户。Snowflake 运营着接受这些密码的认证端点。它提供了多因素认证能力并选择了何时更改默认行为。它公开或扣留了遥测字段。它提供了网络策略控制和信任中心发现。它可以看到任何单一租户无法看到的跨客户信号。它后来可以在服务中构建泄露密码保护。这是真正的控制，即使客户拥有账户。
Snowflake 的 2025 财年年度报告见https://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htm，阐明了公司的共享责任立场，并描述了 2024 年活动后的法律、监管和声誉后果。报告是公司的陈述，而非裁决。但它仍然是相关的，因为 Snowflake 自身披露了该活动影响了超出任何单个客户租户的业务风险。共享责任成为了一家上市公司的问题。
因此，本文的视角并非“Snowflake 被攻破”或“客户单独失败”。而是可验证修复。在一种活动利用可预见的纯密码访问、过时的信息窃取凭证和缺失的网络限制模式之后，提供商和客户需要证据证明下一次类似活动将具有更少的有效凭证、更少的纯密码会话、更少的无限制来源、更好的警报和更快的证据交付。
活动路径使用常规功能在敌对身份下进行
Mandiant 描述了一个实际链条。凭证已被信息窃取恶意软件从非 Snowflake 拥有的系统（包括在某些情况下用于个人活动的承包商机器）窃取。这些凭证仍然有效，有时长达数年。账户缺乏多因素认证。客户实例缺乏网络允许列表。攻击者使用标准客户端和工具连接，进行侦察、选择数据、暂存结果、压缩文件并检索。该模式在未经授权身份下使用了受支持的数据库功能。
这一区别对修复至关重要。静态加密不是决定性屏障。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，将敏感列的发现与掩码和行访问策略连接起来。这并不证明受影响的客户拥有此类控制。它展示了修复路径：客户应识别个人和受监管字段，尽可能暴露视图而不是原始表，并将导出角色与普通读取角色分开。
观察到的外渗路径也使导出本身成为一种控制。在数据平台中进行批量卸载是合法的。它们支持分析、备份、下游处理和模型工作流。但一个不寻常的会话创建临时阶段、导出大量结果并从陌生来源下载不仅仅是“一个查询”。这是一个数据移动事件。修复应使此类事件可衡量、可归属，并对于高风险数据集可中断。
多因素认证的可用性变成了多因素认证的结果
多因素认证在活动之前就已可用。Mandiant 报告中的成功账户缺乏它。这一差距是共享责任争议的核心。客户管理员可以启用多因素认证，但许多人没有。提供商可以如实说控制可用。但一个提供商看到许多高价值账户仍然仅通过密码可达，并未实现安全结果，仅仅使设置可用。
Snowflake 2024 年 9 月的公告见https://www.snowflake.com/en/blog/multi-factor-identification-default/，改变了产品姿态。它表示自 2024 年 10 月起创建的账户中，人类用户默认强制使用多因素认证，服务用户不受此特定要求约束。它还宣布了对新创建和更改的用户密码的更强密码要求。这是有意义的修复，因为它改变了未来账户的默认路径。
新账户和现有账户之间的区别同样有意义。未来账户的默认值不会自动消除已安装基础中的每个纯密码路径。现有客户可能有传统用户、服务账户、承包商、应急账户和较旧的客户端。因此，可验证修复记录应直接衡量遗留风险：没有多因素认证的人类用户数量和比例、没有多因素认证的特权人类用户、具有陈旧最后登录日期的密码用户、已知暴露凭证的用户、使用密码而非更强工作负载认证的服务账户，以及具有业务所有者和到期日期的例外。
Snowflake 的认证策略文档见https://docs.snowflake.com/en/user-guide/authentication-policies，为管理员提供对认证方法、客户端、身份提供者和多因素认证注册的控制。其密钥对认证文档见https://docs.snowflake.com/en/user-guide/key-pair-auth，为服务账户提供了静态密码的替代方案。这些控制将责任放在客户身上，但也定义了提供商的修复面：产品应使良好模式更容易，不良例外可见，迁移风险更低。
NIST 数字身份指南见https://pages.nist.gov/800-63-4/sp800-63b.html，有助于说明结果。密码不是抗重放的。抗钓鱼或密码学绑定的方法减少了被盗密码的价值。对于 Snowflake 客户，这意味着人类管理员应转向联合身份或强多因素认证，而服务用户应使用作用域的工作负载凭证，这些凭证可以轮换并且可以在不冒充人的情况下禁用。
泄露密码拦截使共享责任可衡量
在凭证盗窃活动之后最直接的提供商修复不是关于密码重用的说教。它是使已知被盗密码停止工作。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，框定了这一区别。它要求制造商超越可选控制，转向可衡量的成果，如默认多因素认证和采用指标。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、攻击已经在允许列表中的承包商机器，或在认证后窃取令牌。然而防御应分层。被盗密码、无多因素认证、无网络限制、广泛角色和未监控的导出是一个链条。打破任何一环都可能有用。修复是减少所有环节同时保持开放的客户环境数量的过程。
提供商还应使锁定管理安全。管理员可能因为害怕阻塞业务用户或服务作业而避免网络策略。模拟、分阶段推出、紧急联系人、临时例外和清晰的日志可以减少这种恐惧。迁移路径越好，就越难将缺失策略视为正常。
遥测是证据边界
在数据盗窃活动之后，客户需要的不仅仅是泛泛的保证。他们需要知道谁登录了、从哪里、使用了什么因子、使用了什么客户端、在什么角色下、运行了什么查询、接触了什么对象、卸载了什么数据、使用了什么阶段、以及移动了多少数据。Snowflake 当前文档描述了多个视图，可以支持此类工作。
LOGIN_HISTORY 见https://docs.snowflake.com/en/sql-reference/account-usage/login_history提供登录尝试，包括源 IP、客户端、成功和因子信息。QUERY_HISTORY 见https://docs.snowflake.com/en/sql-reference/account-usage/query_history提供查询活动、用户、角色、查询文本、结果大小、卸载行和通过网络发送的字节数。ACCESS_HISTORY 见https://docs.snowflake.com/en/sql-reference/account-usage/access_history可以帮助重建对象和列访问（如果符合版本条件）。信任中心文档见https://docs.snowflake.com/en/user-guide/trust-center/overview描述了多因素认证、网络策略、风险登录、异常 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 Canada 的事件页面见https://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incident，描述了一个孤立的第三方云数据库、一些北美购票者可能的字段，以及 Ticketmaster 客户账户未受影响的界限。加拿大隐私专员后来在议会简报中确定了 Snowflake 为 Ticketmaster 的提供商，见https://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/，同时指出调查仍在进行，Ticketmaster Canada 仍是在审查的控制者。
AT&T 2024 年 7 月的文件见https://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htm，描述了对第三方云平台上 AT&T 工作空间的非法访问以及电话和短信交互记录的外渗。该文件未提及 Snowflake。它有助于理解一个披露的第三方云工作空间事件及其字段边界，而不是独立的归因。
这些例子并未创建活动范围的人员计数。Mandiant 大约 165 个潜在暴露的组织是一个通知人群，而不是确认的受害者计数、记录计数或受影响个人计数。每个客户持有不同的数据、角色、保留、区域和通知责任。可验证修复必须帮助每个客户界定其自身事实，而不是让单平台数字承担所有工作。
证据包的排版说明
当客户收到高严重性云安全证据时，布局可以决定正确的人是否迅速行动。会话、因子、角色、对象和传输的表格必须在压力下可读。以下排版块属于公共正文，因为证据设计是修复的一部分。
对于 Snowflake 客户，可读的证据意味着单一时间基准的时间戳、清晰的用户和角色标签、确认活动与怀疑的分离、可见的多因素认证状态，以及查询、阶段、传输量和受影响数据存储之间的直接链接。密集的日志导出可能完整但不可用。一个简洁的证据包可能是在快速遏制决策和延迟的隐私分析之间的区别。
通过实际控制的责任
攻击者控制了犯罪活动：使用被盗凭证、进入客户环境、暂存数据、带走数据以及试图出售或勒索。他们对此行为负责。
客户控制了许多失败的门。他们创建了用户、分配了角色、选择了人类用户是否可以单独使用密码登录、保留了陈旧的凭证、允许了承包商访问、使一些账户没有网络策略、授予了数据访问权限并管理了导出。一个其高价值仓库在没有多因素认证或狭隘角色下从不熟悉来源接受旧密码的客户不能将所有责任转嫁给提供商。
Snowflake 控制了基线和修复工具。它控制了新人类用户是否默认使用多因素认证、泄露密码是否在提供商侧禁用、风险配置是否出现在信任中心、哪些遥测字段可用、客户如何被通知、指南如何编写以及事后控制多快发布。一个看到跨租户相同模式提供商有责任大规模减少该模式，而不仅仅是告诉每个客户阅读手册。
身份提供者、承包商和端点所有者控制了相邻条件。跨客户使用的承包商设备可以将一个信息窃取事件传播到多个云租户。身份提供者可以强制更强的因子和条件访问。受管理的端点可以将凭证保留在个人机器之外。这些行为者很重要，但它们并不消除客户和提供商在 Snowflake 账户本身上的责任。
监管机构、保险公司和采购团队控制激励。NIST 的供应链指南见https://csrc.nist.gov/pubs/sp/1305/final，支持定义与关键性成比例的供应商要求。对于数据仓库，这意味着合同和续约应询问多因素认证采用指标、泄露密码响应、证据包字段、保留保证、通知时间、支持升级和区域移动控制。一个仅询问多因素认证是否存在的安全问卷在该活动后过于浅薄。
什么将证明持久的修复
修复记录应包括至少十个结果。
第一，所有新人类用户默认使用多因素认证或更强的联合访问，且已安装基础显示受保护的人类和特权人类账户的份额正在上升。第二，服务用户远离静态密码，转向密钥对、OAuth 或其他作用域的工作负载凭证，并轮换。第三，泄露密码保护报告确认的禁用事件和平均禁用时间。第四，网络策略覆盖范围增加，特别是对于特权账户和内部阶段。
第五，信任中心发现不仅显示，而且被修复，有例外所有者和到期日期。第六，遥测保留和导出足以用于延迟发现和隐私范围界定。第七，大额卸载和异常来源检测被调整并路由到可以采取行动的人。第八，提供商通知包括具体的会话、查询、角色、对象和传输证据。第九，受影响的客户可以将查询映射到人员和受监管数据类别。第十，客户合同和续约审查纳入证据，而不仅仅依赖共享责任措辞。
诉讼可以影响记录，但不应取代控制证据。Snowflake 多地区诉讼中诉答辩阶段指令见https://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdf，允许某些指控在程序标准下进行。这不是最终的责任认定。它确实表明法院可以审查提供商的默认设置、可预见性和因果关系，即使公开故事始于客户凭证。
已安装基础问题
安全默认值在创建时最有效。它们在已安装基础中更困难，因为客户已经有自动化、服务用户、承包商、身份提供者、旧客户端和应急账户。Snowflake 对新建账户的默认多因素认证更改是一个实质性步骤，但该活动的风险主要存在于现有账户和现有习惯中。因此，可验证修复需要为已安装基础提供迁移故事，而不仅仅是新账户故事。
已安装基础问题有几个层次。第一，旧人类用户可能仍然直接使用密码认证，因为联合从未完成。第二，特权用户可能因为管理员害怕锁定而拥有例外。第三，服务用户可能被误分类为人类，或者人类可能使用服务风格的凭证。第四，承包商可能在项目结束后仍保留访问权限。第五，休眠账户可能仍然拥有可以访问敏感数据的角色。第六，如果密码规则或网络策略突然改变，集成可能失败。
提供商可以减少这种摩擦而不接管客户的租户。它可以向管理员显示按特权和数据访问范围划分的风险身份优先列表。它可以提供显示谁会被多因素认证或网络策略阻止的试运行策略。它可以要求例外所有者和到期日期。它可以区分应急账户和普通旧账户。它可以为服务用户迁移到密钥对或 OAuth 模式提供迁移帮助。它可以发送与真实风险相关的重复产品提示，而不是通用横幅。
然后客户必须采取行动。一个收到显示特权纯密码用户仪表板并数月保持不变的用户拥有该残余风险。一个无法判断承包商账户是否仍然需要的用户拥有身份治理失败。一个因为“管道曾经需要它”而让服务账户读取整个原始表的用户拥有过度的角色范围。当提供商显示证据并且客户要么修复要么记录可接受的例外时，共享责任变得具体。
修复记录应区分三种状态：已修复、已例外和未知。已修复意味着风险条件已消失。已例外意味着业务所有者接受它，并具有补偿控制和审查日期。未知意味着没有人承担责任。一个成熟的程序将未知计数推向零。公开保证通常跳过这一区别；可验证修复依赖于它。
客户证据必须将技术日志连接到人员
Snowflake 可以暴露丰富的技术遥测，但隐私和法律响应需要从技术对象到人员和义务的桥梁。查询标识符、角色名称或阶段路径只是开始。客户必须知道哪个表持有哪些个人字段、代表哪些数据主体、适用哪个国家或州的规则、存在哪些合同通知义务，以及哪些下游系统收到了副本。没有那座桥梁，客户可能知道字节离开了，但不知道通知谁。
那座桥梁应在事件之前准备好。数据所有者应维护受监管数据、业务目的、保留期限、掩码策略和批准导出路线的字段清单。安全团队应知道 Snowflake 日志在平台之外保留在哪里以及保留多久。隐私团队应能够请求受影响表的列表，并接收映射到人员类别和字段的信息。法律团队应知道哪些区域和客户合同附加到这些记录上。
提供商证据可以使这更容易。如果通知包括确切的角色、对象、阶段和量，客户可以避免广泛而缓慢的搜索。如果提供商还标记是否有多因素认证、来源是否异常、以及泄露密码保护后来是否禁用了凭证，客户可以理解原因和遏制。如果提供商仅提供一般建议，客户必须在通知和勒索响应的时钟已经启动的情况下重构证据。
该活动还暴露了遥测本身的保留问题。本地历史可能覆盖一年，但法律纠纷、延迟发现和监管查询可能更长。高风险客户应将日志流式传输到独立的安全存储，保留期与其义务一致。提供商应使此类导出实用且有文档支持。客户应通过定期从登录到查询到数据类别重构样本访问路径来证明其有效。
修复不能依赖客户羞辱
在凭证活动之后，将没有多因素认证的客户视为故事的教训是诱人的。这在部分上是正确的，但仍不够。公开羞辱客户不会禁用泄露密码、重新设计默认值或交付证据包。它甚至可能使客户隐藏弱配置，直到事件迫使披露。
更好的模型是渐进强化。提供商从可见性开始，然后更强的默认值，然后有针对性的警告，然后例外治理，然后对后果证明合理性的风险类别的强制执行。客户接收迁移时间和工具，但他们也失去了使高优先级差距不可见的能力。然后采购团队询问采用指标和例外计数，而不仅仅是功能列表。
这种方法认识到云平台是业务数据的共享操作系统。做出更安全默认值的提供商可能暂时增加客户摩擦，但它也减少了犯罪群体可用的目标池。接受强制执行的客户可能需要更新脚本或身份，但它获得了对监管机构、保险公司和数据主体的更强说服力。当双方都可以指出已改变的条件而不是已改变的信息时，修复有效。
采购应要求修复遥测
高价值数据平台的购买者应将事后遥测作为采购要求。问题不仅仅是提供商现在是否提供多因素认证、网络策略、泄露密码控制和信任中心发现。问题是购买者是否能够收到证据，证明这些控制在其自身账户中是活跃的、完整的和经过测试的。功能可用性是供应商语言。控制覆盖是操作语言。
采购记录应要求身份覆盖报告，包括人类用户、特权用户、服务用户、休眠账户、外部承包商、联合状态、多因素认证状态和密码例外。它应要求按账户、用户类别、内部阶段和私有端点的网络覆盖。它应询问泄露密码保护是否启用，它产生什么事件通知，以及禁用密码如何在审计记录中反映。它应询问在合同层级哪些信任中心发现可用，以及相关历史保留多久。
事件条款应同样具体。在此活动后，通用通知条款是薄弱的。客户需要高严重性通知的时间线、将包含的证据字段、紧急联系人、支持升级、日志保留以及在数据主体范围界定中的合作。持有受监管个人数据的客户应在续约前要求样本证据包，而不是在盗窃后。桌面演练可以测试提供商和客户是否能在必要窗口内从可疑登录到受影响字段分析。
这并不会将所有工作转移给 Snowflake。客户必须维护其自己的地图、保留日志并了解其隐私义务。但提供商控制着使地图可用的许多事实。只要求认证的采购过程将错过操作问题。要求修复遥测的过程将揭示共享责任是否准备好应对下一次活动。
同样的证据应在续约中出现。如果客户在活动一年后仍然停留在密码密集型访问上，续约应强制指定例外或有资金支持的迁移。如果客户由于版本而无法接收 ACCESS_HISTORY 级别的细节，续约应记录该限制对于存储的数据是否可接受。如果网络策略缺失，续约应明确识别操作障碍。修复应在杠杆消失到另一个合同期之前进行审查。
续约证据还应区分平台变化和租户变化。Snowflake 可以推出更强的默认值，但客户的账户可能仍然包含仅密码用户、广泛角色、陈旧承包商和未审查的阶段。购买者应要求账户自身的例外账本，而不仅仅是提供商的产品路线图。这种区分防止了常见的事件后漂移：提供商宣布控制，客户假设风险已转移，已安装基础仍然实质性暴露。
对于董事会和隐私团队，该租户级记录是技术修复与法律信心之间的桥梁。声称“多因素认证可用”并未回答受影响的账户是否使用了它。声称“网络策略存在”并未回答被盗凭证是否能够从异常来源访问数据。声称“遥测保留”并未回答组织是否能够将查询映射到受监管字段。可验证修复存在于这些账户特定的答案中。
什么不应推断
一个克制的账户应避免四个跳跃。第一，该活动并不证明 Snowflake 的生产平台被攻破。第二，它并不证明每个被通知的组织都丢失了数据。第三，它并不证明每个受影响的客户都有相同的字段、人员或法律义务。第四，事后产品变更本身并不证明变更前的疏忽。安全产品在事件后出于许多原因而演变，包括更好的威胁情报和变化的标准。
同时，克制并不要求对提供商责任保持沉默。提供商可以没有平台攻破的发现，但仍然对默认设计、遥测质量和跨客户警告负责。客户可以因薄弱身份控制而有过错，但仍然需要提供商的数据进行调查。诉讼指令可以是非最终的，但仍然表明默认多因素认证和可预见性将受到审查。平衡的责任同时保持所有这些命题。
最终评估是高影响和高置信度。已确认的证据支持客户凭证活动，而非 Snowflake 平台攻破。但证据也显示了为什么提供商默认值、遥测和跨客户安全自动化是责任的一部分。共享责任只有当双方都能展示他们关闭的门时才有信誉。在此活动之后，Snowflake 的考验不是它能否说多因素认证存在。而是更少的被盗密码能否变成会话，更少的会话能否访问广泛的数据，以及更多的客户能否在数据离开之前确切证明发生了什么。