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

Le contrôle d’accès Lakewatch est régi par Unity Catalog. Les ressources Lakewatch sont des objets sécurisés de Unity Catalog qui se trouvent dans un catalogue et un schéma que vous choisissez, et vous leur accordez l’accès à l’aide des privilèges de Unity Catalog. Les autorisations d’accès sont héritées dans la hiérarchie Unity Catalog. Ainsi, les privilèges accordés sur un catalogue ou un schéma s’appliquent également aux ressources Lakewatch qu’il contient.

Principals

L’accès est accordé à des principaux : utilisateurs individuels, principaux de service (identifiés par leur nom ou par 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 recommandée basée sur l’équipe qui associe les groupes aux rôles de sécurité, voir Configurer le contrôle d’accès.

Ressources Lakewatch en tant qu’objets sécurisables Unity Catalog

Ces ressources Lakewatch sont des sécurisables du catalogue Unity et se trouvent sous un catalogue et un schéma que vous choisissez :

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

Vous les organisez comme n’importe quelle autre donnée du catalogue Unity, par exemple un catalogue par environnement (dev/staging/prod) et un schéma par équipe. Consultez Modèles de déploiement pour découvrir les configurations recommandées.

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

• Les requêtes 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 alertessont dérivés des règles de détection : une règle produit des signaux, qui sont compilés en alertes. Ce ne sont pas des éléments sécurisables distincts, donc vous n’accordez pas d’autorisations directement sur ceux-ci. Les privilèges de sécurité des données (READ_SECURITY_DATA et UPDATE_SECURITY_DATA) sur la règle parente ou la source de données contrôlent l’accès à celles-ci (voir Héritage).

Environnements et dossiers

Lakewatch enregistre les catalogues et schémas du catalogue Unity qui contiennent vos ressources sous forme d’environnements et de dossiers :

• Un environnement est un catalogue enregistré auprès de Lakewatch (la portée principale pour ses ressources). Un environnement n’est disponible que depuis l’espace de travail auquel son catalogue est lié (voir liaison entre les espaces de travail et catalogue).
• Un dossier est un schéma enregistré sous ce catalogue dans Lakewatch. Les sources de données et les règles de détection résident dans des dossiers, et les privilèges que vous accordez à un dossier s’appliquent à chaque ressource qu’il contient.

Les environnements et dossiers sont une vue sur l’organisation catalogue par environnement, schéma par équipe décrite dans les modèles de déploiement ; ils ne modifient pas la manière dont l’accès est accordé. Les permissions de dossier sont des autorisations Unity Catalog sur le schéma sous-jacent, donc les privilèges et l’héritage s’appliquent sans modification.

Privilèges

Vous accordez l’accès avec des privilèges de catalogue Unity sur un catalogue, un schéma ou une ressource individuelle. Lakewatch définit des privilèges pour lire la configuration d’une ressource, gérer la ressource, gérer son accès, ainsi que lire ou mettre à jour les données de sécurité (signaux et alertes) qu’elle produit. Pour la liste complète par type de ressource et ce que chaque privilège permet, voir Rôles et capacités.

Pour créer une ressource, un principal doit disposer de USE CATALOG sur le catalogue et de 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 : en eux-mêmes, ils permettent à un principal d’accéder au catalogue et au schéma mais n’accordent pas la possibilité de visualiser une ressource (ce qui nécessite READ_METADATA) ou d’en créer une.

Parce que chaque ressource Lakewatch est un objet sécurisable de Unity Catalog, tout accès à l’une d’elles (y compris la simple visualisation) 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, comme une table, donc accorder à quelqu’un un accès en affichage à une source de données ou à une règle de détection (READ_METADATA) signifie aussi lui accorder USE CATALOG et USE SCHEMA, même si ces deux privilèges seuls ne révèlent pas la ressource.

Inheritance

Les autorisations d’accès sont héritées dans la hiérarchie Unity Catalog : catalogue → schéma → ressource. Un privilège accordé sur un catalogue ou un schéma s’applique à chaque ressource Lakewatch qui en dépend, donc vous pouvez l’accorder de manière générale au niveau du catalogue ou du schéma plutôt que ressource par ressource.

La configuration recommandée accorde les privilèges de chaque groupe au niveau du catalogue, donc ils s’appliquent à chaque schéma et ressource du catalogue. Pour réduire plus précisément 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 autorisations propres. L’accès est hérité de la règle de détection parent ou de la source de données, mais grâce à un privilège distinct de la lecture de la configuration du parent :

• Le privilège READ_METADATA sur une règle de détection ou une source de données permet de consulter cette ressource et sa configuration. Il n’accorde pas, à lui seul, l’accès aux signaux et alertes produits par la ressource.
• La visualisation de ces signaux et alertes nécessite READ_SECURITY_DATA sur la ressource parent (un privilège distinct de READ_METADATA).
• La mise à jour d’une alerte nécessite le privilège UPDATE_SECURITY_DATA sur la ressource parente. Les signaux sont immuables.

Propriété

Le principal qui crée une ressource Lakewatch en devient le propriétaire, avec le contrôle total de 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.

Settings

Les paramètres de Lakewatch sont liés à un catalogue et s’appliquent à toutes les ressources Lakewatch de ce catalogue. Un principal disposant du privilège 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 pertinent (CREATE_DATASOURCE ou CREATE_RULE) peut y créer des ressources Lakewatch et possède ce qu’il crée. Dans le catalogue par défaut de l’espace de travail, les utilisateurs de l’espace de travail ont USE CATALOG et USE SCHEMA par défaut, mais CREATE_DATASOURCE et CREATE_RULE ne sont pas accordés par défaut, donc un utilisateur doit bénéficier du privilège de création pertinent avant de pouvoir créer des ressources Lakewatch à cet endroit. Pour configurer Lakewatch pour une équipe, suivez les instructions de Configurer le contrôle d’accès, qui permettent de créer les groupes, un principal de service utilisé pour l’exécution et les attributions de privilèges nécessaires. 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 repose principalement sur la propriété des ressources : une vérification des privilèges est satisfaite si le privilège a été explicitement accordé ou si le principal est propriétaire de la ressource. Lakewatch ne dispose d’aucun mécanisme distinct permettant aux administrateurs de contourner ces contrôles. Les administrateurs de compte et les administrateurs de métastore peuvent néanmoins devenir propriétaires des ressources ou s’accorder le privilège MANAGE à l’aide des privilèges d’administration d’Unity Catalog. Si le propriétaire d’une ressource n’est plus disponible (par exemple, la personne part ou un principal de service est supprimé) et qu’aucun autre principal ne détient MANAGE, l’accès peut être difficile à récupérer, Databricks recommande donc d’attribuer la propriété des ressources de production à un groupe. Voir les modèles de déploiement.

Tâches planifiées et principal utilisé pour l’exécution

Chaque source de données et chaque règle de détection enregistre un principal utilisé pour l’exécution. Vous la choisissez lors de la création de la ressource (votre propre identité, ou un principal de service que vous avez la permission d’utiliser), et seule une personne ayant MANAGE sur la ressource peut la modifier. Les pipelines d’ingestion et de détection programmés pour la ressource s’exécutent sous cette identité, ce principal doit donc se voir accorder l’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 principal de service à cet effet et lui accorder l’accès dont ses tâches planifiées ont besoin, voir Configurer le contrôle d’accès.