Rôles et fonctionnalités

Important

Lakewatch est en aperçu privé. Pour demander l’accès, contactez votre équipe de comptes Azure Databricks.

Lakewatch gouverne chaque type de ressource avec les privilèges du catalogue Unity. Cette référence liste les privilèges pour les sources de données, les règles de détection, les signaux, les alertes et les requêtes, ainsi que la capacité que chacune accorde.

Comment les privilèges sont organisés

Chaque ressource Lakewatch (source de données et règle de détection) possède deux groupes de privilèges :

  • Les privilèges de la ressource gouvernent la ressource elle-même : lire sa configuration, la gérer, et gérer son accès.
  • Les privilèges de sécurité des données régissent les sorties de la ressource : les signaux et alertes qui en sont dérivés.

Vous pouvez accorder un privilège directement sur une ressource, ou l’accorder sur le schéma parent ou le catalogue et le laisser hériter aux ressources en dessous.

Databricks recommande quatre groupes correspondant aux rôles d’une équipe de sécurité. Chaque groupe reçoit un ensemble fixe de privilèges sur le catalogue Lakewatch. Pour les commandes qui créent ces groupes et appliquent ces subventions, voir Configurer le contrôle d’accès.

Group Privilèges sur le catalogue
lakewatch-admins USE CATALOG, USE SCHEMA, READ_METADATAMANAGE, , SELECT, , CREATE_DATASOURCECREATE_RULECREATE_SECRETREAD_SECURITY_DATAMODIFYUPDATE_SECURITY_DATA
lakewatch-data-engineers USE CATALOG, USE SCHEMA, CREATE_DATASOURCE, CREATE_SECRET, SELECT, MODIFY, CREATE TABLE, CREATE SCHEMA
lakewatch-detection-engineers USE CATALOG, USE SCHEMA, CREATE_RULE, READ_METADATA, READ_SECURITY_DATA, SELECT
lakewatch-analysts USE CATALOG, USE SCHEMA, READ_SECURITY_DATA, UPDATE_SECURITY_DATA, SELECT, READ_METADATA

Ce que chaque rôle peut accomplir

Ces privilèges sont accordés dans le catalogue, ils héritent donc de chaque schéma et ressource qui s’y trouve. L’accès d’un groupe couvre donc toutes les ressources Lakewatch de ce catalogue, y compris celles créées par d’autres utilisateurs, et pas seulement celles créées par ses propres membres. Cet accès provient de la subvention de catalogue, et non d’une dérogation administrateur : comme le modèle de contrôle d’accès n’a pas de dérogation, un groupe atteint exactement ce que ses subventions couvrent et rien dans un catalogue où il ne détient aucune subvention.

  • lakewatch-admins gèrent l’ensemble du catalogue : ils créent, visualisent, modifient, suppriment et partagent à nouveau toute source de données ou règle de détection (MANAGE), lisent et mettent à jour toutes les données de sécurité produites par ces ressources, interrogent toutes les données (SELECT), et modifient les paramètres Lakewatch du catalogue.
  • lakewatch-data-engineers créer et posséder des sources de données, créer des tables et des schémas, et interroger et écrire les données à travers le catalogue (SELECT, MODIFY).
  • lakewatch-detection-engineers créer des règles de détection, consulter toute source de données ou règle de détection dans le catalogue (READ_METADATA), lire les données de sécurité produites par ces ressources (READ_SECURITY_DATA), et interroger les données (SELECT).
  • lakewatch-analysts Travailler la file d’alerte à travers le catalogue : ils lisent et mettent à jour les données de sécurité (alertes et signaux) produites par toute règle ou source de données (READ_SECURITY_DATA, UPDATE_SECURITY_DATA), interrogent les tables et signaux sous-jacents (SELECT), et consultent la configuration des ressources (READ_METADATA).

Un groupe n’atteint les ressources d’un autre membre que dans la mesure où ses privilèges accordés s’étendent : la visualisation d’une ressource a besoin READ_METADATAde , et le travail avec ses données de sécurité nécessitent le privilège de données de sécurité correspondant. La propriété ajoute toujours un contrôle total, donc celui qui crée une ressource peut la gérer indépendamment de l’appartenance au groupe, et changer une ressource ou son accès nécessite MANAGE une propriété.

Partagez une ressource avec votre équipe

Vous possédez ce que vous créez, et la propriété inclut le droit d’accorder l’accès à d’autres. Pour partager une règle de détection ou une source de données, accordez le privilège correspondant à ce que le destinataire doit faire :

  • Pour leur permettre de le voir , accordez READ_METADATA.
  • Pour leur permettre de voir les alertes et les signaux qu’il produit, accordez-vous READ_SECURITY_DATA.
  • Pour leur permettre de l’éditer, supprimer ou co-gérer , accordez MANAGE.

Il n’est pas nécessaire MANAGE de rendre une ressource visible à l’équipe. MANAGE c’est seulement pour laisser les autres la changer. Avec la configuration recommandée, les groupes d’équipe détiennent déjà ces privilèges sur le catalogue partagé, donc les ressources que vous créez là-bas sont automatiquement partagées avec l’équipe. Accordez sur une ressource individuelle uniquement lorsque vous devez élargir l’accès au-delà des paramètres par défaut du groupe.

Sources de données et règles de détection

Les sources de données et les règles de détection partagent les mêmes privilèges de ressources et de données de sécurité. Ils ne diffèrent que par le privilège de création (CREATE_DATASOURCE pour une source de données, CREATE_RULE pour une règle de détection) :

Privilège Grants
READ_METADATA Lisez la ressource et sa configuration.
MANAGE Gérez la ressource : mettez à jour, supprimez et transférez la propriété. Cela ne permet pas à lui seul l’accès à la lecture ou aux données.
MANAGE_ACCESS_CONTROL Accordez et révoquez des privilèges sur la ressource.
READ_SECURITY_DATA Lisez les données de sécurité produites par la ressource (ses signaux et alertes).
UPDATE_SECURITY_DATA Mettez à jour ces données de sécurité (par exemple, mettez à jour une alerte).

Pour créer une source de données, il faut USE CATALOG que vous soyez sur le catalogue, USE SCHEMA sur le schéma et CREATE_DATASOURCE sur le schéma parent. Pour créer une règle de détection, il faut les mêmes USE CATALOG privilèges et USE SCHEMA les mêmes et sur CREATE_RULE le schéma parent.

L’accès à une ressource possédée par un autre utilisateur suit ces mêmes privilèges, qu’il s’agisse d’une source de données ou d’une règle de détection :

  • Pour la voir , il faut READ_METADATA être sur la ressource, ou sur un schéma ou un catalogue au-dessus.
  • Pour l’éditer, supprimer ou transférer , vous devez MANAGE, ou vous devez en être le propriétaire. MANAGE Seul ne vous permet pas de consulter une ressource ; associez-la à READ_METADATA.
  • Pour changer qui peut y accéder , il faut MANAGE_ACCESS_CONTROL (inclus dans MANAGE), ou la propriété.

Dans chaque cas, le principal doit USE CATALOG également avoir sur le catalogue et USE SCHEMA sur le schéma contenant la ressource, car une source de données ou une règle de détection est sécurisée par Unity Catalog que le principal doit pouvoir atteindre avant que tout privilège ne prenne effet. C’est pourquoi accorder l’accès à la vue seul (READ_METADATA) ne suffit pas sans USE CATALOG et USE SCHEMA. Voir modèle de contrôle d’accès.

Signaux et alertes (artefacts dérivés)

Les signaux et les alertes sont des artefacts dérivés. Ce ne sont pas des sécurisables séparés, donc les privilèges de sécurité des données sur la règle de détection parent ou l’accès au contrôle de la source de données à eux :

Pour… Vous avez besoin de cela sur la règle parent ou la source de données
Voir ou lister les signaux et alertes READ_SECURITY_DATA
Mettre à jour une alerte UPDATE_SECURITY_DATA

Les signaux sont immuables, donc seules les alertes peuvent être mises à jour.

Queries

Vous gérez l’accès aux requêtes via l’application Lakewatch, en utilisant ces niveaux d’autorisation :

Niveau d’autorisation Grants
CAN_VIEW Consultez la requête et ses résultats.
CAN_RUN Exécutez la requête.
CAN_EDIT Modifier et enregistrer la requête.
CAN_MANAGE Gérez la requête, y compris son accès. Le créateur de la requête comprend ceci.