2. 身份与认证机制

Snowflake 的安全边界从“谁可以进入账户”开始。理解身份与认证机制，需要把三个层面分开看：身份主体（用户、服务账号、外部身份提供方中的身份）、认证方式（密码、MFA、SSO、OAuth、密钥对）以及身份生命周期管理（身份联邦与 SCIM 自动同步）。三者共同决定了一个请求能否以可信身份进入 Snowflake，而授权（角色与权限）则在此之后决定“能做什么”。

用户与角色：身份与权限的分离

Snowflake 中的“用户”是认证主体，代表一个可以登录或调用 API 的实体；“角色”是权限容器，代表一组可被授予的对象权限。二者通过 GRANT ROLE ... TO USER ... 建立绑定关系。这种分离带来一个重要特性：同一个用户可以被授予多个角色，登录后通过 USE ROLE 切换当前活动角色，从而在不同工作场景下获得不同权限范围。

Snowflake 预置了若干系统角色，其中 ACCOUNTADMIN 拥有账户级最高权限，SYSADMIN 负责对象与仓库管理，SECURITYADMIN 负责用户、角色与授权管理，USERADMIN 专注于用户和角色的创建。实践中应遵循最小权限原则：日常开发使用自定义角色，仅在必要时临时切换到高权限角色，避免长期以 ACCOUNTADMIN 身份操作。

-- 创建自定义角色并授予权限
USE ROLE USERADMIN;
CREATE ROLE IF NOT EXISTS analyst_role;

USE ROLE SECURITYADMIN;
GRANT ROLE analyst_role TO USER alice;

USE ROLE SYSADMIN;
GRANT USAGE ON DATABASE sales_db TO ROLE analyst_role;
GRANT USAGE ON SCHEMA sales_db.public TO ROLE analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;

上述示例中，alice 被授予 analyst_role，该角色仅能读取 sales_db.public 下的表。若后续新增表，需要重新授权或使用 FUTURE TABLES 语法预先授权，这一点在权限设计中容易被忽略。

认证方式：从密码到密钥对

Snowflake 支持多种认证方式，适用于不同场景：

• 用户名 + 密码：最基础的方式，适合人工登录，但安全性最低，应配合 MFA 使用。
• MFA（多因素认证）：在密码基础上增加一次性验证码，Snowflake 原生支持基于 TOTP 的 MFA，可对单个用户强制启用。
• SSO（单点登录）：通过 SAML 2.0 与外部 IdP（如 Okta、Azure AD、ADFS）集成，用户使用企业统一身份登录，Snowflake 不存储密码。
• OAuth：适用于第三方应用或自定义客户端，通过授权服务器颁发令牌，常用于 BI 工具和应用程序集成。
• 密钥对认证：使用 RSA 公钥/私钥对，适合服务账号、自动化脚本和 CI/CD 场景，避免在代码中硬编码密码。

选择认证方式时，核心判断依据是“谁在登录”：人类用户优先 SSO + MFA，服务账号优先密钥对或 OAuth，临时脚本可使用带轮换策略的密钥对。Snowflake 允许同一用户配置多种认证方式，但生产环境应明确主认证路径，避免管理混乱。

身份联邦与 SCIM 集成

身份联邦解决的是“用户在企业 IdP 中已有身份，如何免密进入 Snowflake”的问题。配置 SAML SSO 时，需要在 IdP 侧创建应用、配置 ACS URL 与实体 ID，并在 Snowflake 侧通过 CREATE SAML IDENTITY PROVIDER 或 ACCOUNT 级参数完成对接。联邦登录后，Snowflake 依据 IdP 传递的属性（如邮箱、组）映射到本地用户或角色。

SCIM（System for Cross-domain Identity Management）则进一步解决“用户和组的生命周期自动化”。启用 SCIM 后，IdP 中创建、禁用或删除用户时，Snowflake 侧会自动同步，减少手工维护。典型配置包括：在 IdP 中启用 SCIM provisioning，生成 SCIM token，并在 Snowflake 中通过 CREATE SECURITY INTEGRATION ... TYPE = SCIM 建立集成。SCIM 同步的用户默认不设置密码，只能通过 SSO 登录，这本身就是一种安全加固。

认证与身份链路的整体视图

下图展示了从用户/服务账号发起请求，到通过不同认证方式进入 Snowflake，再经由身份联邦与 SCIM 完成身份同步与生命周期管理的整体关系。图中区分了人工登录路径与自动化路径，并标出了 IdP、SCIM 集成与 Snowflake 账户之间的数据流向。

从图中可以看出，人工用户与服务账号走的是两条不同的认证路径，但最终都汇聚到 Snowflake 账户中的“用户—角色—权限”结构。IdP 同时承担两个职责：通过 SAML 完成登录时的身份断言，通过 SCIM 完成登录之外的身份生命周期同步。理解这一分工，有助于在实际部署中避免“只配了 SSO 却忘了 SCIM，导致离职员工账号仍存在”这类常见问题。

关键配置与验证要点

在 Snowflake 中查看当前用户的认证配置，可以使用以下命令：

-- 查看用户属性（含认证方式、默认角色等）
DESCRIBE USER alice;

-- 查看账户级 SSO 配置
SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;

-- 查看 SCIM 集成
SHOW INTEGRATIONS LIKE '%SCIM%';

验证 SSO 是否生效，最直接的方式是使用浏览器访问 Snowflake 登录页，确认是否跳转到企业 IdP 页面；验证 SCIM 是否生效，可在 IdP 中新增一个测试用户，观察 Snowflake 中是否在预期时间内出现同名用户，且该用户 PASSWORD 字段为空、MUST_CHANGE_PASSWORD 为 false。若同步未发生，优先检查 SCIM token 是否过期、IdP 侧 provisioning 是否启用、以及 Snowflake 安全集成是否处于 ENABLED 状态。

综合来看，身份与认证机制的设计目标可以归纳为三点：可信进入（认证方式与身份来源匹配）、最小权限（用户与角色分离、按需授予）、自动治理（联邦与 SCIM 减少手工维护和遗漏）。这三者共同构成 Snowflake 访问控制体系的第一道防线，也是后续角色层级设计与数据权限管理的基础。