Práticas recomendadas para migração da autenticação de fator único¶

Amostras de consultas para listas de usuários de risco¶

A Snowflake adicionou recentemente dois novos verificadores: um para usuários pessoais e outro para usuários de serviços. Isso permite que os clientes tenham listas separadas de usuários que usam o logon por senha de fator único, dependendo do tipo de usuário.

Você pode retornar uma lista de usuários de risco para cada tipo.

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
;

Distribuição de usuários no TYPE e método de autenticação usado¶

Além da consulta anterior, é útil listar a distribuição de usuários entre os tipos de usuários e os métodos de autenticação usados. Isso ajuda os clientes a criar estratégias de migração de usuários para os métodos de autenticação mais fortes, como SAML e OAuth. Por exemplo, se um usuário estiver sendo exibido como arriscado (porque tem uma senha no Snowflake), mas esse usuário estiver usando apenas a autenticação SAML, é aconselhável remover essa senha do Snowflake o mais rápido possível.

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
;

Considerações sobre a migração¶

Aqui estão algumas considerações que você deve ter em mente ao planejar sua migração:

• Primeiro, defina os tipos de usuário (isso pode ser automatizado via SCIM).

• Em segundo lugar, verifique quais métodos de autenticação são compatíveis com seus aplicativos; o Snowflake oferece suporte a uma variedade de métodos de autenticação, como OAuth, SAML, par de chaves, MFA e assim por diante. No entanto, o aplicativo que se conecta ao Snowflake também precisa oferecer suporte a métodos de autenticação fortes. Há dois casos de uso:

  • O aplicativo já é compatível com SAML e/ou OAuth. Incentivados você a migrar para essa autenticação o mais rápido possível.

  • O aplicativo é antigo e não oferece suporte a métodos de autenticação fortes, como SAML ou OAuth; ele apenas oferece suporte a senhas. Nesse caso, você é aconselhado a atualizar seu aplicativo legado. Enquanto isso, você pode aproveitar as políticas de rede, a rotação de senhas e os recursos de proteção de senhas vazadas até atualizar o aplicativo.

• Em seguida, os clientes devem considerar o seguinte para usuários locais (criados manualmente no Snowflake que não estejam habilitados para SAML ou OAuth):

  • Para um aplicativo compatível com SSO, troque o usuário local por usuários habilitados para SSO e considere o tempo de inatividade ao trocar de usuário.

  • Para alternar os usuários locais para SSO, certifique-se de que esses usuários existam em seu IdP e, em seguida, sejam provisionados no Snowflake manualmente ou, de preferência, automaticamente, por meio do SCIM.

  • Desative usuários locais não utilizados.

• O Snowflake oferece suporte a políticas de autenticação, políticas de rede e políticas de senha tanto no nível do usuário quanto no nível da conta. Considere primeiro as políticas no nível do usuário para migrar gradualmente (as políticas no nível do usuário têm prioridade sobre as políticas no nível da conta):

  • A Snowflake recomenda políticas de rede no nível de usuário para aplicativos que usam usuários de serviço (TYPE = SERVICE ou LEGACY_SERVICE).

  • Para usuários humanos (TYPE = PERSON ou NULL), é possível começar com políticas de rede no nível do usuário e, em seguida, aplicar políticas de rede no nível da conta para proteger todas as populações de usuários que não têm políticas específicas no nível do usuário.

  • O mesmo conceito com as políticas de MFA começa primeiro com as políticas em nível de usuário.

• Se você tiver um aplicativo legado que não ofereça suporte ao login único, a Snowflake recomenda aproveitar os tokens de acesso programático (PATs), que, por padrão, estão vinculados a funções específicas, exigem uma política de redes e têm prazo determinado.

Defina o tipo de usuário¶

A primeira etapa da fase de proteção é definir os tipos de usuário automaticamente pelo SCIM ou manualmente:

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

Além disso, agora é possível definir o tipo de usuário administrador quando ele cria uma conta:

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

Remova as senhas locais quando elas não forem necessárias¶

Utilize as consultas em Distribuição de usuários em TYPE e Método AuthN usado e Lista de usuários de risco, com base nas descobertas do Trust Center, para começar a limpar qualquer senha no Snowflake para um usuário que já esteja usando SAML, OAuth ou par de chaves exclusivamente.

Crie políticas de autenticação para usuários do serviço¶

A Snowflake recomenda o uso de OAuth para usuários de serviços programáticos, e você pode aplicar isso com políticas de autenticação:

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;

Os clientes ainda podem usar o par de chaves para autenticação com usuários SERVICE, mas devem combinar isso com as políticas de rede e alternar regularmente suas chaves.

Crie políticas de autenticação para aplicar MFA em usuários humanos¶

A Snowflake recomenda que os clientes usem seus próprios provedores de identidade SAML (IdPs) com qualquer solução de MFA compatível com IdP. O exemplo de política de autenticação a seguir ajuda os clientes a:

• Aplicar a MFA nativa do Snowflake a todos os usuários humanos que usam senhas nativas do Snowflake.

• Confiar no IdP de SAML cliente para aplicar MFA a usuários de login único.

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';

Os clientes devem considerar uma situação de emergência caso o IdP cliente esteja offline para que seus administradores de conta ainda possam fazer login em suas contas Snowflake.

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

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';

Criação da política de senhas¶

Caso você tenha um sistema legado ou uma situação de emergência em que precise usar senhas nativas do Snowflake, aproveite as políticas de senhas do Snowflake para corresponder às políticas de senha da organização, se elas forem diferentes das políticas padrão.

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>';

Criar política de sessão¶

A Snowflake recomenda que você crie políticas de sessão para aplicar a reautenticação após um período específico de inatividade. Este é apenas um exemplo; você pode personalizar as políticas no nível do usuário individual.

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>';

Crie políticas de rede para usuários de serviços¶

Em geral, os usuários de serviço ou de acesso programático devem vir de endereços IP autorizados (ou VPCE ID, LinkID e assim por diante, no caso de conectividade privada).

A Snowflake recomenda a criação de políticas de rede no nível do usuário do serviço para restringir o acesso a esses usuários de acesso programático de fontes autorizadas e confiáveis. Os clientes devem considerar a aplicação de regras de rede também nos estágios internos.

As conexões podem vir de redes privadas ou públicas, dependendo se o cliente está usando conectividade privada ou não. Lembre-se de que você pode permitir conectividade pública e privada ao mesmo tempo adicionando várias regras de rede que incluam as tags relevantes IPs (públicos ou privados) e/ou CSP (como VPCE ID e 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' )
;

Crie políticas de rede no nível da conta¶

As políticas no nível da conta funcionam como políticas de rede de segurança padrão para usuários que não têm políticas de rede aplicadas diretamente a eles. A prática recomendada é manter essas políticas tão restritivas e curtas quanto possível e, ao mesmo tempo, usar políticas no nível do usuário para atender às necessidades específicas do usuário.

A Snowflake não recomenda a criação de políticas de rede enormes no nível da conta para satisfazer todas as necessidades da organização; em vez disso, habilite políticas no nível do usuário para ter controles mais granulares.

Semelhante às políticas de rede no nível do usuário, as conexões podem vir de redes privadas ou públicas, dependendo de o cliente estar usando conectividade privada. Lembre-se de que você pode permitir conectividade pública e privada ao mesmo tempo adicionando várias regras de rede que incluam as tags relevantes IPs (públicos ou privados) e/ou CSP (como VPCE ID e 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' )
;

Proteja os usuários do serviço¶

Os usuários com TYPE=SERVICE estão isentos das políticas de aplicação de MFA no nível da conta e têm restrições para melhorar a postura de segurança de casos de uso não interativos. Notavelmente, os usuários do tipo SERVICE não podem fazer login usando uma senha ou SAML SSO. Veja a advertência abaixo.

-- 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;

Aplique as políticas de senha e sessão no nível da conta¶

O administrador de segurança Snowflake deve aplicar políticas básicas de senha e sessão no nível da conta e, em seguida, substituir essas políticas por políticas no nível do usuário, conforme necessário.

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

Teste os usuários do serviço¶

Nesse estágio, a conta tem políticas de senha e sessão aplicadas; os usuários programáticos do serviço estão isentos de MFA; e eles têm suas próprias políticas de autenticação específicas e políticas de rede que garantem que as conexões sejam estabelecidas a partir de fontes confiáveis e usem os métodos de autenticação recomendados, como OAuth ou par de chaves.

O administrador de segurança deve testar alguns usuários do serviço para garantir operações tranquilas e confirmar que as conexões são provenientes de fontes confiáveis e usam os métodos de autenticação adequados. Os administradores devem usar LOGIN_HISTORY, além do Trust Center, para confirmar que os usuários do serviço estão protegidos pelas políticas de rede.

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

Proteja a conta com a aplicação de MFA¶

Para aplicar MFA a todos os usuários que não sejam do tipo SERVICE, aplique a política de aplicação de MFA no nível da conta.

Essas políticas ajudam a garantir que todos os usuários interativos humanos habilitem a MFA a partir de seu próprio IdP ou da MFA nativa do Snowflake.

ALTER ACCOUNT SET
AUTHENTICATION POLICY = HUMAN_ACCESS_ACCOUNT_ENFORCE_MFA;

Se quiser aplicar MFA dupla aos seus usuários altamente privilegiados, como administradores de conta, imponha a MFA nesse nível de usuário. No entanto, você precisa encontrar um equilíbrio entre os procedimentos de acesso de emergência, caso o IdP esteja inoperante, e seus requisitos de segurança.

ALTER USER SUPER_PROTECTED_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_DOUBLE_MFA;

Para uma situação de emergência:

ALTER USER BREAKGLASS_ACCOUNTADMIN_1
AUTHENTICATION POLICY = ACCOUNTADMIN_BREAKGLASS_MFA;

Aplique políticas de rede no nível da conta¶

Por fim, é hora de aplicar políticas de rede no nível da conta para proteger todos os outros usuários que não têm políticas de rede explícitas.

ALTER ACCOUNT SET
NETWORK_POLICY = ACCOUNT_LEVEL_NET_POLICY;

Desative os usuários não utilizados¶

O verificador Trust Center CIS (1.8) monitorará os usuários que não estiveram ativos nos últimos 90 dias. Conforme mostrado no diagrama a seguir, você pode clicar em Open a Worksheet para mostrar a consulta que lista os usuários inativos:

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;

A Snowflake recomenda enfaticamente que você desabilite esses usuários.