Politiques ABAC au niveau du métastore (bêta)

info

Bêta

Les politiques de contrôle d'accès basé sur les attributs (ABAC) au niveau du métastore sont en bêta. Vous pouvez associer des politiques ABAC au niveau du métastore, la racine de la hiérarchie d'objets Unity Catalog, afin qu'une seule politique s'applique à l'ensemble des catalogues du métastore.

Le métastore est une portée valide pour les politiques ABAC. Une politique rattachée au métastore s’applique à l’ensemble des catalogues, des schémas et des objets pris en charge par chaque type de politique au sein du métastore, y compris les objets créés après la définition de la politique. Cela offre aux équipes chargées de la gouvernance un emplacement unique pour définir des règles de protection des données à l’échelle de l’organisation, sans avoir à configurer ni à répliquer une politique pour chaque catalogue. Un métastore ne pouvant pas être étiqueté directement, les politiques basées sur les tags associent les objets aux tags gouvernés appliqués aux catalogues et aux objets de niveau inférieur.

Les quatre types de politiques ABAC sont pris en charge au niveau du métastore : filtre de lignes, masquage de colonnes, GRANT et DENY (bêta). Une politique au niveau du métastore utilise les mêmes champs, conditions et comportement d'évaluation que n'importe quelle autre politique ABAC. Seule sa portée diffère.

Vous pouvez créer et gérer des politiques au niveau du métastore à l'aide de Catalog Explorer, de SQL ou de l'API REST. Pour un aperçu de l'ABAC et des concepts fondamentaux, y compris les tags gouvernés et les fonctions intégrées telles que has_tag et has_tag_value, consultez Concepts fondamentaux pour le contrôle d'accès à base d'attributs (ABAC).

Prérequis

Exigences en matière de compute

L’utilisation de SQL pour créer, modifier ou supprimer des politiques au niveau des métastores nécessite un compute exécutant Databricks Runtime 19 ou une version ultérieure.

Exigences d’autorisation

La création, la mise à jour et la suppression de stratégies au niveau du métastore nécessitent le rôle administrateur du métastore.
L’affichage et la consultation des stratégies au niveau du métastore nécessitent READ METADATA ou le rôle d’administrateur du métastore.

Fonctionnement des stratégies au niveau du métastore

Une politique au niveau des métastores est héritée le long de la hiérarchie d’objets selon les mêmes règles que les autres politiques ABAC :

Une seule politique couvre l’ensemble du métastore. Une politique associée au métastore est évaluée pour chaque objet du type nommé dans la clause FOR dans l’ensemble des catalogues et schémas du métastore.
Les nouveaux catalogues sont pris en compte automatiquement. Un catalogue créé après la définition de la politique est pris en compte lorsqu’il correspond aux conditions de celle-ci, sans action de la part du propriétaire ou de l’administrateur du catalogue.
Le comportement correspond aux politiques de niveau inférieur. Les politiques au niveau du metastore présevent les fonctionnalités standard et le comportement d'évaluation de chaque type de politique, tels que la précédence DENY, les liaisons de Workspace et la composition des filtres de lignes. Il n'y a aucune logique d'évaluation spécifique à la portée du métastore.

Un métastore ne pouvant pas être étiqueté directement, si une politique au niveau du métastore utilise une condition de balise, appliquez la balise régie à chaque catalogue ou objet de niveau inférieur auquel vous souhaitez que la politique corresponde.

Cibles de politiques prises en charge

Une politique au niveau du métastore peut s’appliquer à (FOR) tous les types sécurisables pris en charge par son type de politique au niveau du catalogue :

Les politiques de filtrage des lignes et de masquage des colonnes s’appliquent à FOR TABLES, ce qui inclut les tables de streaming, les vues matérialisées et les vues (bêta).
Les politiques GRANT s'appliquent aux types d'éléments sécurisables répertoriés dans Types d'éléments sécurisables et privilèges pris en charge.
Les politiques DENY s'appliquent aux types sécurisables répertoriés dans Types sécurisables et privilèges pris en charge.

Les politiques GRANT et DENY ne peuvent pas cibler des objets non associés à un catalogue dans le métastore, tels que des emplacements externes, des identifiants de stockage, des partages, des destinataires, des fournisseurs et des connexions. Consultez Limitations.

Créer une stratégie au niveau du métastore

Vous pouvez créer une politique au niveau du métastore à l’aide de l’interface utilisateur de Catalog Explorer, de l’instruction SQL CREATE POLICY ou de l’ API REST.

Catalog Explorer
SQL
REST API

Dans votre workspace Databricks, cliquez sur Catalog .
En haut du volet Catalog , cliquez sur l’icône en forme d’engrenage et sélectionnez Metastore .
Cliquez sur l’onglet tab .
Cliquez sur New policy .
Renseignez les champs de politique requis pour le type de politique sélectionné. Le champ Portée est défini sur le métastore actuel.
Cliquez sur Create policy .

Associez la politique avec ON METASTORE. La politique cible le métastore sur lequel vous opérez actuellement. Ne spécifiez pas de nom de métastore. Consultez Limitations.

La politique de masquage de colonne suivante masque chaque colonne étiquetée ssn dans toutes les tables du métastore, pour tous les utilisateurs du compte à l'exception du groupe HR admins :

SQL
CREATE POLICY ssn_mask
ON METASTORE
COLUMN MASK ssn_to_last_nr
TO `account users` EXCEPT `HR admins`
FOR TABLES
MATCH COLUMNS has_tag('ssn') AS ssn
ON COLUMN ssn
USING COLUMNS (4);

La politique DENY suivante empêche les utilisateurs non administrateurs de gérer le contrôle d’accès sur chaque table étiquetée sensitive dans le métastore. Elle s’applique à tous les utilisateurs du compte à l’exception du groupe data_admins :

SQL
CREATE POLICY managed_access
ON METASTORE
COMMENT 'Prevent non-admins from managing permissions on sensitive tables'
TO `account users` EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR TABLES
WHEN has_tag('sensitive');

Pour connaître la syntaxe SQL complète, consultez CREATE POLICY.

Définissez on_securable_type sur METASTORE et on_securable_fullname sur le nom de votre métastore actuel. Le reste de la charge utile est identique à une politique dont le périmètre est le catalogue.

L’exemple suivant crée la politique DENY présentée dans l’onglet SQL tab :

Bash
curl -X POST "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- << 'EOF'
{
  "name": "managed_access",
  "comment": "Prevent non-admins from managing permissions on sensitive tables",
  "on_securable_type": "METASTORE",
  "on_securable_fullname": "my_metastore",
  "for_securable_type": "TABLE",
  "policy_type": "POLICY_TYPE_DENY",
  "to_principals": ["account users"],
  "except_principals": ["data_admins"],
  "deny": {
    "privileges": ["MANAGE_ACCESS_CONTROL"]
  },
  "when_condition": "has_tag('sensitive')"
}
EOF

on_securable_fullname n’accepte que le nom du métastore dans lequel vous travaillez actuellement. Un ID de métastore, ou le nom d’un autre métastore, est rejeté. Pour trouver le nom de votre métastore, cliquez sur l'icône en forme d'engrenage en haut du volet Catalog dans Catalog Explorer et sélectionnez Metastore . Pour plus de détails sur les requêtes et les réponses, consultez Créer une règle dans la référence de l’API REST.

Supprimer une politique au niveau du métastore

Catalog Explorer
SQL
REST API

Gérez les stratégies au niveau du métastore depuis le tab Policies du métastore.

Dans votre workspace Databricks, cliquez sur Catalog .
En haut du volet Catalog , cliquez sur l’icône en forme d’engrenage et sélectionnez Metastore .
Cliquez sur l’onglet tab .
Sélectionnez la politique.
Cliquez sur Delete policy .

Pour supprimer une politique au niveau des métastores avec SQL, exécutez DROP POLICY:

SQL
DROP POLICY ssn_mask ON METASTORE;

Bash
curl -X DELETE "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies/METASTORE/my_metastore/ssn_mask" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Afficher les stratégies

Utilisez SHOW POLICIES pour lister les politiques définies sur un objet sécurisable. Utilisez SHOW EFFECTIVE POLICIES pour inclure également les politiques héritées des portées parentes, telles que les politiques de niveau métastore qui affectent un catalogue.

SQL
SHOW [EFFECTIVE] POLICIES ON METASTORE

Le résultat inclut le nom de la politique, le type de politique, le catalogue et le schéma de l'élément sécurisable sur lequel chaque politique est définie, ainsi que le type et le nom complet de cet élément sécurisable. Les politiques au niveau du métastore sont renvoyées avec on_securable_type défini sur METASTORE et on_securable_fullname défini sur le nom du métastore. La colonne Table n'est renseignée que lorsqu'une politique est définie sur une table.

Exemple :

SQL
SHOW POLICIES ON METASTORE;

Text
Policy Name     Policy Type  Catalog  Schema  Table  Comment                                                           on_securable_type  on_securable_fullname
--------------  -----------  -------  ------  -----  ----------------------------------------------------------------  -----------------  ---------------------
ssn_mask        COLUMN_MASK  NULL     NULL    NULL   NULL                                                              METASTORE          my_metastore
managed_access  DENY         NULL     NULL    NULL   Prevent non-admins from managing permissions on sensitive tables  METASTORE          my_metastore

Décrire une politique

Utilisez DESCRIBE POLICY pour afficher les détails d'une politique spécifique au niveau du métastore. Nécessite READ METADATA sur le métastore ou le rôle d'administrateur du métastore.

SQL
{ DESC | DESCRIBE } POLICY policy_name ON METASTORE

Le résultat indique les propriétés de la politique sous forme de paires clé-valeur, incluant le nom, le type d'objet sécurisable, le nom d'objet sécurisable, les principaux, les privilèges et la condition WHEN.

Query policy definitions with Information Schema

Pour répertorier les définitions de politiques au niveau du métastore, query SYSTEM.INFORMATION_SCHEMA.ABAC_POLICY_DEFINITIONS et filtrez sur on_securable_type:

SQL
SELECT *
FROM system.information_schema.abac_policy_definitions
WHERE on_securable_type = 'METASTORE';

Les stratégies au niveau du métastore renvoient METASTORE dans on_securable_type, avec catalog_name, schema_name et securable_name tous définis sur NULL. Pour connaître les colonnes disponibles et consulter des exemples supplémentaires, voir ABAC_POLICY_DEFINITIONS.

Quotas de politiques

Ressource	Type de politique	Limit
Stratégies par métastore (tous les objets)	Filtre de lignes / masque de colonne	10 000
Stratégies par métastore (tous les objets)	GRANT/DENY	10 000
Politiques par métastore, associées directement	Filtre de lignes / masque de colonne	100
Politiques par métastore, associées directement	GRANT/DENY	100

Ressource	Type de politique	Limit
Stratégies par métastore (tous les objets)	Filtre de lignes / masque de colonne	10 000
Stratégies par métastore (tous les objets)	GRANT/DENY	10 000
Politiques par métastore, associées directement	Filtre de lignes / masque de colonne	100
Politiques par métastore, associées directement	GRANT/DENY	100

Les politiques de filtrage des lignes et de masquage des colonnes partagent un quota unique, et les politiques GRANT et DENY partagent un quota distinct. Les deux groupes sont comptés indépendamment.

Pour plus d'informations sur les quotas de politiques de filtrage de lignes et de masquage de colonnes, consultez la page Quotas de politiques. Pour plus d'informations sur les quotas de politiques GRANT, consultez la page Quotas de politiques. Pour plus d'informations sur les quotas de politiques DENY, consultez la page Quotas de politiques.

Journalisation d'audit

Les opérations de création, de modification et de suppression de politiques au niveau du métastore sont consignées sous les mêmes actions createPolicy, deletePolicy, getPolicy et listPolicies que les autres politiques ABAC, avec on_securable_type défini sur METASTORE. Consultez Audit logging pour voir des exemples de query de journaux d’audit.

Limitations

SQL cible uniquement le métastore actuel. ON METASTORE cible toujours le métastore dans lequel vous travaillez. La spécification d’un nom de métastore après ON METASTORE génère une erreur de syntaxe, et vous ne pouvez pas gérer de stratégies sur un métastore différent.
Cibles des commandes GRANT et DENY. Les stratégies GRANT et DENY ne peuvent pas cibler des objets autres que des catalogues dans le métastore, tels que les emplacements externes, les identifiants de stockage, les partages, les destinataires, les fournisseurs et les connexions. Pour connaître la hiérarchie complète des objets, consultez The Unity Catalog object hierarchy.
Schéma d’information. La vue ABAC_POLICY_DEFINITIONS ne contient pas de colonne metastore_name. Une stratégie au niveau du métastore est identifiée par on_securable_type = METASTORE.

Prérequis​

Exigences en matière de compute​

Exigences d’autorisation​

Fonctionnement des stratégies au niveau du métastore​

Cibles de politiques prises en charge​

Créer une stratégie au niveau du métastore​

Supprimer une politique au niveau du métastore​

Afficher les stratégies​

Décrire une politique​

Query policy definitions with Information Schema​

Quotas de politiques​

Journalisation d'audit​

Limitations​

Plus d’informations​