Tutoriel : Accès exclusif au modèle avec RBAC

Utilisez le contrôle d'accès basé sur les rôles (RBAC) pour appliquer un accès exclusif aux datasets qui doivent rester séparés les uns des autres. Lorsque chaque dataset est accessible uniquement via son rôle désigné, les utilisateurs et les agents d’IA doivent assumer ce rôle pour y accéder. Pour accéder à un autre dataset, ils doivent changer de rôle. Par conséquent, une seule query ne peut pas combiner des données provenant de cas d'utilisation, de projets, d'essais cliniques ou de clients différents. La combinaison de datasets qui doivent rester séparés est parfois appelée jonction toxique .

Scénario

Un chercheur travaille sur deux essais cliniques dans le même workspace. Il doit avoir accès aux deux essais, mais son travail sur l’un des essais ne doit pas utiliser les données de l’autre essai. Vous configurez un rôle distinct pour chaque essai, testez les queries autorisées et refusées, et restreignez le partage des assets du workspace créés avec chaque rôle.

Le chercheur reste attribué au Workspace et peut accéder au Workspace en son propre nom. Pour exiger un rôle pour accéder au workspace, consultez le tutoriel : Exiger des utilisateurs qu'ils endossent un rôle pour accéder au workspace.

L’exemple utilise deux types de groupes. Il s’agit d’étiquettes explicatives, pas de la terminologie officielle de Databricks :

• Rôle d’accès : Groupe vide qui détient des autorisations sur les données d’une étude. Vous créez role-study-1 et role-study-2. Laissez-les vides. Les membres héritent des autorisations d’un groupe, donc un membre pourrait lire les données sans assumer un rôle.
• Groupe membre : trial-researchers, dont les membres sont autorisés à assumer les deux rôles d'accès. Elle possède l'autorisation Assume, mais pas les autorisations sur les données d'essai. Un groupe de membres est facultatif. Vous pouvez également accorder l'autorisation Assume directement à des utilisateurs individuels ou à des Service Principal Databricks.

Le chercheur peut changer de rôle, mais chaque rôle ne peut lire que la table de son étude :

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

Prérequis

• Workspace activé pour Unity Catalog avec RBAC activé. Voir Activer RBAC.
• Autorisations d'administrateur de compte ou d'administrateur de workspace pour créer des rôles, octroyer l'autorisation Assume et gérer les attributions de workspace. Voir Qui peut gérer les groupes ?.
• Autorisations d’administrateur de workspace pour configurer les droits, l’accès au compute et les restrictions de partage.
• Un catalogue de test existant avec stockage géré, accessible depuis Workspace. L’administrateur qui crée les données doit être propriétaire du catalogue. Ce tutoriel utilise trials avec les nouveaux schémas study_1 et study_2. Utilisez un catalogue sans droits étendus qui donnerait au chercheur ou à l’un des rôles l’accès aux deux datasets. Voir Créer des catalogues.
• Un SQL warehouse avec le droit d'utilisation accordé au propriétaire du catalogue qui crée les datasets de test. La personne qui accorde l'accès au warehouse doit avoir des permissions d'administrateur de workspace ou le droit de gérer 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 sa propre connexion. Ce chercheur ne doit pas être un administrateur, un propriétaire de catalogue ou un membre d'un groupe ayant un large accès aux données.
• Un dossier Workspace pour le notebook de test de chaque rôle. L'administrateur du Workspace configure l'accès à ces dossiers à l'étape 3.
• Pour l’étape 8, un lecteur d’audit configuré comme décrit dans Vérifier l’attribution d’audit.

Remplacez par vos propres noms de catalogue, de groupe et de workspace. 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 workloads.

Étape 1 : créer les datasets de test

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

En tant que propriétaire du catalogue, ouvrez l'éditeur SQL, sélectionnez le warehouse de test et exécutez :

SQL

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 des participants et les résultats sont fictifs. Exécutez les deux queries pour vérifier que les tables existent et que le warehouse peut les lire :

SQL

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

Chaque query renvoie une seule ligne 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 les rôles d'accès. Les groupes locaux au compte sont utiles lorsqu'il est plus simple de créer un groupe dans Databricks que de demander un nouveau groupe à votre fournisseur d'identité. Le groupe de membres peut être local au compte ou synchronisé à partir de votre fournisseur d'identité, comme le montre ce diagramme :

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

Account console

1. En tant qu'administrateur de compte, Connexion à la console du compte.
2. Dans la barre latérale, cliquez sur Gestion des utilisateurs .
3. Sur l'onglet **Groupes**, cliquez sur **Ajouter un groupe**.
4. Saisissez role-study-1. Ne pas ajouter de membres.
5. Cliquez sur Confirmer .
6. Assignez le groupe au workspace de test avec un accès Workspace et un accès Databricks SQL . Voir Attribuer un groupe à un workspace.

Workspace admin settings

1. En tant qu'admin du Workspace, Connexion au Workspace de test.
2. Cliquez sur votre nom d’utilisateur dans la barre supérieure et sélectionnez Paramètres .
3. Cliquez sur le tab Identité et accès .
4. À côté de Groupes , cliquez sur Gérer .
5. Cliquez sur Ajouter un groupe , puis sur Ajouter un nouveau .
6. Entrez role-study-1 et sélectionnez Accès au Workspace et Accès à Databricks SQL . L'étape 3 explique pourquoi ce tutoriel utilise les deux.
7. Cliquez sur Ajouter . Ne pas ajouter de membres.

Cela attribue également le groupe au workspace et vous accorde l'autorisation Manage dessus.

Accorder l’autorisation d’assumer aux chercheurs

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

Account console

1. En tant qu'administrateur de compte, ouvrez Gestion des utilisateurs > Groupes 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 et cliquez sur Enregistrer .

Workspace admin settings

1. En tant qu'administrateur de workspace disposant de l'autorisation Gérer sur le rôle, ouvrez Paramètres > Identité et accès dans le workspace 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 et cliquez sur Enregistrer .

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

Étape 3 : Configurer l'accès au workspace et au compute

Vous avez attribué les deux rôles au workspace de test à l'étape 2. En tant qu'administrateur du workspace, vérifiez que les deux rôles et trial-researchers possèdent les deux droits d'accès, y compris les groupes qui ont déjà été attribués :

• Accès au Workspace : accorde l’accès aux fonctionnalités principales du Workspace, comme les notebooks, les jobs, les modèles et les pipelines. Ce tutoriel utilise des notebooks pour vérifier les contrôles de partage.
• Accès à Databricks SQL : autorise l’accès aux fonctionnalités Databricks SQL, notamment aux tableaux de bord, aux queries et aux SQL Warehouse. Ce tutoriel utilise l'éditeur SQL pour vérifier l'accès aux données.

Pour toutes les autorisations d'accès et la façon de les gérer, consultez Autorisations d'accès.

Si trial-researchers n'est pas attribué, attribuez-le au workspace. Voir Attribuer un groupe à un workspace.

Gardez les chercheurs assignés afin qu’ils puissent se connecter avec leur identité d’utilisateur et revenir à celle-ci après avoir utilisé un rôle.

Accorder à chaque groupe un accès au SQL warehouse :

1. Dans la barre latérale du Workspace, cliquez sur SQL Warehouse .
2. Ouvrez la boîte de dialogue Autorisations du warehouse.
3. Ajoutez chaque groupe avec Peut utiliser , puis enregistrez.

Créez un dossier de test distinct pour chaque rôle dans un emplacement de workspace sans accès hérité étendu. Accordez role-study-1 Peut gérer sur son dossier et role-study-2 Peut gérer sur l'autre dossier. Les rôles utilisent ces dossiers pour créer des notebooks à l'étape 7. Consultez Gérer les objets de workspace et ACL de dossier.

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

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

SQL

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`;

Ne donnez pas de privilèges de données d'essai à trial-researchers. Ses membres reçoivent l'autorisation Assume à la place.

Vérifier les accès directs et hérités avant de tester :

• Le chercheur ne doit disposer d’aucune autre subvention ou appartenance à un groupe lui permettant de lire l’une ou l’autre des tables en tant qu’identité utilisateur.
• Aucun groupe parent ne donne à l'un ou l'autre rôle un accès aux données de l'autre étude.
• Vérifiez les autorisations de catalogue et de schéma ainsi que les autorisations de table : Une autorisation SELECT au niveau du catalogue ou du schéma s'applique aux objets enfants actuels et futurs et peut rendre les deux tables accessibles. Consultez Héritage des privilèges.

Utilisez le Autorisations tab de Catalog Explorer pour inspecter les droits accordés sur le catalogue, les deux schémas et les deux tables. Voir Gérer les privilèges dans Unity Catalog. Si des autorisations partagées empêchent cette configuration, utilisez un catalogue de test ou un workspace isolé. La suppression d’une autorisation partagée peut perturber des utilisateurs et des rôles qui ne sont pas liés.

Étape 5 : restreindre le partage des assets de workspace appartenant à un rôle

Sans restriction de partage, un utilisateur agissant en tant que rôle peut partager des assets de workspace qui appartiennent au rôle. Configurez la restriction pour les deux rôles :

1. En tant qu'administrateur du Workspace, cliquez sur votre nom d'utilisateur et sélectionnez Paramètres .
2. Cliquez sur Avancé .
3. Trouvez Restreindre le partage pour les groupes et cliquez sur le bouton de modification.
4. Ajoutez role-study-1 et role-study-2. Conservez tous les groupes déjà présents dans la liste.
5. Cliquez sur Enregistrer .

Cette restriction s’applique lors de l’utilisation d’un rôle restreint. Il contrôle le partage des assets du Workspace détenus par le rôle. Il ne contrôle pas les privilèges sur les objets Unity Catalog et ne bloque pas tous les moyens de copier des données. Voir Contrôles de partage des assets du Workspace.

Étape 6 : Vérifier l'accès aux données pour chaque identité

Un de vos chercheurs effectue ces vérifications en utilisant sa propre connexion :

1. Connectez-vous au workspace de test et vérifiez que votre nom d'utilisateur apparaît sous le nom du workspace.

2. Ouvrez l'éditeur SQL et sélectionnez le warehouse de test.

3. Exécuter chaque query séparément :

   SQL

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

   Les deux queries échouent avec des erreurs d'autorisation.

4. Cliquez sur le nom du workspace dans la barre supérieure, survolez le workspace actuel et sélectionnez role-study-1 dans le sélecteur de rôle.

5. Une fois le workspace rechargé, vérifiez le nom du rôle, ouvrez l'éditeur SQL, sélectionnez le même warehouse et répétez les deux queries. Seule la query de l'étude 1 aboutit.

6. Basculez vers role-study-2 et répétez les query. Seule la query Study 2 réussit.

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

Identité active	Étude 1 query	query Étude 2
Identité utilisateur du chercheur	Erreur d'autorisation	Erreur d'autorisation
role-study-1	Retourne study-1-a	Erreur d'autorisation
role-study-2	Erreur d'autorisation	Retourne study-2-a

Identité active	Étude 1 query	query Étude 2
Identité utilisateur du chercheur	Erreur d'autorisation	Erreur d'autorisation
role-study-1	Retourne study-1-a	Erreur d'autorisation
role-study-2	Erreur d'autorisation	Retourne study-2-a

Une table manquante, un warehouse indisponible ou une erreur d'authentification ne démontre pas un accès exclusif. Les vérifications du propriétaire du catalogue à l'étape 1 confirment que les deux tables existent. Si une query inattendue réussit, examinez les octrois et les adhésions de l'étape 4 avant de continuer.

Pour découvrir d'autres manières d'assumer un rôle, consultez Changer de rôle RBAC. Le changement de rôle dans ce navigateur ne modifie pas un profil ou une connexion Databricks CLI authentifié(e) séparément.

Étape 7 : vérifier le partage d’assets du Workspace

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

1. Assumez le rôle en utilisant le sélecteur de rôle.
2. Dans Workspace , faites un clic droit sur le dossier de test du rôle et sélectionnez Créer > Notebook .
3. Donnez au notebook le nom de l'étude. Vous n'avez pas besoin d'y exécuter de code.
4. Vérifiez que le rôle possède le nouveau Notebook, puis essayez de le partager. Le partage est indisponible lorsque vous agissez en tant que rôle restreint, même si vous disposez de l’autorisation Can Manage sur l’asset.

Utiliser un notebook créé en agissant en tant que rôle, et non un notebook appartenant au chercheur. Voir Créer un notebook et Vérifier la restriction.

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

En tant que lecteur d'audit, exécutez cette query. Remplacez <workspace-id> par l'ID du workspace de test :

SQL

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;

Recherchez les événements correspondant aux queries de test du chercheur et à la création de Notebooks. identity_metadata.run_by identifie le chercheur qui a initié chaque événement, et run_as identifie le rôle utilisé pour l'autorisation. Les filtres de query sur run_as_display_name, le nom lisible par l'homme du rôle. Les données d'audit sont mises à jour tout au long de la journée, il se peut donc qu'un événement récent n'apparaisse pas immédiatement. Consultez Référence des métadonnées d'identité.

Optionnel : gérer les rôles d’accès dans votre fournisseur d’identité

Utilisez cette alternative lorsque votre organisation gère le cycle de vie des groupes dans votre fournisseur d'identité. Synchronisez un groupe de rôles d'accès vide et un groupe de membres avec Databricks via le provisionnement SCIM (System for Cross-domain Identity Management). Consultez Synchroniser les utilisateurs et les groupes à partir de votre fournisseur d’identité à l’aide de SCIM.

Laissez chaque rôle d'accès vide dans votre fournisseur d'identité. Ajouter des membres à cet emplacement synchronise ces appartenances avec Databricks, où les membres héritent des privilèges de données sans assumer le rôle.

Start avec de nouveaux groupes de fournisseurs d’identité

Pour utiliser de nouveaux groupes de fournisseurs d'identité au lieu des rôles locaux au compte à l'étape 2, effectuez les étapes suivantes :

1. Dans votre fournisseur d’identité, créez un groupe vide pour chaque rôle d’accès.
2. Identifiez ou créez le groupe de membres contenant les chercheurs.
3. Synchronisez les rôles d'accès et le groupe de membres avec votre compte Databricks.
4. Accordez au groupe de membres la permission Assume sur chaque rôle d’accès en utilisant la procédure décrite dans l’ Étape 2.

Réutiliser un groupe de fournisseur d'identité existant

Si un groupe synchronisé à partir de votre fournisseur d'identité possède déjà les privilèges de données souhaités dans Databricks, vous pouvez conserver ces octrois en réutilisant le groupe en tant que rôle d'accès :

1. Créez un nouveau groupe de membres dans votre fournisseur d'identité. Par exemple, si le groupe existant est clinical-trial-1-ds, créez clinical-trial-1-ds-members.
2. Déplacez chaque membre du groupe existant vers le nouveau groupe de membres, en laissant le groupe existant vide.
3. Synchronisez les deux groupes avec 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 ou appartenances qui pourraient toujours donner aux chercheurs un accès permanent aux données.

Le groupe existant conserve ses privilèges de données et ses autorisations de workspace. Vous n'avez pas besoin de recréer ces octrois, mais vérifiez qu'ils correspondent à la limite de l'étude souhaitée. Planifiez la modification de l'adhésion avec les propriétaires du groupe, car les utilisateurs perdent les autorisations héritées lorsqu'ils quittent le groupe d'origine.

Terminer la configuration et les vérifications du workspace

Attribuez à la fois les rôles d’accès et le groupe de membres au workspace, puis configurez les droits et l’accès au compute comme décrit à l’ étape 3. Pour exiger la prise de rôle pour l’accès au workspace à la place, consultez Tutoriel : Exiger des utilisateurs qu’ils assument un rôle pour accéder au workspace.

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

Vérifiez que le groupe membre possède l'autorisation Assume sur chaque rôle d'accès. Tous ses membres peuvent alors assumer ce rôle.

Configurez les restrictions de partage et répétez les vérifications des données, du Data Sharing et de l’audit des étapes 5 à 8 en utilisant les noms de vos groupes de fournisseurs d’identité et vos datasets.

Nettoyer

Pour un test temporaire, supprimez uniquement les ressources et les octrois créés 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 :

   SQL

   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;

   Les suppressions de schéma échouent si d'autres objets subsistent. Ne supprimez pas un catalogue ou un schéma existant utilisé par d'autres charges de travail.

2. En tant qu'administrateur du workspace, supprimez les notebooks de test et les dossiers. Examinez tous les autres assets appartenant aux rôles avant de les supprimer.

3. Révoquez les autorisations de la permission Assume et les permissions de ressource créées pour le test, y compris les autorisations de catalogue et de warehouse. Supprimez les affectations de workspace réservées aux tests, tout en préservant 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 uniquement après avoir vérifié qu'aucune charge de travail ou aucun asset ne les utilise encore. Pour les groupes synchronisés, effectuez les changements de cycle de vie dans votre fournisseur d'identité 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 distinct qui restaure ses appartenances et attributions d’origine. N’utilisez pas le nettoyage de ressources de test pour supprimer un modèle d’accès existant.

Étapes suivantes

• • Gérer l’autorisation Assume
  • Gérez les personnes autorisées à assumer un rôle à l’aide de l’interface utilisateur ou de l’API.
• • Changer de rôle RBAC
  • Utilisez le sélecteur de rôle, le compute dédié, l’interface de ligne de commande (CLI) Databricks, l’API ou les outils de BI tiers.
• • Contrôlez le partage d'assets de workspace avec le RBAC
  • Examinez comment les contrôles de partage des assets du Workspace s’appliquent aux rôles et aux groupes imbriqués.
• • Modèles à usage combiné
  • Appliquez des filtres de lignes ou des masques de colonnes dans les tables auxquelles un rôle peut accéder.
• • Limitations du contrôle d'accès basé sur les rôles (RBAC)
  • Vérifiez la prise en charge des fonctionnalités, les problèmes connus et les restrictions de l’API de gestion de groupe.