2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
您希望克劳德（Claude）——或柯瑟（Cursor）、查特吉皮提（ChatGPT）或任何知晓模型上下文协议（MCP）的智能体——回答有关您的斯诺弗莱克（Snowflake）数据的问题。同时，您也不希望该智能体读取社会安全号码、自由文本形式的客户备注，或任何受《通用数据保护条例》（GDPR）、《健康保险流通与责任法案》（HIPAA）或 SOC 2 审计标准约束的数据。默认的模型上下文协议（MCP）设置会将代理连接角色所能看到的所有内容都交给智能体。这就是问题所在。
本文介绍了五层防御措施，按从成本最低到最全面的顺序排列。每一层都是独立的——请选择符合您风险承受能力的措施。在现有的斯诺弗莱克（Snowflake）账户上搭建整套防御体系大约需要一小时。
默认姿态（及其错误原因）
典型的斯诺弗莱克（Snowflake）模型上下文协议（MCP）服务器（包括官方提供的服务器）使用服务账户进行连接，暴露一个 query 工具，并允许模型运行该角色有权执行的任何结构化查询语言（SQL）语句。该角色通常限定于某个仓库和数据库，但很少限定到列或行集。模型获得了通往您仓库的流畅结构化查询语言（SQL）接口，而仓库则信任它看到的每一个查询。
潜在影响范围巨大。根据《2025年 IBM 数据泄露成本报告》，数据泄露的平均成本高达 488 万美元，其中涉及大量云数据暴露的泄露事件成本比平均水平高出 23%。允许人工智能智能体针对生产仓库运行未经筛选的查询，正是导致这种高额溢价风险的云数据暴露类别。
第一层：专用的模型上下文协议（MCP）角色
首要步骤（每次都必须执行）：创建一个仅用于该智能体的角色。不要复用分析角色，不要复用 dbt 角色，也绝对不要使用系统管理员（SYSADMIN）角色。
- 授予该角色对您希望智能体使用的仓库的使用权（USAGE）。使用小型专用仓库（X-Small 或 Small），以便将失控查询的成本上限控制在有限范围内。
- 授予该角色对数据库及智能体应可见的特定模式（schema）的使用权（USAGE）。
- 授予该角色对智能体应查询的特定视图的查询权限（SELECT），而非原始表。视图为您提供了一个应用掩码、过滤器和连接操作的位置，而无需修改底层数据。
- 切勿授予创建（CREATE）、插入（INSERT）、更新（UPDATE）、删除（DELETE）或截断（TRUNCATE）权限。该智能体应为只读角色。
拥有仅针对视图的查询权限（SELECT）的只读角色，能满足大多数团队约 80% 的需求。剩余的 20% 才是个人身份信息（PII）风险真正所在之处。
第二层：列级掩码策略
斯诺弗莱克（Snowflake）支持基于执行角色触发的掩码策略。相同的结构化查询语言（SQL）查询语句，对于分析师角色会返回原始值，而对于智能体角色则返回掩码后的值。这是最重要的个人身份信息（PII）控制措施，因为它不依赖于智能体或模型上下文协议（MCP）服务器的正确行为。
如果设置一种掩码策略，使得除 ANALYTICS_HUMAN 以外的任何角色都返回 SHA2(email) 哈希值，那么即使模型被越狱并生成 SELECT * 查询，它得到的也是哈希值而非电子邮件地址。该策略在结构化查询语言（SQL）引擎层强制执行，而非在应用层。
将掩码策略应用于每个标记为个人身份信息（PII）的列。如果您尚未设置个人身份信息（PII）标签，审计工具（或 Data Workers 治理智能体）可以扫描模式并自动标记候选列——如电子邮件、电话号码、社会安全号码、自由文本列、互联网协议（IP）地址、出生日期等。
第三层：行访问策略
掩码隐藏的是数值，而行访问策略隐藏的是整行数据。对于多租户数据——或者任何智能体仅应查看单个客户、单个区域或单个财年数据的情况——行访问策略是合适的基本构建块。
常见模式包括：将智能体角色的数据范围限定在最近 90 天内，排除标记为敏感 = true 的行，或限制为特定的 tenant_id（租户标识符）。与掩码策略一样，这些策略也在引擎内部强制执行——没有任何应用层代码能够绕过它们。
第四层：审计日志记录
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
