Visão geral da autenticação do Snowflake¶

As seções a seguir descrevem os métodos de autenticação que os usuários e aplicativos podem usar para acessar o Snowflake. Elas também fornecem considerações importantes para ajudar você a selecionar o melhor método de autenticação para seu caso de uso.

Escolha da autenticação para Snowsight¶

O Snowsight é a interface de usuário para o Snowflake. Esta seção fornece uma visão geral dos métodos de autenticação que os usuários podem usar para fazer login no Snowsight, seguido por uma comparação dos métodos.

Nota

Quando você cria um objeto de usuário Snowflake para uma pessoa que se autentica no Snowsight, especifique TYPE = PERSON. Para obter mais informações sobre tipos de usuário, consulte Tipos de usuários.

SSO (logon único)

Com SSO para Snowsight, os usuários são autenticados com um provedor de identidade de terceiros (IdP) em vez de autenticar diretamente com o Snowflake. Quando um usuário acessa o Snowsight, a página de login inclui uma opção para autenticação com o IdP em vez de uma senha gerenciada pelo Snowflake. O IdP confirma a identidade do usuário e então envia uma Security Assertion Markup Language (SAML) para o Snowflake. Como o Snowflake e o IdP tiverem uma relação de confiança previamente estabelecida, o Snowflake aceita a declaração como prova da identidade do usuário e permite que o usuário acesse o Snowsight.

Algumas organizações utilizam a mesma IdP para fornecer uma experiência de SSO para todos os aplicativos da organização. Essas organizações podem simplesmente adicionar o Snowflake como um novo provedor de serviços (SP) para permitir que seus funcionários utilizem o IdP para acessar o Snowsight.

Senha e nome de usuário com autenticação multifator (MFA)

A autenticação de senha permite que os usuários acessem o Snowsight inserindo uma cadeia de caracteres que esteja em conformidade com os requisitos impostos por uma política de senhas. Para reforçar a segurança deste método de autenticação, o Snowflake requer MFA para todos os usuários de senhas. Com a MFA, o usuário digita uma senha e depois usa um segundo fator de autenticação para confirmar sua identidade. Por exemplo, um usuário pode usar uma chave de acesso armazenada em seu computador como o segundo fator de autenticação.

A tabela a seguir compara os métodos de autenticação que os usuários podem usar para fazer login no Snowsight:

Método	Vantagens	Desafios
Logon único . Opção preferida	Permite que uma organização gerencie centralmente a autenticação. Um usuário se autentica com o mesmo IdP para todos os aplicativos da organização, não apenas para Snowflake. Ideal para organizações que já utilizam um IdP para fornecer SSO para aplicativos.	Exige a configuração de um IdP de terceiros.
Senha com MFA	Implementação simples.	Se as senhas forem gerenciadas pelo Snowflake, uma organização deverá repetir a configuração da autenticação para todos os seus aplicativos.

Método

Vantagens

Desafios

Logon único . Opção preferida

Permite que uma organização gerencie centralmente a autenticação. Um usuário se autentica com o mesmo IdP para todos os aplicativos da organização, não apenas para Snowflake.

Ideal para organizações que já utilizam um IdP para fornecer SSO para aplicativos.

Exige a configuração de um IdP de terceiros.

Senha com MFA

Implementação simples.

Se as senhas forem gerenciadas pelo Snowflake, uma organização deverá repetir a configuração da autenticação para todos os seus aplicativos.

Visão geral dos métodos de autenticação para aplicativos¶

Neste tópico, aplicativo refere-se a qualquer coisa que acesse dados do Snowflake programaticamente, em vez de por meio da interface do usuário do Snowsight. Esta definição inclui aplicativos da web personalizados, aplicativos multilocatários de terceiros, aplicativos de desktop, scripts locais e cargas de trabalho na nuvem.

Ao discutir os métodos de autenticação disponíveis, este tópico distingue entre dois tipos de aplicativos:

Um aplicativo interativo que interage com uma pessoa e se autentica no Snowflake em nome dessa pessoa; por exemplo, uma business intelligence (BI) que interage com os analistas.

Um aplicativo de serviço para serviço que não interage com uma pessoa e possui um método de autenticação dedicado para o serviço; por exemplo, um pipeline CI/CD.

Federação de identidades de carga de trabalho (WIF)

A federação de identidades de carga de trabalho é uma forma de autenticação sem segredo, e é altamente segura porque aproveita credenciais de curta duração que já estão disponíveis para cargas de trabalho na nuvem. Isso elimina a necessidade de gerenciar e alternar os segredos.

Quando uma carga de trabalho está sendo executada em um provedor de nuvem como AWS EC2, VMs do Microsoft Azure ou VMs do Google Cloud, a federação de identidades de carga de trabalho permite que a carga de trabalho seja autenticada no Snowflake usando o mecanismo de identidade nativo do provedor de nuvem. Por exemplo, uma carga de trabalho executada no AWS EC2 pode obter um atestado (ou seja, uma prova de sua identidade) de uma função do AWS Identity and Access Management (IAM) que está associada à carga de trabalho. O driver da carga de trabalho obtém o atestado do mecanismo de identidade nativo e o envia ao Snowflake para autenticar a carga de trabalho.

A federação de identidade de carga de trabalho também permite que cargas de trabalho de terceiros, como o GitHub Actions e cargas de trabalho em execução no Kubernetes, se autentiquem com um provedor de identidade (IdP) compatível com o OpenID Connect, em um processo conhecido como federação OIDC. O Snowflake aceita tokens de ID gerados pelo IdP como prova da identidade da carga de trabalho.

Adequado para:

Aplicativos serviço a serviço

OAuth usando Snowflake como servidor de autorização (Snowflake OAuth)

O Snowflake OAuth fornece a segurança da Estrutura de autorização do OAuth 2.0. Com Snowflake OAuth, Snowflake é tanto o servidor de autorização que autentica um usuário Snowflake quanto o servidor de recursos que aceita um token de acesso do cliente para acessar os dados desse usuário. O Snowflake OAuth permite que o cliente use o tipo de concessão do código de autorização.

Como o Snowflake é o servidor de autorização, o usuário que está interagindo com o aplicativo usa a interface do usuário do Snowflake para autenticar. É possível configurar o Snowflake para autenticar o usuário com login único (SSO) ou uma senha. Para obter informações sobre as vantagens e desafios da autenticação com SSO e senha, consulte Escolha da autenticação para Snowsight.

Adequado para:

Aplicativos interativos

OAuth usando um servidor de autorização de terceiros (OAuth externo)

O OAuth externo também proporciona a segurança do OAuth 2.0, mas um IdP de terceiros, e não o Snowflake, atua como servidor de autorização. Um aplicativo obtém um token de acesso do IdP de terceiros, então usa o token para acessar o Snowflake como o recurso.

Um aplicativo serviço a serviço poderia usar o tipo de concessão de credenciais do cliente para acessar seus próprios dados do Snowflake. Um aplicativo interativo pode usar o tipo de concessão de código de autorização para acessar os dados do Snowflake de uma pessoa que está usando o aplicativo.

Adequado para:

Aplicativos interativos
Aplicativos serviço a serviço

Autenticação de pares de chaves

A autenticação do par de chaves depende de um par de chaves criptográficas: uma chave privada e uma chave pública. A chave privada é um segredo mantido pelo aplicativo, enquanto a chave pública está associada a um objeto de usuário do Snowflake. Durante a autenticação, o aplicativo envia uma prova de que possui a chave privada, e o Snowflake responde verificando se a chave privada corresponde à chave pública associada ao usuário do Snowflake. Esse método de autenticação elimina a necessidade de transmitir ou armazenar senhas, reduzindo o risco de desvio de credenciais.

Adequado para:

Aplicativos serviço a serviço

Embora não seja o caso de uso padrão, a autenticação de par de chaves também pode ser usada para aplicativos interativos.

Token de acesso programático (PATs)

Um PAT é uma credencial de tempo limitado que permite que os aplicativos sejam autenticados sem uma senha. Um PAT pode ser usado como um substituto para uma senha de fator único em cenários onde MFA ou métodos de autenticação mais seguros não funcionarão. Um PAT é mais forte que uma senha por ser uma credencial de curta duração, exige a implementação de medidas de segurança adicionais e pode ser atribuído a uma função específica de controle de acesso.

Adequado para:

Aplicativos interativos
Aplicativos serviço a serviço

Como escolher a autenticação para aplicativos interativos¶

Um aplicativo interativo é aquele que interage com uma pessoa e se autentica no Snowflake em nome dessa pessoa. A tabela a seguir fornece as vantagens e desafios associados aos métodos de autenticação que É possível usar para aplicativos interativos. Para obter uma visão geral desses métodos de autenticação, consulte Visão geral dos métodos de autenticação para aplicativos.

Nota

Quando você cria objetos de usuário do Snowflake para as pessoas que estão usando um aplicativo interativo, especifique TYPE = PERSON. Para obter mais informações sobre tipos de usuário, consulte Tipos de usuários.

Método	Vantagens	Desafios
Snowflake OAuth . Opção forte	Pode ser mais simples de implementar do que o OAuth externo. Aplicativos locais, como um script em execução em VS Code, pode usar uma implementação integrada do Snowflake OAuth, que proporciona a segurança do OAuth sem configuração administrativa. Saiba mais Evita limitações do driver. O usuário pode autorizar o acesso com logon único (SSO), o que permite usar os métodos de autenticação seguros de um IdP de terceiros.	Nenhum.
OAuth externo . Opção forte	Se o IdP oferecer suporte, a pessoa que usa o aplicativo pode usar uma forma sem segredo de autenticação. Ideal para organizações que já utilizam um IdP de terceiros como um servidor de autorização para seus aplicativos.	Exige experiência na configuração de um IdP de terceiros como um servidor de autorização.
Token de acesso programático (PAT)	Fácil substituição de senhas de fator único. Credenciais geradas pelo Snowflake, para que não possam ser reutilizadas fora do Snowflake. Pode ser delimitado para uma função de controle de acesso específica para limitar os danos se for comprometido. O Snowflake exige que você implemente medidas de segurança adicionais para mitigar os riscos do uso de segredos de longa duração. O programa de verificação de segredos do GitHub detecta automaticamente os PATs do Snowflake vazados em repositórios públicos, os desabilita e notifica os administradores do Snowflake.	Ao contrário do par de chaves, deve ser protegido tanto no cliente quanto no servidor. Ao contrário do par de chaves, o segredo deve ser enviado na solicitação ao Snowflake, aumentando a exposição. Se comprometido, qualquer pessoa com a propriedade do pode se passar pelo aplicativo. Os riscos de segurança associados a credenciais de longa duração devem ser mitigados com outras medidas de segurança, como uma estratégia robusta de armazenamento e rotação. Como as políticas de rede são necessárias, se você tiver um aplicativo na nuvem multilocatário, deverá fornecer a seus clientes seus endereços IP para que possam criar uma política de redes que permita esses intervalos de endereços. O campo de entrada que aceita PATs deve ter pelo menos 256 caracteres.
Par de chaves	Método de autenticação flexível. Credenciais sem senha que não são expostas em uma solicitação.	Normalmente não é usado para aplicativos interativos. Os riscos de segurança associados a credenciais de longa duração devem ser mitigados com outras medidas de segurança, como políticas de redes e uma estratégia robusta de armazenamento e rotação. Ao contrário dos tokens de acesso programático, o par de chaves não exige medidas adicionais, o que pode resultar em uma autenticação menos segura.

Como escolher a autenticação para aplicativos serviço a serviço¶

Um aplicativo serviço a serviço não interage com uma pessoa e tem um método de autenticação dedicado para o serviço. A tabela a seguir fornece as vantagens e desafios associados aos métodos de autenticação que É possível usar para aplicativos serviço a serviço. Para obter uma visão geral desses métodos de autenticação, consulte Visão geral dos métodos de autenticação para aplicativos.

Nota

Ao criar um objeto de usuário Snowflake para um aplicativo serviço a serviço, especifique TYPE = SERVICE. Para obter mais informações sobre tipos de usuário, consulte Tipos de usuários.

Método	Vantagens	Desafios
Federação de identidade de carga de trabalho . Opção preferida	Autenticação sem segredo. Os administradores não precisam proteger e alternar continuamente os IDs e segredos dos clientes.	Nenhum.
OAuth externo . Opção forte	Se o IdP oferecer suporte, o aplicativo poderá usar uma forma sem segredo de autenticação. Ideal para organizações que já utilizam um IdP de terceiros como um servidor de autorização para seus aplicativos.	Exige experiência na configuração de um IdP de terceiros como um servidor de autorização.
Par de chaves	Método de autenticação flexível. Credenciais sem senha que não são expostas em uma solicitação.	Os riscos de segurança associados a credenciais de longa duração devem ser mitigados com outras medidas de segurança, como políticas de redes e uma estratégia robusta de armazenamento e rotação. Ao contrário dos tokens de acesso programático, o par de chaves não exige medidas adicionais, o que pode resultar em uma autenticação menos segura.
Token de acesso programático (PAT)	Fácil substituição de senhas de fator único. Credenciais geradas pelo Snowflake, para que não possam ser reutilizadas fora do Snowflake. Pode ser delimitado para uma função de controle de acesso específica para limitar os danos se for comprometido. O Snowflake exige que você implemente medidas de segurança adicionais para mitigar os riscos do uso de segredos de longa duração. O programa de verificação de segredos do GitHub detecta automaticamente os PATs do Snowflake vazados em repositórios públicos, os desabilita e notifica os administradores do Snowflake.	Ao contrário do par de chaves, deve ser protegido tanto no cliente quanto no servidor. Ao contrário do par de chaves, o segredo deve ser enviado na solicitação ao Snowflake, aumentando a exposição. Se comprometido, qualquer pessoa com a propriedade do pode se passar pelo aplicativo. Os riscos de segurança associados a credenciais de longa duração devem ser mitigados com outras medidas de segurança, como uma estratégia robusta de armazenamento e rotação.