Tutoriel : Modéliser l’accès exclusif avec RBAC

Utilisez le contrôle d’accès basé sur les rôles (RBAC) pour imposer un accès exclusif aux ensembles de données qui doivent rester séparés les uns des autres. Lorsque chaque jeu de données n’est accessible que via le rôle qui lui est attribué, les utilisateurs et les agents IA doivent endosser ce rôle pour y accéder. Pour accéder à un autre jeu de données, ils doivent changer de rôle, de sorte qu’une seule requête ne peut pas combiner des données entre cas d’usage, projets, essais cliniques ou clients. La combinaison de jeux de données qui doivent rester séparés est parfois appelée une jointure toxique.

Scenario

Un chercheur travaille sur deux essais cliniques dans un même espace de travail. Ils ont besoin d’accéder aux deux essais, mais leur travail sur l’un ne doit pas utiliser les données de l’autre. Configurez un rôle distinct pour chaque essai, testez les requêtes autorisées et refusées, puis limitez le partage des ressources de l’espace de travail créées sous chacun de ces rôles.

Le chercheur conserve son affectation à l’espace de travail et peut y accéder avec sa propre identité. Pour exiger un rôle pour l’accès à l’espace de travail, voir le tutoriel : Exiger que les utilisateurs endossent un rôle pour accéder à l’espace de travail.

L’exemple utilise deux types de groupes. Il s’agit d’étiquettes explicites, pas de terminologie Azure Databricks formelle :

• Rôle d’accès : Un groupe vide qui détient les permissions sur les données d’un essai. Vous créez role-study-1 et role-study-2. Gardez-les vides. Les membres héritent des autorisations de leur groupe. Un membre pourrait donc lire les données sans avoir à endosser un rôle.
• Groupe de membres : trial-researchers, dont les membres sont autorisés à assumer les deux rôles d’accès. Il dispose de l’autorisation Assume, mais ne possède aucune autorisation sur les données de l’essai. Un groupe membre est facultatif. Vous pouvez également accorder l’autorisation Assume directement à des utilisateurs individuels ou à des service principals.

Le chercheur peut alterner entre les rôles, mais chaque rôle ne peut lire que le tableau de sa propre étude :

Dans le diagramme, le groupe Étude 1 correspond à role-study-1, et le groupe Étude 2 correspond à role-study-2.

Prerequisites

• Un espace de travail avec Unity Catalog activé et RBAC activé. Voir Activer le RBAC.
• Des autorisations d’administrateur de compte ou d’administrateur d’espace de travail pour créer des rôles, accorder l’autorisation Assume et gérer les affectations d’espaces de travail. Voir Qui peut gérer des groupes ?.
• Autorisations d’administrateur d’espace de travail pour configurer les droits, l’accès au calcul et les restrictions de partage.
• Un catalogue de test existant avec stockage géré, accessible depuis l’espace de travail. L’administrateur qui crée les données doit être propriétaire du catalogue. Ce tutoriel utilise trials avec de nouveaux schémas study_1 et study_2. Utilisez un catalogue sans autorisations étendues qui donneraient au chercheur ou à l’un ou l’autre rôle l’accès aux deux ensembles de données. Consultez Créer des catalogues.
• Un entrepôt SQL auquel l’autorisation Can use est accordée pour le propriétaire du catalogue chargé de créer les jeux de données de test. La personne qui accorde l’accès au warehouse doit disposer d’autorisations d’administrateur de l’espace de travail ou de l’autorisation « Peut gérer » sur le warehouse.
• Un groupe de comptes contenant les chercheurs, nommé trial-researchers dans cet exemple. L’un de ses membres participe à la validation en utilisant ses propres identifiants de connexion. Ce chercheur ne doit pas être un administrateur, propriétaire de catalogue ou membre d’un groupe disposant d’un large accès aux données.
• Un dossier d’espace de travail pour le carnet de tests de chaque rôle. L’administrateur de l’espace de travail configure l’accès à ces dossiers à l’étape 3.
• Pour l’étape 8, un lecteur d’audit configuré conformément aux instructions de la section Vérifier l’attribution des opérations dans les journaux d’audit.

Remplacez vos propres noms de catalogue, de groupe et d’espace de travail dans tout le document. Utilisez des données de test fictives ainsi que de nouveaux schémas et rôles afin que le nettoyage n’affecte pas les autres charges de travail.

Étape 1 : Créer les jeux de données de test

Si l’un ou l’autre des schémas existe déjà, choisissez un nouveau nom de schéma plutôt que de remplacer des objets existants.

En tant que propriétaire du catalogue, ouvrez l’éditeur SQL, sélectionnez l’entrepôt de test, et exécutez :

CREATE SCHEMA trials.study_1;
CREATE SCHEMA trials.study_2;

CREATE TABLE trials.study_1.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

CREATE TABLE trials.study_2.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

INSERT INTO trials.study_1.patient_info VALUES ('study-1-a', 'improved');
INSERT INTO trials.study_2.patient_info VALUES ('study-2-a', 'unchanged');

Les identifiants et résultats des participants sont fictifs. Effectuez les deux requêtes pour vérifier que les tables existent et que l’entrepôt peut les lire :

SELECT * FROM trials.study_1.patient_info LIMIT 100;
SELECT * FROM trials.study_2.patient_info LIMIT 100;

Chaque requête renvoie la ligne unique de son étude.

Étape 2 : créer les rôles d’accès et accorder l’autorisation Assume

La procédure principale utilise des groupes locaux au compte pour définir les rôles d’accès. Les groupes locaux de compte sont utiles lorsque créer un groupe dans Azure Databricks est plus simple que de demander un nouveau groupe depuis Microsoft Entra ID. Le groupe de membres peut être local par compte ou synchronisé depuis Microsoft Entra ID, comme montré dans ce schéma :

Créez le premier rôle vide en utilisant l’une ou l’autre méthode :

Console de compte

1. En tant qu’administrateur de compte, connectez-vous à la console de compte.
2. Dans la barre latérale, cliquez sur Gestion des utilisateurs.
3. Dans l’onglet Groupes, cliquez sur Ajouter un groupe.
4. Appuyez sur role-study-1. N’ajoutez pas de membres.
5. Cliquez sur Confirmer.
6. Assignez le groupe à l’espace de travail de test avec l’accès Workspace et l’accès SQL Databricks. Voir Affecter un groupe à un espace de travail.

Paramètres d’administrateur de l’espace de travail

1. En tant qu’administrateur d’espace de travail, connectez-vous à l’espace de test.
2. Cliquez sur votre nom d’utilisateur dans la barre supérieure, puis sélectionnez Paramètres.
3. Cliquez sur l’onglet Identité et accès .
4. À côté de Groupes, cliquez sur Gérer.
5. Cliquez sur Ajouter un groupe, puis sur Ajouter un nouveau groupe.
6. Saisissez role-study-1 et sélectionnez Accès à l’espace de travail et Accès SQL à Databricks. L’étape 3 explique pourquoi ce tutoriel utilise les deux.
7. Cliquez sur Ajouter. N’ajoutez pas de membres.

Cela assigne également le groupe à l’espace de travail et vous accorde l’autorisation Gérer sur celui-ci.

Accorder l’autorisation Assume aux chercheurs

Avant d’attribuer les privilèges d’accès aux données du rôle, accordez aux chercheurs l’autorisation de l’endosser :

Console de compte

1. En tant qu’administrateur de compte, ouvrez Gestion des utilisateurs> dans la console de compte et sélectionnez role-study-1.
2. Cliquez sur Autorisations, puis sur Accorder l’accès.
3. Sélectionnez trial-researchers, sélectionnez Assume, puis cliquez sur Enregistrer.

Paramètres d’administrateur de l’espace de travail

1. En tant qu’administrateur d’espace de travail avec la permission de gérer le rôle, ouvrez Paramètres>Identité et accès dans l’espace de travail de test.
2. À côté de Groupes, cliquez sur Gérer, puis sélectionnez role-study-1.
3. Cliquez sur Autorisations, puis sur Accorder l’accès.
4. Sélectionnez trial-researchers, sélectionnez Assume, puis cliquez sur Enregistrer.

Répétez les étapes pour créer le rôle et accorder l’autorisation Assume pour role-study-2. Les deux rôles restent vides. Voir Choisir ou créer un rôle pour les conseils de nommage et la création de groupes basée sur l’API.

Étape 3 : Configurer l’espace de travail et l’accès au calcul

Vous avez attribué les deux rôles à l’espace de travail de test à l’étape 2. En tant qu’administrateur de l’espace de travail, vérifiez que les deux rôles et trial-researchers disposent des deux droits d’accès requis, y compris les groupes déjà affectés :

• Accès à l’espace de travail : accorde l’accès aux fonctionnalités principales de l’espace de travail, telles que les blocs-notes, les travaux, les modèles et les pipelines. Ce tutoriel utilise des notebooks pour vérifier les contrôles de partage.
• Accès Databricks SQL : accorde l’accès aux fonctionnalités Databricks SQL, notamment les tableaux de bord, les requêtes et les entrepôts SQL. Ce tutoriel utilise l’éditeur SQL pour vérifier l’accès aux données.

Pour obtenir la liste de tous les droits d’accès et savoir comment les gérer, consultez la documentation Droits d’accès.

Si trial-researchers n’est pas affecté, affectez-le à l’espace de travail. Voir Affecter un groupe à un espace de travail.

Maintenez l’affectation des chercheurs afin qu’ils puissent accéder à l’espace de travail avec leur propre identité et revenir à celle-ci après avoir utilisé un rôle.

Accordez à chaque groupe l’accès à l’entrepôt SQL :

1. Dans la barre latérale de l’espace de travail, cliquez sur SQL Warehouses.
2. Ouvrez la boîte de dialogue Autorisations de l’entrepôt.
3. Ajoutez chaque groupe avec l’autorisation Peut utiliser, puis enregistrez les modifications.

Créez un dossier de test distinct pour chaque rôle, dans un emplacement de l’espace de travail ne bénéficiant pas d’autorisations héritées trop étendues. Accordez l’autorisation Peut gérer role-study-1 à un rôle sur son dossier et Peut gérer role-study-2 à l’autre rôle sur l’autre dossier. Les rôles utilisent ces dossiers pour créer des notebooks à l’étape 7. Voir Gérer les objets d’espace de travail et les ACL de dossier.

Étape 4 : Accorder à chaque rôle l’accès à son étude

En tant que propriétaire du catalogue, exécutez :

GRANT USE CATALOG ON CATALOG trials TO `role-study-1`;
GRANT USE SCHEMA ON SCHEMA trials.study_1 TO `role-study-1`;
GRANT SELECT ON TABLE trials.study_1.patient_info TO `role-study-1`;

GRANT USE CATALOG ON CATALOG trials TO `role-study-2`;
GRANT USE SCHEMA ON SCHEMA trials.study_2 TO `role-study-2`;
GRANT SELECT ON TABLE trials.study_2.patient_info TO `role-study-2`;

N’accordez pas de privilèges de données d’essai à trial-researchers. Ses membres reçoivent plutôt l’autorisation Assume.

Vérifiez les accès directs et hérités avant de procéder aux tests :

• Le chercheur ne doit disposer d’aucune autre autorisation ni appartenir à aucun autre groupe lui permettant de lire l’une ou l’autre des tables avec sa propre identité.
• Aucun groupe parent ne donne à l’un ou l’autre rôle accès aux données de l’autre étude.
• Vérifiez les autorisations sur le catalogue et le schéma ainsi que sur les tables. Une autorisation au niveau catalogue ou schéma SELECT s’applique aux objets enfants actuels et futurs et peut rendre les deux tables accessibles. Consultez l’héritage des privilèges.

Utilisez l’onglet Autorisations de Catalog Explorer pour examiner les autorisations accordées sur le catalogue, les deux schémas et les deux tables. Consultez Gérer les privilèges dans Unity Catalog. Si les autorisations partagées empêchent cette configuration, utilisez un catalogue de tests ou un espace de travail isolé. Supprimer une autorisation partagée peut perturber des utilisateurs et des rôles non liés.

Étape 5 : Restreindre le partage des ressources de l’espace de travail détenues par le rôle

En l’absence de restriction de partage, un utilisateur agissant en tant que rôle peut partager les ressources de l’espace de travail dont ce rôle est propriétaire. Configurez la restriction pour les deux rôles :

1. En tant qu’administrateur de l’espace de travail, cliquez sur votre nom d’utilisateur et sélectionnez Paramètres.
2. Cliquez sur Avancé.
3. Recherchez Restreindre le partage pour les groupes, puis cliquez sur le bouton de modification.
4. Ajoutez role-study-1 et role-study-2 . Gardez tous les groupes déjà dans la liste.
5. Cliquez sur Enregistrer.

Cette restriction s’applique lorsque vous agissez dans un rôle restreint. Il contrôle le partage des ressources de l’espace de travail détenues par le rôle. Il ne contrôle pas les privilèges sur les objets du catalogue Unity, et il ne bloque pas toutes les façons de copier les données. Consultez les contrôles de partage des ressources de l’espace de travail.

Étape 6 : vérifier l’accès aux données avec chaque identité

L’un de vos chercheurs effectue ces vérifications en utilisant ses propres identifiants :

1. Connectez-vous à l’espace de travail de test et vérifiez que votre nom d’utilisateur apparaît sous le nom de l’espace de travail.

2. Ouvre l’éditeur SQL et sélectionne l’entrepôt de test.

3. Exécutez chaque requête séparément :

   SELECT * FROM trials.study_1.patient_info LIMIT 100;
   SELECT * FROM trials.study_2.patient_info LIMIT 100;
   

   Les deux requêtes échouent avec des erreurs de permission.

4. Cliquez sur le nom de l’espace de travail dans la barre supérieure, survolez l’espace de travail actuel, puis sélectionnez role-study-1 dans le sélecteur de rôle.

5. Après le rechargement de l’espace de travail, vérifiez le nom du rôle, ouvrez l’éditeur SQL, sélectionnez le même entrepôt, et répétez les deux requêtes. Seule la requête Study 1 réussit.

6. Passez à role-study-2 et répétez les requêtes. Seule la requête Study 2 réussit.

7. Revenez à votre nom d’utilisateur et répétez les vérifications. Les deux demandes sont à nouveau refusées.

Une table manquante, un entrepôt indisponible ou une erreur d’authentification ne démontrent pas qu’il y a un accès exclusif. Les vérifications du propriétaire du catalogue à l’étape 1 établissent que les deux tables existent. Si une requête inattendue aboutit, examinez les autorisations et les appartenances aux groupes de l’étape 4 avant de procéder.

Pour découvrir d’autres méthodes permettant d’endosser un rôle, consultez la documentation Changer de rôle RBAC. Le changement de rôle dans ce navigateur ne modifie pas un profil Databricks CLI ou une connexion authentifiés séparément.

Étape 7 : Vérifier le partage des ressources de l’espace de travail

Le même chercheur répète ces vérifications pour chaque rôle :

1. Endossez le rôle à l’aide du sélecteur de rôles.
2. Dans Espace de travail, cliquez avec le bouton droit sur le dossier de test du rôle, puis sélectionnez Créer>Notebook.
3. Nomme le bloc-notes d’après l’étude. Vous n’avez pas besoin d’y faire tourner du code.
4. Vérifiez que le rôle possède le nouveau bloc-notes, puis essayez de le partager. Le partage n’est pas disponible lorsque vous agissez en tant que rôle soumis à des restrictions, même si vous disposez de l’autorisation Peut gérer sur la ressource.

Utilisez un notebook créé lorsque vous agissiez en tant que rôle, et non un carnet appartenant au chercheur. Consultez les sections Créer un notebook et Vérifier la restriction.

Étape 8 : Vérifier l’attribution de l’audit

En tant que lecteur d’audit, exécutez cette requête. Remplacez <workspace-id> par l’identifiant de l’espace de travail de test :

SELECT event_time, service_name, action_name,
       identity_metadata.run_by, identity_metadata.run_by_display_name,
       identity_metadata.run_as, identity_metadata.run_as_display_name
FROM system.access.audit
WHERE workspace_id = '<workspace-id>'
  AND identity_metadata.run_as_display_name IN ('role-study-1', 'role-study-2')
  AND event_date >= current_date() - INTERVAL 1 DAY
ORDER BY event_time DESC;

Trouvez les événements pour les requêtes de test du chercheur et la création de notebook. identity_metadata.run_by identifie le chercheur qui a initié chaque événement et run_as identifie le rôle utilisé pour l’autorisation. La requête filtre sur run_as_display_name, le nom lisible par l’humain du rôle. Les données d’audit sont mises à jour tout au long de la journée, donc un événement récent peut ne pas apparaître immédiatement. Voir la référence des métadonnées d’identité.

Optionnel : Gérer les rôles d’accès dans Microsoft Entra ID

Utilisez cette alternative lorsque votre organisation conserve la gestion du cycle de vie des groupes dans Microsoft Entra ID. Synchronisez un groupe de rôles d’accès vide et un groupe de membres avec Azure Databricks au moyen du provisionnement SCIM (System for Cross-domain Identity Management). Voir Synchroniser les utilisateurs et groupes de Microsoft Entra ID à l'aide de SCIM.

Gardez chaque rôle d’accès vide dans Microsoft Entra ID. L’ajout de membres à ce groupe synchronise leurs appartenances avec Azure Databricks, où ils héritent des privilèges sur les données sans avoir à endosser le rôle.

Commencez par de nouveaux groupes Microsoft Entra ID

Pour utiliser les nouveaux groupes Microsoft Entra ID au lieu des rôles locaux de compte à l’étape 2, suivez ces étapes :

1. Dans Microsoft Entra ID, créez un groupe vide pour chaque rôle d’accès.
2. Identifiez ou créez le groupe de membres comprenant les chercheurs.
3. Synchronisez les rôles d’accès et le groupe de membres avec votre compte Azure Databricks.
4. Accordez au groupe de membres l’autorisation Assume sur chaque rôle d’accès en utilisant la procédure de l’étape 2.

Réutiliser un groupe Microsoft Entra ID existant

Si un groupe synchronisé depuis Microsoft Entra ID dispose déjà des privilèges d’accès aux données souhaités dans Azure Databricks, vous pouvez conserver ces autorisations en réaffectant ce groupe au rôle de rôle d’accès :

1. Créez un nouveau groupe de membres dans Microsoft Entra ID. Par exemple, si le groupe existant est clinical-trial-1-ds, créez clinical-trial-1-ds-members.
2. Déplacez tous les membres du groupe existant vers le nouveau groupe de membres, laissant le groupe existant vide.
3. Synchronisez les deux groupes sur Azure Databricks et vérifiez que le rôle d’accès n’a aucun membre.
4. Accordez au nouveau groupe de membres l’autorisation Assume sur le rôle d’accès. Examinez les autres autorisations accordées et appartenances à des groupes susceptibles de conférer aux chercheurs un accès permanent aux données.

Le groupe existant conserve ses privilèges de données et les permissions de l’espace de travail. Vous n’avez pas besoin de recréer ces autorisations, mais vérifiez qu’elles correspondent au périmètre de l’étude prévu. Planifiez le changement d’adhésion avec les propriétaires du groupe car les utilisateurs perdent les permissions héritées lorsqu’ils quittent le groupe d’origine.

Complétez la configuration de l’espace de travail et les vérifications

Attribuer à la fois les rôles d’accès et le groupe de membres à l’espace de travail, configurer les droits et l’accès au calcul comme à l’étape 3. Pour exiger plutôt que les utilisateurs assument un rôle pour l’accès à l’espace de travail, voir le tutoriel : Exiger que les utilisateurs assument un rôle pour l’accès à l’espace de travail.

Pour les nouveaux rôles d’accès, accordez l’accès aux données comme à l’étape 4 et l’accès aux ressources de l’espace de travail comme à l’étape 3. Pour les groupes réaffectés, examinez les autorisations existantes au lieu de les remplacer.

Vérifiez que le groupe de membres dispose de l’autorisation Assume sur chacun des rôles d’accès. Tous ses membres peuvent alors assumer ce rôle.

Configurez les restrictions de partage, puis répétez les vérifications des données, du partage et des audits décrites aux étapes 5 à 8, en utilisant les noms des groupes Microsoft Entra ID et les jeux de données correspondants.

Nettoyage

Pour un test temporaire, retirez uniquement les ressources et autorisations créées pour ce tutoriel :

1. En tant que propriétaire du catalogue, vérifiez que les deux tables ne contiennent que les données de test du tutoriel, puis exécutez :

   DROP TABLE trials.study_1.patient_info;
   DROP TABLE trials.study_2.patient_info;
   DROP SCHEMA trials.study_1 RESTRICT;
   DROP SCHEMA trials.study_2 RESTRICT;
   

   La suppression des schémas échoue si d’autres objets y sont encore présents. Ne supprimez pas un catalogue ou un schéma existant utilisé par d’autres charges de travail.

2. En tant qu’administrateur de l’espace de travail, supprimez les carnets et dossiers de test. Examinez les autres ressources appartenant aux rôles avant de les supprimer.

3. Révoquez les autorisations Assume et les autorisations sur les ressources créées pour le test, notamment celles portant sur le catalogue et l’entrepôt. Supprimer les affectations d’espaces de travail de test uniquement, préservant ainsi l’accès existant des chercheurs.

4. Supprimez les rôles de test de Restreindre le partage pour les groupes, en laissant les autres entrées intactes.

5. Supprimez les rôles vides nouvellement créés seulement après avoir vérifié qu’aucune charge de travail ou ressource ne les utilise encore. Pour les groupes synchronisés, effectuez des modifications du cycle de vie dans Microsoft Entra ID afin que la synchronisation ne recrée pas les groupes supprimés. Conservez les groupes de membres existants et leurs utilisateurs.

Si vous avez réutilisé un groupe existant, prévoyez un retour en arrière séparé qui restaure ses appartenances et affectations initiales. N’utilisez pas le nettoyage de la ressource de test pour supprimer un modèle d’accès existant.

Étapes suivantes