Mejores prácticas para secretos de Unity Catalog

Organiza los secretos del Catálogo de Unity para que cada aplicación pueda acceder solo a sus propios secretos, la mayoría de las entidades de seguridad pueda usar un secreto sin leer su valor, y tú controles la clave que cifra esos valores. Para saber cómo crear, conceder y leer secretos, consulta Secretos en Unity Catalog.

Secretos de grupo según quién los necesita

Crea un esquema para cada aplicación, entorno o equipo, y concede CREATE SECRET privilegios en el esquema en lugar de en el catálogo. Un esquema almacena hasta 1.000 secretos, y un metastore hasta 10.000.

• Concesión sobre un solo secreto: Una concesión sobre un esquema se aplica a todos los secretos de él, incluidos los secretos añadidos posteriormente. Cuando un principal necesita solo un secreto, concede READ SECRET sobre ese secreto en lugar de sobre su tipo de secreto.
• Da a los secretos de producción su propio catálogo cuando lo necesites: La vinculación de espacios de trabajo y las claves gestionadas por el cliente se aplican a todo un catálogo. Para mantener los secretos de producción fuera de los espacios de desarrollo, o para cifrarlos con su propia clave, ponlos en un catálogo separado. Consulta Vinculación entre espacio de trabajo y catálogo y Cifra los secretos administrados por Azure Databricks con tu propia clave.

Para dar a la aplicación de órdenes su propio esquema y permitir que un trabajo de reporte lea solo uno de sus secretos, ejecuta lo siguiente:

-- 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`;

Para secretos respaldados por Azure Key Vault, usa un Key Vault para cada esquema, con su propia credencial de servicio y conexión. Las conexiones de Key Vault no admiten filtros de etiquetas, así que el vault es el límite. Si una bóveda contiene más de 1.000 secretos, Unity Catalog importa primero los más antiguos y omite el resto.

No respaldes una base de datos a la que muchas aplicaciones pueden acceder con un solo Key Vault compartido.

Gestiona permisos para descubrir, rotar y leer secretos por separado

Cada uno de estos es un privilegio separado, por lo que un principal que actualiza un secreto o lo encuentra en el Explorador de Catálogos no necesita ver su valor:

Para dejar a un principal	Grant	Devuelve el valor
Encuentra secretos y solicita acceso	BROWSE en el catálogo. Muestra los metadatos de cada secreto, como su nombre, propietario y fecha de caducidad.	No
Rotar un secreto actualizando su valor	WRITE SECRET	No
Lee el valor, por ejemplo con dbutils.secrets en un trabajo	READ SECRET	Yes

Para la lista completa de privilegios, véase Conceder acceso a secretos.

Para que todos encuentren los secretos y soliciten acceso, y que un trabajo rotativo actualice la contraseña del almacén sin leerla, ejecuta lo siguiente:

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 Muestra comentarios a todos los que lo tienen. Usa el comentario de un secreto para decir quién es el propietario y cómo solicitar acceso. Nunca pongas un valor o una pista sobre uno en un comentario.

Cifre los secretos administrados por Azure Databricks con su propia clave

La configuración de clave gestionada por el cliente (CMK) en un catálogo se aplica a todos los secretos gestionados por Azure Databricks en él. Para cifrar secretos de producción con una clave separada, ponlos en su propio catálogo. Para saber cómo se aplica CMK a los secretos, véase Cifrar valores secretos con claves gestionadas por el cliente.

Rote los secretos en el origen

Para secretos respaldados por Azure Key Vault, rota los valores en Azure Key Vault, por ejemplo con una política de rotación de Key Vault. No copies sus valores en secretos gestionados por Azure Databricks, porque cada copia es otro valor que hay que rotar.

Para los secretos administrados por Azure Databricks, actualiza el valor en Catalog Explorer o con la API REST. Establece una fecha de caducidad para que el Explorador de Catálogos muestre una advertencia cuando el secreto expire.

El código que ya contiene un valor lo mantiene hasta que vuelve a leer el secreto. En trabajos de larga duración, lee el secreto cada vez que abras una conexión en lugar de solo al inicio.

Deja que las cargas de trabajo usen secretos sin leerlos

La mayoría de los usuarios que dependen de un secreto nunca necesitan ver su valor. Un UDF del Unity Catalog que declara un secreto lo lee con los permisos de su propietario, por lo que los llamantes solo necesitan EXECUTE en el UDF, por ejemplo, para enmascarar o hacer hash de datos personales. En cambio, cualquiera que ejecute una función SQL que llame a secret() en un ámbito de secretos del espacio de trabajo necesita READ en el ámbito, que expone todos los secretos que contiene. Ver Usar secretos en UDFs.

• Concede READ SECRET solo a las entidades de servicio que gestionan los trabajos, a los propietarios de las UDF que declaran el secreto y al pequeño grupo que posee los secretos.
• Haz que un grupo o principal de servicio sea el propietario de cada UDF que declare un secreto, para que la UDF no falle cuando alguien se vaya.
• Utiliza UDFs con alcance de sesión solo cuando cada llamante ya pueda leer el secreto. Leen secretos con el permiso del llamador.

Warning

Nunca devuelvas un valor secreto desde una UDF. La censura no impide que el código UDF devuelva un valor en los resultados de la consulta.

Un servicio de proveedor de modelos también puede usar un secreto de Unity Catalog como credencial de proveedor, por lo que los llamantes consultan el modelo sin ver la clave. Consulta Respaldar una credencial de proveedor con un secreto de Unity Catalog.

Controla quién puede conceder el acceso y audítalo

• Asignar la propiedad de los secretos y sus esquemas a un grupo en lugar de a un individuo.
• Los administradores y principales del metastore con MANAGE no pueden leer un valor, pero sí pueden concederse READ SECRET a sí mismos. Limítate MANAGE a un grupo pequeño.
• Revisa lecturas del secreto y concesiones en la system.access.audit tabla del sistema. Ver acceso al secreto de auditoría.

Recursos adicionales

Resource	Description
Catálogo de Secretos en Unity	Crea, otorga y lee los secretos del Catálogo de Unity.
Administración de secretos	Compara los secretos de Unity Catalog con los ámbitos secretos de los espacios de trabajo y mira dónde puedes usar cada uno.