Autoriser l’accès aux objets blob à l’aide Microsoft Entra ID

Le stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les requêtes aux données d’objet blob. Microsoft Entra ID vous permet d’utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur, un groupe ou un principal de service d’application. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

L’autorisation avec Microsoft Entra ID offre davantage de sécurité et de facilité d’utilisation sur l’autorisation de clé partagée. Microsoft recommande d’utiliser l’autorisation Microsoft Entra avec vos applications blob dans la mesure du possible pour garantir l’accès avec les privilèges minimaux requis.

L’autorisation avec Microsoft Entra ID est disponible pour tous les comptes de stockage universels et les comptes de stockage Blob dans toutes les régions publiques et les clouds nationaux. Seuls les comptes de stockage créés avec le modèle de déploiement Azure Resource Manager prennent en charge l’autorisation Microsoft Entra.

Le stockage Blob prend également en charge la création de signatures d’accès partagé (SAS) signées avec des informations d’identification Microsoft Entra. Pour plus d’informations, consultez Accorder un accès limité aux données avec des signatures d’accès partagé.

Vue d’ensemble de Microsoft Entra ID pour les objets blob

Lorsqu’un principal de sécurité (utilisateur, groupe ou application) tente d’accéder à une ressource blob, la requête doit être autorisée, sauf s’il s’agit d’un blob disponible pour l’accès anonyme. Avec Microsoft Entra ID, l’accès à une ressource est un processus en deux étapes :

  1. Pour commencer, l’identité du principal de sécurité est authentifiée, et un jeton OAuth 2.0 est renvoyé.

    L’étape d’authentification nécessite qu’une application demande un jeton d’accès OAuth 2.0 au moment de l’exécution. Si une application s’exécute à partir d’une entité Azure telle qu’une machine virtuelle Azure, un groupe de machines virtuelles identiques ou une application Azure Functions, elle peut utiliser une identité managée pour accéder aux données blob.

  2. Ensuite, ce jeton est transmis dans le cadre d’une requête adressée au service BLOB et utilisé par le service pour autoriser l’accès à la ressource spécifiée.

    L’étape d’autorisation exige qu’un ou plusieurs rôles Azure RBAC soient attribués au principal de sécurité qui effectue la requête. Pour plus d’informations, consultez Attribuer des rôles Azure pour les droits d’accès.

Utiliser un compte Microsoft Entra avec le portail, PowerShell ou Azure CLI

Pour savoir comment accéder aux données du Portail Azure avec un compte Microsoft Entra, consultez Accès aux données à partir du Portail Azure. Pour savoir comment appeler des commandes Azure PowerShell ou Azure CLI avec un compte Microsoft Entra, consultez Accès aux données à partir de PowerShell ou d’Azure CLI.

Utiliser Microsoft Entra ID pour autoriser l’accès dans le code de l’application

Pour autoriser l’accès au Stockage Azure avec Microsoft Entra ID, vous pouvez utiliser l’une des bibliothèques clientes suivantes pour obtenir un jeton OAuth 2.0 :

Bibliothèque cliente Azure Identity

La bibliothèque de client Azure Identity simplifie le processus d’obtention d’un jeton d’accès OAuth 2.0 pour l’autorisation avec Microsoft Entra ID via le Kit de développement logiciel (SDK) Azure. Les versions les plus récentes des bibliothèques de client Stockage Azure pour .NET, Java, Python, JavaScript et Go s’intègrent aux bibliothèques Azure Identity pour chacun de ces langages afin de fournir un moyen simple et sécurisé d’acquérir un jeton d’accès pour l’autorisation des demandes Stockage Azure.

L’un des avantages de la bibliothèque de client Azure Identity est qu’elle vous permet d’utiliser le même code pour acquérir le jeton d’accès, que votre application soit exécutée dans l’environnement de développement ou dans Azure. La bibliothèque de client Azure Identity renvoie un jeton d’accès pour un principal de sécurité. Lorsque votre code s’exécute dans Azure, le principal de sécurité peut être une identité managée pour les ressources Azure, un principal de service, un utilisateur ou un groupe. Dans l’environnement de développement, la bibliothèque de client fournit un jeton d’accès pour un utilisateur ou un principal de service à des fins de test.

Le jeton d’accès renvoyé par la bibliothèque de client Azure Identity est encapsulé dans les informations d’identification d’un jeton. Vous pouvez ensuite utiliser les informations d’identification du jeton pour obtenir un objet client de service à utiliser lors de l’exécution d’opérations autorisées sur Stockage Azure. Un moyen simple d’obtenir le jeton d’accès et les informations d’identification du jeton consiste à utiliser la classe DefaultAzureCredential fournie par la bibliothèque de client Azure Identity. DefaultAzureCredential tente d’obtenir les informations d’identification du jeton en essayant séquentiellement plusieurs types d’informations d’identification différents. DefaultAzureCredential fonctionne à la fois dans l’environnement de développement et dans Azure.

Le tableau suivant pointe vers des informations supplémentaires pour autoriser l’accès à des données dans différents scénarios :

Langage .NET Java JavaScript Python Go
Vue d’ensemble de l’authentification avec Microsoft Entra ID Comment authentifier des applications .NET avec les services Azure Authentification Azure avec Java et Azure Identity Authentifier des applications JavaScript auprès des services Azure à l’aide du Kit de développement logiciel (SDK) Azure Authentifier des applications Python auprès des services Azure à l’aide du Kit de développement logiciel (SDK) Azure
Authentification à l’aide de principaux de service de développeur Authentifier des applications .NET auprès des services Azure pendant le développement local à l’aide de principaux de service Authentification Azure avec un principal de service Authentification des applications JS auprès des services Azure avec un principal de service Authentifier des applications Python auprès des services Azure pendant le développement local à l’aide de principaux de service Authentification Azure SDK pour Go avec un principal de service
Authentification à l’aide de comptes de développeur ou d’utilisateur Authentifier des applications .NET auprès des services Azure pendant le développement local à l’aide de comptes de développeur Authentification Azure avec des informations d’identification d’utilisateur Authentification d’applications JS auprès des services Azure avec des comptes de développeur Authentifier des applications Python auprès des services Azure pendant le développement local à l’aide de comptes de développeur Authentification Azure avec Azure SDK pour Go
Authentification à partir d’applications hébergées dans Azure Authentification des applications hébergées dans Azure auprès des ressources Azure avec le Kit de développement logiciel (SDK) Azure pour .NET Authentifier les applications Java hébergées dans Azure Authentification des applications JavaScript hébergées dans Azure auprès des ressources Azure avec le Kit de développement logiciel (SDK) Azure pour JavaScript Authentification des applications hébergées dans Azure auprès de ressources Azure avec le Kit de développement logiciel (SDK) Azure pour Python Authentification avec Azure SDK pour Go en utilisant une identité managée
Authentification à partir d’applications locales S’authentifier auprès des ressources Azure à partir d’applications .NET hébergées localement Authentifier des applications JavaScript locales auprès des ressources Azure S’authentifier auprès des ressources Azure à partir d’applications Python hébergées localement
Vue d’ensemble de la bibliothèque de client Identité Bibliothèque cliente Azure Identity pour .NET Bibliothèque cliente Azure Identity pour Java Bibliothèque cliente Azure Identity pour JavaScript Bibliothèque cliente Azure Identity pour Python Bibliothèque cliente Azure Identity pour Go

Bibliothèque d’authentification Microsoft (MSAL)

Bien que Microsoft recommande d’utiliser la bibliothèque de client Azure Identity dans la mesure du possible, la bibliothèque MSAL peut être appropriée dans certains scénarios avancés. Pour plus d’informations, consultez En savoir plus sur MSAL.

Lorsque vous utilisez MSAL pour obtenir un jeton OAuth pour accéder au Stockage Azure, vous devez fournir un ID de ressource Microsoft Entra. L’ID de ressource Microsoft Entra indique l’audience pour laquelle un jeton émis peut être utilisé pour fournir l’accès à une ressource Azure. Dans le cas du stockage Azure, l’ID de ressource peut être spécifique à un seul compte de stockage ou s’appliquer à n’importe quel compte de stockage.

Lorsque vous fournissez un ID de ressource spécifique à un seul compte de stockage et service, l’ID de la ressource est utilisé afin d’obtenir un jeton pour autoriser les requêtes au compte et au service spécifiés uniquement. Le tableau suivant répertorie les valeurs à utiliser pour l’ID de ressource en fonction du cloud avec lequel vous travaillez. Remplacez <account-name> par le nom de votre compte de stockage.

Cloud ID de ressource
Azure Global https://<account-name>.blob.core.windows.net
Azure Government https://<account-name>.blob.core.usgovcloudapi.net
21Vianet Azure - Chine https://<account-name>.blob.core.chinacloudapi.cn

Vous pouvez également fournir un ID de ressource qui s’applique à n’importe quel compte de stockage, comme illustré dans le tableau suivant. Cet ID de ressource est le même pour tous les clouds publics et souverains, et est utilisé afin d’obtenir un jeton pour autoriser les requêtes à n’importe quel compte de stockage.

Cloud ID de ressource
Azure Global
Azure Government
21Vianet Azure - Chine
https://storage.azure.com/

Attribuer des rôles Azure pour les droits d’accès

Microsoft Entra autorise les droits d’accès aux ressources sécurisées via le contrôle d’accès en fonction du rôle (RBAC) Azure. Stockage Azure définit un ensemble de rôles RBAC intégrés qui englobent les ensembles communs d’autorisations permettant d’accéder aux données blob. Vous pouvez également définir des rôles personnalisés pour l’accès aux données blob. Pour en savoir plus sur l’attribution de rôles Azure pour l’accès au blob, consultez Attribuer un rôle Azure pour l’accès aux données blob.

Un principal de sécurité Microsoft Entra peut correspondre à un utilisateur, à un groupe, à un principal de service d’application ou à une identité managée pour les ressources Azure. Les rôles RBAC qui sont attribués à un principal de sécurité déterminent les autorisations dont le principal disposera pour la ressource spécifiée. Pour en savoir plus sur l’attribution de rôles Azure pour l’accès au blob, consultez Attribuer un rôle Azure pour l’accès aux données blob

Dans certains cas, vous devrez peut-être activer un accès affiné aux ressources d’objets blob ou simplifier les autorisations si vous avez un grand nombre d’attributions de rôles pour une ressource de stockage. Vous pouvez utiliser le contrôle d’accès en fonction de l’attribut (Azure ABAC) pour configurer les conditions d’attribution de rôle. Vous pouvez utiliser des conditions avec un rôle personnalisé ou sélectionner des rôles intégrés. Pour plus d’informations sur la configuration de conditions pour les ressources de stockage Azure avec ABAC, consultez Autoriser l'accès aux objets blob à l'aide des conditions d'attribution de rôle Azure (préversion). Pour obtenir des détails sur les conditions prises en charge pour les opérations de données d’objets blob, consultez Actions et attributs pour les conditions d'attribution de rôle Azure dans le service Stockage Azure (préversion).

Remarque

Lorsque vous créez un compte Stockage Azure, aucune autorisation d’accès aux données ne vous est automatiquement attribuée via Microsoft Entra ID. Vous devez vous attribuer explicitement un rôle Azure pour accéder au stockage Azure. Vous pouvez l’attribuer au niveau de votre abonnement, groupe de ressources, compte de stockage ou conteneur.

Étendue des ressources

Avant d’attribuer un rôle RBAC Azure à un principal de sécurité, déterminez l’étendue de l’accès dont doit disposer le principal de sécurité. Selon les bonnes pratiques, il est toujours préférable d’accorder la plus petite étendue possible. Les rôles RBAC Azure définis au niveau d’une étendue plus large sont hérités par les ressources qui sont sous eux.

Vous pouvez étendre l’accès aux ressources blob Azure aux niveaux suivants, en commençant par l’étendue la plus étroite :

  • Un conteneur individuel. Dans cette étendue, une attribution de rôle s’applique à tous les objets blob dans le conteneur, ainsi qu’aux propriétés et aux métadonnées du conteneur.
  • Le compte de stockage. Dans cette étendue, une attribution de rôle s’applique à tous les conteneurs et à leurs blobs.
  • Groupe de ressources. Dans cette étendue, une attribution de rôle s’applique à tous les conteneurs dans tous les comptes de stockage du groupe de ressources.
  • Abonnement. Dans cette étendue, une attribution de rôle s’applique à tous les conteneurs dans tous les comptes de stockage de tous les groupes de ressources de l’abonnement.
  • Un groupe d’administration. Dans cette étendue, une attribution de rôle s’applique à tous les conteneurs dans tous les comptes de stockage de tous les groupes de ressources de tous les abonnements du groupe d’administration.

Pour plus d’informations sur l’étendue des attributions de rôle RBAC Azure, consultez Comprendre l’étendue de RBAC Azure.

Rôles intégrés Azure pour les blobs

RBAC Azure fournit un certain nombre de rôles intégrés pour autoriser l’accès aux données d’objet blob avec Microsoft Entra ID et OAuth. Voici quelques exemples de rôles qui fournissent des autorisations aux ressources de données dans Stockage Azure :

Pour savoir comment attribuer un rôle intégré Azure à un principal de sécurité, consultez Attribuer un rôle Azure pour l’accès aux données d’objet blob. Pour apprendre à lister les rôles RBAC Azure et leurs autorisations, consultez Lister les définitions de rôles Azure.

Pour plus d’informations sur la définition des rôles intégrés pour le Stockage Azure, consultez Comprendre les définitions de rôles. Pour plus d’informations sur la création de rôles personnalisés Azure, consultez Rôles personnalisés Azure.

Seuls les rôles explicitement définis pour l’accès aux données permettent à un principal de sécurité d’accéder aux données de blob. Des rôles intégrés tels que Propriétaire, Contributeur et Contributeur de comptes de stockage permettent à un principal de sécurité de gérer un compte de stockage, mais n’accordent pas l’accès aux données d’objet blob dans ce compte via Microsoft Entra ID. Toutefois, si un rôle comprend Microsoft.Storage/storageAccounts/listKeys/action, un utilisateur auquel ce rôle est affecté peut accéder aux données du compte de stockage via l’autorisation de la clé partagée avec les clés d’accès au compte. Pour plus d’informations, consultez Choisir comment autoriser l’accès à des données blobs dans le portail Azure.

Pour des informations détaillées sur les rôles intégrés Azure pour le Stockage Azure pour les services de données et de gestion, consultez la section Stockage dans Rôles intégrés Azure pour Azure RBAC. Pour plus d’informations sur les différents types de rôles qui fournissent des autorisations dans Azure, consultez Rôles d’administrateur d’abonnement classique, rôles Azure et rôles Microsoft Entra.

Important

Les attributions de rôles Azure peuvent prendre jusqu’à 30 minutes pour se propager.

Autorisations d’accès pour les opérations de données

Pour plus d’informations sur les autorisations requises pour l’appel d’opérations propres aux services BLOB, consultez Autorisations pour l’appel d’opérations de données.

Accéder aux données avec un compte Microsoft Entra

L’accès aux données d’objet blob par le biais du Portail Azure, de PowerShell ou d’Azure CLI peut être autorisé à l’aide du compte Microsoft Entra de l’utilisateur ou au moyen des clés d’accès au compte (autorisation de clé partagée).

Attention

L’autorisation avec une clé partagée n’est pas recommandée, car elle peut être moins sécurisée. Pour une sécurité optimale, désactivez l’autorisation via une clé partagée pour votre compte de stockage, comme décrit dans Empêcher l’autorisation avec clé partagée pour un compte de stockage Azure.

L’utilisation de clés d’accès et de chaînes de connexion doit être limitée aux applications de preuve de concept initiales ou aux prototypes de développement qui n’accèdent pas aux données de production ou aux données sensibles. Sinon, les classes d’authentification basées sur des jetons disponibles dans le kit de développement logiciel (SDK) Azure doivent toujours être priorisées lors de l’authentification auprès de ressources Azure.

Microsoft recommande aux clients d’utiliser Microsoft Entra ID ou une signature d’accès partagé (SAP) pour autoriser l’accès aux données dans le service Stockage Azure. Pour plus d’informations, consultez Autoriser les opérations pour l’accès aux données.

Accès aux données à partir du Portail Azure

Le Portail Azure peut utiliser soit votre compte Microsoft Entra, soit les clés d’accès au compte pour accéder aux données d’objet blob dans un compte de stockage Azure. Le schéma d’autorisation utilisé par le portail Azure dépend des rôles Azure qui vous sont attribués.

Lorsque vous tentez d’accéder aux données blob, le Portail Azure commence par vérifier si vous avez reçu un rôle Azure avec Microsoft.Storage/storageAccounts/listkeys/action. Si vous êtes doté d’un rôle avec cette action, le Portail Azure utilise la clé de compte pour l’accès aux données blob par le biais de l’autorisation par clé partagée. Si un rôle avec cette action ne vous a pas été attribué, le Portail Azure tente d’accéder aux données à l’aide de votre compte Microsoft Entra.

Pour accéder aux données d’objet blob à partir du Portail Azure à l’aide de votre compte Microsoft Entra, vous devez disposer d’autorisations pour accéder aux données blob, ainsi que pour parcourir les ressources de compte de stockage dans le Portail Azure. Les rôles intégrés fournis par le Stockage Azure octroient l’accès aux ressources blob, mais n’accordent pas d’autorisations pour les ressources de compte de stockage. C’est la raison pour laquelle l’accès au portail requiert également l’attribution d’un rôle Azure Resource Manager, tel que le rôle Lecteur, étendu au niveau du compte de stockage ou à un niveau supérieur. Le rôle Lecteur octroie les autorisations les plus restreintes, mais l’utilisation d’un autre rôle Azure Resource Manager accordant l’accès aux ressources de gestion de compte de stockage est également acceptable. Pour en savoir plus sur l’attribution d’autorisations à des utilisateurs pour l’accès aux données dans le Portail Azure avec un compte Microsoft Entra, consultez Attribuer un rôle Azure pour l’accès aux données Blob.

Le Portail Azure indique le schéma d’autorisation en cours d’utilisation lorsque vous accédez à un conteneur. Pour plus d’informations sur l’accès aux données dans le portail, consultez Choisir comment autoriser l’accès à des données blobs dans le Portail Azure.

Accès aux données à partir de PowerShell ou d’Azure CLI

Azure CLI et PowerShell prennent en charge la connexion avec des informations d’identification Microsoft Entra. Une fois que vous vous êtes connecté, votre session s’exécute sous ces informations d’identification. Pour plus d’informations, consultez l’un des articles suivants :

Prise en charge des fonctionnalités

La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.

L’autorisation d’opérations de données d’objet blob avec Microsoft Entra ID est prise en charge uniquement pour les versions 2017-11-09 et ultérieures de l’API REST. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.

Étapes suivantes