Autoriser l’accès aux blobs à l’aide de Microsoft Entra ID

Le stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les requêtes aux données Blob. En utilisant Microsoft Entra ID, vous pouvez utiliser Azure contrôle d’accès en fonction du rôle (Azure RBAC) pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur, un groupe ou un principal de service d’application. Microsoft Entra ID authentifie le principal de sécurité et retourne un jeton OAuth 2.0. Utilisez le jeton pour autoriser une demande auprès du service Blob.

Vous pouvez utiliser l'autorisation Microsoft Entra ID avec tous les comptes de stockage généraux et de Blob dans toutes les régions publiques et les clouds nationaux. Seuls les comptes de stockage créés à l’aide du modèle de déploiement Azure Resource Manager prennent en charge l’autorisation Microsoft Entra.

Important

Pour une sécurité optimale, Microsoft recommande d’utiliser quand c’est possible Microsoft Entra ID avec des identités managées pour autoriser les requêtes sur les données de blob, de file d’attente et de table. L’autorisation avec Microsoft Entra ID et les identités managées offre davantage de sécurité et de facilité d’utilisation que l’autorisation de clé partagée. Pour plus d’informations sur les identités managées, consultez Présentation des identités managées pour les ressources Azure. Pour obtenir un exemple d’activation et d’utilisation d’une identité managée pour une application .NET, consultez Authentification d’applications hébergées par Azure auprès de ressources Azure avec .NET.

Pour les ressources hébergées en dehors d’Azure, comme des applications locales, vous pouvez utiliser des identités managées via Azure Arc. Par exemple, les applications s’exécutant sur des serveurs avec Azure Arc peuvent utiliser des identités managées pour se connecter à des services Azure. Pour en savoir plus, consultez S’authentifier auprès de ressources Azure au moyen de serveurs avec Azure Arc.

Pour les scénarios où les signatures d’accès partagé (SAP) sont utilisées, Microsoft recommande d’utiliser une SAP de délégation d’utilisateur. Une signature d’accès partagé (SAS) de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra, au lieu de la clé de compte. Pour en savoir plus sur les signatures d’accès partagé, consultez Accorder un accès limité aux données avec des signatures d’accès partagé. Pour obtenir un exemple de création et d’utilisation d’une SAP de délégation d’utilisateur avec .NET, consultez Créer une SAP de délégation d’utilisateur pour un objet blob avec .NET.

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. En utilisant 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, le jeton est transmis dans le cadre d’une demande au service Blob et le service l’utilise 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 en savoir plus sur l’accès aux données dans le portail Azure à l’aide d’un compte Microsoft Entra, consultez Accès aux données depuis le portail Azure. Pour savoir comment utiliser des commandes Azure PowerShell ou Azure CLI avec un compte Microsoft Entra, consultez Accès aux données depuis PowerShell ou Azure CLI.

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

Pour autoriser l’accès à stockage Azure à l’aide de Microsoft Entra ID, utilisez l’une des bibliothèques clientes suivantes pour acquérir un jeton OAuth 2.0 :

  • La bibliothèque cliente Azure Identity est recommandée pour la plupart des scénarios de développement.
  • Le Microsoft Authentication Library (MSAL) peut convenir à certains scénarios avancés.

Bibliothèque cliente Azure Identity

La bibliothèque cliente Azure Identity simplifie le processus d’obtention d’un jeton d’accès OAuth 2.0 pour l’autorisation à l’aide de Microsoft Entra ID via le Kit de développement logiciel (SDK) Azure. Les dernières versions des bibliothèques clientes 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 de 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é gérée pour les ressources Azure, un principal de service ou 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 retourné par la bibliothèque cliente Azure Identity est encapsulé dans des informations d’identification de 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 que fournit la bibliothèque cliente 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 Allez
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 avec les principaux de service des développeurs 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 Kit de développement logiciel (SDK) Azure 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 Kit de développement logiciel (SDK) Azure 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 Kit de développement logiciel (SDK) Azure 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 cliente Azure Identity lorsque cela est possible, la bibliothèque MSAL peut être appropriée pour l’utiliser 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 de 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.

Nuage ID de ressource
Azure Global https://<account-name>.blob.core.windows.net
Azure pour le gouvernement 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.

Nuage ID de ressource
Azure Global
Azure pour le gouvernement
21Vianet Azure - Chine
https://storage.azure.com/

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

Microsoft Entra autorise des 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 être un utilisateur, un groupe, un principal de service d’application ou une identité managée pour les ressources Azure. Les rôles RBAC que vous affectez à un principal de sécurité déterminent les autorisations dont dispose le principal pour la ressource spécifiée.

Pour en savoir plus sur l’attribution de rôles Azure pour l’accès aux objets blob, consultez Assigner un rôle Azure pour accéder aux données d’objet blob.

Dans certains cas, vous devrez peut-être activer l’accès granulaire aux ressources d’objets blob ou simplifier les autorisations lorsque vous avez un grand nombre d’attributions de rôles pour une ressource de stockage. Utilisez Azure contrôle d’accès basé sur les attributs (Azure ABAC) pour configurer des conditions sur les attributions de rôles. 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 de blobs, consultez Actions et attributs pour les conditions d'attribution de rôle Azure dans le service Stockage Azure (aperçu).

Remarque

Lorsque vous créez un compte stockage Azure, vous n'êtes pas automatiquement autorisé à accéder aux données via Microsoft Entra ID. Vous devez vous attribuer explicitement un rôle Azure pour accéder à Azure Stockage Blob. 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é. Accordez toujours uniquement l’étendue la plus étroite 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.
  • L’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

Azure RBAC fournit plusieurs rôles intégrés pour autoriser l'accès aux données blob à l'aide de Microsoft Entra ID et d'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 inclut Microsoft. Storage/storageAccounts/listKeys/action, puis un utilisateur auquel ce rôle est affecté peut accéder aux données du compte de stockage via l’autorisation de clé partagée à l’aide des clés d’accès du 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 Azure intégrés pour stockage Azure, pour les services de données et le service 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.

Délais de propagation de l’attribution de rôle pour l’accès aux données de type blob

Lorsque vous attribuez des rôles ou supprimez des attributions de rôle, un délai de 10 minutes maximum peut être nécessaire avant que les modifications soient prises en compte. Si vous attribuez des rôles à l’étendue du groupe d’administration, cela peut prendre beaucoup plus de temps.

Vous pouvez attribuer des rôles intégrés avec des actions de données dans l’étendue du groupe d’administration. Toutefois, dans de rares scénarios, il peut y avoir un délai important (jusqu’à 12 heures) avant que les autorisations d’action de données soient effectives pour certains types de ressources. Les autorisations sont finalement appliquées. Pour les rôles intégrés avec des actions de données, l'ajout ou la suppression d'attributions de rôles au niveau de l'étendue du groupe d'administration n'est pas recommandée pour les scénarios où l'activation ou la révocation d'autorisations en temps opportun, comme Microsoft Entra Privileged Identity Management (PIM), est requise.

Si vous définissez les autorisations d'autorisation appropriées pour accéder aux données via Microsoft Entra ID et que vous ne pouvez pas accéder aux données, par exemple, vous obtenez une erreur « AuthorizationPermissionMismatch », veillez à accorder suffisamment de temps aux modifications d'autorisations que vous avez apportées dans Microsoft Entra ID pour répliquer. En outre, assurez-vous que vous n'avez pas de règles de refus qui bloquent votre accès. Pour plus d’informations, consultez Comprendre les affectations de refus Azure.

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

Vous pouvez autoriser l'accès aux données d'objet blob via le portail Azure, PowerShell ou Azure CLI, soit en utilisant votre compte Microsoft Entra, soit avec les 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 d’objet blob, le portail Azure vérifie d’abord si vous avez reçu un rôle Azure avec Microsoft.Storage/storageAccounts/listkeys/action. Si vous avez été assigné à un rôle comportant cette action, le portail Azure utilise la clé de compte pour accéder aux données Blob via l’autorisation de clé partagée. Si vous n'êtes pas affecté à un rôle avec cette action, le portail Azure tente d'accéder aux données à l'aide de votre compte Microsoft Entra.

Pour accéder aux données d’objets blob à partir du portail Azure à l’aide de votre compte Microsoft Entra, vous avez besoin d’autorisations pour accéder aux données d’objet blob, et vous avez également besoin d’autorisations pour parcourir les ressources du compte de stockage dans le portail Azure. Les rôles intégrés fournis par stockage Azure octroient l'accès aux ressources blob, mais ils n'octroient pas d'autorisations pour les ressources du 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 des opérations sur les données BLOB avec Microsoft Entra ID n'est prise en charge que 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