Partager via


Présentation des salles blanches Azure Databricks

Cet article présente les salles blanches, une fonctionnalité Azure Databricks qui utilise Delta Sharing et le calcul serverless pour fournir un environnement sécurisé et de protection de la confidentialité où plusieurs parties peuvent travailler ensemble sur des données d’entreprise sensibles sans accéder directement aux données des autres.

Spécifications

Pour pouvoir utiliser des salles propres, vous devez disposer des éléments suivants :

Comment fonctionnent les salles blanches ?

Lorsque vous créez une salle blanche, vous créez les éléments suivants :

  • Un objet de salle blanche sécurisable dans votre metastore Unity Catalog.
  • La salle blanche « centrale », qui est un environnement éphémère isolé géré par Databricks.
  • Un objet de salle blanche sécurisable dans le metastore Unity Catalog de votre collaborateur.

Les tables, volumes (données non tabulaires), vues et blocs-notes partagés par chaque collaborateur dans la salle propre ne sont partagés qu'avec la salle propre centrale grâce à Delta Sharing.

Les collaborateurs ne peuvent pas voir les données dans les tables, vues ou volumes d’autres collaborateurs, mais ils peuvent voir les noms de colonnes et les types de colonnes, et ils peuvent exécuter du code de notebook approuvé qui fonctionne sur les ressources de données. Le code du notebook s’exécute dans la salle blanche centrale. Les blocs-notes peuvent également générer des tables de sortie qui permettent à votre collaborateur d’enregistrer temporairement la sortie en lecture seule dans leur metastore Du catalogue Unity afin qu’ils puissent l’utiliser dans leurs espaces de travail.

Architecture et flux simples des salles propres, avec des tables de sortie

Comment les salles blanches garantissent-elles un environnement sans confiance ?

Le modèle de salles blanches Databricks est « sans confiance ». Tous les collaborateurs d’une salle blanche sans confiance ont des privilèges égaux, y compris le créateur de la salle blanche. Les salles propres sont conçues pour empêcher l’exécution de code non autorisé et le partage non autorisé de données. Par exemple, tous les collaborateurs doivent approuver un notebook avant de pouvoir l’exécuter. Cette approbation est appliquée implicitement en empêchant un collaborateur d’exécuter un notebook qu’il a créé lui-même : vous ne pouvez exécuter qu’un notebook créé par l’autre collaborateur.

Protections ou restrictions supplémentaires

Les protections suivantes sont en place en plus du processus d’approbation implicite du notebook mentionné ci-dessus :

  • Une fois qu’une salle blanche est créée, elle est verrouillée pour empêcher les nouveaux collaborateurs de rejoindre la salle blanche.

  • Si un collaborateur supprime la salle blanche, la salle blanche centrale est vide et aucune tâche de salle blanche ne peut être exécutée par n’importe quel utilisateur.

  • Pendant la préversion publique, chaque salle blanche est limitée à deux collaborateurs.

  • Vous ne pouvez pas renommer la salle blanche.

    Le nom de la salle blanche doit être unique dans le metastore de chaque collaborateur, afin que tous les collaborateurs puissent faire référence à la même salle blanche sans ambiguïté.

  • Les commentaires sur la salle blanche sécurisables dans l’espace de travail de chaque collaborateur ne sont pas propagés à d’autres collaborateurs.

Qu’est-ce qui est partagé avec d’autres collaborateurs ?

  • Nom de la salle blanche.
  • Cloud et région de la salle blanche centrale.
  • Nom de votre organisation (qui peut être n’importe quel nom que vous choisissez).
  • Identificateur de partage de salle propre (ID global metastore + ID d’espace de travail + adresse e-mail de l’utilisateur).
  • Alias de tables, vues ou volumes partagés.
  • Métadonnées de colonne (nom de colonne ou alias et type).
  • Notebooks (en lecture seule).
  • Tables de sortie (lecture seule, temporaire).
  • Table système des événements de salle blanche.
  • Historique des exécutions, notamment :
    • Nom du notebook en cours d’exécution
    • Collaborateur qui a exécuté le notebook (et non l’utilisateur).
    • État de l’exécution du notebook.
    • Heure de début de l’exécution du notebook.

Qu’est-ce qui est partagé avec la salle blanche centrale ?

  • Tout ce qui est répertorié dans la section précédente.

  • Tables, volumes, vues et blocs-notes en lecture seule.

    Les tables, vues et volumes sont enregistrés dans le metastore de la salle blanche centrale avec tous les alias fournis. Les ressources de données sont partagées tout au long du cycle de vie de la salle propre.

Questions fréquentes (FAQ) sur les salles propres

Les questions suivantes sont fréquemment posées sur les salles propres.

Comment mes données sont-elles gérées dans une salle propre ?

La salle propre centrale est gérée par Azure Databricks. Dans la salle propre centrale :

  • Aucun des tiers n’a de privilèges d’administrateur.
  • Seules les métadonnées sont visibles par toutes les parties.
  • Chaque partie peut ajouter des données à la salle blanche centrale.
  • Les salles propres utilisent le partage Delta pour partager des données en toute sécurité dans la salle propre, mais pas entre les participants. Consultez Qu’est-ce que le Delta Sharing ?.

Comment mes données sont-elles conservées privées ?

Les salles blanches centrales s’exécutent dans un environnement de calcul serverless, isolé et géré par Databricks, hébergé dans une région du fournisseur cloud choisie par le créateur de la salle blanche.

Les chambres propres fournissent :

  • Approbation du code  : le créateur de la salle blanche et les collaborateurs peuvent partager des tables et des volumes avec la salle blanche centrale, mais peuvent exécuter uniquement les blocs-notes chargés par l’autre partie. Vous pouvez passer en revue le code ajouté par l’autre partie avant d’approuver. Si vous exécutez un bloc-notes ajouté par un autre tiers, vous approuvez implicitement le code.
  • Contrôle de version : Les blocs-notes des environnements contrôlés sont dotés d’un contrôle de version pour s’assurer que toutes les parties peuvent exécuter des blocs-notes entièrement approuvés uniquement. Seule la version la plus récente d’un notebook peut être exécutée. Vous pouvez utiliser le tableau du système de salles blanches pour déterminer la version du notebook qui a été exécutée et surveiller les modifications apportées.
  • Accès restreint : Lorsque vous créez une salle propre, vous pouvez utiliser le contrôle de sortie serverless pour gérer les connexions réseau sortantes. Si vous limitez l’accès à partir de votre salle propre, l’accès au stockage non autorisé est bloqué. Consultez Qu’est-ce que le contrôle de sortie serverless ?.

Pour en savoir plus sur la sécurité et le réseau du plan de calcul serverless, consultez Mise en réseau du plan de calcul serverless.

Comment les actions sont-elles enregistrées ?

Les actions de salle blanche effectuées par vous ou vos collaborateurs sont enregistrées dans la table système des événements de salle blanche. Ces enregistrements incluent des métadonnées détaillées sur l’action spécifique effectuée. Consultez la table de référence du système d'événements de salle blanche.

Les actions de salle blanche sont également enregistrées dans le journal d’audit de votre compte sous le service clean-room. Consultez Référence de table système du journal d’audit.

Limites

Pendant la préversion publique, les limitations suivantes s’appliquent :

  • Aucune bibliothèque Scala d’informations d’identification de service n’est incluse dans la version de Databricks Runtime requise.

Quotas de ressources

Azure Databricks applique des quotas de ressources sur tous les objets sécurisables de salle blanche. Ces quotas sont répertoriés dans les limites de ressources. Si vous prévoyez de dépasser ces limites de ressources, contactez l’équipe de votre compte Azure Databricks.

Vous pouvez surveiller l’utilisation de vos quotas à l’aide des API de quotas de ressources d’Unity Catalog. Consultez Surveiller l’utilisation de vos quotas de ressources Unity Catalog.

Démarrage