1. Snowflake安全体系总览
Snowflake 的安全体系并不是单一功能，而是一套围绕“身份、权限、数据、网络、审计”五个维度协同工作的分层控制框架。理解这套框架的关键，是先分清 Snowflake 与客户之间的责任边界，再理解访问控制在 Snowflake 内部是如何逐层收敛的，最后才能把各个安全组件放到正确的位置上。
共享责任模型：谁保护什么
Snowflake 采用共享责任模型（Shared Responsibility Model）。Snowflake 负责云基础设施、存储层加密、计算资源隔离、平台自身补丁与物理安全；客户负责身份管理、访问策略、数据分类、网络策略配置以及审计监控。这条边界决定了：即使 Snowflake 默认对存储数据做了 AES-256 加密，客户仍然必须自己决定“谁能解密、谁能查询、谁能导出”。
一个常见的误解是“用了 Snowflake 就自动安全了”。实际上，Snowflake 提供的是安全能力（capability），而不是安全结果（outcome）。例如，默认情况下账户管理员拥有极大权限，如果没有启用 MFA、没有限制网络策略、没有做角色最小化设计，数据仍然可能被内部人员或泄露的凭据访问。因此共享责任模型的核心实践含义是：Snowflake 保证平台可信，客户保证使用可信。
访问控制层次：从账户到行级
Snowflake 的访问控制是分层收敛的，从外到内大致可分为五层：
- 网络层：通过 Network Policy 限制允许访问的 IP 范围，可作用于整个账户或单个用户。
- 身份层：通过用户、MFA、SSO（SAML/OAuth）确认“你是谁”。
- 角色层：通过 RBAC 决定“你以什么身份操作”，角色是权限的载体。
- 对象层：通过 GRANT 决定角色能对哪些数据库、Schema、表、视图执行哪些操作。
- 数据层：通过行访问策略（Row Access Policy）、列级掩码（Masking Policy）、安全视图等决定“你能看到哪些行、哪些列、什么值”。
这五层是“与”关系：任何一层拒绝，访问就不成立。例如一个用户即使拥有 SELECT 权限，如果其 IP 不在网络策略白名单内，连接仍会被拒绝；即使连接成功，如果查询的表上绑定了行访问策略，返回结果也会被过滤。
核心组件与设计目标
围绕上述五层，Snowflake 提供了一组核心安全组件，它们各自解决不同层面的问题：
| 组件 | 作用层次 | 典型用途 |
|---|---|---|
| Network Policy | 网络层 | 限制 IP 范围，防止凭据泄露后的异地登录 |
| MFA / SSO | 身份层 | 强化登录验证，统一企业身份源 |
| RBAC 角色体系 | 角色层 | 按职能划分权限，实现最小权限 |
| Dynamic Data Masking | 数据层 | 对敏感列按角色返回脱敏值 |
| Row Access Policy | 数据层 | 按用户属性过滤可见行 |
| Secure View | 数据层 | 隐藏底层表结构与过滤逻辑 |
| Access History / ACCOUNT_USAGE | 审计层 | 追踪谁在何时访问了哪些数据 |
| Object Tagging | 治理层 | 标记敏感级别，驱动策略自动化 |
这些组件的设计目标可以归纳为四条：最小权限（默认拒绝，按需授予）、纵深防御（多层独立控制，单点失效不致命）、可审计（所有访问可追溯）、可治理（策略集中管理、可复用、可自动化）。
一个具体的权限判断示例
假设分析师 Alice 使用角色 ROLE_ANALYST 查询 SALES.ORDERS 表。系统会依次判断：她的 IP 是否在公司网络策略白名单内；她的登录是否通过了 MFA；ROLE_ANALYST 是否被授予了对该表的 SELECT 权限；该表上是否绑定了行访问策略，如果有，则按策略表达式过滤行；如果查询涉及 CUSTOMER_EMAIL 列且该列绑定了掩码策略，则根据角色返回掩码值（如 ****@***.com）。只有全部通过，Alice 才能看到符合策略的结果。
这个例子说明：Snowflake 的安全不是靠某一个开关，而是靠多层策略的组合。设计安全体系时，应该先明确“谁、在什么网络环境、以什么角色、访问什么对象的什么数据”，再把这四个问题分别映射到对应的控制层上。