Modèle de contrôle d'accès

info

Aperçu

Lakewatch est en aperçu privé. Pour demander l’accès, veuillez contacter votre équipe de compte Databricks.

Le contrôle d’accès Lakewatch est régi par Unity Catalog. Les ressources Lakewatch sont des éléments sécurisables d'Unity Catalog qui résident dans un catalogue et un schéma que vous choisissez, et auxquels vous accédez à l'aide des privilèges Unity Catalog. L’accès est hérité de la hiérarchie Unity Catalog : une autorisation sur un catalogue ou un schéma s’applique aux ressources Lakewatch situées en dessous.

Principals

L'accès est accordé aux principaux : utilisateurs individuels, Service Principal (identifiés par leur nom ou applicationId) et groupes. Lakewatch ne nécessite aucun rôle ou groupe prédéfini, et vous pouvez utiliser n'importe quelle identité prise en charge par Unity Catalog. Pour une configuration par équipe recommandée qui associe les groupes aux rôles de sécurité, voir Configurer le contrôle d'accès.

Ressources Lakewatch en tant que ressources sécurisables Unity Catalog

Ces ressources Lakewatch sont des objets sécurisables Unity Catalog et résident sous un catalogue et un schéma que vous choisissez :

• Sources de données
• Règles de détection

Vous pouvez les organiser comme n’importe quelle autre donnée Unity Catalog, par exemple un catalogue par environnement (dev/staging/prod) et un schéma par équipe. Voir Modèles de déploiement pour les modèles suggérés.

Deux groupes de ressources sont régis par Unity Catalog, mais traités différemment :

• Les queries sont gérées via l’application Lakewatch, en utilisant leurs propres niveaux d’autorisation plutôt que les privilèges que vous accordez sur les sources de données et les règles de détection.
• Les signaux et les alertes sont dérivés des règles de détection : une règle produit des signaux, qui sont collationnés en alertes. Ce ne sont pas des objets sécurisables distincts, vous n'accordez donc pas de droits directement sur eux. Les privilèges de données de sécurité (READ_SECURITY_DATA et UPDATE_SECURITY_DATA) sur la règle parente ou la source de données contrôlent leur accès (voir Héritage).

Environnements et dossiers

Lakewatch enregistre les catalogues et schémas Unity Catalog qui contiennent vos ressources en tant qu’ environnements et dossiers :

• Un environnement est un catalogue enregistré auprès de Lakewatch (l’étendue de niveau supérieur pour ses ressources). Un environnement n’est accessible qu’à partir de l’espace de travail auquel son catalogue est lié (voir Liaison entre un Workspace et un catalogue).
• Un dossier est un schéma enregistré avec Lakewatch sous ce catalogue. Les sources de données et les règles de détection se trouvent dans des dossiers, et les privilèges que vous accordez sur un dossier s'appliquent à toutes les ressources qu'il contient.

Les environnements et les dossiers sont une vue sur l'organisation un catalogue par environnement, un schéma par équipe décrite dans les modèles de déploiement ; ils ne modifient pas la façon dont l'accès est accordé. Les autorisations de dossier sont des autorisations Unity Catalog sur le schéma de sauvegarde, donc les Privilèges et l' Héritage s'appliquent sans modification.

Privilèges

Vous pouvez accorder l’accès grâce aux privilèges Unity Catalog sur un catalogue, un schéma ou une ressource individuelle. Lakewatch définit des privilèges pour la lecture de la configuration d’une ressource, la gestion de la ressource, la gestion de son accès et la lecture ou la mise à jour des données de sécurité (signaux et alertes) qu’elle produit. Pour obtenir la liste complète par type de ressource et connaître les possibilités de chaque privilège, consultez la section Rôles et fonctionnalités.

Pour créer une ressource, un principal doit disposer de USE CATALOG sur le catalogue et USE SCHEMA sur le schéma, ainsi que du privilège de création sur ce schéma ou catalogue : CREATE_DATASOURCE pour une source de données ou CREATE_RULE pour une règle de détection. USE CATALOG et USE SCHEMA sont des privilèges de traversée : eux seuls permettent à un principal d’accéder au catalogue et au schéma, mais ne permettent pas d’afficher une ressource (ce qui nécessite READ_METADATA) ou d’en créer une.

Comme chaque ressource Lakewatch est un élément sécurisable Unity Catalog, tout accès à celle-ci (y compris le simple affichage) nécessite USE CATALOG sur son catalogue et USE SCHEMA sur son schéma, en plus du privilège pour l’action elle-même. Unity Catalog applique cette règle à chaque objet qu'il gouverne, par exemple une table. Accorder à un utilisateur un droit de lecture sur une source de données ou une règle de détection (READ_METADATA) signifie donc également lui accorder les droits USE CATALOG et USE SCHEMA, bien que ces deux privilèges ne révèlent pas la ressource eux-mêmes.

Héritage

L'accès circule vers le bas dans la hiérarchie Unity Catalog : catalogue → schéma → ressource . Un privilège accordé sur un catalogue ou un schéma s'applique à toutes les ressources Lakewatch situées en dessous. Vous pouvez donc accorder des accès étendus au niveau du catalogue ou du schéma au lieu de les accorder ressource par ressource.

La configuration recommandée accorde les privilèges de chaque groupe au niveau du catalogue, afin qu’ils s’appliquent à chaque schéma et ressource dans le catalogue. Pour limiter la portée d’un groupe, accordez plutôt les mêmes privilèges au niveau du schéma.

Les signaux et les alertes sont des artefacts dérivés sans octroi d'accès. L'accès est hérité de la règle de détection ou de la source de données parente, mais via un privilège différent de la lecture de la configuration du parent :

• READ_METADATA sur une règle de détection ou une source de données vous permet de lire cette ressource et sa configuration. Il n’accorde pas, par lui-même, l’accès aux signaux et alertes que la ressource produit.
• L'affichage de ces signaux et alertes nécessite READ_SECURITY_DATA sur la ressource parente (un privilège distinct de READ_METADATA).
• La mise à jour d'une alerte suit le privilège UPDATE_SECURITY_DATA sur la ressource parente. Les signaux sont immuables.

Propriété

Le principal qui crée une ressource Lakewatch devient son propriétaire , avec un contrôle total sur la ressource, y compris la gestion de son accès. La propriété peut être transférée et l’accès peut être partagé plus largement en accordant des privilèges à d’autres principaux.

Paramètres

Les paramètres Lakewatch sont liés à un catalogue et s’appliquent à toutes les ressources Lakewatch situées en dessous. Un principal disposant de MANAGE sur le catalogue peut modifier les paramètres de ce catalogue.

Intégration et administration

Un utilisateur qui dispose de USE CATALOG sur un catalogue, de USE SCHEMA sur un schéma et du privilège de création approprié (CREATE_DATASOURCE ou CREATE_RULE) peut y créer des ressources Lakewatch et possède ce qu'il crée. Dans le catalogue default de Workspace, les utilisateurs de Workspace ont par défaut USE CATALOG et USE SCHEMA, mais CREATE_DATASOURCE et CREATE_RULE ne sont pas accordés par défaut, donc un utilisateur doit disposer du privilège de création approprié avant de pouvoir y créer des Ressources Lakewatch. Pour configurer Lakewatch pour une équipe, suivez Configurer le contrôle d’accès, qui crée les groupes, un service principal d’exécution et les autorisations requises. Vous pouvez déléguer la gestion d'un ensemble de ressources en accordant MANAGE sur le catalogue ou le schéma.

Le contrôle d'accès est principalement basé sur le propriétaire : une vérification des privilèges est satisfaite par un octroi explicite ou par la possession de la ressource, et Lakewatch n'a pas de remplacement d'administrateur séparé. Les administrateurs de compte et les administrateurs de métastore peuvent toujours prendre possession ou s’accorder MANAGE via les privilèges d’administrateur de Unity Catalog. Si le propriétaire d'une ressource est perdu (par exemple, la personne quitte l'entreprise ou un service principal est supprimé) et qu'aucun autre principal ne détient MANAGE, l'accès peut être difficile à récupérer. Databricks recommande donc de faire appartenir les ressources de production à un groupe. Voir Modèles de déploiement.

Jobs planifiés et principal « run-as »

Chaque source de données et règle de détection enregistre un principal d’exécution . Vous choisissez cette identité au moment de la création de la ressource (votre propre identité, ou un service principal que vous êtes autorisé à utiliser), et seul un utilisateur disposant des autorisations MANAGE sur la ressource peut la modifier. Les pipelines d’ingestion et de détection planifiés pour la ressource s’exécutent en tant que ce principal, il doit donc avoir accès aux tables auxquelles la source de données ou la règle de détection fait référence. Pour créer un service principal à cette fin et lui accorder l’accès dont ses jobs planifiés ont besoin, consultez Configurer le contrôle d’accès.