Snowflake 凭证盗窃活动与共享责任的局限

摘要

• 确认的攻击范围：Mandiant 将一次出于经济动机的攻击活动归因于 UNC5537，并表示其直接处理的每一起事件都源于客户凭证被泄露。它没有发现证据表明客户账户的未授权访问源于 Snowflake 企业环境的破坏。Snowflake 同样表示，没有发现平台存在漏洞、配置错误或被攻破导致此活动的证据。
• 观察到的控制链：成功被入侵的账户缺乏多因素认证，保留了在历史信息窃取器记录中暴露的凭证，并且没有网络允许列表。攻击者随后使用受支持的 Snowflake 客户端和 SQL 操作来枚举数据、暂存、压缩并下载。大约 165 个组织被通知可能暴露；这不是确认泄露、个人或记录的数量。
• 共享责任发现：客户控制其用户、角色、密码轮换、MFA 注册、网络策略、终端安全和数据最小化。Snowflake 控制哪些保护措施存在、如何呈现和默认设置、平台能看到的跨客户信号，以及警告和更强基线行为到达现有客户的速度。这些责任是并行的，而非互斥的。
• 主权发现：选择 Snowflake 区域决定了账户存储和计算的位置；Snowflake 的文档明确说明这并不限制用户访问。在此次活动中，有效的身份可以将区域存储的数据集转化为可下载的副本。没有身份、出口和证据控制的数据本地化只是一个放置决策，而非完整的主权控制。

平台未被证明遭攻破，但服务关系经受考验

本案的首要原则是术语。Snowflake 客户实例并非 Snowflake 自身的企业环境或共享生产平台。持有有效凭证的人可以进入一个客户的账户，而无需跨入其他租户、利用软件漏洞、获取供应商管理员账户或破坏隔离客户的底层基础设施。公开证据支持客户账户被入侵，但不支持平台范围的技术入侵。

Mandiant 的UNC5537 攻击活动报告在这一点上异常直接。对于 Mandiant 亲自处理的与该活动相关的每一起事件，根本原因都是客户凭证泄露。其调查没有发现证据表明客户账户的未授权访问源于 Snowflake 企业环境的破坏。Snowflake 自身的调查与加固通知同样将目标客户账户与生产平台区分开，并向客户提供了查询和指标用于调查自身环境。CISA 在2024 年 6 月 3 日的警报中强化了这一指导。

这一否定性发现很重要。将事件称为 Snowflake 平台的破坏，可能暗示共享代码或基础设施的缺陷打开了所有租户，或者 Snowflake 丢失了能够解锁客户的主凭证。审查的记录证实了这两点均未发生。它还会掩盖客户需要立即采取的行动：识别仅使用密码的用户、轮换凭证、检查登录和查询历史、限制网络、降低角色权限以及保留证据。

相反的错误是将平台未遭攻破等同于供应商无需承担问责。云服务不仅仅是客户放置数据的被动磁盘。Snowflake 构建并运行了接受凭证的认证端点、攻击者使用的接口、处理其命令的查询引擎、记录会话的遥测系统，以及可能要求第二因素或限制网络来源的产品控制。Snowflake 还拥有任何单个客户都无法具备的跨客户可见性。决定性控制可由客户配置这一事实，决定了谁有操作责任进行配置。它并不能回答供应商的默认设置、警告、检测和执行措施是否与其服务上的数据集中程度相称。

Snowflake 2025 财年的10-K 表格正式了其立场。它表示 Snowflake 负责平台和底层云基础设施的安全性，而客户为其环境选择和配置控制。它将 2024 年 5 月的访问归因于客户未能履行 MFA 和网络策略等义务，同时记录了诉讼、监管调查、立法者质询、声誉损害以及赔偿纠纷的可能性。这是一项关于 Snowflake 既定模式和业务敞口的实质性公司证据，并非对所有责任或法律主张均属于客户方的独立裁决。

因此，有用的问题既比“谁遭到了入侵？”更窄，也比“谁的密码被盗？”更广。那就是：从秘密被盗到数据被下载的每一步，哪一方能够预防、检测、中断、重建或警告该行为？问责制跟随对这些步骤的控制权。

攻击活动将旧的终端盗窃与当前的云授权结合

Mandiant 于 2024 年 4 月首次获得关于数据库记录的情报，这些记录随后被追溯到受害者的 Snowflake 实例。该受害者聘请了 Mandiant，后者得出结论认为入侵者使用了此前被信息窃取器恶意软件窃取的凭证。相关账户未启用 MFA。2024 年 5 月 22 日，在识别出指向更广泛攻击活动的情报后，Mandiant 联系了 Snowflake 并开始通知潜在受害者。Snowflake 于 5 月 30 日发布了客户检测与加固指南。到 6 月报告发布时，Mandiant 和 Snowflake 已通知了大约 165 个可能暴露的组织。

上一句中的每个术语都需要防止被夸大。“大约”表示估算。“可能暴露”描述的是通知人群，而非 165 个已完成的取证结论。“组织”并不意味着账户、数据库、个人或记录。一些组织可能运营多个 Snowflake 账户，而一个账户可能持有关于更大人口的数据。该报告并未提供整个活动的确认组织总数、受影响个人数量、导出字节数或勒索付款金额。

凭证历史解释了为何 2024 年的云登录可能源于多年前的终端感染。Mandiant 发现 UNC5537 使用的大多数凭证都出现在历史信息窃取器的输出中，最早的相关感染观察于 2020 年 11 月。至少 79.7% 的被利用账户此前已有凭证暴露。该百分比适用于在分析活动中被攻击者利用的账户，而非所有 Snowflake 客户或全部 165 个被通知组织。

三个条件反复将暴露的秘密转化为有效访问。受影响的账户未配置 MFA。在信息窃取器记录中找到的密码仍然有效，有时长达数年。受影响的客户实例缺乏网络允许列表来限制连接至可信来源。这些条件中没有一个是新颖的利用手段。它们共同形成了一条持久的授权路径：知道账户定位符、用户名和仍然有效的密码；从攻击者控制的系统连接；获得会话；继承分配的角色；查询该角色可读取的任何内容。

终端维度也比传统的员工笔记本电脑叙事更为分散。在几项调查中，Mandiant 在承包商系统上发现了较早的信息窃取器感染，这些系统也用于个人活动，包括游戏或盗版下载。承包商设备可能位于客户管理的终端设备之外，同时携带多个客户的凭证。它还可能持有管理员账户，因为专业承包商通常被聘请来构建或运营数据平台。创建该用户的客户仍然对该身份及其权限负责，但暴露可能对客户自身的终端工具不可见。

这是一个云依赖乘数。凭证从一个终端被盗，可能位于 Snowflake 或数据所有者的设备之外。凭证被全球性服务接受。该角色可能访问一个包含多年来自多个业务系统记录的整合仓库。攻击者不再需要逐一入侵那些源系统。使仓库对客户有用的分析价值，也使成功访问对勒索者有价值。

攻击者直接承担盗窃、购买、测试和使用凭证、未经授权进入客户环境、盗取数据以及试图出售或勒索的责任。描述使这些犯罪成为可能的控制失败并不会削弱这一责任。它解释了为何相同的犯罪技术大规模成功，以及如何减少再次发生。

受支持的功能成为数据外泄路径

该攻击活动并未止步于认证。Mandiant 观察到通过 Snowsight、SnowSQL、驱动程序和数据库工具的访问。攻击者列出了用户、角色、会话、组织名称、数据库、模式和表。他们使用熟悉的 SQL 操作来选择数据、创建临时暂存区、将查询输出复制到压缩文件，并将这些文件检索到本地机器。在多个客户环境中，出现了相似的命令序列。

这一序列使事件成为在未授权身份下使用普通功能的案例：

1. 有效的客户用户名和密码建立了会话。
2. 会话继承了客户分配的角色和对象权限。
3. 侦察识别出有价值的表和可用的暂存区。
4. 查询选择了该角色允许读取的记录。
5. 临时暂存和COPY INTO将结果转换为可下载的文件。
6. GET将文件移动到攻击者控制的客户端。

该链条中的每一步都不需要数据库出现故障。这就是为什么静态加密虽然是必要的，但并非决定性控制。Snowflake 的端到端加密文档表示客户数据在静态时加密，在传输时使用 TLS，但它也解释说 Snowflake 在执行转换或表操作时会解密数据，并允许用户卸载和下载结果。加密保护文件和传输免受缺乏授权或密钥的方侵害。但它并不能阻止一个被接受的身份和允许的角色向服务请求可读的结果。

同一原则适用于客户管理的密钥。密钥控制可以应对供应商、存储和撤销场景，但一个正在运行的账户必须使用其密钥层次结构来服务授权查询。除非密钥策略与拒绝会话或操作的独立决策相关联，否则数据库无法将账户所有者与满足所有者配置的认证策略的入侵者区分开来。

因此，角色设计在登录后控制了访问半径。Snowflake 当前的访问控制模型支持基于角色和自主访问控制、所有权、角色层次结构和对象权限。仅分配了狭窄数据库或视图的凭证与持有ACCOUNTADMIN、广泛仓库使用权限或对原始数据集的选择权限的凭证，后果截然不同。集成使用的服务账户不应继承人类管理员的可探索范围。承包商的临时角色应在合作结束后过期，而不是带着有效密码处于休眠状态。

即使角色被入侵，数据保护策略也可以缩小结果范围。Snowflake 的敏感数据分类文档将个人和敏感列的发现与数据掩码和行访问策略联系起来。这是一个当前能力的描述，而非证明每个受影响客户在 2024 年已对其数据进行了分类或屏蔽。它确立了设计问题：客户是否向只需要聚合、近期分区、令牌化字段或经批准视图的身份公开了完整的历史表？

导出本身就是一项特权业务功能，应作为此类进行治理。数据仓库通常需要批量卸载以支持合法管道、备份、模型训练和下游系统。全面禁止通常不现实。但创建暂存区、卸载异常大的结果或使用不熟悉的客户端和网络来源应该是可观察的，对于高风险数据集，可能还需要批准、速率限制、目的地限制、短期提升或单独的导出角色。该活动的命令足够正常以执行，但在上下文中足够异常以值得快速安全决策。

客户拥有设置权，Snowflake 拥有基线

MFA 是最尖锐的共享责任测试，因为双方都可以陈述事实。客户管理员有能力也有责任启用它。Snowflake 自 2015 年起提供 MFA，自 2016 年起提供网络策略。与此同时，2024 年成功的账户能够在不使用 MFA 的情况下进行认证，这意味着该服务的有效基线允许这些账户仅使用密码。

可用性与强制之间的差异并非语义问题。安全功能可以免费、有文档记录、被推荐，但仍然在关键时刻的会话中缺失。管理员面临旧集成、非交互式服务用户、承包商、紧急访问账户、多种客户端以及对锁定之忧。这些限制解释了采用摩擦的原因；但不能证明将特权人类访问依赖于可重复使用的密码是合理的。它们还向供应商提供了构建迁移工具、将人类和服务身份分开以及明确例外所需的信息。

活动发生后，Snowflake 的公开方向从推荐转向更强默认。其 2024 年 7 月的安全设计承诺公告强调了 MFA 策略控制和 Trust Center 检查。2024 年 9 月，Snowflake 表示MFA 将默认强制执行，针对 2024 年 10 月起创建的账户中的人类用户，同时建议人类使用带有身份提供者 MFA 的 SSO，服务使用 OAuth 或密钥对认证。新账户与现有账户的区别很重要。安全的默认设置保护未来创建；它不会自动淘汰现有客户中所有继承的密码路径。

Snowflake 后来引入了泄露密码保护，它使用威胁情报源以隐私保护方式测试报告的泄露密码，并在确认仍然有效时禁用该密码。这一供应商端控制直接解决了 UNC5537 的优势之一：旧的信息窃取器凭证仍然可用。这也证明了共享责任是可以演进的。客户仍然需要管理身份和轮换，但供应商可以利用跨服务情报使被盗密码在客户独立发现之前失效。

当前的身份验证策略文档允许管理员控制允许的方法和客户端，并在账户或用户级别要求 MFA。它还警告说，客户端类型限制是尽力而为，不应作为唯一的安全边界。当前的密钥对指南为服务用户提供了静态密码的替代方案。这些页面描述了截至 2026 年可用的功能；不能将其反向解读为 2024 年 4 月每个客户的确切功能、默认设置或强制状态。

标准有助于解释为何供应商默认设置属于分析范畴。NIST 当前的身份验证和认证器管理指南将密码视为不可重放抵抗，并定义网络钓鱼抵抗为不依赖用户警觉性的协议属性。2024 年CISA 安全设计承诺特别指出默认 MFA、持久产品提示、基线 SSO 支持以及发布采用指标是软件制造商可衡量地提高 MFA 使用率的方式。Snowflake 在活动后签署了该自愿承诺。该承诺并非对 Snowflake 2024 年设计的法律裁决，但它拒绝了提供复选框即穷尽供应商角色的想法。

可问责的基线区分了身份类型。人类管理员应使用网络钓鱼抵抗型 MFA 或受严格管理的联合身份。服务工作负载应使用可限定范围、可轮换和可归属的工作负载凭证，而非假装机器人能响应推送通知。紧急访问应罕见、受监控、有时限且经过测试。承包商身份应有所有者、到期日、经批准的设备姿态，且无跨客户端凭证重用。每个例外都应出现在仪表板上，其分母是所有身份，而不仅是活跃员工。

网络策略是第二道门，而非身份替代品

Mandiant 的第三个反复因素是没有网络允许列表。因此，有效凭证可以从没有业务理由访问客户仓库的基础设施上使用。网络限制无法修复被盗密码，但可以使该密码在不受信任的来源上不足够。

Snowflake 当前的网络策略文档明确了默认设置：没有策略时，用户可以从任何计算机或设备连接。客户可以允许或阻止 IP 范围和私有端点，在账户或用户级别应用控制，并通过附加配置限制内部暂存区访问。私有连接和公共访问控制可以进一步加强高敏感度账户。

客户知道其批准的办公室、云工作负载、VPN、承包商和集成端点，因此客户必须定义可用的允许列表。Snowflake 无法在不妨碍业务的情况下推断所有合法来源。然而，供应商控制着默认可达性、策略语法、模拟更改的能力、锁定保护、日志记录，以及在没有账户策略时是否向管理员发出警告。平台可以在保留客户选择的同时，使不受限制的公共访问成为可见的、有时限的例外，而非沉默的稳态。

网络规则也有局限性。攻击者可能从批准的承包商设备获取会话、通过允许的企业 VPN 路由、入侵允许云内的工作负载，或在认证后窃取令牌。大型企业可能拥有不断变化的出口地址，使静态列表难以维护。私有连接可能排除不支持它的 SaaS 工具。这些是将网络控制与强大身份和行为检测搭配使用的原因，而非省略它们的理由。

该活动展示了独立门控的价值。密码轮换会使历史凭证失效。MFA 需要另一个因素。网络策略会拒绝不熟悉的来源。最小权限会减少可见数据。导出控制可以中断暂存。检测可以缩短驻留时间。没有单一的完美措施；攻击者在多个措施同时缺席或宽松的情况下得逞。

对于问责制，每个门控都需要所有者和有效性衡量标准。“支持网络策略”是产品事实。“每个生产账户都有涵盖服务和内部暂存区的已测试策略”是运营结果。“支持 MFA”是产品事实。“没有特权人类能仅使用可重复密码建立会话”是结果。只有双方都能展示其边界的成果时，共享责任才变得有意义。

供应商看到的攻击活动，每个客户只能视为单一事件

单个客户可以检查其自身失败和成功的登录、客户端、IP 地址、查询文本、角色、暂存区和数据移动。Snowflake 可以跨账户关联模式：相同的基础设施、不寻常的客户端、重复的侦察、相似的暂存命令、仅密码登录激增，或与威胁情报源匹配的凭证。这种不对称性是供应商最重要的非合同责任。它源于大规模运营服务。

Snowflake 当前的LOGIN_HISTORY 视图保留一年的登录尝试，包括用户、来源 IP、报告的客户端、第一和第二因素、成功与否以及相关风险细节，并带有记录的延迟。QUERY_HISTORY保留一年的查询活动，并将查询与认证事件、会话、用户、角色、文本、结果字节、卸载行数以及通过网络发送的字节数关联。企业版客户可以使用ACCESS_HISTORY重建访问过的表、视图、列、暂存区、策略和修改的对象。这些模式为高质量调查提供了原材料。

原始历史不等同于检测。客户必须授予分析师访问权限、导出或查询数据、理解正常行为、编写警报、路由警报、在必要时在本地窗口之外保留警报，并配备响应人员。两小时的遥测延迟对于回顾性审查可能是可接受的，但对于某些批量导出决策可能太慢。企业版边界对列级访问历史的限制也会影响客户精确限定暴露范围的能力。这些产品和运营事实应在采购期间进行测试，而非在盗窃发生后才发现。

Snowflake 当前的Trust Center通过安全与威胁情报扫描器检查 MFA 注册、账户网络策略、特权角色、休眠用户、风险登录、异常 IP 地址和大数据传输。当前文档也说明了局限性：某些包必须启用；某些检测可能在一小时内到达；配置策略的存在并不能证明其内容实现了预期目标。再次强调，当前能力并非证明某一特定客户或 Snowflake 在 2024 年春季检测到了什么。它展示了供应商在理解跨客户失败模式后可以产品化什么。

警告系统应在两个层面运行。在租户层面，客户需要即时的、可导出的事件和控制来阻止或暂停活动。在供应商层面，Snowflake 需要攻击活动分析和一个经过演练的流程，以足够证据通知客户采取行动。有用的通知包括账户和用户标识符、UTC 时间戳、来源基础设施、认证因素、会话和查询 ID、命令、访问的对象和列、暂存操作、估计传输量、遏制状态和置信度。“可能暴露”是一个适当的开场标签，前提是随后提供解决该可能性所需的证据。

供应商干预也需要治理。自动阻止客户会话可能会中断生产，并可能超出供应商的合同权限。不作为可能允许继续盗窃。因此，设计应提前定义风险阈值、临时暂停、客户升级渠道、紧急联系人和快速覆盖流程。客户应指定能够在任何时间接收高严重性警报并授权暂停的人员。供应商应衡量从跨账户信号到客户联系的时间、遏制时间，以及能够检索完整证据包的通知客户比例。

数据本地化并未使访问本地化

Snowflake 营销和文档中提及区域部署，因为客户有延迟、弹性、隐私、监管和主权需求。Snowflake 的受支持区域文档表示每个账户托管在一个区域，数据保留在该区域，除非用户显式复制、移动或复制。同一页面包含了关键限制：区域决定了数据存储和计算的位置，但不限制用户对 Snowflake 的访问。

这一区别将 UNC5537 链变成了一个主权案例。入侵发生前，客户的表可能被存储和处理在选定的国家或区域云位置。成功认证后，攻击者可以从其他地方查询该区域账户、暂存结果并下载到客户端。Mandiant 观察到从临时暂存区本地检索的技术模式。公开的活动记录并未为每个受害者确定来源国、目的国或法律传输状态，因此无法支持普遍的非法跨境传输主张。然而，架构表明存储本地化本身无法强制执行用户本地化。

跨区域共享和复制创建了一个单独的、合法的移动路径。Snowflake 的跨区域共享指南告诉组织在将数据复制到不同区域或国家之前确认法律和监管限制。这是在客户管理下的计划性移动。凭证驱动的导出则不同：它可以在不改变源账户位置的情况下，在所选环境之外创建一个不受控制的副本。仅记录来源区域的数据清单会继续显示“欧盟”或“加拿大”，即使攻击者已经移除了副本。

因此，数据主权至少包含四个层面：

• 放置：权威存储和计算资源在哪里配置。
• 访问：哪些人类和机器身份可以连接，来自哪些设备、网络和司法管辖区。
• 移动：哪些查询、卸载、共享、复制、连接器和下载可以创建另一个副本。
• 证据和补救：组织能否证明访问来源、泄露内容、涉及哪些个人或受监管记录，以及遏制和通知的速度。

即使客户选择策略，供应商也控制着所有四个层面的重要部分。供应商提供区域并将账户数据保存在其中。供应商认证请求并公开网络控制。供应商执行导出命令并记录查询元数据。供应商拥有跨客户威胁可见性，并可以禁用泄露密码。客户决定其法律依据、数据类别、角色、允许来源、数据掩码、保留和批准的移动。没有这些互补控制的区域托管承诺可以满足狭窄的数据中心位置要求，同时将实际复制数据的权限暴露在全球范围内。

这也是为何加密和主权不应混为一谈。加密可以保护存储对象免受基础设施操作员或未授权存储层读取者的侵害。必须分析该对象的应用程序必然使数据在授权查询上下文中可用。如果身份保证和角色范围薄弱，密码学共存可以与操作外泄共存。

客户披露显示不同后果，而非统一入侵

该活动通常通过知名客户名称来描述，但每个客户的公开记录有其自身范围、日期、数据、术语和置信度。将一家公司的事实转移给另一家或将犯罪论坛声明转化为已验证人群是不安全的。

Live Nation 的 2024 年 5 月 31 日8-K 表格称其于 5 月 20 日在一个包含公司数据的第三方云数据库环境中发现未授权活动，主要来自 Ticketmaster。它表示 5 月 27 日一名犯罪分子声称出售该公司用户数据，Live Nation 正在相应通知执法部门、监管机构和用户。该文件未提及 Snowflake、提供确认受影响人数或解释认证路径。

Ticketmaster 加拿大的事件页面提供了不同详细程度。它描述了在一个由第三方数据服务提供商托管的隔离云数据库上的未授权访问，称该数据库包含部分北美购票者的有限个人信息，并列出了可能字段，包括电子邮件、电话号码、加密卡信息以及客户提供的其他信息。它表示 Ticketmaster 客户账户未受影响。最后一个界限很重要：后端数据仓库被入侵并不证明攻击者获得了每个人的 Ticketmaster 登录权限或可以通过消费者账户进行交易。

加拿大隐私专员办公室 2025 年 10 月的议会问题单将 Snowflake 确定为 Ticketmaster 使用的第三方提供商，给出了 2024 年 4 月 2 日至 5 月 18 日的 Ticketmaster 加拿大事件窗口，并称涉及包括加拿大人在内的数百万人的个人信息。它还说调查仍在进行中，Ticketmaster 加拿大作为 PIPEDA 下的数据控制者正在接受调查。这是有用的监管背景，但并非解决保障充分性、通知时间或责任问题的最终结论。

AT&T 的 2024 年 7 月 12 日8-K 表格说明了即使事件一起讨论，来源边界为何重要。AT&T 称一名犯罪分子在 4 月 14 日至 25 日期间未授权访问了一个第三方云平台上的 AT&T 工作空间并窃取了文件。这些文件包含了 2022 年指定时期和 2023 年某一天的几乎全部 AT&T 无线客户以及相关移动虚拟网络运营商客户的通话和短信交互记录。AT&T 表示文件不包含通话或短信内容、社会安全号码、出生日期或其他 AT&T 术语中的个人信息。该文件本身未提及 Snowflake 或 UNC5537。它支持 AT&T 的事件事实，而非单独的活动归因。

这些记录产生了四条纪律规则。第一，仅使用客户的文件对应其自身。第二，区分数据库、组织账户和消费者登录。第三，区分数据字段与所代表的人数。第四，保留负面事实，如“无消息内容”或“消费者账户未受影响”，以及影响。当分析扩大戏剧性主张并删除限制性信息时，问责制变得不那么可信。

客户仍需对其委托的数据和身份负责

共享责任的客户方面是实质性的。组织创建或批准 Snowflake 用户、选择认证路径、分配角色、加载数据、保留历史、选择区域、启用集成，并决定哪些员工和承包商可以查询仓库。它还持有其数据所代表个人的主要关系，并通常承担适用隐私法下的控制者义务。

客户可以在多个点中断观察到的活动。他们可以在终端暴露后轮换密码、禁止仅密码的服务账户、为人类要求 MFA、通过受治理的身份提供者联合访问、限制网络、使承包商用户过期、减少角色授权、分类和屏蔽敏感字段、隔离导出权限、监控登录和查询历史，以及演练云供应商通知。对于受监管或高影响数据集，这些是基线操作职责，而非委托给采购的可选增强。

终端和承包商治理值得特别关注。拥有高影响云角色的用户不应从未管理的个人计算机认证。承包商应尽可能使用客户控制的虚拟桌面或具有端点监控的设备。其身份应对每个客户唯一、与主办人关联并自动过期。组织应搜索凭证暴露源以匹配其 Snowflake 账户模式，并在出现证据时强制轮换，无需等待确认滥用。

最小权限必须根据数据进行测试，而非职位。“分析师”听起来可能非管理性，同时保留对客户、员工或交易表中每一行的选择访问。角色审查应询问哪些行和列可以被返回、是否需要原始标识符、是否可以写入暂存区批量结果集，以及该身份是否可以创建新凭证或集成。该角色下的示例查询比看似干净的角色名称更有力。

客户也拥有响应准备能力。他们应能够将 Snowflake 用户映射到员工或承包商、将查询映射到受影响数据主体，以及将导出映射到司法管辖区和通知分析。本地一年历史可能不足以满足更长的法律保留或延迟发现，因此高风险客户应将相关事件流式传输到独立安全存储。供应商警报需要经过测试的路径到达客户安全团队、隐私办公室、业务负责人和行政决策者。

NIST 的网络安全框架供应链指南建议根据关键性定义和沟通供应商要求。应用于此，Snowflake 客户应在合同中规定事件通知时间、证据字段、保留、支持升级、区域处理、子处理器可见性、控制变更通知和保证访问。还应为其数据功能维护退出或隔离计划，这些功能的丢失或妥协将不可容忍。共享责任应作为可测试的接口编写，而非仅在事件发生后出现的段落。

Snowflake 仍需对服务层面的风险降低负责

Snowflake 并未控制承包商个人设备上的恶意软件或客户禁用 MFA 的决定。但它控制着旧密码是否仍能成为唯一因素、无限制来源是否是安静的默认状态、风险配置是否产生持续警告，以及供应商在观察到跨客户模式后做了什么。

本案中的供应商问责制有六个部分。

安全基线。人类特权访问不应仅依赖于可重复使用的密码。服务身份应有单独类型和受支持的非密码方法。新默认设置应通过分阶段执行、显式异常和迁移帮助覆盖现有高风险账户，而非仅保护新租户。

配置可见性。供应商应展示安全管理员一个完整的分母：未启用 MFA 的人类、使用密码的遗留服务用户、休眠账户、没有网络限制的用户、特权角色以及允许公开入站的账户。发现结果应在组织级别可见并可导出以进行审计。

跨客户检测。重复使用的基础设施、泄露的凭证、不寻常的客户端、侦察序列、临时暂存区创建和大规模导出可以形成攻击活动信号。供应商应在服务层检测、联系可能受害者，并定义何时高置信度活动触发临时阻止。

可操作遥测。客户需要认证、查询、对象、暂存区和传输证据，并具有足够的保留期和足够低的延迟以遏制正在进行的盗窃。更高质量的证明不应在服务恰好存储最高影响数据时变得不可用。

警告与协调。客户警报必须通过已知的紧急路径传递并附带证据，而不仅仅是建议查看日志。供应商应跟踪确认、遏制和反复暴露，并应支持执法和监管机构请求，而不将不确定的观察转化为已确认的受害者数量。

事后验证。宣布的功能和默认设置需要采用和有效性衡量。Snowflake 后来朝向默认 MFA、泄露密码禁用、Trust Center 发现和更强身份类型的更改解决了观察到的路径。剩余的问责问题是覆盖范围：哪些用户和客户端实际上受到保护，还有哪些例外，以及控制措施在多大程度上阻止了真实或模拟尝试？

这种分配不会使 Snowflake 成为每个客户数据集的数控制者，也不会使供应商对每个客户配置负责。它认识到一家云公司通过集中数据和运营安全边界来获利。规模创造了只有供应商才能履行的职责，特别是跨租户关联和基线工程。

后续诉讼测试相同边界，但尚未解决

事件发生后，Snowflake 和受影响公司面临合并民事诉讼。在 2025 年 10 月 29 日的联邦法院命令中，蒙大拿地区法院认为金融机构原告已充分主张某些过失理论，足以驳回 Snowflake 和 Ticketmaster 的动议。法院在该程序阶段将所谓的默认 MFA 和可预见性视为与义务、违反和因果关系相关。

该命令并非认为 Snowflake 或 Ticketmaster 存在过失的审判认定。在驳回动议阶段，法院测试充分陈述的主张是否构成合理索赔；它不解决有争议的证据、为每个原告确定最终事件机制或分配损害赔偿。Snowflake 否认这些主张，并辩称客户未能实施 MFA、网络策略和其他保障措施造成了损害。该命令之所以重要，是因为它表明将 MFA 描述为客户设置并不自动结束所有供应商义务索赔。它不能取代最终的实体记录。

加拿大隐私调查采用了不同的分配。OPC 表示 Ticketmaster 加拿大仍然是控制者，是受调查的实体，同时办公室联系了 Snowflake 以获取信息。这反映了常见的隐私原则：外包存储不会外包控制者保护和通知的义务。这并不意味着服务提供商没有自身的合同、技术或法定义务。

Snowflake 自身的 10-K 承认了大量诉讼、监管调查和立法者质询，但未报告最终普遍的责任分配。截至出版日期，此处审查的公开来源不支持声称 Snowflake 被法律免除责任、每个客户在法律上有过错，或有最终法院或监管机构采用了本文的操作分配。

操作问责可以在最终责任之前进行评估。仅密码访问是否可预见？是。客户能否要求 MFA 和网络策略？是。Snowflake 能否设计默认设置并检测跨客户活动？是。犯罪分子是否故意利用了由此产生的路径？是。这些主张可以共存。侵权法、合同法、隐私法和证券法可能根据司法管辖区和原告以不同方式分配后果，但工程不应等待一个口号获胜。

可衡量的共享责任测试

最强有力的回应不是另一张一侧是“客户”另一侧是“供应商”的图表。而是一组可以展示覆盖范围和故障行为的控制措施。

董事会应接受结果而非功能清单。有用的指标包括受网络钓鱼抵抗型 MFA 保护的人类用户百分比、有密码能力的服务用户数量、每个紧急访问异常的年龄、具有测试网络策略的账户百分比、过去到期的高权限承包商身份数量、对不熟悉来源的警报中位数时间、暂停高置信度会话的时间，以及生成字段级暴露包的时间。

Snowflake 应在不暴露客户的情况下发布汇总进展。CISA 的承诺明确考虑了按用户和 MFA 类型的采用统计。声明 MFA 可用不如随时间变化的仅密码登录分布有信息量。声明 Trust Center 已启用不如有多少关键发现未在指定期限内关闭有信息量。声明可疑客户已被通知不如通知延迟和证据包完善度有信息量。

客户应对自身要求同样的严谨性。供应商无法拯救一个创建广泛角色、忽视发现、保留旧承包商用户且无人接听紧急联系人的组织。更强默认的目的不是将客户安全的所有权转移给 Snowflake。而是使可预见的疏忽不太可能演变为大规模数据盗窃。

公开记录仍未确立的内容

证据足够强大以重建活动模式，但不足以覆盖每个受害者事件。

公开记录未识别所有被通知组织、确认全部 165 个组织遭受未授权访问，或提供整个活动的最终受影响个人、表、记录或下载字节总数。它未显示哪些受害者支付了勒索要求，或是否发生了承诺的删除。

它未公布每个组织的用户类型、角色层次、MFA 历史、网络配置、端点所有者、会话序列、访问的列或导出量。来自几项调查的承包商设备发现不应分配给每个受害者。79.7% 的凭证暴露统计不应转变为受害者百分比。

它未建立软件漏洞、跨租户逃逸、Snowflake 生产平台被攻破、供应商主凭证被盗或访问每个 Snowflake 客户的证据。观察到的使用受支持客户端和命令是凭证滥用的证据，而非产品代码被利用的证据。

它未证明区域数据在每个事件中都跨越了国界。架构允许远程访问和本地下载；法律传输分析需要每个客户的来源、目的地、数据主体、合同和司法管辖区事实。

它不允许将 Ticketmaster 的可能字段、AT&T 的通话详细范围或任何犯罪论坛计数推广到其他客户。Live Nation 的文件未提及 Snowflake。AT&T 的文件未提及 Snowflake 或 UNC5537。外部关联可能与进一步调查相关，但文件应被引用为其实际确立的内容。

最后，当前的 Snowflake 文档并不证明 2024 年 4 月和 5 月控制措施的操作。后来的默认 MFA、泄露密码保护、Trust Center 检测、身份验证策略和身份更改可能减少再次发生，但关于采用、异常覆盖、检测性能和独立有效性的公开证据仍比功能描述有限。

共享责任必须在推荐被忽视的时刻继续存在

Snowflake 活动最好被理解为两个绝对故事之间的竞争。一个故事说平台被黑客入侵且供应商独自失败。证据不支持它。另一个故事说客户丢失密码，因此供应商问题已关闭。这在技术上是片面的。

UNC5537 找到了终端入侵与云集中之间的可扩展连接点。历史密码仍然有效。人类和服务身份并不总是分开。MFA 和网络门控缺失。受支持的查询和暂存功能快速移动了数据。供应商可以看到跨租户的模式，而每个客户只看到自己的账户。选定的存储区域可以保持源数据在适当位置，即使认证会话在其他地方创建了不受控制的副本。

客户有最明确的义务来管理其用户、角色、终端、承包商和数据。Snowflake 有最明确的义务来保护和观察服务边界、使高价值保护变得容易并日益不可避免、检测攻击活动行为并提供证据。攻击者直接对犯罪行为负责。监管机构和法院必须在每个组织的事实和适用法律下评估法律义务。这些分配重叠是因为控制措施重叠。

活动后的产品方向暗示了能力与结果之间的差距。针对新人类用户的默认 MFA、泄露密码禁用、更强的身份验证策略、服务用户迁移和 Trust Center 发现使安全更接近供应商基线。它们不会消除客户责任。它们使共享系统减少对每个管理员在测试被盗密码之前找到并启用每个正确选项的依赖。

这就是云数据平台的持久问责测试。假设客户会错过警告、承包商设备会被感染、凭证会保持有效、攻击者会使用普通产品功能。然后问，默认设置是否会阻止登录、另一个门控是否会拒绝来源、角色是否会暴露少量内容、导出是否会触发干预、证据是否会及时到达客户。只有当服务在一方可预测的错误后仍保持可防御，并且双方都能证明他们在之前和之后做了什么时，共享责任才可信。