Snowflake 凭证窃取行动与共同责任边界

摘要

• 已确认的活动边界：Mandiant 将该出于经济动机的活动归因于 UNC5537，并指出其直接处理的每一起活动事件均可追溯至被泄露的客户凭证。调查未发现任何证据表明未经授权的客户访问源于 Snowflake 企业环境的入侵。Snowflake 同样表示，未发现其平台存在导致该活动的漏洞、配置错误或入侵的证据。
• 观察到的控制链：成功入侵的账户缺少多因素身份验证，保留了历史信息窃取记录中泄露的凭证，且未设置网络允许列表。随后，攻击者使用受支持的 Snowflake 客户端和 SQL 操作来枚举数据、暂存、压缩并下载数据。约有 165 个组织收到潜在暴露通知；这并非已确认入侵、受影响人数或记录的数量。
• 共同责任发现：客户控制其用户、角色、密码轮换、多因素身份验证注册、网络策略、终端卫生以及数据最小化。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 所述模式及业务暴露的重要公司证据，并非独立裁决认定每项责任或法律主张都属于客户方。

因此，有用的问题比“谁被入侵了？”更窄，又比“谁的密码被盗了？”更宽泛。问题在于：从被盗机密到数据被下载的每一步，哪个行动者能够阻止、检测、中断、重建或警告该动作？责任跟随对这些步骤的控制权。

活动将旧终端盗窃与当前云权限相结合

2024 年 4 月，Mandiant 首次获取了与数据库记录相关的情报，这些记录后来被追溯到一名受害者的 Snowflake 实例。该受害者聘请了 Mandiant，后者得出结论，入侵者使用了先前由信息窃取恶意软件窃取的凭证。相关账户未启用多因素身份验证（MFA）。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、广泛仓库使用权限或跨原始数据集的 select 访问权限的凭证截然不同。集成使用的服务账户不应继承人类管理员的探索范围。承包商的临时角色应随着服务终止而到期，而非以有效密码保持休眠状态。

即使角色遭到泄露，数据保护策略也能缩小结果。Snowflake 的敏感数据分类文档将个人和敏感列的发现与掩码及行访问策略关联起来。这是对当前功能的描述，并非证据表明 2024 年每个受影响的客户都已对其数据进行了分类或掩码。它提出了一个设计问题：客户是否将完整的历史表暴露给那些仅需要聚合、最新分区、标记化字段或已批准视图的身份？

导出本身是一种特权业务功能，应据此进行治理。数据仓库通常需要批量卸载，用于合法管道、备份、模型训练和下游系统。全面禁止鲜有现实性。然而，创建暂存区、卸载异常大量的结果，或使用不熟悉的客户端和网络来源，应是可观察的，并且对于高风险数据集，可能有理由要求审批、速率限制、目的地限制、短期权限提升或单独的导出角色。该活动的命令虽正常到足以执行，但其情境下的异常性足以要求快速做出安全决策。

客户拥有设置权；Snowflake 拥有基线责任

多因素身份验证（MFA）是最尖锐的共同责任测试，因为双方都能陈述一个真实事实。客户管理员能够且被期望启用它。Snowflake 自 2015 年起提供 MFA，自 2016 年起提供网络策略。与此同时，2024 年成功的账户却能在无 MFA 的情况下进行身份验证，这意味着服务有效基线为这些账户允许了仅密码路径。

可用性与执行之间的区别并非语义层面的。一项安全功能可以是免费、有文档记录、被推荐的，却仍然在关键的会话中缺失。管理员面临老旧集成、非交互式服务用户、承包商、应急账户、多种客户端以及对锁定的恐惧。这些限制解释了采用阻碍；但它们并不能为将特权限人类访问依赖于可重用密码提供正当理由。它们也为提供方提供了构建迁移工具、分离人类与服务身份以及使例外明确化所需的信息。

活动之后，Snowflake 的公开方向从建议转向了更强默认设置。其 2024 年 7 月的Secure by Design 承诺公告强调了 MFA 策略控制和信任中心检查。2024 年 9 月，Snowflake 表示将对 2024 年 10 月起创建的账户中的人类用户默认强制执行 MFA，同时建议人类用户使用带身份提供方 MFA 的 SSO，服务使用 OAuth 或密钥对身份验证。新旧账户之间的区别至关重要。安全默认设置保护未来的创建；它并不会自动淘汰已安装用户群中每一个遗留的密码路径。

Snowflake 随后推出了密码泄露保护，该功能利用威胁情报源测试报告的泄露密码，并在隐私保护流程中确认密码仍然有效后禁用该密码。该提供方侧的控制直接针对了 UNC5537 的一个优势：仍然可用的旧信息窃取凭证。这也是共同责任可以演变的证据。客户仍需管理身份和轮换，但提供方可以利用跨服务情报，在每位客户独立发现之前使被盗密码失效。

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

标准有助于解释为何提供方默认设置应纳入分析。NIST 当前的身份验证与验证器管理指南将密码视为不可防重放的，并将防钓鱼定义为一种不依赖用户警觉性的协议属性。2024 年CISA Secure by Design 承诺特别将默认 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 当前的信任中心会检查 MFA 注册、账户网络策略、特权角色、休眠用户、风险登录、异常 IP 地址以及通过安全和威胁情报扫描器进行的大数据传输。当前文档还说明了限制：某些包必须启用；某些检测可能在一小时内到达；已配置策略的存在并不能证明其内容达成了预期目标。同样，当前的能力并不能证明 2024 年春季某个特定客户或 Snowflake 检测到了什么。它表明的是，提供方在理解了跨客户故障模式后，可以产品化哪些内容。

警告系统应该运行在两个层面。在租户层面，客户需要即时、可导出的事件和控制措施，以阻止或暂停活动。在提供方层面，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 Canada 的事件页面提供了不同详细程度的信息。它描述了未经授权访问由第三方数据服务提供商托管的隔离云数据库，称该数据库包含部分北美购票者的有限个人信息，并列出了可能的字段，包括电子邮件、电话号码、加密卡信息以及客户提供的其他信息。它表示 Ticketmaster 客户账户未受影响。这最后一条界限很重要：后端数据仓库的入侵，并不证明攻击者获得了每个人的 Ticketmaster 登录信息，或可通过消费者账户进行交易。

加拿大隐私专员办公室 2025 年 10 月的议会问题简报指明 Snowflake 为 Ticketmaster 使用的第三方提供商，将 Ticketmaster Canada 的事件窗口期定为 2024 年 4 月 2 日至 5 月 18 日，并表示涉及数百万人的个人信息，包括加拿大人。它还表示调查仍在进行中，而 Ticketmaster Canada 作为《个人信息保护与电子文件法》(PIPEDA) 下的数据控制者，是调查对象。这些是有用的监管背景，但并非最终调查结果，无法解决保障措施的充分性、通知时间或责任问题。

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

这些记录产生了四条纪律规则。第一，仅将客户文件用于该客户。第二，区分数据库、组织账户和消费者登录。第三，区分数据字段与它们所代表的人数。第四，在影响之外保留诸如“无信息内容”或“消费者账户未受影响”等否定性事实。当分析扩大戏剧性主张而忽略限制性主张时，问责会变得可信度降低。

客户对其委托的数据和身份仍然负有责任

共同责任中客户方的分量很重。组织创建或批准了 Snowflake 用户、选择了身份验证路径、分配了角色、加载了数据、保留了历史记录、选择了区域、启用了集成，并决定了哪些员工和承包商可以查询数据仓库。它还承担着与其数据所代表人群的主要关系，并通常在适用隐私法下保留控制者职责。

客户本可以在多个节点打断所观察到的活动。它本可以在终端暴露后轮换密码、禁止仅凭密码的服务账户、强制人类用户使用 MFA、通过受管控的身份提供方联合访问、限制网络、到期承包商用户、减少角色授权、分类并掩码敏感字段、隔离导出权限、监控登录和查询历史，并进行云提供商通知演练。对于受监管或高风险数据集，这些是基线运营职责，而非移交给采购的可选增强措施。

终端和承包商治理值得特别关注。拥有高风险云角色的用户不应从未受管理的个人电脑进行身份验证。承包商应在可行情况下使用客户控制的虚拟桌面或带有终端监控的设备。他们的身份应是每客户唯一的，与赞助方关联，并自动到期。组织应搜索凭证暴露源中其 Snowflake 账户模式，并在出现证据时强制轮换，而无需等待确认的滥用。

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

客户还掌控着响应准备度。他们应能够将 Snowflake 用户映射至员工或承包商，将查询映射至受影响的数据主体，将导出映射至司法管辖区和通知分析。原生的一年历史记录可能不足以满足更长的法律保留或延迟发现的需求，因此高风险客户应将相关事件流式传输至独立的安全存储。提供方警报需要一条经过测试的路径，以便快速到达客户安全团队、隐私办公室、业务所有者和执行决策者。

NIST 的网络安全框架供应链指南建议根据关键性定义并传达供应商要求。应用至此，Snowflake 客户应就事件通知时间、证据字段、保留期、支持升级、区域处理、子处理者可见性、控制变更通知及保证访问权进行合同约定。它还应为其数据功能制定退出或隔离计划，这些功能的丧失或受损将不可容忍。共同责任应被编写为可测试的接口，而非仅在事件发生后出现的一个段落。

Snowflake 对服务级风险降低仍负有责任

Snowflake 无法控制承包商个人设备上的恶意软件，或客户不启用 MFA 的决定。它确实控制的是：旧密码是否仍能作为唯一因素、不受限制的来源是否为静默默认状态、风险配置是否产生持续警告，以及提供方在观察到跨客户模式后采取了什么行动。

此案例中的提供方责任有六个部分。

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

配置可见性。提供方应向安全管理员展示完整的分母：无 MFA 的人类用户、带密码的旧式服务用户、休眠账户、无网络限制的用户、特权角色以及允许公共入口的账户。发现结果应在组织级别可见，并可导出以供审计。

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

可操作遥测。客户需要具有足够保留期和足够低延迟的身份验证、查询、对象、暂存和传输证据，以遏制活跃的窃取。更高保真度的证据不应在服务存储最高影响数据的节点恰好不可用。

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

事件后验证。宣布的功能和默认设置需要采用度和有效性衡量标准。Snowflake 后续转向默认 MFA、泄露密码禁用、信任中心发现以及更强的身份类型，均针对已观察到的路径。剩余的问责问题是覆盖范围：哪些用户和客户端实际受到保护，哪些例外仍然存在，以及控制措施阻止真实或模拟尝试的频率如何？

这种分配并未使 Snowflake 成为每个客户数据集的数据控制者，也未使提供方为每个客户的配置负责。它认识到，云公司因集中数据和运营安全边界而获利。规模化产生了只有提供方才能履行的职责，尤其是跨租户关联和基线工程。

后续诉讼考验同一边界，但尚未解决

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

该命令并非陪审团裁决认定 Snowflake 或 Ticketmaster 存在过失。在驳回动议阶段，法院仅检验充分主张的指控是否陈述了一个貌似合理的索赔；它不解决争议证据，不确定每位原告的最终事件机制，也不分配损害赔偿。Snowflake 对这些指控提出异议，并辩称客户未能实施 MFA、网络策略及其他保障措施造成了损害。该命令之所以重要，是因为它表明将 MFA 描述为客户设置，并不会自动终结每一项提供方责任主张。它不能替代最终的实质记录。

加拿大隐私调查则具有不同的责任分配。OPC 表示 Ticketmaster Canada 仍是控制者，为被调查实体，而该办公室联系 Snowflake 以获取信息。这反映了一项普遍隐私原则：外包存储并不外包控制者的保护和通知义务。这并不意味着服务提供商自身没有合同、技术或法定义务。

Snowflake 自身的 10-K 承认了诸多诉讼、监管调查和立法者问询，但未报告最终的普遍责任分配。截至发布日期，本文所审查的公开来源不支持宣布 Snowflake 已法律免责、每个客户均法律上有过失，或任何最终法院或监管机构已采纳本文的运营分配。

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

可衡量的共同责任测试

最强的回应并非另一幅一边写着“客户”、另一边写着“提供方”的示意图，而是一套可演示覆盖范围和失败行为的控制措施。

董事会应接收成果而非功能清单。有用的衡量指标包括受防钓鱼 MFA 保护的人类用户百分比、仍可使用密码的服务用户数量、每个应急例外的存在时间、具有已测试网络策略的账户百分比、过期特权承包商身份的数量、对不常见来源发出警报的中位时间、暂停高置信度会话的时间，以及生成字段级暴露包的时间。

Snowflake 应在不暴露客户的前提下发布汇总进展。CISA 的承诺明确设想了按用户和 MFA 类型划分的采用统计数据。声明“MFA 可用”不如随时间展示仅密码登录的分布信息。声明“信任中心已启用”不如说明有多少严重发现在超过规定期限后仍未关闭。声明“已通知可疑客户”不如公开通知延迟和证据包的完整性。

客户也应要求自身保持同样的严谨性。提供方无法拯救一个创建宽泛角色、忽略发现、保留过期承包商用户且无人接听紧急联系人的组织。更强默认设置的目的并非将客户安全的责任转移给 Snowflake，而是让可预见的疏漏不太可能演变为大规模数据窃取。

公开记录仍未能证实之处

证据足够足以重建活动模式，但并非每位受害者事件。

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

它未公布每个组织的用户类型、角色层次结构、MFA 历史、网络配置、终端所有者、会话序列、访问的列或导出量。来自若干调查的承包商设备发现不应被归于每名受害者。79.7% 的凭证暴露统计数据不应被转化为受害者比例。

它未证实存在软件漏洞、跨租户逃逸、Snowflake 生产平台遭入侵、提供方主凭证失窃或所有 Snowflake 客户均被访问。观察到的使用受支持客户端与命令是凭证滥用的证据，而非产品代码被利用的证明。

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

它不允许将 Ticketmaster 的可能字段、AT&T 的通话详情范围或任何犯罪论坛的计数泛化至其他客户。Live Nation 的文件未指明 Snowflake。AT&T 的文件未指明 Snowflake 或 UNC5537。外部关联可能与进一步调查相关，但文件应被引用其实际所证实的内容。

最后，当前的 Snowflake 文档不能证明 2024 年 4 月和 5 月的控制操作。后续的默认 MFA、密码泄露保护、信任中心检测、身份验证策略及身份变更可能会减少复现，但关于采用率、例外覆盖、检测性能及独立有效性的公开证据，仍比功能描述更为有限。

共同责任必须在建议被忽略的那一刻仍能存活

Snowflake 活动最好不被理解为两个绝对叙述之间的较量。一种叙述称平台被黑，仅提供方失职。证据不支持。另一种称客户丢失了密码，因此提供方问题已终结。这在技术上是不完整的。

UNC5537 找到了终端入侵与云集中之间的可扩展交汇点。历史密码仍然有效。人类与服务身份并非总是分离。MFA 和网络关卡缺失。受支持的查询与暂存功能快速转移了数据。提供方能够看到跨租户模式，而每个客户只能看到自己的账户。选定的存储区域可将源数据保存在原地，即使经过验证的会话在其他地方创建了不受控制的副本。

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

活动后的产品方向含蓄地承认了能力与结果之间的差距。针对新人类用户的默认 MFA、泄露密码禁用、更强的身份验证策略、服务用户迁移以及信任中心发现，将安全性更靠近提供方基线。它们并未抹去客户责任。它们使共享系统更少依赖每位管理员在被盗密码被测试前找到并启用每个正确选项。

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