Utiliser OAuth 2.0 avec Snowflake

Utiliser OAuth 2.0 avec Snowflake


La prise en charge d’OAuth 2.0 est une fonctionnalité disponible pour tous les comptes à tous les niveaux de service. Cet article de blog est spécifique à OAuth flocon de neigeoù Snowflake est le service d’autorisation contre OAuth externeoù le client fournit le service d’autorisation.

Qu’est-ce qu’OAuth 2.0 ?

OAuth 2.0 est un protocole standard de l’industrie pour sécuriser l’autorisation des API Web. Il s’agit d’un mécanisme permettant aux utilisateurs d’accorder à des services Web, à des tiers ou à des applications (par exemple un outil de BI) l’accès à leurs données. Étant donné que Snowflake est un service Web basé sur le cloud, il utilise des protocoles Internet à la fois pour la communication réseau et la sécurité. OAuth est un choix naturel pour ces services et permet la prise en charge des contrôles d’accès centrés sur l’utilisateur et des options de persistance des jetons, que l’utilisateur soit présent ou qu’une connexion soit établie en arrière-plan au nom de l’utilisateur.

Avant la prise en charge d’OAuth dans Snowflake, les services et applications tiers devaient stocker les informations d’identification des utilisateurs afin d’accéder à Snowflake au nom d’un utilisateur. Cette exigence entraînait souvent des scénarios dans lesquels les clients configuraient des applications avec un utilisateur générique, partagé ou système, puis accordaient des rôles et des ressources à cet utilisateur. Ce processus a entraîné une sécurité affaiblie à la fois du point de vue des informations d’identification et du contrôle d’accès basé sur les rôles (RBAC), car les droits de l’utilisateur générique régissaient l’accès aux données. De plus, il était difficile d’auditer avec précision l’activité, car toutes les activités étaient liées à cet utilisateur unique.

Avec OAuth tel qu’implémenté par Snowflake, un client n’a plus besoin de connaître ou de stocker les informations d’identification de la base de données car un jeton est utilisé pour tous les processus et actions qui accèdent à Snowflake. Les jetons d’accès sont émis liés à un utilisateur et les jetons sont fixés à un rôle qui a ressources et privilèges lui a été accordé. Les administrateurs peuvent afficher ces autorisations et en révoquer l’accès à tout moment, coupant ainsi l’accès immédiatement sans rien changer de spécifique à l’utilisateur dans Snowflake.

Implémentation OAuth 2.0 de Snowflake

Bien que la spécification OAuth 2.0 décrive quelques flux de protocole, Snowflake implémente uniquement la Code d’autorisation flux, qui est principalement destiné aux applications ou services de serveur à serveur. À un niveau élevé, le flux de code d’autorisation OAuth 2.0 spécifie que le client (par exemple, un outil de BI) demandant l’accès aux ressources (par exemple, Snowflake Table) peut diriger les utilisateurs vers un point de terminaison d’autorisation (Snowflake Authorization Server). Après s’être authentifié via un nom d’utilisateur et un mot de passe ou via une authentification fédérée, l’utilisateur autorise l’accès aux ressources spécifiées. Le client fournit ensuite un point de terminaison connu sous le nom d’URI de redirection vers lequel les utilisateurs sont dirigés après autorisation. Le client reçoit alors un code d’autorisation de courte durée qui peut être échangé contre un jeton d’accès et, éventuellement, un jeton d’actualisation en faisant une demande à un point de terminaison de jeton. Un jeton d’actualisation peut être utilisé pour obtenir des jetons d’accès supplémentaires afin de faciliter l’accès à long terme et hors ligne.

Configuration d’une intégration de sécurité OAuth 2.0

Pour commencer à utiliser OAuth, un administrateur doit d’abord configurer un OAuth intégration de la sécurité. Les intégrations sont un nouveau type d’objet au niveau du compte dans Snowflake que les administrateurs peuvent utiliser pour étendre les fonctionnalités entre Snowflake et d’autres systèmes. Seul le rôle ACCOUNTADMIN peut créer et gérer des intégrations. Un administrateur doit donc assumer ce rôle lors de la création d’une intégration de sécurité pour OAuth.

Un administrateur peut configurer les intégrations de sécurité OAuth avec un nombre d’optionspar exemple s’il faut émettre des jetons d’actualisation, la durée de vie des jetons d’actualisation, quels rôles ne peuvent pas être autorisés, liste blanche IP via politiques de réseau pour limiter les adresses IP qui peuvent effectuer des demandes de jeton, et Prise en charge de la clé de preuve pour l’échange de code (PKCE). Au minimum, l’administrateur doit configurer l’intégration de la sécurité OAuth avec les éléments suivants :

  • L’URI de redirection, qui est l’URI vers lequel Snowflake redirige l’utilisateur après avoir effectué l’autorisation avec un code d’autorisation de courte durée.
  • Le type de client. Snowflake prend en charge les deux clients confidentiels et publics. Les clients confidentiels sont ceux qui gardent des secrets, alors que les clients publics ne le peuvent pas. Chaque type de client a un comportement différent en ce qui concerne les autorisations ; la principale différence est que les clients confidentiels n’invitent pas l’utilisateur à autoriser un rôle s’il existe une autorisation précédente, alors qu’un client public demandera toujours une autorisation.

La commande permettant de créer une intégration de sécurité OAuth simple ressemble à ceci :

CREATE SECURITY INTEGRATION my_oauth_integration

    TYPE=OAUTH

    OAUTH_CLIENT= OAUTH_CUSTOM

    OAUTH_REDIRECT_URI=’https://myredirecturi.com/oauth_callback’

    OAUTH_CLIENT_TYPE=’CONFIDENTIAL’

    ENABLED=true;

Dans cet exemple, la commande ci-dessus crée une intégration de sécurité OAuth active, qui est destinée à être un client confidentiel, avec l’URI de redirection « https://mydirecturi.com/oauth_callback. L’option ENABLED indique qu’il s’agit d’une intégration active ; l’administrateur peut désactiver l’intégration à tout moment en la définissant sur FALSE, comme suit :

ALTER SECURITY INTEGRATION my_oauth_integration SET ENABLED=FALSE;

Configuration de l’application ou du service client

Une fois qu’un administrateur a créé l’intégration de sécurité, en tant qu’utilisateur ACCOUNTADMIN, l’administrateur doit configurer l’application ou le service client avec l’ID client et le ou les secrets client liés à cette intégration de sécurité.

L’administrateur peut trouver l’ID client en décrivant l’intégrationc’est-à-dire en utilisant le INTÉGRATION DE LA SÉCURITÉ DESC commande. L’administrateur peut trouver les secrets du client en utilisant la fonction système SHOW_OAUTH_CLIENT_SECRETS. Cette fonction révèle deux secrets client, ainsi que l’ID client à nouveau à des fins de vérification.

La fonction fournit deux secrets client afin que l’application ou le service en cours de configuration puisse effectuer une rotation des secrets client sans aucun temps d’arrêt. Bien que Snowflake n’applique pas la rotation des secrets client ou ne fasse pas pivoter automatiquement les secrets client, la rotation périodique de ces secrets est une bonne pratique.

Pour effectuer la rotation d’un secret client, l’administrateur peut utiliser le INTÉGRATION ALTER SECURITY langage de définition de données (DDL) :

ALTER SECURITY INTEGRATION my_oauth_integration REFRESH OAUTH_CLIENT_SECRET;

ALTER SECURITY INTEGRATION my_oauth_integration REFRESH OAUTH_CLIENT_SECRET_2;

Spécification de paramètres supplémentaires

Une fois que l’administrateur a correctement configuré le client, le client peut commencer à diriger les utilisateurs vers l’URL d’autorisation de l’intégration de sécurité afin que les autorisations puissent être obtenues après qu’un utilisateur a autorisé avec succès le client avec Snowflake. Pour plus de commodité, la sortie de DESC SECURITY INTEGRATION fournit cette URL, mais l’URL doit être modifiée pour contenir le paramètres suivants:

  • identité du client: ID client avec lequel le client a été configuré.
  • type_réponse: Le type de réponse attendu. Étant donné que Snowflake ne prend en charge que le flux de code d’autorisation, cela devoir être prêt à code.
  • redirect_uri: L’URI vers lequel l’utilisateur doit être dirigé après avoir autorisé le client avec succès. Il doit s’agir du même URI avec lequel l’administrateur a configuré l’intégration.

De plus, Snowflake recommande fortement les paramètres facultatifs suivants :

  • Etat: Une chaîne ne dépassant pas 2 048 caractères ASCII, qui est destinée à être utilisée pour empêcher les attaques de falsification de requête intersite (CSRF).
  • code_challenge: Si l’administrateur a activé PCCE pour l’intégration de la sécurité, c’est le défi pour PKCE.
  • code_challenge_method: Si l’administrateur a activé PKCE pour l’intégration de la sécurité, il s’agit d’une chaîne indiquant la méthode utilisée pour dériver le test de code.
  • portée: chaîne utilisée pour limiter les opérations et le rôle autorisés par le jeton d’accès émis.

La portée paramètre permet au client de demander un rôle, qui contrôle l’accès à un ensemble de ressources dans Snowflake, ainsi que de spécifier si un jeton d’actualisation doit être émis afin que le client puisse effectuer des opérations hors ligne au nom de l’utilisateur pour ce rôle.

Si aucun rôle n’est spécifié dans le portée paramètre, le rôle par défaut de l’utilisateur sera utilisé par l’application ou le service lorsqu’il se connecte au compte Snowflake de l’utilisateur. Si un rôle par défaut n’existe pas, le Rôle PUBLIC, auquel chaque utilisateur a accès, sera utilisé. Si le client demande un rôle auquel l’utilisateur n’a pas accès, aucun jeton ne sera émis et l’utilisateur ne pourra pas établir de connexion à son compte Snowflake.

Si la portée du jeton d’actualisation n’est pas demandée, seul un jeton d’accès est émis, ce qui est idéal pour les clients initialisant une session Snowflake dans laquelle l’utilisateur est présent.

Par exemple, une fois que l’utilisateur s’est authentifié avec succès, si le client demandeur souhaite accéder au rôle PUBLIC et souhaite que des jetons d’actualisation soient émis, l’utilisateur voit une page d’autorisation semblable à la suivante :

image1 1

Après que l’utilisateur a autorisé l’application ou le service

Une fois que l’utilisateur a autorisé l’application ou le service, Snowflake renvoie un code d’autorisation ainsi que l’état fourni par l’application ou le service (s’il a choisi de le faire) à l’URI de redirection de l’intégration de sécurité. Le client se charge ensuite d’échanger ce code d’autorisation avec le serveur de ressources Snowflake en adressant une requête au point de terminaison de jeton contenant le code, et en réponse le client reçoit un jeton d’accès et, éventuellement, un jeton d’actualisation.

Le jeton d’accès peut ensuite être transmis à l’un des chauffeurs clients en utilisant l’authentificateur OAuth. Actuellement, la prise en charge du pilote client est limitée à JDBC, ODBC, Python et Go. Le pilote client crée alors une session qui est fixée à l’utilisateur et au rôle qui a été autorisé. Le rôle ne peut pas être modifié par l’application ou le service après l’établissement d’une connexion, et toute tentative d’établissement d’une connexion avec un rôle autre que celui autorisé entraînera une erreur. Une fois la session de base de données créée, vous pouvez voir via le Affichage de l’historique de connexion qu’une session a été créée via OAuth, ce qui permet une plus grande auditabilité.

Vous pouvez afficher les autorisations qui ont été émises pour différents utilisateurs et rôles à l’aide de la AFFICHER LES AUTORISATIONS DÉLÉGUÉES DDL. Ce DDL peut être subdivisé par intégrations et utilisateurs, ce qui permet de savoir quels utilisateurs autorisent quels rôles. L’administrateur peut révoquer les autorisations à tout moment via le MODIFIER L’UTILISATEUR Commandes DDL. Cela empêchera la création de nouvelles sessions avec des jetons d’accès et d’actualisation en attente ; le client doit ensuite diriger l’utilisateur via le flux d’autorisation pour obtenir de nouveaux jetons. Les administrateurs peuvent également désactiver une intégration ou l’abandonner complètement.

Sommaire

OAuth 2.0 est une fonctionnalité de sécurité puissante avec un certain nombre d’avantages, notamment permettre à un client d’accéder à Snowflake au nom d’un utilisateur sans transmettre d’informations d’identification utilisateur explicites, appliquer des contrôles d’accès précis spécifiques à cet utilisateur et à ce rôle, une auditabilité complète des actions du client et permettant un accès à long terme par le client pour agir au nom de l’utilisateur tout en donnant aux administrateurs un aperçu clair de la façon dont les autorisations sont utilisées. Cette fonctionnalité peut être utilisée dans un certain nombre de scénarios et permet aux applications cloud natives de s’intégrer de manière plus transparente à Snowflake.

Remerciements

Un certain nombre de personnes ont contribué au projet OAuth. Plus précisément, nous tenons à remercier Jason Benterou, Johnston Chu, Vikas Jain, Gillian Maducdoc, Peter Provinec et Qin Yang pour leurs innombrables contributions et conseils pour ce projet.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.