Vue d’ensemble de l’authentification Snowflake¶

Choix de l’authentification pour Snowsight¶

Snowsight est l’interface utilisateur de Snowflake. Cette section donne un aperçu des méthodes d’authentification que les utilisateurs peuvent utiliser pour se connecter à Snowsight, suivi d’une comparaison des méthodes.

Connexion unique (SSO)

Avec la SSO pour Snowsight, les utilisateurs s’authentifient auprès d’un fournisseur d’identité tiers (IdP) plutôt que de s’authentifier directement auprès de Snowflake. Lorsqu’un utilisateur accède à Snowsight, la page de connexion comprend une option pour s’authentifier auprès du IdP au lieu d’un mot de passe géré par Snowflake. Le IdP confirme l’identité de l’utilisateur, puis envoie un Security Assertion Markup Language (SAML) vers Snowflake. Parce que Snowflake et le IdP ont une relation de confiance préalablement établie, Snowflake accepte l’assertion comme preuve de l’identité de l’utilisateur et permet à l’utilisateur d’accéder à Snowsight.

Certaines organisations utilisent le même IdP pour fournir une expérience SSO pour toutes les applications de l’organisation. Ces organisations peuvent simplement ajouter Snowflake comme nouveau fournisseur de services (SP) pour permettre à ses employés d’utiliser le IdP pour accéder à Snowsight.

Nom d’utilisateur et mot de passe avec authentification multifactorielle (MFA)

L’authentification par mot de passe permet aux utilisateurs d’accéder à Snowsight en saisissant une chaîne de caractères conforme aux exigences appliquées par une politique de mot de passe. Pour renforcer la sécurité de cette méthode d’authentification, Snowflake nécessite la MFA pour tous les utilisateurs de mots de passe. Avec la MFA, l’utilisateur saisit un mot de passe, puis utilise un deuxième facteur d’authentification pour confirmer son identité. Par exemple, un utilisateur peut utiliser une clé d’accès stockée sur son ordinateur comme deuxième facteur d’authentification.

Le tableau suivant compare les méthodes d’authentification que les utilisateurs peuvent utiliser pour se connecter à Snowsight :

Aperçu des méthodes d’authentification pour les applications¶

Dans ce chapitre, le terme application fait référence à tout ce qui accède aux données Snowflake de manière programmatique plutôt que via l’interface utilisateur Snowsight. Cette définition comprend les applications Web personnalisées, les applications multi-locataires tierces, les applications pour bureau, les scripts locaux et les charges de travail dans le Cloud.

Lorsque l’on examine les méthodes d’authentification disponibles, cette rubrique fait la distinction entre deux types d’applications :

• Une application interactive qui interagit avec une personne et s’authentifie auprès de Snowflake au nom de cette personne ; par exemple, un outil de Business Intelligence (BI) qui interagit avec les analystes.

• Une application de service à service qui n’interagit pas avec une personne et qui possède une méthode d’authentification dédiée au service ; par exemple, un pipeline CI/CD.

Fédération d’identité de charge de travail (WIF)

La fédération d’identité de charge de travail est une forme d’authentification sans secret et est hautement sécurisée car elle exploite les identifiants à courte durée de vie qui sont déjà disponibles pour les charges de travail Cloud. Cela élimine le besoin de gérer et de faire pivoter les secrets.

Lorsqu’une charge de travail s’exécute sur un fournisseur Cloud comme AWS EC2, les VMs Microsoft Azure, ou les VMs Google Cloud, la fédération d’identité de charge de travail permet à la charge de travail de s’authentifier auprès de Snowflake en utilisant le mécanisme d’identité natif du fournisseur Cloud. Par exemple, une charge de travail s’exécutant sur AWS EC2 peut obtenir une attestation, c’est-à-dire une preuve de son identité, auprès d’un rôle de Gestion des identités et des accès (IAM) AWS associé à la charge de travail. Le pilote de la charge de travail obtient l’attestation auprès du mécanisme d’identité natif, puis l’envoie à Snowflake pour authentifier la charge de travail.

La fédération d’identité de charge de travail permet également des charges de travail tierces telles que les actions GitHub et les charges de travail s’exécutant dans Kubernetes de s’authentifier auprès d’un fournisseur d’identité (IdP) prenant en charge OpenID Connect, dans un processus appelé fédération OIDC. Snowflake accepte les jetons ID générés par le IdP comme preuve de l’identité de la charge de travail.

Adapté pour :

• Les applications de service à service

OAuth utilisant Snowflake comme serveur d’autorisation (Snowflake OAuth)

Snowflake OAuth assure la sécurité du OAuth Authorization Framework 2.0. Avec Snowflake OAuth, Snowflake est à la fois le serveur d’autorisation qui authentifie un utilisateur Snowflake et le serveur de ressources qui accepte un jeton d’accès du client pour accéder aux données de cet utilisateur. Snowflake OAuth permet au client d’utiliser le type d’accord de code d’autorisation.

Comme Snowflake est le serveur d’autorisation, l’utilisateur qui interagit avec l’application utilise l’interface utilisateur de Snowflake pour s’authentifier. Vous pouvez configurer Snowflake pour authentifier l’utilisateur avec une authentification unique (SSO) ou un mot de passe. Pour plus d’informations sur les avantages et les inconvénients de la SSO et de l’authentification par mot de passe, voir Choix de l’authentification pour Snowsight.

Adapté pour :

• Applications interactives

OAuth utilisant un serveur d’autorisation tiers (External OAuth)

External OAuth offre également la sécurité de OAuth 2.0, mais un IdP tiers, et non Snowflake, agit en tant que serveur d’autorisation. Une application obtient un jeton d’accès du IdP tiers, puis utilise le jeton pour accéder à Snowflake en tant que ressource.

Une application de service à service pourrait utiliser le type d’accord d’informations de connexion du client pour accéder à ses propres données Snowflake. Une application interactive pourrait utiliser le type d’accord de code d’autorisation pour accéder aux données Snowflake d’une personne qui utilise l’application.

Adapté pour :

• Applications interactives

• Les applications de service à service

Authentification par paire de clés

L’authentification par paire de clés s’appuie sur une paire de clés cryptographiques : une clé privée et une clé publique. La clé privée est un secret détenu par l’application, tandis que la clé publique est associée à un objet utilisateur Snowflake. Lors de l’authentification, l’application envoie la preuve qu’elle possède la clé privée, et Snowflake répond en vérifiant que la clé privée correspond à la clé publique associée à l’utilisateur Snowflake. Cette méthode d’authentification élimine la nécessité de transmettre ou de stocker des mots de passe, réduisant ainsi le risque de vol d’identifiants.

Adapté pour :

• Les applications de service à service

Bien que cela ne soit pas le cas d’utilisation standard, l’authentification par paire de clés peut également être utilisée pour les applications interactives.

Jeton d’accès programmatiques (PATs)

Un PAT est un identifiant limité dans le temps qui permet aux applications de s’authentifier sans mot de passe. Un PAT peut être utilisé comme remplacement direct d’un mot de passe à facteur unique dans les scénarios où la MFA ou les méthodes d’authentification plus sécurisées ne fonctionneront pas. Un PAT est plus sûr qu’un mot de passe, car il s’agit d’un identifiant de courte durée, qui nécessite que vous mettiez en œuvre des mesures de sécurité supplémentaires et qui peut être limité à un rôle de contrôle d’accès spécifique.

Adapté pour :

• Applications interactives

• Les applications de service à service

Choix de l’authentification pour les applications interactives¶

Une application interactive est une application qui interagit avec une personne et s’authentifie auprès de Snowflake au nom de cette personne. Le tableau suivant présente les avantages et les inconvénients associés aux méthodes d’authentification que vous pouvez utiliser pour les applications interactives. Pour un aperçu de ces méthodes d’authentification, voir Aperçu des méthodes d’authentification pour les applications.

Choix de l’authentification pour les applications de service à service¶

Une application de service à service n’interagit pas avec une personne et possède une méthode d’authentification dédiée pour le service. Le tableau suivant présente les avantages et les inconvénients associés aux méthodes d’authentification que vous pouvez utiliser pour les applications de service à service. Pour un aperçu de ces méthodes d’authentification, voir Aperçu des méthodes d’authentification pour les applications.