Combler le déficit de gouvernance

Dans la pile de données moderne, Snowflake est une pépite. Cependant, à mesure que les entreprises se développent, la gestion des accès et, surtout, la révocation de ces accès, devient un enjeu majeur en matière de conformité. Si vous comptez uniquement sur les connecteurs SCIM prêts à l’emploi d’Okta, vous avez probablement constaté qu’ils ne couvrent qu’une partie de vos besoins. Ils peuvent créer un utilisateur, mais gèrent difficilement le cycle de vie complexe des rôles Snowflake et la récupération des licences.

Ce guide présente une architecture avancée « trois flux » utilisant Okta Identity Governance (OIG) et Okta Workflows (mis à jour en avril 2026) pour automatiser la « dernière étape » de l’administration Snowflake.

Le problème : pourquoi les connecteurs d’intégration Okta ne suffisent pas

L’intégration standard entre Okta et Snowflake porte généralement sur le provisioning des utilisateurs. Si cela permet de répondre à la question « Cette personne est-elle un utilisateur ? », elle présente deux lacunes majeures :

1. Gestion granulaire des rôles : l’accès à Snowflake est défini par des rôles (par exemple, SYSADMIN, DATA_ENGINEER). Les connecteurs standard ne déclenchent pas nativement de commandes SQL spécifiques à un rôle en réponse aux demandes d’accès d’OIG.
2. Nettoyage des droits d’accès : lorsqu’une demande OIG expire ou que l'accès d’un utilisateur à une application est révoqué, l’enregistrement de l’utilisateur persiste souvent dans Snowflake. Cela entraîne des comptes « zombies » qui consomment des licences et élargissent votre surface d’attaque.

La solution consiste à utiliser Okta Workflows comme moteur d’orchestration capable d’écouter les événements OIG et de communiquer dans le langage de Snowflake.

Guide de configuration des exigences

Avant d’aborder cette solution avec Okta OIG et Workflows, il est nécessaire d’apporter quelques modifications de configuration dans Snowflake, OIG et Slack afin d’utiliser le pack de workflows (Snowflake Delegated Flow, Unassigned Entitlements et User Unassigned Cleanup). Vous devez effectuer ces étapes de configuration spécifiques sur les quatre plateformes. Voici le guide complet pour configurer les exigences principales :

Exigences Snowflake

Snowflake sert de système cible pour la gestion des rôles et des utilisateurs.

1. Créer un rôle de provisionneur : créez un rôle dédié (par exemple, OKTA_PROVISIONER) qu’Okta utilisera pour effectuer des actions.

2. Configurer l’intégration SCIM : créez une intégration de sécurité SCIM pour permettre à Okta de communiquer avec Snowflake.

3. Générer un token SCIM : générez le token d’autorisation à coller dans Okta.

4. Politique réseau : veillez à ce que la politique réseau de Snowflake autorise le trafic entrant depuis les adresses IP d’Okta.

Exigences d’Okta (principales et workflows)

Okta est le fournisseur d’identité central et le moteur qui pilote l’automatisation.

Intégration SCIM de l’application Snowflake

1. Ajoutez l’application Snowflake depuis Okta Integration Network.
2. Dans l’onglet Provisioning, activez l’intégration API et collez le token SCIM Snowflake.
3. Activez les options Créer des utilisateurs, Mettre à jour les attributs utilisateur et Désactiver les utilisateurs.

Autorisation et importation du connecteur Workflows

Le cœur du système repose sur deux éléments principaux : Okta Access Requests et Okta Workflows. Okta Workflows sert à créer des fonctions métier spécifiques, telles que le provisioning manuel, l’envoi de notifications ou la création de tickets d’assistance. Ces workflows sont configurés en tant que flux délégués, qui peuvent être utilisés par Okta Access Requests. Suivez ces étapes pour activer ces workflows :

1. Autoriser l’accès

• Autorisez le connecteur Snowflake dans la console Workflows en utilisant le token d’accès dans l’application Snowflake. Cela nous aidera à effectuer des appels API vers l’application Snowflake.
• Connecteur Okta : vérifiez que la connexion est autorisée.

• Accordez le scope okta.governance.entitlements.manage à l’application Okta Workflows OAuth dans l'admin console Okta (Applications > App Okta Workflows OAuth).

2. Importer le pack de workflows

Remarque : pour terminer cette étape, vous devez télécharger ce fichier de pack de workflows.

Importez le pack de workflows joint dans Admin Console -> Workflows -> Flows : Snowflake Entitlement Management - Okta Workflows :

• Créez un nouveau dossier et nommez-le « Gestion des droits Snowflake », puis sélectionnez « Importer » dans le menu déroulant.

• Il existe trois workflows principaux : Snowflake Delegated Flow (Assignment), Unassign Entitlements et User Unassigned from Snowflake. Nous allons expliquer le rôle de chaque workflow dans la section suivante. 
  

  Activez ces connexions d’application dans chacun des trois flux (par exemple, la carte Snowflake dans le flux Unassign Entitlements).

3. Configurer un flux délégué

Pour utiliser le flux délégué Snowflake, vous devez d’abord activer Okta Workflows dans Access Requests. Cela permet, dès qu’une demande d’accès à l’application Snowflake est approuvée, au flux délégué Snowflake de déclencher une requête API afin d’attribuer les droits d’accès.

• Activez cette option dans Paramètres -> Fonctionnalité -> actions Okta Workflows dans Access Requests

• Créez un rôle personnalisé et une ressource afin d’autoriser Access Requests à consulter et exécuter les workflows disponibles.

• Créez un ensemble de ressources et attribuez-lui des Workflows.

• Revenez à l’ensemble de ressources délégué pour attribuer les autorisations d’admin.

• Sous Identity Governance, accédez à Access Requests → Paramètres → Ressources → Workflows pour vérifier que les workflows délégués sont activés pour être exécutés à partir des demandes d’accès. Si tout a été exécuté avec succès, vous verrez « workflows délégués » apparaître.

4. Créer un event hook

Configurez un event hook pour envoyer les données d’événement d’Okta vers l’API endpoint dans le flux délégué lorsqu’un événement OIG se produit :

• Accédez à l’onglet « Event Hooks » sous « Workflows » pour créer un nouvel Event Hook.

À présent, vérifiez que les journaux système détectent un événement OIG « updated user’s entitlements in a resource » et l’envoient à la carte API endpoint en renseignant l’URL d’invocation du workflow de suppression des droits dans le champ Endpoint URL, puis en sélectionnant cet événement dans l’event hook :

• Accédez au workflow « Unassign Entitlements » -> paramètres du point de terminaison.

• Copiez l’URL d’endpoint et collez-la dans le champ « Endpoint URL » du nouvel event hook.

• Dans l’event hook, sélectionnez « Updated user's entitlements in a resource ».

• Une fois l’event hook configuré, nous pourrons le tester dans l’onglet « Aperçu ».

Exigences relatives à Okta Identity Governance (OIG)

OIG fournit la couche de droits d'accès granulaires utilisée dans le flux de synchronisation.

1. Activez le moteur de gouvernance : veillez à ce que le moteur Okta Identity Governance soit activé pour votre organisation.
2. Activez la gestion des droits : accédez à l’application Snowflake dans Okta > onglet Governance et cliquez sur « activer la gestion des droits ». Avant d’activer ou de désactiver la gestion des droits, vous devez d’abord désactiver le provisioning.

3. Configurez des droits personnalisés dans l’application Snowflake -> Governance. Comme indiqué précédemment, les droits d’accès de Snowflake ne sont pas automatiquement renseignés à l’aide du connecteur d’Okta. Nous devrons donc configurer des rôles personnalisés et des droits d’accès.
   
   Voici les rôles présents dans l’application Snowflake :

Nous devons faire correspondre ces rôles sur Okta Platform : une fois la correspondance effectuée, ces rôles (tels que ORGADMIN ou SYSADMIN) sont convertis en objets pouvant être demandés, ce qui les rend visibles pour les utilisateurs dans le catalogue Access Request.

• Accédez à l’onglet Governance.

• Ajoutez un droit d’accès.

• Ajoutez un droit d’accès nommé « ROLES ».

• Ajoutez des rôles utilisateur, que nous utiliserons dans les demandes d'accès.

Une fois créés, voici à quoi ils ressembleront :

• Créez un bundle pour chaque rôle.

Une fois que vous avez terminé de créer des bundles, voici le résultat :

• Utilisez ces bundles pour créer une demande d’accès pour chaque rôle dans l’application Snowflake -> onglet Access Requests.

• Faites défiler jusqu’en bas et sélectionnez Séquence d’approbation → Sélectionner la séquence.

• Modifiez la séquence « Justification métier ».

• Juste en dessous de l’étape « Approbation par le responsable du demandeur », cliquez sur « + » pour ajouter une nouvelle étape de workflow dans la séquence.

• Ajoutez une étape de workflow et sélectionnez le workflow délégué que nous avons importé depuis le pack de workflows.

• Une fois ajoutée, renommez la séquence en « Séquence d'approbation Snowflake » et enregistrez-la.

• Sélectionnez la « Séquence d'approbation Snowflake » que nous venons d’enregistrer pour appeler le flux délégué Snowflake lors du processus de demande d’accès.

• Activez les demandes d'accès pour chaque rôle.

• Accédez au tableau de bord de l’utilisateur final et sélectionnez Request Access -> Snowflake pour effectuer une vérification finale permettant de s’assurer que l’utilisateur peut demander ces rôles.

• Vous devriez voir la liste de tous les rôles que les utilisateurs peuvent demander.

Exigences Slack

Slack fournit la couche de notification pour les workflows.

1. Périmètres et autorisations : l’utilisateur qui autorise le connecteur Slack dans Okta Workflows doit disposer de l’autorisation d’ajouter des applications à l’espace de travail.
2. Autorisation de l’application : autorisez l’application Okta Workflows dans votre espace de travail Slack.
3. ID du canal : trouvez l'identifiant du canal Slack (p. ex, #security-alerts ou #it-ops) dans lequel le workflow doit publier des messages. 

Maintenant que les exigences fondamentales ont été satisfaites, nous allons procéder au déploiement du package de workflows et détailler la configuration de l’architecture.

L’architecture : analyse approfondie de la solution à trois workflows

Dans cette section, nous allons détailler le rôle de chacun des trois principaux workflows :

1. Flux délégué Snowflake (Assignment) 
2. Unassign Entitlements (retirer des droits) 
3. User Unassign de Snowflake

Regarder : comment utiliser OIG et Workflows pour gérer les rôles dans Snowflake

Cette vidéo montre comment utiliser OIG et Workflows pour gérer les rôles Snowflake à grande échelle, sans les limites des connecteurs d’intégration traditionnels. Découvrez comment cette intégration automatise les tâches, sécurise les données et élimine le déficit de gouvernance tout en réduisant le risque d’erreur humaine.

1. Le flux d’attribution déléguée : la « porte d’entrée »

Ce flux est conçu pour l’administration déléguée, permettant aux administrateurs de déclencher des attributions de rôles sans avoir à accéder à la console Workflows.

• Portes logiques et de sécurité : le flux commence par la saisie d’un userEmail et d’un requestedRole. Avant d’agir, il effectue une vérification readUser dans Okta et une vérification getAssignedUserForApplication afin de vérifier l’état actuel de l’utilisateur.
• L’exigence « provisioned » : une carte « Continue If » joue le rôle de filtre, en vérifiant que le statut de l’utilisateur dans l’application Snowflake est précisément PROVISIONED.
• Prévention des conditions de compétition : nous avons mis en place une carte « Wait » de cinq secondes. Lors des tests, nous avons constaté que Snowflake a parfois besoin de quelques secondes pour enregistrer un nouvel utilisateur avant de pouvoir accepter une commande GRANT ROLE.
• Exécution : une fois validée, elle utilise la carte « Grant Role to User » de Snowflake et informe l’équipe via un canal Slack.

Flux délégué : cartes d’attribution de rôles à l'utilisateur 

1. DÉBUT : événement de flux délégué

   1. Entrées : requestedRole, userEmail, AccessLevelName.

2. Okta - Read User

   1. Extrait les détails du profil utilisateur (prénom, nom) à partir de l’adresse e-mail fournie.

3. String - Concatenate

   1. Combine les noms d’utilisateur à des fins d’archivage.

4. Control - Wait

   1. Met le flux en pause pendant 5 secondes pour permettre au provisioning en amont de se stabiliser.

5. Okta - Get Assigned User for Application

   1. Vérifie le statut d’attribution de l’application Snowflake pour l’utilisateur spécifique.

6. Control - Continue If

   1. Condition : poursuivre uniquement si le statut est PROVISIONED.

   2. Sinon : arrêter avec l’erreur « Error granting a role to the user ».

7. Snowflake - Grant Role to User

   1. Exécute l’attribution de rôle dans Snowflake.

8. String - Concatenate

   1. Crée le message de réussite pour Slack.

9. END: Slack - Send Message to Channel

   1. Publie une confirmation : « [User] s’est vu attribuer le rôle [Role] avec succès. »

2. Retrait des droits d’accès : l’intégration de l’API OIG

C’est le « cerveau » de l’opération qui gère la tâche complexe de révoquer des rôles spécifiques lorsqu’une autorisation OIG est refusée ou arrive à expiration.

• Le « Golden Thread » (grantId) : lorsque OIG déclenche une révocation, il envoie un webhook à l’API endpoint de ce flux. Nous utilisons une carte « Object Pick » pour extraire le grantId en profondeur dans le JSON : data.events.0.debugContext.debugData.grantId.
• Le callback de l’API OIG : le nom spécifique du rôle manque souvent dans le webhook initial. Le flux utilise une action API personnalisée pour appeler l’API OIG : /governance/api/v1/grants/{{grantId}}?include=full_entitlements.
• Analyse des droits imbriqués : à l’aide des cartes « At » et « Get », le flux parcourt la liste renvoyée pour trouver le nom exact du rôle situé à values.0.name.
• La porte logique « DENY » : pour éviter les révocations accidentelles lors des cycles d’approbation, une carte « Continue if » vérifie que l’action OIG est exactement DENY.

Cartes de flux Unassign entitlements 

1. START: API Endpoint (Webhook)

   1. Reçoit les données du corps contenant les informations de délégation et de cible.

2. Object - Get Multiple (Pick)

   1. Extrait le grantId et l’objet target des données de l’événement.

3. Object - Get

   1. Extrait l’Alternate ID (identifiant utilisateur) de l’objet cible.

4. Okta - Read User

   1. Récupère le profil complet de l'utilisateur identifié.

5. String - Concatenate

   1. Crée une URL relative pour l’API IGA : /governance/api/v1/grants/[grantId]?include=full_entitlements.

6. Okta IGA - Custom API Action

   1. Effectue une requête GET pour extraire tous les détails de l’autorisation concernée.

7. Control - Continue If

   1. Condition : poursuivre uniquement si l’action est « DENY » (indiquant une demande de suppression).

8. List - At

   1. Récupère le droit d'accès spécifique de la liste renvoyée.

9. Object - Get

   1. Extrait le nom du rôle à partir de l’objet Entitlement.

10. Concatenate - First name + Last name

    1. Crée un nom d’utilisateur à partir du prénom et du nom de famille de l’utilisateur afin de les faire correspondre dans Snowflake.

11. Snowflake - Revoke Role from User

    1. Supprime le rôle de l’utilisateur dans Snowflake.

12. Concatenate - Slack output

    1. Crée un message à envoyer dans Slack.

13. END: Slack - Send Message to Channel

    1. Publie une confirmation : « [Utilisateur] a bien été retiré du rôle [Rôle]. »

3. Offboarding complet : suppression du compte utilisateur

Lorsqu’une personne utilisatrice est entièrement supprimée de l’application Snowflake dans Okta, la révocation des rôles ne suffit pas ; il faut également supprimer la personne concernée afin de récupérer la licence.

• Le déclencheur : le flux démarre lorsqu’un utilisateur est supprimé de l’instance de l’application Snowflake dans Okta.
• Traitement asynchrone : il utilise une boucle Async Each pour traiter la suppression, en appelant un flux d’aide pour chaque utilisateur supprimé.
• L’acte final : le flux d’aide exécute la commande Drop User dans Snowflake. Cela permet de supprimer complètement l’utilisateur de l’environnement Snowflake, en automatisant une tâche qui nécessite habituellement une intervention manuelle en SQL.

Cartes de flux Offboarding 

Flux parent

1. START: Okta - User Unassigned from Application

   1. Surveille les événements application.user_membership.remove pour l’application Snowflake.

2. List - For Each (Async Each)

   1. Envoie chaque utilisateur supprimé vers le flux d’aide pour traitement.

Flux d’aide

1. START: Callable Event

   1. Reçoit les données utilisateur du flux parent.

2. Object - Expand

   1. Extrait l’ID alternatif (généralement le nom d’utilisateur).

3. Snowflake - Drop User

   1. Supprime le compte utilisateur dans Snowflake.

4. END: Slack - Send Message to Channel

   1. Informe l’équipe que l’utilisateur Snowflake a été supprimé.

Test de la configuration OIG et Workflows

Test du workflow « Access Request-to-Role » 

La demande d’accès (action de l’utilisateur)

1. Se connecter en tant qu’utilisateur de test standard. Accédez au Tableau de bord pour utilisateurs finaux d’Okta > Demander un accès.
2. Soumettre une demande pour le type de demande « Snowflake Role ». Sélectionnez le rôle spécifique (par exemple, USERADMIN). 
3. Vérifiez l’historique des demandes d’accès pour vous assurer que la demande a bien été créée et que l’approbateur approprié (responsable) a été désigné.

Approbation et provisioning (action de l’administrateur ou du responsable)

1. Connectez-vous en tant qu’administrateur approbateur, puis cliquez sur « Approuver ».
2. Transmettez le rôle à Snowflake : OIG Approval → Okta Assigns Entitlement to User → Okta SCIM.
3. Dans Okta, accédez au profil de l’utilisateur > Applications > Snowflake pour vérifier que le rôle apparaît sous « Entitlements ».
4. Effectuez des vérifications similaires dans Snowflake pour vérifier que l’utilisateur s’est vu attribuer un rôle approprié.

L’utilisateur doit maintenant pouvoir se connecter à Snowflake et voir le rôle attribué.

Test de la révocation des droits d’accès 

Révocation des droits d’accès (action de gouvernance)

Il existe deux méthodes pour révoquer le droit d’accès au rôle Snowflake :

1. Accédez à Identity Governance > Access Certifications (ou au profil de l’utilisateur).
2. Accédez à Applications > Snowflake > Assignments et cliquez sur Test_user > Manage Entitlements.

Flux d’exécution

1. Un événement OIG déclenche le webhook API Unassign Entitlements.
2. Début du workflow : le flux reçoit le grantId et le target (Utilisateur).
3. Appel d’API IGA : le workflow appelle /governance/api/v1/grants/[id] pour vérifier que l’action est DENY.
4. Révocation dans Snowflake : le workflow exécute la carte Revoke Role from the User dans Snowflake.
5. Audit Slack : un message est envoyé dans le canal IT.

Critères de vérification et de réussite

1. Historique des Workflows : ouvrez l’historique du flux Unassign Entitlements.
   1. Vérification de la réussite: chaque carte (Object Pick, IGA API, Snowflake Revoke) doit afficher une coche verte.
2. Dans Snowflake, exécutez SHOW GRANTS TO USER "TEST_USER";. Le rôle doit avoir été supprimé.
3. Dans Slack, confirmez le message : [User] a bien été retiré du rôle [Role].

Test du nettoyage « Drop User » lors du départ d’un utilisateur

1. Retirer l’utilisateur test de l’ensemble de l’application Snowflake dans Okta.
2. Flux d’exécution : Okta Unassignment → Flux parent : User Unassigned → Flux d’assistance : Drop User.
3. Dans Okta, vérifiez que l’utilisateur ne figure plus dans la liste d’affectation de l’application Snowflake.
4. Dans Snowflake, exécutez SHOW USERS LIKE 'TEST_USER%';. L’utilisateur ne doit renvoyer aucun résultat (supprimé).
5. Dans Slack, confirmez la notification « L’utilisateur Snowflake a été supprimé ».

Enseignements tirés de l’automatisation Workflows OIG

La mise en place de cette automatisation a mis en lumière plusieurs nuances essentielles dans la façon dont OIG et Snowflake communiquent :

Cartographie des statuts et des actions

L’une des erreurs les plus fréquentes que nous avons rencontrées était le déclenchement du flux à une étape inappropriée du cycle de vie de la gouvernance. Nous avons défini une correspondance stricte pour les portes Continue If :

Mise en forme des chaînes pour Snowflake

Snowflake est sensible à la casse et attend souvent un format d’identifiant précis. Nous avons utilisé les cartes Concatenate pour fusionner les champs firstName et lastName d’Okta afin de répondre précisément aux exigences du champ user_name de Snowflake, par exemple : JOHNDOE

L’état Wait

Sans la carte Wait, le flux « Delegated Assignment » échouerait de façon intermittente avec une erreur « User Not Found » provenant de Snowflake, même si l’utilisateur venait d’être créé. Un délai de cinq secondes a permis d’éliminer 100 % de ces échecs liés aux conditions de compétition.

Atteindre une véritable gouvernance des identités

En allant au-delà du connecteur standard et en utilisant API Okta Identity Governance ainsi que les Workflows, vous créez un système en boucle fermée, qui offre des avantages importants en matière de gouvernance des identités :

• Sécurité : les rôles sont révoqués immédiatement à l’expiration des autorisations.
• Optimisation des coûts : les utilisateurs de Snowflake sont supprimés lorsqu’ils ne sont plus nécessaires, et les licences sont automatiquement récupérées.
• Conformité : chaque action, de la demande OIG à la commande SQL Snowflake, est enregistrée et peut être auditée dans l’historique d’exécution du workflow.

Essayez-le gratuitement : découvrez les avantages de l’automatisation à grande échelle des processus d’identité complexes avec Okta Identity Governance et Workflows. Commencez votre essai gratuit de 30 jours.