在人工智能与数据平台深度融合的当下，Snowflake 作为领先的数据云服务提供商，其 AI 能力 Cortex 已成为企业构建智能化数据应用的核心组件。然而，安全研究社区近期发现 Snowflake Cortex AI 搜索服务存在一项关键的权限绕过漏洞，该漏洞允许低权限用户通过 AI 查询接口访问本应受到保护的高敏感数据，这一问题本质上构成了一种「AI 沙箱逃逸」场景。本文将从技术根因、攻击路径和防御策略三个维度进行深入分析。
漏洞的技术根因分析
该漏洞的核心问题在于 Snowflake Cortex AI 搜索服务的默认执行权限模型。根据安全研究机构 Cyera 和 Nudge Security 的披露，Cortex 搜索服务在默认情况下以「所有者权限」（owner's rights）模式运行，而非「调用者权限」（caller's rights）模式。这意味着当用户通过自然语言查询调用 Cortex 搜索时，查询请求并非在当前用户的角色上下文中执行，而是在创建该搜索服务的管理员角色上下文中执行。
具体而言，当高权限管理员（如 ACCOUNTADMIN 或负责数据平台的核心角色）创建 Cortex 搜索服务并对敏感数据表建立索引时，该服务会继承管理员的完整数据访问权限。由于 Snowflake 的动态数据掩码（Dynamic Data Masking）和行访问策略（Row Access Policies）是基于执行查询的角色进行评估的，在所有者权限模式下，这些安全控制机制会失效或大幅弱化。攻击者只需获得对 Cortex 搜索服务的 USAGE 权限，即可绕过传统的基于角色的访问控制（RBAC），直接获取原本需要更高权限才能访问的敏感信息。
攻击场景与实际影响
一个典型的攻击场景如下：首先，管理员创建一个 Cortex 搜索服务并对包含客户个人信息、财务数据或医疗记录的表进行索引，这些表通常配置了动态掩码策略或行访问策略以限制普通用户的访问范围。随后，管理员将该搜索服务的 USAGE 权限授予分析员角色或业务用户角色，而这些角色本身对底层表没有直接的 SELECT 权限或只能看到掩码后的数据。当低权限用户发起类似「显示加州所有客户的完整信用卡号」的查询时，Cortex 搜索服务会以管理员的高权限执行查询，返回未掩码的敏感数据，并将其作为自然语言回答返回给请求者。
此漏洞的影响范围包括：动态数据掩码失效，攻击者可获取明文敏感字段；行访问策略绕过，用户可以看到本应被过滤的行数据；权限模型崩溃，即使调用者角色对表没有任何 SELECT 权限，只要能够调用 Cortex 搜索服务，即可访问底层数据。这种权限提升机制从根本上违反了最小权限原则，构成严重的数据泄露风险。
企业级防御策略
针对该漏洞的防御需要从多个层面入手。在服务配置层面，组织应避免使用高权限角色（如 ACCOUNTADMIN）创建 Cortex 搜索服务，而应创建专门的低权限服务所有者角色，确保该角色仅能访问目标用户群体应该看到的数据子集。同时，应严格限制哪些表和列可以被索引到搜索服务中，避免将高敏感字段混入广泛共享的搜索服务中。
在权限管理层面，应仔细审查所有已授予的 USAGE 权限，确保获得权限的角色本身已经具有与底层数据相当的访问级别。定期审计搜索服务的权限继承关系，移除任何不符合最小权限原则的过度授权。在监控层面，应启用 Snowflake 的 QUERY_HISTORY 和 ACCESS_HISTORY 功能，对 Cortex 相关查询进行持续监控，特别关注异常的敏感数据检索模式。
此外，组织还应认识到 AI 运行时不具备传统意义上的安全沙箱隔离能力，应避免在任何 AI 工具中直接存放高价值凭证，改为使用短生命周期的委托令牌或代理服务。定期进行对抗性测试，验证 AI 搜索功能是否正确遵循现有的 RBAC 和行访问策略。
总结
Snowflake Cortex AI 搜索服务的权限绕过漏洞揭示了 AI 功能与数据安全控制之间可能存在的深刻矛盾。当 AI 服务默认以所有者权限运行时，其本质上创建了一条绕过传统访问控制的特权通道。企业在部署 AI 数据能力时，必须将权限模型的审查纳入安全开发生命周期，确保 AI 创新不会以牺牲数据安全为代价。