2. 身份认证机制

在 Snowflake 中，“身份认证（Authentication）”回答的是一个非常具体的问题：当前这个连接请求，究竟代表哪一个用户或服务身份？它与“授权（Authorization）”是两个不同阶段——认证先确认“你是谁”，授权再决定“你能做什么”。Snowflake 把认证能力设计成可插拔的多种机制，以适应人类用户、程序账号、外部身份提供商等不同场景。理解这些机制的适用边界，是设计安全访问体系的第一步。

Snowflake 支持的身份认证方式主要包括五类：用户名密码、多因素认证（MFA）、联合认证（Federated Authentication，含 SSO）、密钥对认证（Key Pair Authentication）以及 OAuth。它们并非互相排斥，而是可以按用户类型组合使用。下面逐一说明其原理、配置要点与典型适用对象。

用户名密码：最基础也最需要加固

用户名密码是 Snowflake 原生账号中最直接的认证方式。用户以 登录名 + 密码 连接，Snowflake 校验其密码哈希后建立会话。它简单、无需外部依赖，适合快速起步，但风险也最明显：密码可被猜测、撞库、钓鱼或在脚本中明文泄露。

因此 Snowflake 对密码策略提供了多项控制参数，例如通过 PASSWORD_MIN_LENGTH、PASSWORD_MIN_UPPER_CASE_CHARS、PASSWORD_MIN_NUMERIC_CHARS 等设置复杂度，通过 PASSWORD_MAX_AGE_DAYS 控制有效期，并可用 MINS_TO_BYPASS_MFA 规定 MFA 缓存时长。一个合理的示例策略是：最小长度 12、至少 1 个大写字母、至少 1 个数字、有效期 90 天。这些参数属于示例配置，实际应结合组织安全基线调整。

多因素认证：在密码之上再加一道锁

多因素认证（MFA）要求用户在密码之外再提供一个动态因素。Snowflake 支持基于时间的一次性密码（TOTP），用户通过 Duo、Google Authenticator 等应用生成 6 位验证码。启用后，登录流程变为“密码 + 动态码”两步。

MFA 可以按用户强制，也可以按账号策略统一要求。管理员可对高权限用户（如 ACCOUNTADMIN、SECURITYADMIN）强制启用 MFA，降低凭据被盗后的直接冲击。需要注意，MFA 主要面向交互式登录；对纯程序化连接，通常改用密钥对或 OAuth，而不是让服务账号依赖人工输入动态码。

联合认证：把身份判断交给企业 IdP

联合认证（Federated Authentication）让 Snowflake 信任外部身份提供商（IdP），如 Okta、Azure AD、ADFS 等，通过 SAML 2.0 或 OIDC 完成单点登录（SSO）。用户在企业门户登录后，IdP 签发断言，Snowflake 据此建立会话，无需在 Snowflake 内单独维护密码。

其核心价值在于：身份生命周期由 IdP 统一管理，员工离职时在 IdP 停用即可同步阻断 Snowflake 访问；同时可结合 IdP 自身的 MFA 策略。配置时通常需要设置 SAML_IDENTITY_PROVIDER、SAML_SSO_URL、SAML_ISSUER 等参数，并在 IdP 侧配置 ACS URL 与实体 ID。联合认证最适合已具备成熟 IdP 的企业，是面向人类用户的主流方案。

密钥对认证：为程序账号设计的强认证

密钥对认证使用非对称加密：用户持有私钥，Snowflake 保存公钥。连接时客户端用私钥签名，Snowflake 用公钥验签，从而证明身份，全程无需传输密码。它特别适合服务账号、ETL 任务、CI/CD 流水线等无人值守场景。

典型流程是：先用 openssl 生成私钥并导出公钥，再通过 ALTER USER ... SET RSA_PUBLIC_KEY='...' 将公钥注册到用户。私钥必须妥善保管，建议加密存储并设置轮换周期。相比密码，密钥对认证更难被暴力破解，也便于自动化，但私钥一旦泄露同样危险，因此轮换与最小权限同样重要。

OAuth：面向第三方集成的授权式认证

OAuth 是一种基于令牌的授权框架。客户端先向授权服务器换取访问令牌（Access Token），再以该令牌连接 Snowflake。Snowflake 支持 OAuth 与外部授权服务器集成，常用于 BI 工具、数据应用等第三方系统接入，避免在集成中硬编码用户密码。

OAuth 的优势是令牌可限定作用域与有效期，便于集中撤销；代价是配置链路较长，需要维护客户端 ID、密钥、令牌端点与安全集成对象。它适合需要“代表用户访问”或“跨系统集成”的场景。

如何为不同对象选择认证方式

把五类机制放在一起看，选择逻辑其实很清晰：人类用户优先走联合认证 SSO，并在 IdP 或 Snowflake 侧叠加 MFA，避免在 Snowflake 内维护独立密码；程序账号（ETL、调度、CI/CD）优先用密钥对认证，若涉及第三方应用代表用户访问，则用 OAuth；临时或低权限的起步账号可先用用户名密码，但必须配合复杂度策略并尽快迁移。

需要强调的是，认证方式的选择不是“越强越好”的单一排序，而是与使用场景匹配。例如让无人值守任务使用 MFA 并不现实，而让高权限管理员仅用密码则明显不足。合理做法是按账号类型分层：交互式高权限账号强制 MFA，服务账号使用密钥对或 OAuth，普通用户通过 SSO 统一接入。

配置示例：为服务账号启用密钥对认证

下面给出一个可参考的密钥对认证配置片段。先生成密钥对，再注册公钥，最后用私钥连接。示例参数仅用于说明流程，实际密钥长度与路径请按组织规范调整。

# 1. 生成加密私钥与公钥（示例：2048 位 RSA）
openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -out rsa_key.p8
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

# 2. 在 Snowflake 中为用户注册公钥（去掉 PEM 头尾与换行）
ALTER USER svc_etl SET RSA_PUBLIC_KEY='MIIBIjANBgkqh...';

# 3. 客户端以私钥连接（示意）
# snowsql -a <account> -u svc_etl --private-key-path rsa_key.p8

配置完成后，可通过 DESC USER svc_etl 查看 RSA_PUBLIC_KEY_FP 指纹是否已写入，以此判断公钥注册是否成功。若连接失败，优先检查私钥是否加密、公钥是否完整、用户是否被禁用，以及网络策略是否放行。

总结来看，Snowflake 的五类认证机制覆盖了从人类用户到程序账号的完整谱系。掌握每种机制的凭据形态、配置入口与适用对象，才能在后续的授权与网络策略设计中，构建出既安全又可持续维护的访问控制体系。