从单因素身份验证迁移的最佳实践¶
本部分为客户提供有关如何利用 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 时,会发生以下情况:
网络和身份验证策略:一般准则¶
在任何情况下都要考虑以下准则。有关更多信息,请参阅 阶段 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 建议按照以下四个步骤迁移到更强的身份验证机制:
检测风险用户。
规划您的迁移以更大限度地减少中断。
在 Snowflake 中保护您的用户。
持续监控风险用户。

阶段 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);
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
;
风险服务用户列表¶
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
;
跨 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
;
阶段 2:迁移规划¶
迁移规划从 阶段 1:检测 开始。在识别出有风险的用户之后,开始计划遵循 网络和身份验证策略:一般准则。您应该尽可能放弃静态凭据(如密码和密钥对),并利用单点登录(联合身份验证),例如适用于交互式用户的 SAML,以及同时适用于编程 (SERVICE) 和交互式 (PERSON) 用户的 OAuth。
如果您被迫使用静态凭据(密钥对或密码)来支持某些旧版应用程序,请在规划时考虑以下事项:
尽可能利用网络策略。
根据组织的策略轮换这些静态凭据。
迁移注意事项¶
以下是在规划迁移时需要牢记的几个注意事项:
第二,检查您的应用程序支持哪些身份验证方法: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 账户被盗的风险:
设置用户类型¶
保护阶段的第一步是通过 SCIM 自动设置用户类型或手动设置:
ALTER USER svc_user1 SET TYPE = SERVICE;
ALTER USER user1@example.COM SET TYPE = PERSON;
-- LEGACY APPLICATION ONLY
此外,您现在可以在创建账户时设置管理员用户类型:
CREATE ACCOUNT <name> [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ];
小技巧
许多客户的服务用户名通常有一些模式(如 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;
客户仍然可以使用密钥对对 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';
如果客户 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';
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';
创建密码策略¶
如果您有旧版系统或必须使用 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>';
创建会话策略¶
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>';
为服务用户创建网络策略¶
一般来说,服务或编程访问用户应该来自授权的 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' )
;
在账户级别创建网络策略¶
对于没有直接应用网络策略的用户,账户级策略将作为默认安全网络策略。最佳实践是在使用用户级策略来处理特定用户需求时,尽可能保持这些策略的限制性和简短性。
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' )
;
保护服务用户¶
具有 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;
旧版应用程序的服务用户¶
如果您有不支持 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;
测试服务用户¶
在此暂存区,账户应用密码和会话策略;服务编程用户不受 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;
通过 MFA 强制执行保护账户¶
要对所有非 SERVICE 类型的用户强制执行 MFA,请在账户级应用 MFA 强制执行策略。
这些策略有助于确保所有人类交互用户从自己的 IdP 或原生 Snowflake MFA 启用 MFA。
ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;
如果要对高权限用户(如账户管理员)强制执行双重 MFA,请在此用户级别强制执行 MFA。但是,您需要在防止 IdP 下降的紧急程序和安全需求之间取得平衡。
ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;
对于紧急情况:
ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;
应用账户级网络策略¶
最后,在账户级应用网络策略,保护没有明确网络策略的所有其他用户。
ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;
禁用未使用的用户¶
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;
Snowflake 强烈建议您禁用这些用户。
阶段 4:持续监控¶
利用 Trust Center 威胁智能扫描器包,监控 MFA 和网络策略强制执行情况。通过泄露密码保护功能,Snowflake 将监控暗网中被盗的凭据,并禁用其密码哈希值与暗网中找到的密码哈希值匹配的任何用户。您还可以利用 Snowflake 原生警报以及自定义查询,为以下对象构建额外的卫生警报:
未专门设置类型的用户
具有静态凭据(如密码或密钥对)的应用程序
添加了 LEGACY_SERVICE 的新用户
定期了解旧版应用程序,以升级到更强大的授权