Utiliza la identidad gestionada a nivel de base de datos con Azure SQL Database (vista previa)

Se aplica a:Azure SQL Database

La identidad gestionada a nivel de base de datos otorga a una base de datos individual en Azure SQL Database su propia identidad gestionada asignada por el usuario (UAMI). Una base de datos que tiene una identidad se autentica en Azure Storage como sí misma, en lugar de como el servidor lógico que la aloja.

Sin una identidad a nivel de base de datos, todas las bases de datos en un servidor lógico comparten la identidad gestionada de ese servidor, por lo que todas acceden al mismo almacenamiento. Una identidad a nivel de base de datos reduce ese acceso a una sola base de datos, por lo que puedes conceder a cada base solo el almacenamiento que necesita.

Seleccionas la identidad en una credencial con alcance de base de datos, la misma que las consultas de virtualización de datos usan para leer archivos Parquet, CSV y Delta de Azure Blob Storage o Azure Data Lake Storage (ADLS) Gen2. Elige entre dos valores de identidad de credenciales:

Prerequisites

• Una Azure SQL Database en un servidor lógico. Todos los niveles de servicio y todas las regiones de Azure soportan esta función.
• Una identidad gestionada asignada por el usuario en la misma suscripción. Para contexto, véase Identidades gestionadas en Microsoft Entra para Azure SQL.
• Permiso para asignar roles en la cuenta de almacenamiento objetivo, como Propietario o Administrador de Acceso de Usuario.
• Una cuenta de Azure Blob Storage o ADLS Gen2 que guarde los archivos que quieres consultar.

Elige el mismo tenant o un tenant cruzado

Ambos recorridos crean una credencial con alcance de base de datos y consultan datos externos. Difieren en cómo la identidad llega a la cuenta de almacenamiento.

• Si la base de datos y la cuenta de almacenamiento están en el mismo tenant, sigue Usa una identidad a nivel de base de datos en el mismo tenant.
• Si la cuenta de almacenamiento está en otro inquilino, sigue Usa una identidad de cliente federada entre inquilinos.

Utiliza una identidad a nivel de base de datos en el mismo tenant

Paso 1: Creación de una identidad administrada asignada por el usuario

Crea la identidad y anota tanto su ID de recurso como su ID de objeto (principal). Necesitas el ID de Recurso para asignar la identidad a la base de datos. Solo necesitas el ID de Objeto (principal) para el tutorial entre inquilinos, donde identifica al sujeto de la credencial de identidad federada.

az identity create \
    --name <identity-name> \
    --resource-group <resource-group> \
    --location <region>

Para otros métodos, véase Gestionar identidades gestionadas asignadas por usuarios.

Paso 2: Asignar la identidad a la base de datos

Asigna el UAMI a la base de datos, no al servidor lógico. Esta asignación utiliza el mismo mecanismo que el cifrado transparente de datos (TDE) a nivel de base de datos con claves gestionadas por el cliente, descrito en Claves administradas por el cliente a nivel de base de datos. Para el conjunto completo de métodos de asignación, véase Obtener o establecer una identidad administrada para una base de datos.

Para asignar la identidad en el portal de Azure:

1. Ve a tu base de datos SQL.
2. En Seguridad, seleccione Identidad.
3. En Identidad administrada asignada por el usuario, selecciona Añadir.
4. Selecciona la identidad que has creado y luego selecciona Añadir.
5. Seleccione Guardar.

Para asignar la identidad con la CLI de Azure, usa az sql db update:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id>

Para asignarlo con PowerShell, usa Set-AzSqlDatabase:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId>

El identificador de identidad ID de recurso se ve como /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Búscalo en Propiedades en la identidad gestionada en el portal de Azure.

Paso 3: Concede a la identidad acceso al almacenamiento

Concede a la identidad gestionada acceso de lectura a la cuenta de almacenamiento:

1. Vaya a la cuenta de almacenamiento.
2. Seleccione Control de acceso (IAM).
3. Seleccione Agregar>Agregar asignación de rol.
4. Selecciona el rol Lector de datos de blobs de almacenamiento y luego selecciona Siguiente.
5. En Asignar acceso a, seleccione Identidad administrada.
6. Selecciona Seleccionar miembros, elige tu identidad gestionada asignada por el usuario y luego selecciona Seleccionar.
7. Seleccione Revisar y asignar.

Para un acceso más detallado en ADLS Gen2, establece listas de control de acceso (ACLs) en directorios específicos en lugar de asignar un rol a nivel de cuenta. Para más información, consulte listas de control de acceso en Azure Data Lake Storage.

Paso 4: Crear la credencial con alcance de base de datos

Conéctate a tu base de datos de usuario, no master, y crea la credencial:

CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Esta credencial no necesita secreto ni clave maestra de base de datos. El motor resuelve la identidad asignada a la base de datos en el momento de la consulta.

El equivalente a nivel de servidor utiliza un valor de identidad diferente. Comparar:

-- Server-level identity: every database on the logical server shares this access
CREATE DATABASE SCOPED CREDENTIAL MyServerIdentityCred
WITH IDENTITY = 'MANAGED IDENTITY';

-- Database-level identity: only this database has this access
CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

Para la sintaxis completa, consulte CREATE DATABASE SCOPED CREDENTIAL.

Paso 5: Crear la fuente de datos externa

Crea una fuente de datos externa que apunte a tu contenedor y adjunta la credencial. Usa el prefijo que coincida con tu tipo de almacenamiento:

CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

Paso 6: Consulta los datos

Consulta los archivos ad hoc con:OPENROWSET

SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'sales/2026/*.parquet',
    DATA_SOURCE = 'MyExternalStorage',
    FORMAT = 'parquet'
) AS externalData;

O define una tabla externa para consultas repetidas:

CREATE EXTERNAL FILE FORMAT ParquetFormat
WITH (FORMAT_TYPE = PARQUET);

CREATE EXTERNAL TABLE dbo.Sales
(
    OrderId int,
    OrderDate date,
    Amount decimal(10, 2)
)
WITH (
    LOCATION = 'sales/2026/',
    DATA_SOURCE = MyExternalStorage,
    FILE_FORMAT = ParquetFormat
);

SELECT TOP 100 * FROM dbo.Sales;

Utiliza una identidad de cliente federada entre los tenants

Utiliza esta ruta cuando tu base de datos esté en un tenant y la cuenta de almacenamiento en otro. Un registro de aplicación multiinquilino vehicula la relación de confianza entre ellos: el UAMI de la base de datos es el sujeto de una credencial de identidad federada en esa aplicación, y el inquilino de almacenamiento concede acceso a los datos al principal de servicio de la aplicación.

El patrón coincide con claves gestionadas por el cliente entre arrendatarios para un cifrado de datos transparente, así que la configuración resulta familiar si ya usas esa función.

Paso 1: Registrar una aplicación multitenant

En el tenant que contiene la base de datos, registra una aplicación multitenant en Microsoft Entra ID y anota su ID de aplicación (cliente).

Para obtener más información, consulte Registrar una aplicación con la plataforma de identidad de Microsoft.

Paso 2: Añadir una credencial de identidad federada

Añadir una credencial de identidad federada a esa aplicación para que confíe en la identidad administrada asignada por el usuario de la base de datos. La aplicación y la identidad gestionada deben pertenecer al mismo tenant de Microsoft Entra.

1. En el registro de la app, selecciona Certificados y secretos>Credenciales federadas>Añadir credencial.
2. Para el escenario de credenciales federadas, seleccione Identidad administrada.
3. Selecciona la identidad gestionada que creaste en el Paso 1 del tutorial del mismo tenant.
4. Verifica que el Issuer completado automáticamente identifique a tu tenant. Para la nube pública de Azure, el emisor es https://login.microsoftonline.com/<tenant-id>/v2.0.
5. Asegúrate de que Audience sea api://AzureADTokenExchange, el valor para la nube pública de Azure.
6. Introduce un nombre único para la credencial y luego guárdala.

El sujeto de la credencial es el ID de objeto (principal) de la identidad gestionada, no su ID de cliente. Si configuras la credencial manualmente, copia exactamente el ID del objeto (principal), porque el asunto distingue entre mayúsculas y minúsculas. Microsoft Entra ID acepta valores incorrectos de emisor, sujeto o audiencia cuando guardas la credencial, pero el intercambio de tokens falla más adelante.

Para más información, véase Configurar una aplicación para confiar en una identidad gestionada.

Paso 3: Da tu consentimiento para la aplicación y concede acceso al almacenamiento

En el tenant que posee la cuenta de almacenamiento:

1. Un administrador da su consentimiento a la aplicación multiinquilino, lo que crea una entidad de servicio en ese inquilino.
2. Asigna el rol Storage Blob Data Reader a ese principal de servicio en la cuenta de almacenamiento. Sigue el paso 3: Concede acceso a almacenamiento a la identidad, pero para Asignar acceso a, selecciona Usuario, grupo o principal de servicio, y luego selecciona el principal de servicio de la aplicación.

Paso 4: Establecer el ID federado del cliente en la base de datos

En el tenant que contiene la base de datos, asigna la identidad gestionada asignada por el usuario a la base de datos y establece el ID de la aplicación (cliente) del Paso 1 como el ID de Cliente Federado:

1. Ve a tu base de datos SQL.
2. En Seguridad, seleccione Identidad.
3. En Identidad administrada asignada por el usuario, comprueba que la identidad del Paso 1 del tutorial del mismo tenant esté listada. Si no lo es, selecciona Añadir, selecciona la identidad y luego selecciona Añadir.
4. En Identidad de cliente federado, selecciona la aplicación y luego selecciona Guardar.

Para configurarlo con la CLI de CLI de Azure:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id> \
    --federated-client-id <application-client-id>

Para configurarlo con PowerShell:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId> -FederatedClientId <ApplicationClientId>

Paso 5: Crear la credencial y la consulta

CREATE DATABASE SCOPED CREDENTIAL MyCrossTenantCred
WITH IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY';

CREATE EXTERNAL DATA SOURCE PartnerStorage
WITH (
    LOCATION = 'adls://<container>@<storage-account>.dfs.core.windows.net',
    CREDENTIAL = MyCrossTenantCred
);

Luego crea una tabla externa o ejecuta OPENROWSET en PartnerStorage exactamente como en el Paso 6: Consulta los datos.

Comparar identidades a nivel de servidor y a nivel de base de datos

Ambos tipos de credenciales pueden coexistir en el mismo servidor lógico y dentro de sus bases de datos. Elige la credencial que mejor se adapte a tus requisitos de seguridad.

Geo-replicación y conmutación por error

Se asigna una identidad a una base de datos, así que cada réplica lleva su propia asignación. Configura la geosecundaria igual que la primaria antes de realizar la conmutación por error:

• Asigna la misma identidad gestionada asignada por el usuario que usa la base de datos principal a la base de datos secundaria.
• Otorga a esa identidad el mismo acceso al almacenamiento descrito en Paso 3: Otorga a la identidad acceso al almacenamiento.
• Para el acceso entre tenants, establece la misma identidad de cliente federada en la base de datos secundaria.

Cuando configuras ambas réplicas de esta manera, las consultas que usan una credencial con alcance de base de datos siguen funcionando tras un conmutamiento por error. El requisito coincide con las claves gestionadas por el cliente a nivel de base de datos, que también requieren la identidad en cada réplica.

La misma configuración se aplica tanto a la geo-replicación activa como a los grupos de conmutación por error.

Limitations

• Solo Azure SQL Database. Azure SQL Managed Instance, SQL Server y Azure Synapse Analytics no soportan estas identidades de credenciales.
• Solo autenticación de salida. Esta función no cambia cómo se autentican los usuarios y las aplicaciones contra la base de datos.
• No se admite en la base de datos master. Crea la credencial en una base de datos de usuarios.
• Solo identidades administradas asignadas por el usuario. Una identidad gestionada asignada por el sistema está asignada al servidor lógico, por lo que no puede actuar como identidad a nivel de base de datos.
• Una identidad gestionada asignada por el usuario por cada base de datos.
• Esta vista previa cubre únicamente la virtualización de datos: CREATE EXTERNAL TABLE y OPENROWSET con DATA_SOURCE. Otras características de salida, como sp_invoke_external_rest_endpoint, no están dentro del alcance.

Troubleshoot

Crear una credencial con alcance de base de datos no confirma que la identidad de la base de datos pueda obtener un token o acceder a almacenamiento. Los errores aparecen más adelante, cuando creas una fuente de datos externa o ejecutas una consulta que use la credencial.

La identidad de la base de datos no está configurada (error 15858)

Puedes crear una credencial con IDENTITY = 'DATABASE MANAGED IDENTITY' antes de asignar una identidad gestionada asignada por el usuario a la base de datos. Si una consulta entonces utiliza la credencial y la base de datos no tiene identidad para obtener un token, la consulta falla con el error 15858:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: 'Azure SQL Server or Database identity is not configured. Please follow the steps in "Assign a Microsoft Entra managed identity to your Azure SQL" (https://aka.ms/SQLDBMSI)'.

Asigna una identidad gestionada asignada por el usuario a la base de datos, como se describe en el Paso 2, dale acceso a la cuenta de almacenamiento y luego vuelve a intentar la consulta. Asignar una identidad solo al servidor lógico no configura una identidad a nivel de base de datos. Si la asignación de la base de datos está configurada y el error persiste, contacte con Soporte técnico de Microsoft para investigar la provisión de identidad de base de datos.

No se puede encontrar ni referenciar la credencial (error 46516)

Cuando creas una fuente de datos externa, Azure SQL Database comprueba que la credencial existe en la base de datos actual y que tienes permiso para hacer referencia a ella. Si alguna de las pruebas falla, obtienes el error 46516:

The specified credential cannot be found or the user does not have permission to perform this action.

Crea la credencial en la base de datos que contiene la fuente externa de datos, comprueba el nombre de la credencial y asegúrate de tener permiso para referenciar la credencial.

Error al adquirir el token (error 15858)

Cuando la base de datos no puede obtener un token Microsoft Entra y el proveedor de tokens devuelve una razón, el error 15858 incluye esa razón:

Cannot obtain a Microsoft Entra ID token to access storage. Error message: '<details>'.

Utiliza el mensaje de error anidado para averiguar por qué falló la petición del token. Para el acceso entre inquilinos, comprueba la aplicación, el consentimiento del administrador en el tenant de almacenamiento y la credencial de identidad federada, tal como se describe en Configurar una aplicación para confiar en una identidad gestionada.

Para leer datos externos, la identidad también necesita un rol de datos de almacenamiento. Para el acceso en el mismo tenant, concede Storage Blob Data Reader sobre el contenedor o la cuenta de almacenamiento a la identidad administrada asignada por el usuario de la base de datos. Para acceso entre tenants, concédelo al principal de servicio de la aplicación en el tenant de almacenamiento. Para más información, vea Asignación de un rol de Azure para el acceso a datos de blob.

El archivo no existe o no se puede acceder al archivo (error 4860)

Cuando falta un archivo o no se puede leer, aparece el error 4860:

Cannot bulk load. The file "<path>" does not exist or you don't have file access rights. See https://go.microsoft.com/fwlink/?LinkId=2374938 for more information.

Comprueba que el archivo existe en la ubicación configurada. Luego comprueba que la identidad que utiliza la solicitud pueda acceder a ella, a través de un rol de datos de almacenamiento o, en el caso de ADLS Gen2, listas de control de acceso (ACLs) en la ruta.

El acceso a la red está bloqueado (errores 42121 y 16539)

Cuando el servidor lógico está asociado a un perímetro de seguridad de red que no permite el tráfico saliente a la cuenta de almacenamiento, obtienes el error 42121:

The operation could not be completed because attempts to connect were denied by the configured Network Security Perimeter.

Añade una regla de acceso saliente para el nombre de host de la cuenta de almacenamiento al perfil perimetral, o asocia la cuenta de almacenamiento con el mismo perímetro. Para más información, consulte el perímetro de seguridad de red para Azure SQL Database.

Cuando la red saliente está restringida en el servidor lógico y la cuenta de almacenamiento no está en las reglas del firewall saliente del servidor, obtienes el error 16539:

Operation failed since the external data source '<external-data-source>' has underlying storage account that is not in the list of Outbound Firewall Rules on the server. Please add this storage account to the list of Outbound Firewall Rules on your server and retry the operation.

Añade una regla de firewall saliente para el nombre exacto del host de almacenamiento en la ubicación de la fuente de datos externa. Para más información, consulta Reglas de firewall saliente para Azure SQL Database y Azure Synapse Analytics.

Falta la configuración entre tenants o es incorrecta (errores 16561 y 16562)

Una consulta entre tenants puede fallar con cualquiera de estos errores, o con el error 4860:

External table '<table-name>' is not accessible because content of directory cannot be listed.

External table '<table-name>' is not accessible because location does not exist or it is used by another process.

Estos errores significan que la consulta no pudo acceder a los archivos. La identidad puede no tener el rol de almacenamiento requerido, el acceso a la red puede estar bloqueado, la ubicación de almacenamiento puede no resolverse o el token puede ser del tenant equivocado. Para corregirlo:

• Asigne el rol de datos de Storage adecuado.
• Permitir el acceso a la red a la cuenta de almacenamiento.
• Incluye el contenedor en la ubicación de la fuente de datos externa.
• Utiliza DATABASE FEDERATED CLIENT IDENTITY, y establece el ID de Cliente Federado en la base de datos, como se describe en el Paso 4.
• Confirma que el sujeto de la credencial de identidad federada coincide exactamente con el ID de Objeto (principal) de la identidad gestionada.

Las consultas fallan tras una conmutación por error

Si las consultas fallan con errores de token o autorización tras un conmutamiento por error, el nuevo primario podría no tener la misma identidad gestionada asignada por el usuario que usó el primario original. O esa identidad puede que no tenga asignación de rol en la cuenta de almacenamiento. Asignar la misma identidad a ambas réplicas y concederle acceso al almacenamiento, como se describe en Geo-replicación y conmutación por error.

Preguntas más frecuentes

¿Pueden coexistir las credenciales a nivel de servidor y a nivel de base de datos en el mismo servidor?

Sí, en el mismo servidor lógico y en la misma base de datos. El valor de IDENTITY de cada credencial decide qué identidad utiliza una consulta: MANAGED IDENTITY utiliza la identidad del servidor y DATABASE MANAGED IDENTITY la identidad de la base de datos.

¿Puedo usar una identidad gestionada asignada por el sistema?

N. º Una identidad gestionada asignada por el sistema pertenece al servidor lógico, por lo que no puedes asignarla a una sola base de datos. Utiliza una identidad gestionada asignada por el usuario.

¿Qué niveles de servicio y regiones soportan esta vista previa?

Todos los niveles de servicio de Azure SQL Database, en todas las regiones de Azure.

¿Necesito una clave maestra de base de datos?

N. º Ni DATABASE MANAGED IDENTITY ni DATABASE FEDERATED CLIENT IDENTITY admiten un secreto, así que no se requiere ninguna llave maestra.

¿Esta función funciona con sp_invoke_external_rest_endpoint?

No en esta vista previa. La vista previa cubre la virtualización de datos.

Contenido relacionado

• Virtualización de datos con Azure SQL Database
• Identidades administradas en Microsoft Entra para Azure SQL
• Claves gestionadas por el cliente a nivel de base de datos
• Claves gestionadas por el cliente entre arrendatarios
• CREAR CREDENCIAL LIMITADA AL ÁMBITO DE LA BASE DE DATOS (Transact-SQL)
• CREAR TABLA EXTERNA (Transact-SQL)