Sélectionner et configurer une méthode appropriée pour l’accès aux files d’attente Azure

Le Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les requêtes aux données de file d’attente. Avec l’ID Microsoft Entra, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (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. 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 demande auprès du service de files d'attente.

L’autorisation avec l’ID Microsoft Entra offre une sécurité et une facilité d’utilisation supérieures sur l’autorisation de clé partagée. Microsoft recommande d’utiliser l’autorisation Microsoft Entra avec vos applications de file d’attente dans la mesure du possible pour garantir l’accès avec les privilèges minimum requis. Pour les applications s’exécutant dans Azure, utilisez des identités managées pour éliminer la nécessité de stocker les informations d’identification dans votre code.

L’autorisation avec l’ID Microsoft Entra est disponible pour tous les comptes de stockage à usage général dans toutes les régions publiques et 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.

Vue d’ensemble de l’ID Microsoft Entra pour les files d’attente

Lorsqu’un principal de sécurité (un utilisateur, un groupe ou une application) tente d’accéder à une ressource de file d’attente, la demande doit être autorisée. Avec l’ID Microsoft Entra, l’accès à une ressource est un processus en deux étapes :

• Authentification : l’identité du principal de sécurité est authentifiée et un jeton OAuth 2.0 est retourné. 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 de file d’attente. L’utilisation d’identités managées est l’approche recommandée , car elle élimine la nécessité de gérer les informations d’identification.
• Autorisation : le jeton est transmis dans le cadre d’une demande au service file d’attente et utilisé par le service pour autoriser l’accès à la ressource spécifiée. L’étape d’autorisation nécessite qu’un ou plusieurs rôles RBAC Azure soient attribués au principal de sécurité effectuant la requête.

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 avec un compte Microsoft Entra, consultez l’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 l’accès aux données à partir de PowerShell ou d’Azure CLI.

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

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

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

Bibliothèque de client 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 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’avantage 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 s’exécute dans l’environnement de développement ou dans Azure. La bibliothèque cliente Azure Identity retourne 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 ou un utilisateur ou un groupe. Dans l’environnement de développement, la bibliothèque cliente 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 pour effectuer des 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 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 aux données dans différents scénarios :

Bibliothèque d’authentification Microsoft (MSAL)

Bien que Microsoft recommande d’utiliser la bibliothèque de client Azure Identity si possible, la bibliothèque MSAL peut être appropriée pour l’utiliser dans certains scénarios avancés.

Lorsque vous utilisez MSAL pour acquérir 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’applique à 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 ressource est utilisé pour acquérir un jeton pour autoriser les demandes au compte et au service spécifiés uniquement. Le tableau suivant répertorie la valeur à 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.

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

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 Azure RBAC. 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 de la file d’attente. Vous pouvez également définir des rôles personnalisés pour accéder aux données de file d’attente.

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 affectés à un principal de sécurité déterminent les autorisations dont dispose le principal.

Dans certains cas, vous devrez peut-être activer l’accès précis aux ressources de file d’attente ou simplifier les autorisations lorsque vous disposez d’un grand nombre d’attributions de rôles pour une ressource de stockage. Vous pouvez utiliser le contrôle d’accès basé sur des attributs Azure (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 des conditions pour les ressources de stockage Azure avec ABAC, consultez Autoriser l’accès aux files d’attente à l’aide des conditions d’attribution de rôle Azure.

Lorsque vous créez un compte de stockage Azure, vous ne disposez pas automatiquement des autorisations d’accès aux données via l’ID Microsoft Entra. Vous devez vous attribuer explicitement un rôle Azure pour accéder au stockage file d’attente. Vous pouvez l’affecter au niveau de votre abonnement, groupe de ressources, compte de stockage ou file d’attente.

Étendue des ressources

Avant d’attribuer un rôle RBAC Azure à un principal de sécurité, déterminez l’étendue de l’accès que le principal de sécurité doit avoir. Accordez toujours uniquement l’étendue la plus restreinte possible nécessaire au principal de sécurité pour effectuer leurs tâches. Cela suit le principe des privilèges minimum et réduit les risques de sécurité. 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 de file d’attente Azure aux niveaux suivants, en commençant par l’étendue la plus étroite (la plus restrictive) :

• File d’attente individuelle. Dans cette étendue, une attribution de rôle s’applique aux messages de la file d’attente et aux propriétés et métadonnées de file d’attente.
• Compte de stockage. Dans cette étendue, une attribution de rôle s’applique à toutes les files d’attente et à leurs messages.
• Groupe de ressources. Dans cette étendue, une attribution de rôle s’applique à toutes les files d’attente de tous les comptes de stockage du groupe de ressources.
• Abonnement. Dans cette étendue, une attribution de rôle s’applique à toutes les files d’attente de 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 à toutes les files d’attente dans tous les comptes de stockage de tous les groupes de ressources de tous les abonnements du groupe d’administration.

Rôles intégrés Azure pour les files d’attente

Azure RBAC fournit plusieurs rôles intégrés pour autoriser l’accès aux données de file d’attente à l’aide de Microsoft Entra ID et OAuth. Voici quelques exemples de rôles qui fournissent des autorisations pour les ressources de données dans Stockage Azure :

• Contributeur aux données de file d’attente de stockage : accorde des autorisations de lecture, d’écriture et de suppression aux files d’attente Azure. Utilisez ce rôle pour les applications ou les utilisateurs qui ont besoin d’un accès total aux messages de file d’attente.
• Lecteur de données de file d’attente de stockage : accorde des autorisations en lecture seule aux files d’attente Azure. Utilisez ce rôle pour les applications ou les utilisateurs qui doivent uniquement afficher les messages de file d’attente sans droits de modification.
• Processeur de messages de données de file d’attente de stockage : accorde des autorisations d’aperçu, de récupération et de suppression aux messages dans les files d’attente stockage Azure. Utilisez ce rôle pour les applications de travail qui traitent et suppriment les messages des files d’attente.
• Expéditeur de messages de données de file d’attente de stockage : accorde des autorisations d’ajout aux messages dans les files d’attente de stockage Azure. Utilisez ce rôle pour les applications qui doivent uniquement mettre en file d’attente des messages sans les lire ni les supprimer.

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 file d’attente. Les rôles intégrés tels que Propriétaire, Contributeuret Contributeur de compte de stockage permettent à un principal de sécurité de gérer un compte de stockage, mais ne fournissent pas d'accès aux données de file d'attente au sein de ce compte via l'ID Microsoft Entra. Toutefois, si un rôle inclut 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 clé partagée avec les clés d’accès au compte.

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

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

L’accès aux données de file d’attente via le portail Azure, PowerShell ou Azure CLI peut être autorisé à l’aide du compte Microsoft Entra de l’utilisateur ou à l’aide des clés d’accès du compte (autorisation de clé partagée).

• Évitez l’autorisation de clé partagée : l’autorisation avec la clé partagée n’est pas recommandée, car elle fournit un accès complet au compte de stockage et ne prend pas en charge les fonctionnalités de sécurité avancées telles que l’accès conditionnel. 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 de clé partagée pour un compte de stockage Azure.
• Limiter l’utilisation des clés d’accès : l’utilisation des clés d’accès et des chaînes de connexion doit être limitée aux prototypes de preuve de concept initiales ou de développement qui n’accèdent pas aux données de production ou sensibles. Pour les charges de travail de production, utilisez toujours des classes d’authentification basées sur des jetons disponibles dans le Kit de développement logiciel (SDK) Azure.
• Préférer l’ID Microsoft Entra : Microsoft recommande aux clients d’utiliser l’ID Microsoft Entra pour la méthode d’autorisation la plus sécurisée. Lorsque la délégation est requise, utilisez une SAS de délégation d’utilisateur pour le stockage Blob sécurisé avec les informations d’identification Microsoft Entra.

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

Le portail Azure peut utiliser votre compte Microsoft Entra ou les clés d’accès du compte pour accéder aux données de file d’attente 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 de file d’attente, 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 reçu un rôle avec cette action, le portail Azure utilise la clé de compte pour accéder aux données de file d’attente via l’autorisation de clé partagée. Si vous n’avez pas été 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 de file d’attente à partir du portail Azure à l’aide de votre compte Microsoft Entra, vous avez besoin d’autorisations pour accéder aux données de file d’attente et vous devez également accéder aux ressources du compte de stockage dans le portail Azure. Les rôles intégrés fournis par Stockage Azure accordent l’accès aux ressources de file d’attente, mais ils n’accordent pas d’autorisations aux ressources du compte de stockage. Pour cette raison, l’accès au portail nécessite également l’attribution d’un rôle Azure Resource Manager, tel que le rôle Lecteur, limité au niveau du compte de stockage ou supérieur. Le rôle Lecteur accorde les autorisations les plus restreintes, mais un autre rôle Azure Resource Manager qui accorde l’accès aux ressources de gestion des comptes de stockage est également acceptable.

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

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

• Choisir comment autoriser l’accès aux données de file d’attente avec Azure CLI
• exécuter des commandes PowerShell avec des identifiants Microsoft Entra pour accéder aux données de file d’attente

Meilleures pratiques pour autoriser l’accès à la file d’attente

Lors de l’implémentation de l’autorisation de Microsoft Entra ID pour le stockage de files d'attente Azure, suivez les bonnes pratiques de sécurité suivantes :

• Utilisez des identités managées : pour les applications s’exécutant dans Azure (machines virtuelles, App Service, Azure Functions, Container Instances, AKS), utilisez toujours des identités managées au lieu des principaux de service avec des informations d’identification stockées. Cela élimine la surcharge de gestion des informations d’identification et améliore la sécurité.
• Implémentez le privilège minimum : attribuez le rôle le plus restrictif qui répond aux exigences :
  • Utiliser le lecteur de données de file d’attente de stockage pour les applications qui doivent uniquement afficher les messages
  • Utilisez l’Expéditeur de messages de données en file d’attente du stockage pour les applications qui ne font que mettre en file d’attente les messages
  • Utiliser le processeur de messages de données de file d’attente de stockage pour les applications de travail qui traitent et suppriment des messages
  • Utiliser Contributeur de données de file d'attente de stockage uniquement lorsque l’accès complet est requis
• Définissez correctement la portée des attributions : appliquez les attributions de rôles au niveau de la file d’attente lorsque cela est possible plutôt qu’au niveau du compte de stockage ou de l’abonnement. Cela limite l’accès aux files d’attente spécifiques dont les utilisateurs ou les applications ont besoin.
• Désactiver l’autorisation de clé partagée : une fois que vous avez migré vers l’authentification Microsoft Entra ID, envisagez de désactiver l’autorisation de clé partagée au niveau du compte de stockage pour empêcher l’accès non autorisé via des clés de compte.
• Utilisez des rôles personnalisés pour un contrôle précis : si les rôles intégrés ne répondent pas à vos exigences spécifiques, créez des rôles RBAC Azure personnalisés avec uniquement les autorisations nécessaires.
• Surveiller les modèles d’accès : activez la journalisation des diagnostics et passez régulièrement en revue les journaux Azure Monitor pour suivre l’accès à la file d’attente et identifier toute activité suspecte ou non autorisée.
• Appliquer des stratégies d’accès conditionnel : utilisez des stratégies d’accès conditionnel Microsoft Entra pour appliquer des exigences de sécurité supplémentaires telles que l’authentification multifacteur, la conformité des appareils ou les restrictions basées sur l’emplacement.
• Implémenter une logique de nouvelle tentative : les applications basées sur la file d’attente doivent implémenter une logique de nouvelle tentative appropriée avec une interruption exponentielle pour gérer correctement les échecs d’authentification ou d’autorisation temporaires.
• Révisions d’accès régulières : auditez régulièrement les attributions de rôles pour garantir que les utilisateurs et les applications nécessitent toujours leurs autorisations affectées et suppriment l’accès inutile.
• Environnements distincts : utilisez différents comptes de stockage et attributions de rôles pour les environnements de développement, de test et de production afin de réduire le risque d’exposition ou de modification accidentelle des données.