从单因素身份验证迁移的最佳实践

本部分为客户提供有关如何利用 Snowflake 功能来实施强身份验证和降低凭据盗窃风险的最佳实践。结合此信息与 为单因素密码登录的弃用做好计划,该文档重点介绍了关于摆脱仅密码身份验证的最新 Snowflake 策略。

本指南中的示例查询是旨在帮助 Snowflake 客户的示例,不在生产环境中实施。

简介

本文 所述,Snowflake 专注于三个关键因素,以便更轻松地确保您的账户安全:

  • Prompt: Encourage users who are not using security best practices to adopt them (for example, configure multi-factor authentication (MFA).

  • Enforce: Make it easy for admins to enforce security by default (for example, require all human users to use MFA).

  • Monitor: Provide visibility into adherence to security policies (for example, audit which users haven't configured MFA).

以下信息主要介绍使用 Snowflake Trust Center 进行监控的最佳实践,以及利用身份验证和网络策略的实施步骤。

Snowflake 连接会话生命周期

Snowflake 的连接从驱动程序、连接器或 Snowsight 开始,如下图所示:

安全连接到 Snowflake 的方法

当用户或服务连接到 Snowflake 时,会发生以下情况:

  • 如果已配置,则应用 网络策略。请记住,用户级网络策略会替换账户级网络策略。

  • 如果已配置,则应用 身份验证策略。请记住,用户级身份验证策略会替换账户级身份验证策略。

    如果用户或服务使用 Snowflake 原生密码身份验证,则应用 :ref:`密码策略 <label-password_policies>`(如果已配置)。

  • 如果上述控件允许和授权用户或服务,则 会话策略 将应用于控制用户在非活动期后如何重新进行身份验证。用户级会话策略会替换账户级会话策略。

网络和身份验证策略:一般准则

在任何情况下都要考虑以下准则。有关更多信息,请参阅 阶段 3:保护

Snowflake 强烈建议配置和应用:

  • 用户 TYPE 属性以区分 PERSON(人类)、SERVICE 和 LEGACY_SERVICE。

    • PERSON:用于通过人类用户进行的交互式身份验证,其中 MFA 将强制执行。在撰写本文时,默认情况下该属性为 NULL,从 MFA 强制执行的角度来看,它被视为 PERSON。

    • SERVICE:用于使用编程访问的服务到服务身份验证。这将免于 MFA 强制执行,但这些用户将不再支持密码身份验证。这些用户将仅支持 OAuth 或密钥对。

    • LEGACY_SERVICE:这是唯一支持仅密码身份验证的用户类型(免于 MFA 强制执行)。它只是作为一种迁移工具,客户必须使用网络策略保护这些用户,并使用 泄露密码保护 功能对其进行监控。

      备注

      LEGACY_SERVICE 应用作迁移工具,并将 于 2025 年 11 月弃用

  • SCIM,用于通过 客户属性 (https://community.snowflake.com/s/article/How-to-use-Okta-SCIM-provisioning-to-configure-user-TYPE-attribute-in-Snowflake) 自动配置和设置用户类型

  • 网络策略,确保您的用户和服务仅来自授权和可信的来源(如果可能)。

  • 身份验证策略,用于强制执行强身份验证方法,该方法利用 OAuth 和 SAML 等短期凭据。

  • 密码策略,用于强制执行组织的密码策略。

  • 会话策略,用于限制空闲会话时间。

对于服务用户,鼓励客户尽可能使用短期凭据,例如 OAuth。对于较长期的凭据(如 密钥对),建议客户定期轮换这些密钥,并尽可能将其与网络策略相结合。

对于人类交互式用户,客户应将其 Snowflake 账户与组织范围内的身份提供商集成,利用自己的身份提供商和 MFA 进行 SAML联合身份验证

对于紧急情况用例和使用原生密码的客户,Snowflake 强烈建议为这些紧急情况用户使用 Snowflake 原生 MFA

客户应根据其内部安全策略定期轮换凭据。

客户应始终使用 Trust Center 来监控其风险用户,并将其 Snowflake 账户与组织的安全运营中心集成。

适用于更强身份验证的 Snowflake North Star

在 2025 年,Snowflake 将支持更多功能来帮助客户。

2025 年上半年

  • 改进我们的原生 MFA 支持以超越仅支持密钥和身份验证器应用程序的 DUO(非公开预览版,定于 2025 年 4 月底左右正式发布)。

  • 在我们的驱动程序和连接器中提供原生 OAuth 支持,以简化 OAuth 配置和采用。

  • Trust Center 新功能,例如:

    • 电子邮件通知(公开预览版定于 2025 年 4 月底推出)。

    • 与合作伙伴的扩展集成及自定义扫描器包(现在为非公开预览版,定于 2025 年 7 月底左右正式发布)。

    • 客户组织级别 Trust Center(2025 年 4 月底提供非公开预览版)。

2025 年晚些时候

  • 增强 Trust Center 以使用机器学习异常检测。

  • 通过 Snowsight 使用 SAML、OAuth 改善用户体验。

  • 支持工作负载身份和 OIDC,客户可以使用原生 CSP 身份(例如 Azure 托管身份、AWS 角色和 GCP 服务账户),轻松将其工作负载连接到 Snowflake,而无需凭据。

  • 双向支持 mTLS,入站到 Snowflake,以及从 Snowflake 出站,到支持 mTLS 的客户资源。

Snowflake 保留在公司认为合适的情况下更新和更改上述列表和时间表的权利;我们将在未来分享更多细节。

强制执行身份验证和网络策略的最佳实践

Snowflake 建议按照以下四个步骤迁移到更强的身份验证机制:

  1. 检测风险用户。

  2. 规划您的迁移以更大限度地减少中断。

  3. 在 Snowflake 中保护您的用户。

  4. 持续监控风险用户。

迁移到 MFA 的四个阶段

阶段 1:检测

Snowflake 引入两个主要功能:

  • Threat Intelligence 扫描器包:此扫描器根据下图中的逻辑识别风险用户。本部分还包括示例查询,用于列出风险用户并解释他们有风险的原因。

  • 泄露密码保护:这将验证并自动禁用在暗网上发现的用户密码。此功能针对泄露密码提供内置保护,并有助于限制数据泄露的可能性。受影响的用户可以联系账户管理员重置密码。

客户应打开威胁智能扫描器并自定义扫描频率。一般来说,该扫描器应该每周运行一次,以报告当前的风险用户状况。来自所有信任扫描器的发现都存储在 SNOWFLAKE.TRUST_CENTER 架构中。客户可以利用 Snowflake 原生警报来自动通知安全管理员,甚至在检测到风险用户时采取行动。

健康用户的评估逻辑

健康用户的评估逻辑

风险用户列表的示例查询

以下查询列出了最新的风险用户以及他们有风险的原因:

SELECT DISTINCT
  f.value:entity_id::VARCHAR AS entity_id,
  f.value:entity_name::VARCHAR AS entity_name,
  f.value:entity_detail:user_type::VARCHAR as user_type,
  f.value:entity_detail:has_password::VARCHAR as has_password,
  f.value:entity_detail:has_rsa_public_key::VARCHAR as has_rsa_public_key,
  f.value:entity_detail:mfa_enabled::VARCHAR as mfa_enabled,
  f.value:entity_detail:account_auth_policy_name::VARCHAR as Account_level_Auth_policy,
  f.value:entity_detail:account_auth_policy_requires_mfa::VARCHAR as Account_level_EnforceMFA_policy,
  f.value:entity_detail:user_auth_policy_name::VARCHAR as User_level_Auth_policy,
  f.value:entity_detail:user_auth_policy_requires_mfa::VARCHAR as User_level_EnforceMFA_policy,
  f.value:entity_detail:account_network_policy_name::VARCHAR as Account_level_Net_policy_Name,
  f.value:entity_detail:account_network_policy_Allowlist::VARCHAR as Account_level_Net_policy_Allowlist,
  f.value:entity_detail:user_network_policy_name::VARCHAR as User_level_Net_policy_Name,
  f.value:entity_detail:user_network_policy_allowlist::VARCHAR as User_level_Net_policy_Allowlist,
FROM SNOWFLAKE.TRUST_CENTER.FINDINGS,
  LATERAL FLATTEN(input => at_risk_entities) AS f
WHERE EVENT_ID =
  (SELECT event_id FROM snowflake.trust_center.findings WHERE SCANNER_PACKAGE_NAME = 'Threat Intelligence'
   ORDER BY event_id DESC LIMIT 1);
Copy

Snowflake 最近添加了两个新扫描器:一个用于个人用户,一个用于服务用户。这允许客户根据用户类型使用单因素密码登录拥有单独的用户列表。

您可以返回每种类型的风险用户列表。

风险人类用户列表
SELECT *
  FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
  WHERE event_id =
    (SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
    WHERE scanner_id = 'THREAT_INTELLIGENCE_NON_MFA_PERSON_USERS'
    ORDER BY event_id DESC LIMIT 1) AND total_at_risk_count != 0
;
Copy
风险服务用户列表
SELECT *
  FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
  WHERE event_id =
    (SELECT event_id FROM SNOWFLAKE.TRUST_CENTER.FINDINGS
    WHERE scanner_id = 'THREAT_INTELLIGENCE_PASSWORD_SERVICE_USERS'
    ORDER BY event_id DESC LIMIT 1 ) and total_at_risk_count != 0
;
Copy

跨 TYPE 和所用身份验证方法的用户分布

除前面的查询外,列出跨用户类型和所用身份验证方法的用户分布也有益。这有助于客户制定用户迁移到更强大的身份验证方法(如 SAML 和 OAuth)的策略。例如,如果用户显示为有风险(因为他们在 Snowflake 中有密码),但该用户仅使用 SAML 身份验证,则建议尽快从 Snowflake 中移除该密码。

WITH users AS (
  SELECT DISTINCT
       user_id
      , name
      , login_name
      , type
      , email
  FROM
      SNOWFLAKE.ACCOUNT_USAGE.USERS
  WHERE
      DELETED_ON IS NULL)
SELECT
    u.user_id
    , a.event_timestamp
    , a.user_name
    , u.type
    , a.reported_client_type
    , a.first_authentication_factor
    , a.second_authentication_factor
  FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY AS a
    JOIN USERS u ON a.user_name = u.name
;
Copy

阶段 2:迁移规划

迁移规划从 阶段 1:检测 开始。在识别出有风险的用户之后,开始计划遵循 网络和身份验证策略:一般准则。您应该尽可能放弃静态凭据(如密码和密钥对),并利用单点登录(联合身份验证),例如适用于交互式用户的 SAML,以及同时适用于编程 (SERVICE) 和交互式 (PERSON) 用户的 OAuth。

如果您被迫使用静态凭据(密钥对或密码)来支持某些旧版应用程序,请在规划时考虑以下事项:

  • 尽可能利用网络策略。

  • 根据组织的策略轮换这些静态凭据。

迁移注意事项

以下是在规划迁移时需要牢记的几个注意事项:

  • 第一,设置用户 :ref:`类型 <label-user-type-property>`(这可以 `通过 SCIM 自动完成 <https://community.snowflake.com/s/article/How-to-use-Okta-SCIM-provisioning-to-configure-user-TYPE-attribute-in-Snowflake>`_)。

  • 第二,检查您的应用程序支持哪些身份验证方法:Snowflake 支持多种 身份验证方法,例如 OAuth、SAML、密钥对、MFA 等。但是,连接到 Snowflake 的应用程序还需要支持强身份验证方法。两个用例如下:

    • 应用程序已经支持 SAML 和/或 OAuth。建议您尽快迁移到该身份验证方法。

    • 应用程序为旧版,不支持强身份验证方法,如 SAML 或 OAuth;它只支持密码。在这种情况下,建议您更新旧版应用程序。与此同时,在您更新其应用程序之前,您可以利用网络策略、密码轮换和泄露密码保护功能。

  • 接下来,客户应为本地用户(在 Snowflake 中手动创建,未启用 SAML 或 OAuth)考虑以下事项:

    • 对于支持 SSO 的应用程序,请将本地用户切换为启用 SSO 的用户,并在切换用户时考虑停机时间。

    • 要将本地用户切换为启用 SSO 的用户,请确保此类用户存在于 IdP 中,然后通过 SCIM 手动或最好自动在 Snowflake 中进行配置。

    • 禁用未使用的本地用户。

  • Snowflake 支持用户级和账户级身份验证策略、网络策略和密码策略。首先考虑用户级策略以逐步迁移(用户级策略优先于账户级策略):

    • Snowflake 建议为使用服务用户 (TYPE = SERVICE or LEGACY_SERVICE) 的应用程序考虑用户级网络策略。

    • 对于人类用户(TYPE = PERSON 或 NULL),您可以先应用用户级网络策略,然后应用账户级网络策略,以保护没有用户级特定策略的所有用户群体。

    • MFA 策略的概念与此相同,首先从用户级策略开始。

  • 如果您的旧版应用程序不支持单点登录,Snowflake 建议利用编程访问令牌 (PATs),这些令牌默认与特定角色绑定,需要网络策略,并且有时间限制。

阶段 3:保护

下图可帮助您浏览推荐的身份验证最佳实践。正如您所见,Snowflake 总是建议首先使用联合身份验证和授权。

身份验证最佳实践

请遵循以下步骤来降低 Snowflake 账户被盗的风险:

  1. 设置用户类型

  2. 移除不需要的本地密码

  3. 为服务用户创建身份验证策略

  4. 创建要对人类用户强制执行 MFA 的身份验证策略

  5. 创建密码策略

  6. 创建会话策略

  7. 为服务用户创建网络策略

  8. 在账户级别创建网络策略

  9. 保护服务用户

  10. 在账户级应用密码和会话策略

  11. 测试服务用户

  12. 通过 MFA 强制执行保护账户

  13. 应用账户级网络策略

  14. 禁用未使用的用户

设置用户类型

保护阶段的第一步是通过 SCIM 自动设置用户类型或手动设置:

ALTER USER svc_user1 SET TYPE = SERVICE;
ALTER USER user1@example.COM SET TYPE = PERSON;
-- LEGACY APPLICATION ONLY
Copy

此外,您现在可以在创建账户时设置管理员用户类型:

CREATE ACCOUNT <name> [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ];
Copy

小技巧

许多客户的服务用户名通常有一些模式(如 local_svc_user1)。您可以利用此命名模式来大规模设置 SERVICE 类型。

移除不需要的本地密码

根据 Trust Center 的发现结果,利用跨 TYPE 和所用 AuthN 方法的用户分布,以及风险用户列表下的查询,开始为已专门使用 SAML、OAuth 或密钥对的用户清除 Snowflake 中的任何密码。

为服务用户创建身份验证策略

Snowflake 建议对程序化服务用户使用 OAuth,您可以通过身份验证策略强制执行:

CREATE AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH
  CLIENT_TYPES = ('DRIVERS', 'SNOWSQL')
  AUTHENTICATION_METHODS = ('OAUTH')
  SECURITY_INTEGRATIONS = ('<OAUTH SECURITY INTEGRATIONS>');

ALTER USER <SERVICE_USER> SET AUTHENTICATION POLICY PROGRAMMATIC_ACCESS_USER_AUTH;
Copy

客户仍然可以使用密钥对对 SERVICE 用户进行身份验证,但他们应该将其与网络策略结合起来,并定期轮换密钥。

备注

如果您的旧版系统不支持密钥对或 OAuth,并且您必须使用密码进行身份验证,请使用身份验证方法 PASSWORD 创建其他身份验证策略,并将其应用于该特定编程用户。将该方法与 网络和身份验证策略:一般准则 结合使用。

创建要对人类用户强制执行 MFA 的身份验证策略

Snowflake 建议客户将自己的 SAML 身份提供程序 (IdPs) 与其 IdP 支持的任何 MFA 解决方案一起使用。以下身份验证策略示例可帮助客户执行以下操作:

  • 为使用 Snowflake 原生密码的任何人类用户强制执行 Snowflake 原生 MFA。

  • 依靠客户 SAML IdP 对单点登录用户强制执行 MFA。

CREATE AUTHENTICATION POLICY HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA
  AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
  SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD'); -- enforce Snowflake MFA for native passwords only
  MFA_ENROLLMENT = 'REQUIRED';
Copy

如果客户 IdP 离线,客户应考虑紧急情况,以便他们的账户管理员仍然可以登录他们的 Snowflake 账户。

CREATE AUTHENTICATION POLICY ACCOUNTADMIN_BREAKGLASS_MFA
  AUTHENTICATION_METHODS = ('PASSWORD')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD') -- enforce Snowflake MFA for native passwords only
  MFA_ENROLLMENT = 'REQUIRED';
Copy
SSO 的 MFA

备注

对于更严格的策略,您可以创建其他 MFA 强制执行策略并直接在用户级别应用:例如,当客户 IdP 不支持 MFA 时,对用户强制执行 Snowflake MFA,而不管是否在 IdP 级别强制执行 MFA。(一些客户可以使用此选项,对高特权用户 [如账户管理员] 执行双重 MFA。)

CREATE AUTHENTICATION POLICY ACCOUNTADMIN_DOUBLE_MFA
  AUTHENTICATION_METHODS = ('PASSWORD', 'SAML')
  SECURITY_INTEGRATIONS = ('<SAML SECURITY INTEGRATIONS>')
  MFA_AUTHENTICATION_METHODS = ('PASSWORD', 'SAML') -- double MFA
  MFA_ENROLLMENT = 'REQUIRED';
Copy

创建密码策略

如果您有旧版系统或必须使用 Snowflake 原生密码的紧急情况,请利用 Snowflake 密码策略来匹配组织密码策略(如果它们与默认策略不同)。

CREATE PASSWORD POLICY password_policy_account
  PASSWORD_MIN_LENGTH = 32
  -- PASSWORD_MAX_LENGTH = <integer>
  PASSWORD_MIN_UPPER_CASE_CHARS = 6
  PASSWORD_MIN_LOWER_CASE_CHARS = 6
  PASSWORD_MIN_NUMERIC_CHARS = 4
  PASSWORD_MIN_SPECIAL_CHARS = 8
  PASSWORD_MIN_AGE_DAYS = 10
  PASSWORD_MAX_AGE_DAYS = 30
  PASSWORD_MAX_RETRIES = 3
  PASSWORD_LOCKOUT_TIME_MINS = 30
  PASSWORD_HISTORY = 24
  COMMENT = '<string_literal>';
Copy

创建会话策略

Snowflake 建议您创建会话策略,以便在特定的不活动时间段后强制重新执行身份验证。这只是一个示例;您可以在单个用户级别自定义策略。

CREATE SESSION POLICY session_policy_account
  SESSION_IDLE_TIMEOUT_MINS = 240 -- Snowflake clients and programmatic clients
  SESSION_UI_IDLE_TIMEOUT_MINS = 20 -- For the Snowflake web interface
  COMMENT = '<string_literal>';
Copy

为服务用户创建网络策略

一般来说,服务或编程访问用户应该来自授权的 IP 地址(或者 VPCE ID、LinkID 等,前提是有专用连接)。

Snowflake 建议创建服务用户级网络策略,以限制访问来自授权和可信来源的编程访问用户。客户也应该考虑在内部暂存区强制执行网络规则。

备注

Snowflake 仅在 AWS 区域中支持内部暂存区的网络规则;对于 Azure,您可以考虑阻止公共访问,而对于服务控制 GCP,请联系 Snowflake 支持部门。

在某些情况下,由于云的动态特性,一些云提供商无法提供要在 Snowflake 网络策略中列出的 IP 地址范围。对于此类情况,请遵循网络和身份验证策略一般准则。或者,如果您的工具支持专用连接,请考虑使用专用连接。

连接可以来自专用或公共网络,这取决于客户是否使用专用连接。请记住,您可以通过添加包含相关 IPs(公共或专用)和/或 CSP 标签(例如 VPCE ID、LinkIDs)的网络规则,同时允许公共和专用连接。

-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC
  TYPE = IPV4
  VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
  MODE =  INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_PL
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1931' , 'VPCE-123ABC3420C1932' )
  MODE =  INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1933' )
  MODE =  INTERNAL_STAGE
;
CREATE NETWORK POLICY PROGRAMMATIC_ACCESS_USER_NET_POLICY
  ALLOWED_NETWORK_RULE_LIST =
    (
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_PUBLIC',
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_PL',
     'PROGRAMMATIC_ACCESS_USER_NET_RULE_INTERNAL_STAGE'
    )
  --BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
Copy

在账户级别创建网络策略

对于没有直接应用网络策略的用户,账户级策略将作为默认安全网络策略。最佳实践是在使用用户级策略来处理特定用户需求时,尽可能保持这些策略的限制性和简短性。

Snowflake 不建议构建庞大的账户级网络策略来满足组织的所有需求;相反,它允许用户级策略具有更精细的控制。

与用户级网络策略类似,连接可以来自专用网络或公共网络,具体取决于客户是否使用专用连接。请记住,您可以通过添加包含相关 IPs(公共或专用)和/或 CSP 标签(例如 VPCE ID、LinkIDs)的网络规则,同时允许公共和专用连接。

-- ACCESS FROM PUBLIC IP ADDRESSES
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC
  TYPE = IPV4
  VALUE_LIST = ( 'PUBLIC IP1' , 'XX.XX.XX.XX/24' [ , ... ] )
  MODE =  INGRESS
;
-- ACCESS FROM PRIVATE NETWORK
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_PL
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1934' , 'VPCE-123ABC3420C1936' )
  MODE =  INGRESS
;
-- RESTRICT ACCESS TO INTERNAL STAGE USING VPCE ID
CREATE NETWORK RULE HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE
  TYPE = AWSVPCEID
  VALUE_LIST = ( 'VPCE-123ABC3420C1937')
  MODE =  INTERNAL_STAGE
;
CREATE NETWORK POLICY ACCOUNT_LEVEL_NET_POLICY
  ALLOWED_NETWORK_RULE_LIST =
   (
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_PUBLIC',
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_PL',
    'HUMAN_ACCESS_ACCOUNT_NET_RULE_INTERNAL_STAGE'
   )
   --BLOCKED_NETWORK_RULE_LIST = ( 'OPTIONAL BLOCKED LIST OF IPS' )
;
Copy

保护服务用户

具有 TYPE=SERVICE 的用户不受账户级 MFA 强制执行策略的约束,并且具有限制以提高非交互式用例的安全状况。值得注意的是,SERVICE 类型的用户不能使用密码或 SAML SSO。请参阅下面的警告。

-- FOR EVERY SERVICE PROGRAMMATIC ACCESS USER
ALTER USER SERVICE_USER_1 SET
TYPE = SERVICE
NETWORK_POLICY = PROGRAMMATIC_ACCESS_USER_NET_POLICY
AUTHENTICATION POLICY = PROGRAMMATIC_ACCESS_USER_AUTH;
Copy
旧版应用程序的服务用户

如果您有不支持 OAuth 的旧版应用程序,请使用 编程访问令牌 (PATs),而不是结合使用密码和 LEGACY_SERIVCE。(PAT 功能目前为非公开预览版。)

PATs 有许多限制以提高安全性:当您生成 PAT 时,它会绑定到特定角色,有时间限制,并绑定到应用于该特定用户(账户级或用户级)的网络策略。

您可以复制 PAT 并将其用于旧版应用程序的密码字段中;对于此类旧版应用程序,您不需要使用 LEGACY_SERVICE 或仅密码身份验证。

小心

由于 SERVICE 类型的用户不能使用密码作为身份验证方法,因此对于不支持任何更强形式的身份验证的旧版系统,建议客户改用 PAT。

备注

请记住,LEGACY_SERVICE 将在 2025 年 11 月弃用。

在账户级应用密码和会话策略

Snowflake 安全管理员应在账户级应用基线密码和会话策略,然后根据需要使用用户级别策略替换这些策略。

ALTER ACCOUNT SET
SESSION POLICY = SESSION_POLICY_ACCOUNT;
PASSWORD POLICY = PASSWORD_POLICY_ACCOUNT;
Copy

测试服务用户

在此暂存区,账户应用密码和会话策略;服务编程用户不受 MFA 限制;他们有自己的特定身份验证策略和网络策略,确保从可信来源建立连接并使用推荐的身份验证方法,例如 OAuth 或密钥对。

安全管理员应该测试一些服务用户,确保操作顺畅,并确认连接来自可信来源,并使用正确的身份验证方法。除 Trust Center 外,管理员还应使用 LOGIN_HISTORY,确认服务用户受到网络策略的保护。

SELECT *
  FROM TABLE(INFORMATION_SCHEMA.LOGIN_HISTORY(TIME_RANGE_START =>
    DATEADD('HOURS',-1,CURRENT_TIMESTAMP()),CURRENT_TIMESTAMP()))
  ORDER BY EVENT_TIMESTAMP;
Copy

通过 MFA 强制执行保护账户

要对所有非 SERVICE 类型的用户强制执行 MFA,请在账户级应用 MFA 强制执行策略。

这些策略有助于确保所有人类交互用户从自己的 IdP 或原生 Snowflake MFA 启用 MFA。

ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;
Copy

如果要对高权限用户(如账户管理员)强制执行双重 MFA,请在此用户级别强制执行 MFA。但是,您需要在防止 IdP 下降的紧急程序和安全需求之间取得平衡。

ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;
Copy

对于紧急情况:

ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;
Copy

应用账户级网络策略

最后,在账户级应用网络策略,保护没有明确网络策略的所有其他用户。

ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;
Copy

禁用未使用的用户

Trust Center CIS 扫描器 (1.8) 将监控在过去 90 天内没有活动的用户。如下图所示,您可以点击 Open a Worksheet 以显示查询,列出非活动用户:

SELECT
  F.VALUE:ENTITY_ID::VARCHAR AS ENTITY_ID,
  F.VALUE:ENTITY_NAME::VARCHAR AS ENTITY_NAME,
  F.VALUE:ENTITY_OBJECT_TYPE::VARCHAR AS ENTITY_OBJECT_TYPE,
  F.VALUE:ENTITY_DETAIL AS ENTITY_DETAIL
FROM
  SNOWFLAKE.TRUST_CENTER.FINDINGS,
  LATERAL FLATTEN(INPUT => AT_RISK_ENTITIES) AS F;
Copy

Snowflake 强烈建议您禁用这些用户。

阶段 4:持续监控

利用 Trust Center 威胁智能扫描器包,监控 MFA 和网络策略强制执行情况。通过泄露密码保护功能,Snowflake 将监控暗网中被盗的凭据,并禁用其密码哈希值与暗网中找到的密码哈希值匹配的任何用户。您还可以利用 Snowflake 原生警报以及自定义查询,为以下对象构建额外的卫生警报:

  • 未专门设置类型的用户

  • 具有静态凭据(如密码或密钥对)的应用程序

  • 添加了 LEGACY_SERVICE 的新用户

  • 定期了解旧版应用程序,以升级到更强大的授权

语言: 中文