1. Snowflake安全架构总览

Snowflake 的安全模型与传统自建数据库最大的区别在于：它把“谁负责什么”这件事拆得非常清楚。Snowflake 作为云原生数据平台，负责底层云基础设施、存储加密、网络隔离、平台补丁与可用性；而客户负责身份治理、权限设计、数据分类、访问策略与审计使用。理解这条共享责任分界线，是后续所有访问控制、脱敏、审计与合规配置的前提。

从架构上看，Snowflake 的安全边界可以理解为三层：云基础设施层、Snowflake 平台层、客户数据与身份层。云基础设施层由 Snowflake 托管在 AWS、Azure 或 GCP 上，客户不直接接触虚拟机、存储卷或网络设备；平台层提供账户、用户、角色、仓库、数据库对象、网络策略、密钥管理等能力；客户层则是客户真正需要设计和维护的部分，包括用户身份来源、角色层级、对象授权、数据脱敏策略和审计范围。

Snowflake 的核心安全组件可以归纳为六类：身份与认证、访问控制、网络与连接安全、数据加密与密钥管理、数据治理与脱敏、审计与监控。它们不是彼此独立的，而是围绕“请求进入—身份确认—权限判定—数据返回—行为记录”这条链路协同工作。下面这张图展示了 Snowflake 云原生安全模型中的共享责任边界与核心组件关系。

这张图的关键信息是：Snowflake 负责“平台可信”，客户负责“使用可信”。平台层已经提供了加密、认证、网络隔离和审计基础设施，但这些能力是否真正生效，取决于客户如何配置角色、如何绑定策略、如何管理密钥和如何复核权限。

共享责任模型的实际含义

共享责任模型不是一句口号，它直接决定日常安全工作的分工。举例来说，Snowflake 保证数据在静态存储时使用 AES-256 加密，但“哪些角色可以查询这张表”由客户决定；Snowflake 提供网络策略能力，但“允许哪些 IP 段访问账户”由客户配置；Snowflake 记录登录历史和查询历史，但“谁定期查看这些日志、发现异常后如何处理”由客户负责。

因此，在 Snowflake 中做安全设计时，建议先明确三个问题：第一，身份从哪里来——是本地用户、SSO 联合身份，还是 OAuth 或密钥对；第二，权限如何收敛——是通过角色层级逐层授予，还是直接对用户授权；第三，数据如何分级保护——哪些列需要脱敏、哪些行需要行级安全策略、哪些对象需要额外审计。

核心安全组件的协同关系

六个核心组件并不是并列关系，而是存在明确的先后依赖。一次查询请求进入 Snowflake 后，大致经历以下判定顺序：

1. 网络策略判定：检查来源 IP 是否在允许列表中，若账户启用了网络策略且来源不在白名单，连接直接被拒绝。
2. 身份认证：验证用户名/密码、MFA、SSO 令牌或密钥对签名，确认请求者身份。
3. 角色激活与权限判定：确认当前会话激活的角色，检查该角色是否对目标数据库、模式、表或视图拥有相应权限。
4. 策略执行：若目标对象绑定了动态数据脱敏策略、行级安全策略或标签策略，在返回结果前按策略改写或过滤数据。
5. 加密与密钥管理：数据在存储层已加密，若使用 Tri-Secret Secure，则客户密钥参与解密过程。
6. 审计记录：查询语句、执行用户、角色、时间、结果状态写入访问历史，供后续审计与告警使用。

这个顺序说明：网络策略和身份认证是入口防线，访问控制和策略执行是核心防线，加密和审计是兜底与追溯防线。任何一层配置不当，都可能导致安全边界被绕过。

一个可参考的初始安全配置检查表

在新账户启用初期，可以按以下检查表逐项确认。表中参数为示例建议，实际值需根据组织安全基线调整。

安全边界与信任边界

Snowflake 的安全边界可以按“信任级别”划分。最外层是公网与客户端，属于不可信区域；中间是 Snowflake 平台服务，属于受控可信区域；最内层是客户数据与密钥，属于高敏感区域。网络策略、TLS、私有链接用于收缩外层边界；身份认证与访问控制用于控制进入中间层的身份；加密、脱敏与审计用于保护最内层数据。

需要特别注意的是，角色激活并不等于权限永久生效。Snowflake 中一个用户可以被授予多个角色，但同一会话中只有当前激活的角色及其下级角色权限生效。这意味着权限设计必须考虑“角色切换”带来的影响，避免用户通过激活高权限角色绕过预期限制。