Utilisez l’identité gérée au niveau de la base de données avec Azure SQL Database (aperçu)

S’applique à :Azure SQL Database

L’identité gérée au niveau de la base de données donne à une base de données individuelle dans Azure SQL Database sa propre identité managée attribuée par l’utilisateur (UAMI). Une base de données qui en possède une s’authentifie auprès d’stockage Azure en tant qu’elle-même, plutôt qu’en tant que serveur logique qui l’héberge.

Sans identité au niveau de la base de données, chaque base de données sur un serveur logique partage l’identité gérée de ce serveur, de sorte qu’elles accèdent toutes au même stockage. Une identité au niveau de la base de données réduit cet accès à une seule base de données, ce qui permet d’accorder à chaque base de données uniquement le stockage dont elle a besoin.

Vous sélectionnez l’identité dans une information d’identification délimitée à la base de données, la même que celle utilisée par les requêtes de virtualisation de données pour lire les fichiers Parquet, CSV et Delta depuis Stockage Blob Azure ou Azure Data Lake Storage (ADLS) Gen2. Choisissez entre deux valeurs d’identité d’identifiant :

Prerequisites

• Une Azure SQL Database sur un serveur logique. Tous les niveaux de service et toutes les régions Azure prennent en charge cette fonctionnalité.
• Une identité managée attribuée par l’utilisateur dans le même abonnement. Pour contexte, voir Identités managées dans Microsoft Entra pour Azure SQL.
• Permission d’attribuer des rôles au compte de stockage cible, tels que propriétaire ou administrateur d’accès utilisateur.
• Un compte Stockage Blob Azure ou ADLS Gen2 détenant les fichiers que vous souhaitez interroger.

Choisissez le même tenant ou inter-tenant

Les deux guides créent des informations d’identification limitées à la base de données et interrogent des données externes. Ils diffèrent dans la manière dont l’identité accède au compte de stockage.

• Si la base de données et le compte de stockage sont dans le même tenant, suivez la procédure Utiliser une identité au niveau de la base de données dans le même tenant.
• Si le compte de stockage est dans un autre tenant, suivez Utiliser une identité client fédérée entre les tenants.

Utilisez une identité au niveau de la base de données dans le même locataire

Étape 1 : Créer une identité managée affectée par l’utilisateur

Créez l’identité et notez à la fois son identifiant de ressource et son identifiant d’objet (principal). Vous avez besoin de l’identifiant de la ressource pour attribuer l’identité à la base de données. Vous avez besoin de l’ID de l’objet (principal) uniquement pour la procédure pas à pas entre locataires, où il identifie le sujet des informations d’identification d’identité fédérée.

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

Pour d’autres méthodes, voir Gérer les identités gérées attribuées par les utilisateurs.

Étape 2 : Attribuer l’identité gérée à la base de données

Assignez l’UAMI à la base de données, pas au serveur logique. Cette attribution utilise le même mécanisme que le chiffrement transparent des données (TDE) au niveau de la base de données avec des clés gérées par le client, décrit dans Clés gérées par le client au niveau de la base de données. Pour l’ensemble complet des méthodes d’affectation, voir Obtenir ou définir une identité gérée pour une base de données.

Pour attribuer l’identité dans le portail Azure :

1. Accédez à votre base SQL.
2. Sous Sécurité, sélectionnez Identité.
3. Dans identité managée affectée par l’utilisateur, sélectionnez Ajouter.
4. Sélectionnez l’identité que vous avez créée, puis sélectionnez Ajouter.
5. Sélectionnez Enregistrer.

Pour attribuer l’identité à l’aide d’Azure CLI, utilisez 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>

Pour l’assigner avec PowerShell, utilisez Set-AzSqlDatabase :

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

L’identifiant ID de ressource ressemble à /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>. Trouvez-le sous Propriétés sur l’identité gérée dans le portail Azure.

Étape 3 : Accorder à l’identité l’accès au stockage

Donnez à l’identité gérée un accès en lecture au compte de stockage :

1. Accédez au compte de stockage.
2. Sélectionnez Contrôle d’accès (IAM).
3. Sélectionnez Ajouter>Ajouter une attribution de rôle.
4. Sélectionnez le rôle Lecteur des données Blob du stockage, puis sélectionnez Suivant.
5. Pour Attribuer l’accès à, sélectionnez Identité managée.
6. Sélectionnez Sélectionner les membres, choisissez votre identité gérée attribuée par l’utilisateur, puis sélectionnez Sélectionner.
7. Sélectionnez Vérifier + attribuer.

Pour un accès plus précis sur ADLS Gen2, définissez des listes de contrôle d’accès (ACL) sur des répertoires spécifiques au lieu d’attribuer un rôle au niveau du compte. Pour plus d’informations, consultez les listes de contrôle d’accès dans Azure Data Lake Storage.

Étape 4 : Créer les informations d’identification limitées à la base de données

Connectez-vous à votre base de données utilisateur, et non master, puis créez les informations d’identification :

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

Ces informations d’identification ne nécessitent ni secret ni clé maîtresse de base de données. Le moteur résout l’identité attribuée à la base de données au moment de la requête.

L’équivalent au niveau serveur utilise une valeur d’identité différente. Comparer:

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

Pour la syntaxe complète, voir CREATE DATABASE SCOPED CREDENTIAL.

Étape 5 : Créer la source de données externe

Créez une source de données externe qui pointe vers votre conteneur, et attachez les informations d’identification. Utilisez le préfixe correspondant à votre type de stockage :

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

Étape 6 : Interroger les données

Interrogez les fichiers ad hoc avec OPENROWSET:

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

Ou définissez une table externe pour les requêtes répétées :

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;

Utilisez une identité client fédérée entre les tenants

Utilisez ce chemin lorsque votre base de données est dans un tenant et que le compte de stockage est dans un autre. Un enregistrement d’application mutualisée porte la relation de confiance entre les deux : l’UAMI de la base de données fait l’objet d’une accréditation d’identité fédérée sur cette application, et le locataire de stockage accorde l’accès aux données au principal de service de l’application.

Le modèle correspond aux clés gérées par le client entre locataires pour le chiffrement transparent des données, donc la configuration vous est familière si vous utilisez déjà cette fonctionnalité.

Étape 1 : Enregistrer une application multilocataire

Dans le locataire/client qui détient la base de données, enregistrez une application multilocataire dans Microsoft Entra ID et notez son ID d’application (client).

Pour plus d’informations, consultez Registrer une application avec le Plateforme d'identités Microsoft.

Étape 2 : Ajouter un justificatif d’identité fédéré

Ajoutez des informations d’identification d’identité fédérée à cette application afin qu’elle fasse confiance à l’identité managée affectée par l’utilisateur de la base de données. L’application et l’identité gérée doivent appartenir au même locataire Microsoft Entra.

1. Dans l’inscription à l’application, sélectionnez Certificats & secrets>Informations d’identification fédérées>Ajouter un identifiant.
2. Pour le scénario des identifiants fédérés, sélectionnez Managed Identity.
3. Sélectionnez l’identité gérée que vous avez créée dans l’étape 1 du guide du même locataire.
4. Vérifiez que l’émetteur automatiquement rempli identifie votre locataire. Pour le cloud public Azure, l’émetteur est https://login.microsoftonline.com/<tenant-id>/v2.0.
5. Assurez-vous que Audience a pour valeur api://AzureADTokenExchange, la valeur du cloud public Azure.
6. Saisissez un nom unique pour les informations d’identification, puis enregistrez-le.

L’objet des informations d’identification est l’ID d’objet (principal) de l’identité gérée, et non son identifiant client. Si vous configurez les informations d’identification manuellement, copiez exactement l’ID d’objet (principal), car cette valeur est sensible à la casse. Microsoft Entra ID accepte des valeurs incorrectes de l’émetteur, du sujet ou de l’audience lorsque vous sauvegardez les informations d’identification, mais l’échange de jetons échoue plus tard.

Pour plus d’informations, voir Configurer une application pour faire confiance à une identité gérée.

Étape 3 : Consentez à l’application et accordez l’accès au stockage

Dans le tenant qui détient le compte de stockage :

1. Un administrateur consent à l’application multilocataire, qui crée un principal de service dans ce locataire.
2. Attribuez le rôle Storage Blob Data Reader à ce principal de service sur le compte de stockage. Suivez l’étape 3 : Accordez à l’identité un accès au stockage, mais pour Assigner l’accès à, sélectionnez Utilisateur, groupe ou principal de service, puis sélectionnez le principal de service de l’application.

Étape 4 : Définir l’identifiant client fédéré sur la base de données

Dans le locataire qui contient la base de données, attribuez l’identité managée attribuée par l’utilisateur à la base de données, puis définissez l’ID de l’application (client) de l’étape 1 comme identifiant client fédéré :

1. Accédez à votre base de données SQL.
2. Sous Sécurité, sélectionnez Identité.
3. Dans Identité managée affectée par l’utilisateur, vérifiez que l’identité de l’étape 1 de la procédure pas à pas pour le même locataire est listée. Si ce n’est pas le cas, sélectionnez Ajouter, sélectionnez l’identité, puis sélectionnez Ajouter.
4. Dans Identité client fédérée, sélectionnez l’application, puis sélectionnez Sauvegarder.

Pour le définir avec l’interface Azure CLI :

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>

Pour le configurer avec PowerShell :

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

Étape 5 : Créer les informations d’identification et effectuer une requête

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

Puis créez une table externe ou exécutez OPENROWSET sur PartnerStorage exactement comme à l’étape 6 : interrogez les données.

Comparez les identités au niveau serveur et au niveau de la base de données

Les deux types d’identifiants peuvent coexister sur le même serveur logique et au sein de ses bases de données. Choisissez les informations d’identification qui correspondent le mieux à vos besoins en matière de sécurité.

Géo-réplication et basculement

Vous attribuez l’identifiant à une base de données, donc chaque réplique porte sa propre affectation. Configurez la géo-secondaire de la même manière que la primaire avant de faire le basculement :

• Attribuer à la base de données secondaire la même identité managée attribuée par l’utilisateur que la base de données primaire utilise.
• Accordez à cet identité le même accès au stockage décrit à l’étape 3 : Accorder à l’identité un accès au stockage.
• Pour un accès interlocataire, définissez la même identité client fédérée sur la base de données secondaire.

Lorsque vous configurez les deux répliques de cette manière, les requêtes utilisant des informations d’identification délimitées à la base de données continuent de fonctionner après un basculement. L’exigence correspond aux clés gérées par le client au niveau de la base de données, qui nécessitent également une identité en place sur chaque réplica.

La même configuration s’applique aussi bien à la géo-réplication active qu’aux groupes de basculement.

Limitations

• Azure SQL Database uniquement. Azure SQL Managed Instance, SQL Server et Azure Synapse Analytics ne prennent pas en charge ces identités d’informations d’identification.
• Authentification sortante uniquement. Cette fonctionnalité ne change pas la façon dont les utilisateurs et les applications s’authentifient dans la base de données.
• Non pris en charge dans la master base de données. Créez les informations d’identification dans une base de données utilisateur.
• Uniquement les identités gérées attribuées par l’utilisateur. Une identité managée attribuée par le système a une portée limitée au serveur logique, elle ne peut donc pas agir comme une identité au niveau de la base de données.
• Une identité managée affectée par l’utilisateur par base de données.
• Cette prévisualisation couvre uniquement la virtualisation des données : CREATE EXTERNAL TABLE et OPENROWSET avec DATA_SOURCE. D’autres fonctionnalités sortantes, comme sp_invoke_external_rest_endpoint, ne font pas partie du périmètre.

Troubleshoot

Créer un identifiant à portée de base de données ne confirme pas que l’identité de la base de données peut obtenir un jeton ou accéder au stockage. Les erreurs apparaissent plus tard, lorsque vous créez une source de données externe ou lancez une requête utilisant les informations d’identification.

L’identité de la base de données n’est pas configurée (erreur 15858)

Vous pouvez créer des informations d’identification avec IDENTITY = 'DATABASE MANAGED IDENTITY' avant d’attribuer une identité managée attribuée par l’utilisateur à la base de données. Si une requête utilise alors les informations d’identification et que la base de données n’a pas d’identité pour obtenir un jeton, la requête échoue avec l’erreur 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)'.

Attribuez une identité managée attribuée par l’utilisateur à la base de données, comme indiqué à l’étape 2, donnez-lui accès au compte de stockage, puis réessayez la requête. Attribuer une identité uniquement au serveur logique ne configure pas d’identité au niveau de la base de données. Si l’affectation de base de données est en place et que l’erreur persiste, contactez le Support Microsoft pour examiner le provisionnement de l’identité de la base de données.

Identifiant ne peut pas être trouvé ni référencé (erreur 46516)

Lorsque vous créez une source de données externe, Azure SQL Database vérifie que les informations d’identification existent dans la base de données actuelle et que vous disposez des autorisations nécessaires pour y faire référence. Si l’un ou l’autre test échoue, vous obtenez l’erreur 46516 :

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

Créez les informations d’identification dans la base de données qui contient la source de données externe, vérifiez le nom des informations d’identification, et assurez-vous d’avoir la permission de référencer les informations d’identification.

Échec de l’acquisition du jeton (erreur 15858)

Lorsque la base de données ne peut pas obtenir un jeton Microsoft Entra et que le fournisseur de jetons renvoie une raison, l'erreur 15858 inclut cette raison :

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

Utilisez le message d’erreur imbriqué pour comprendre pourquoi la requête de jeton a échoué. Pour l’accès inter-locataire, vérifiez l’application, le consentement administrateur dans le locataire de stockage et les informations d’identification d’identité fédérée, comme décrit dans Configurer une application pour faire confiance à une identité gérée.

Pour lire les données externes, l’identité a également besoin d’un rôle de données de stockage. Pour un accès dans le même locataire, accordez Storage Blob Data Reader sur le conteneur ou le compte de stockage à l’identité gérée attribuée par l’utilisateur de la base de données. Pour un accès interlocataire, accordez-le à l’identité de service de l’application dans le locataire de stockage. Pour plus d’informations, consultez Attribuer un rôle Azure pour l’accès aux données BLOB.

Le fichier n’existe pas ou ne peut pas être consulté (erreur 4860)

Lorsqu’un fichier manque ou ne peut pas être lu, vous obtenez l’erreur 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.

Vérifiez que le fichier existe à l’emplacement configuré. Puis vérifiez que l’identité utilisée par la requête peut y accéder, via un rôle de données de stockage ou, pour l’ADLS Gen2, des listes de contrôle d’accès (ACL) sur le chemin.

L’accès réseau est bloqué (erreurs 42121 et 16539)

Lorsque le serveur logique est associé à un périmètre de sécurité réseau qui n’autorise pas le trafic sortant vers le compte de stockage, vous obtenez l’erreur 42121 :

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

Ajoutez une règle d’accès sortant pour le nom hôte du compte de stockage au profil périmétrique, ou associez le compte de stockage au même périmètre. Pour plus d’informations, voir Périmètre de sécurité réseau pour Azure SQL Database.

Lorsque le réseau sortant est restreint sur le serveur logique et que le compte de stockage n’est pas dans les règles du pare-feu sortant du serveur, vous obtenez l’erreur 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.

Ajoutez une règle de pare-feu sortant pour le nom exact de l’hôte de stockage dans l’emplacement de la source de données externe. Pour plus d’informations, consultez les règles de pare-feu sortant pour Azure SQL Database et Azure Synapse Analytics.

La configuration inter-locataire est manquante ou incorrecte (erreurs 16561 et 16562)

Une requête inter-locataires peut échouer avec l’une ou l’autre de ces erreurs, ou avec l’erreur 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.

Ces erreurs signifient que la requête n’a pas pu atteindre les fichiers. L’identité peut ne pas avoir le rôle de stockage requis, l’accès réseau peut être bloqué, l’emplacement de stockage peut ne pas se résoudre, ou le jeton peut être pour le mauvais locataire. Pour résoudre ce problème :

• Accordez le rôle approprié de stockage des données.
• Autorisez l’accès réseau au compte de stockage.
• Incluez le conteneur dans l’emplacement de la source de données externe.
• Utilisez DATABASE FEDERATED CLIENT IDENTITY, et définissez l’ID Client Fédéré sur la base de données, comme décrit à l’étape 4.
• Confirmez que le sujet des informations d’identification de l’identité fédérée correspond exactement à l’ID de l’objet (principal) de l’identité gérée.

Les requêtes échouent après un basculement

Si les requêtes échouent avec des erreurs de jeton ou d’autorisation après un basculement, le nouveau primaire peut ne pas avoir la même identité gérée attribuée par l’utilisateur que le primaire d’origine. Ou bien cette identité pourrait ne pas avoir d’attribution de rôle sur le compte de stockage. Attribuer la même identité aux deux répliques et leur accorder un accès au stockage, comme décrit dans la géo-réplication et le basculement.

Questions fréquemment posées

Les identifiants au niveau serveur et au niveau de la base de données peuvent-ils coexister sur le même serveur ?

Oui, sur le même serveur logique et dans la même base de données. La valeur de chaque identifiant IDENTITY détermine l’identité utilisée par une requête : MANAGED IDENTITY utilise l’identité du serveur et DATABASE MANAGED IDENTITY celle de la base de données.

Puis-je utiliser une identité managée attribuée par le système ?

No. Une identité managée attribuée par le système appartient au serveur logique, donc on ne peut pas la limiter à une seule base de données. Utilisez une identité managée attribuée par l’utilisateur.

Quels niveaux de service et régions prennent en charge cette prévisualisation ?

Tous les niveaux de service Azure SQL Database, dans toutes les régions Azure.

Ai-je besoin d’une clé maître de base de données ?

No. Ni DATABASE MANAGED IDENTITY ni DATABASE FEDERATED CLIENT IDENTITY ne prend de secret, donc aucune clé maîtresse n’est requise.

Cette fonctionnalité fonctionne-t-elle avec sp_invoke_external_rest_endpoint?

Pas dans cet aperçu. L’aperçu couvre la virtualisation des données.

Contenu connexe

• Virtualisation des données avec Azure SQL Database
• Identités gérées dans Microsoft Entra pour Azure SQL
• Clés gérées par le client au niveau de la base de données
• Clés gérées par le client interlocataire
• CRÉER DES INFORMATIONS D’IDENTIFICATION LIMITÉES À LA BASE DE DONNÉES (TRANSACT-SQL)
• CRÉER TABLE EXTERNE (Transact-SQL)