Meilleures pratiques pour les secrets Unity Catalog

Organisez les secrets du catalogue Unity de façon à ce que chaque application puisse accéder uniquement à ses propres secrets, la plupart des identités utilisent un secret sans en lire la valeur, et vous contrôlez la clé qui chiffre ces valeurs. Pour savoir comment créer, accorder et lire des secrets, voir Secrets in Unity Catalog.

Regroupez les secrets selon les personnes qui en ont besoin

Créez un schéma pour chaque application, environnement ou équipe, et accordez des privilèges CREATE SECRET sur le schéma plutôt que sur le catalogue. Un schéma contient jusqu’à 1 000 secrets, et un métastore jusqu’à 10 000.

• Autorisation sur un seul secret : Une autorisation sur un schéma s’applique à chaque secret qu’il contient, y compris les secrets ajoutés ultérieurement. Quand un principal n’a besoin que d’un seul secret, accorder READ SECRET sur ce secret plutôt que sur son schéma.
• Donnez aux secrets de production leur propre catalogue quand vous en avez besoin : la liaison de l’espace de travail et les clés gérées par le client s’appliquent à tout un catalogue. Pour garder les secrets de production hors des espaces de développement, ou pour les chiffrer avec leur propre clé, placez-les dans un catalogue séparé. Voir Workspace-catalog binding et Chiffrer les secrets gérés par Azure Databricks avec votre propre clé.

Pour donner à l’application de commandes son propre schéma, et laisser un travail de reporting lire un seul de ses secrets, exécutez ce qui suit :

-- The application's service principal reads every secret in its schema
CREATE SCHEMA main.orders_app;
GRANT USE CATALOG ON CATALOG main TO `orders-service-principal`;
GRANT USE SCHEMA, READ SECRET ON SCHEMA main.orders_app TO `orders-service-principal`;

-- The reporting job reads only the warehouse password
GRANT USE CATALOG ON CATALOG main TO `reporting-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `reporting-service-principal`;
GRANT READ SECRET ON SECRET main.orders_app.warehouse_password TO `reporting-service-principal`;

Pour les secrets adossés à Azure Key Vault, utilisez un Key Vault pour chaque schéma, avec ses propres informations d’identification du service et sa propre connexion. Les connexions Key Vault ne supportent pas les filtres de tags, donc le coffre est la frontière. Si un coffre contient plus de 1 000 secrets, Unity Catalog importe d’abord les plus anciens et saute les autres.

Ne stockez pas un schéma auquel de nombreuses applications peuvent accéder dans un seul Key Vault partagé.

Gérez les permissions pour découvrir, effectuer la rotation et lire les secrets séparément

Chacun de ces éléments est un privilège distinct, donc un principal qui met à jour un secret ou le trouve dans Catalog Explorer n’a pas besoin d’en voir la valeur :

Autoriser une entité de sécurité	Grant	Renvoie la valeur
Trouvez des secrets et demandez l’accès	BROWSE sur le catalogue. Il affiche les métadonnées de chaque secret, telles que son nom, son propriétaire et sa date d’expiration.	No
Effectuer la rotation d’un secret en mettant à jour sa valeur	WRITE SECRET	No
Lisez la valeur, par exemple dans un job avec dbutils.secrets	READ SECRET	Yes

Pour la liste complète des privilèges, voir Accorder l’accès aux secrets.

Pour permettre à tout le monde de trouver les secrets et de demander l’accès, et qu’un job de rotation puisse mettre à jour le mot de passe de l’entrepôt sans le lire, exécutez ce qui suit :

GRANT BROWSE ON CATALOG main TO `account users`;

GRANT USE CATALOG ON CATALOG main TO `rotation-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `rotation-service-principal`;
GRANT WRITE SECRET ON SECRET main.orders_app.warehouse_password TO `rotation-service-principal`;

BROWSE affiche les commentaires à tous ceux qui y ont accès. Utilisez le commentaire d’un secret pour indiquer à qui il appartient et comment demander l’accès. Ne mettez jamais de valeur ou d’indice à ce sujet dans un commentaire.

Chiffrez les secrets gérés par Azure Databricks avec votre propre clé

Les paramètres de clé gérée par le client (CMK) sur un catalogue s’appliquent à chaque secret géré par Azure Databricks qui s’y trouve. Pour chiffrer les secrets de production avec une clé séparée, mettez-les dans leur propre catalogue. Pour la manière dont la CMK s’applique aux secrets, voir Chiffrer les valeurs secrètes avec des clés gérées par le client.

Renouveler les secrets à la source

Pour les secrets protégés par Azure Key Vault, effectuez la rotation des valeurs dans Azure Key Vault, par exemple avec une stratégie de rotation Key Vault. Ne copiez pas leurs valeurs dans des secrets gérés par Azure Databricks, car chaque copie est une valeur supplémentaire à renouveler.

Pour les secrets gérés par Azure Databricks, mettez à jour la valeur dans Catalog Explorer ou via l’API REST. Réglez une date d’expiration pour que l’Explorateur de catalogue affiche un avertissement lorsque le secret expire.

Le code qui contient déjà une valeur la conserve jusqu’à ce qu’il relise le secret. Pour les tâches de longue durée, lisez le secret à chaque fois que vous ouvrez une connexion au lieu de seulement au démarrage.

Laissez les charges de travail utiliser des secrets sans les lire

La plupart des utilisateurs qui comptent sur un secret n’ont jamais besoin d’en voir la valeur. Un UDF du catalogue Unity qui déclare un secret le lit avec les permissions de son propriétaire, donc les appelants n’ont besoin que de EXECUTE sur l’UDF, par exemple pour masquer ou hacher des données personnelles. En revanche, toute personne qui exécute une fonction SQL appelant secret() sur un scope de secrets d’espace de travail a besoin de READ sur ce scope, ce qui expose tous les secrets qu’il contient. Voir Utiliser des secrets dans les UDF.

• Accordez READ SECRET uniquement aux principaux de service qui gèrent les travaux, aux propriétaires des UDF qui déclarent le secret, et au petit groupe qui possède les secrets.
• Faites d’un groupe ou d’un principal de service le propriétaire de chaque UDF qui déclare un secret, afin que l’UDF ne faillisse pas quand quelqu’un part.
• Utilisez des UDF à portée de session uniquement lorsque chaque appelant peut déjà lire le secret. Ils lisent les secrets avec les autorisations de l’appelant.

Warning

Ne retournez jamais un secret d’un UDF. Le masquage n’empêche pas le code UDF de retourner une valeur dans les résultats de requête.

Un service fournisseur de modèles peut également utiliser un secret Unity Catalog comme informations d’identification du fournisseur, de sorte que les appelants interrogent le modèle sans voir la clé. Consultez Sécuriser les informations d’identification d’un fournisseur à l’aide d’un secret Unity Catalog.

Contrôler qui peut accorder l’accès et l’auditer

• Attribuer la propriété des secrets et de leurs schémas à un groupe plutôt qu’à un individu.
• Les administrateurs et principaux du Metastore ne MANAGE peuvent pas lire une valeur, mais ils peuvent s’accorder eux-mêmes READ SECRET. Limitez MANAGE à un petit groupe.
• Consultez les lectures des secrets et les autorisations dans la table système system.access.audit. Voir Audit secret access.

Ressources supplémentaires

Ressource	Description
Secrets dans Unity Catalog	Créez, accordez et lisez les secrets du catalogue Unity.
Gestion des secrets	Comparez les secrets de Unity Catalog avec les scopes de secrets d’espace de travail, et voyez où vous pouvez utiliser chacun d’eux.