📚 课程目录第2章 Snowflake账户与安全基础

2. Snowflake账户与安全基础

Snowflake 的安全体系并不是“建个账号、发个密码”这么简单。它把身份、权限、网络边界和认证强度分成四层来管理：组织（Organization）负责跨账户的全局治理，账户（Account）是计费与资源的隔离单元，用户与角色决定“谁能对什么对象做什么”，MFA 与网络策略则决定“从哪里、以多强的身份证明才能登录”。理解这四层的关系，是后续所有数据湖仓工程的安全地基。

一、组织与账户结构：先分清两层边界

一个组织是 Snowflake 中最高层的管理实体，通常对应一家企业。组织之下可以挂载多个账户，例如生产账户、测试账户、开发账户，或者按业务线拆分的账户。组织层负责全局用户、全局角色、账户间数据共享和跨账户复制；账户层则是实际存放数据库、仓库、计算资源和本地用户的地方。

需要特别注意的是：组织账户（Organization Account）与普通账户是两种不同定位。组织账户用于集中管理，一般不直接承载业务数据；普通账户才是日常开发、加载、查询的工作场所。创建账户时，Snowflake 会分配一个账户定位符（Account Locator）或账户 URL，例如 https://xy12345.snowflakecomputing.com，这个 URL 就是后续连接、配置网络策略和排查登录问题的关键标识。

在规划阶段，建议先明确三件事：账户按环境拆分还是按业务域拆分；哪些账户需要加入同一组织以便共享数据；每个账户的云区域（Region）和云平台（AWS/Azure/GCP）是否一致。区域一旦选定，后续迁移成本较高，应提前确认合规与延迟要求。

二、用户、角色与权限模型：RBAC 是核心

Snowflake 采用基于角色的访问控制（RBAC）。权限不直接授予用户，而是先授予角色，再把角色授予用户。这样做的价值在于：人员变动时只需调整角色归属，不必逐个对象改权限。

角色之间存在继承关系。系统预置了 SYSADMIN、SECURITYADMIN、USERADMIN、ACCOUNTADMIN 等高阶角色，其中 ACCOUNTADMIN 权限最大，应严格限制使用。实际工程中更推荐自建角色层级，例如：

-- 创建角色层级
CREATE ROLE IF NOT EXISTS analyst;
CREATE ROLE IF NOT EXISTS engineer;
CREATE ROLE IF NOT EXISTS loader;

-- 让 engineer 继承 analyst 的权限
GRANT ROLE analyst TO ROLE engineer;

-- 把角色授予用户
GRANT ROLE engineer TO USER zhangsan;

-- 授予对象权限
GRANT USAGE ON DATABASE lakehouse TO ROLE analyst;
GRANT USAGE ON SCHEMA lakehouse.raw TO ROLE analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA lakehouse.raw TO ROLE analyst;
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE analyst;

这里的关键判断是：权限授予要遵循最小权限原则。加载角色只需要对目标表的 INSERT 和对应阶段的读写权限，不应拥有 DROP 或 ACCOUNTADMIN。查询角色只应拿到 SELECT 和仓库 USAGE。若使用 FUTURE TABLES 授权，可以让新建表自动继承权限，避免每次建表后手动补授权。

此外，Snowflake 还支持数据库角色（Database Role），用于在单个数据库内部做更细粒度的权限划分，适合多团队共享同一数据库但需要隔离 schema 的场景。

三、多因素认证：把密码之外的第二把锁加上

MFA 的作用是：即使密码泄露，攻击者仍缺少第二因素。Snowflake 支持多种 MFA 方式，包括基于时间的一次性密码（TOTP，如 Authenticator App）、Duo Push，以及通过 SSO 联合认证时由身份提供商（IdP）强制 MFA。

配置 MFA 的常见做法有两种：一是对单个用户强制，二是通过认证策略（Authentication Policy）对一批用户统一要求。示例：

-- 创建认证策略，要求 MFA
CREATE AUTHENTICATION POLICY require_mfa
  MFA_AUTHENTICATION_METHODS = ('TOTP', 'DUO')
  MFA_ENROLLMENT = REQUIRED
  CLIENT_TYPES = ('SNOWFLAKE_UI', 'DRIVERS');

-- 应用到账户
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa;

配置后，用户首次登录会被要求绑定 TOTP。判断是否生效，可以查看用户属性中的 HAS_MFA 或通过 SHOW USERS 观察 MFA_AUTHENTICATION_METHODS 字段。若企业已使用 Okta、Azure AD 等 IdP，更推荐走 SSO + SCIM，把 MFA 交给 IdP 统一管理，Snowflake 侧只保留联合登录配置。

四、网络策略：限制“从哪里来”

网络策略（Network Policy）通过 IP 允许列表和阻止列表控制访问来源。它既可以绑定到整个账户，也可以绑定到单个用户。典型场景是：只允许公司办公网和 VPN 出口 IP 访问生产账户，其他来源一律拒绝。

-- 创建网络策略
CREATE NETWORK POLICY corp_policy
  ALLOWED_IP_LIST = ('203.0.113.0/24', '198.51.100.10')
  BLOCKED_IP_LIST = ('192.0.2.0/24');

-- 绑定到账户
ALTER ACCOUNT SET NETWORK_POLICY = corp_policy;

-- 或绑定到特定用户
ALTER USER zhangsan SET NETWORK_POLICY = corp_policy;

配置网络策略时最容易出问题的是把自己锁在外面。因此建议：先确认当前出口 IP 已加入允许列表，再执行绑定；保留一个高权限用户不绑定策略作为应急通道；变更后立即用新会话验证登录。若使用 PrivateLink 或云厂商私有连接，网络策略应结合私有端点一起规划，而不是只依赖公网 IP 白名单。

注意：网络策略和 MFA 是互补关系，不是替代关系。网络策略限制来源，MFA 验证身份强度，两者同时启用才能形成较完整的登录防护。

五、四层安全关系一览

下面这张图把组织、账户、用户角色、MFA 与网络策略放在同一张关系图中，帮助理解它们各自管什么、在哪一层生效。

把这张图记在脑子里，后续配置时就不会混淆：组织管全局，账户管资源，角色管权限，MFA 和网络策略管入口。实际落地时，建议先用一个测试账户完整走一遍“建角色 → 授权限 → 强制 MFA → 绑网络策略 → 验证登录”的闭环，确认无误后再复制到生产账户。这样既能避免把自己锁在门外，也能让安全基线在多个账户之间保持一致。