Considérations de sécurité pour les conditions d’attribution de rôle Azure dans Azure Blob Storage

2025-05-08

Pour sécuriser entièrement les ressources à l’aide du contrôle d’accès basé sur des attributs Azure (Azure ABAC), vous devez également protéger les attributs utilisés dans les conditions d’attribution de rôle Azure. Par exemple, si votre condition est basée sur un chemin d’accès au fichier, vous devez être averti que l’accès peut être compromis si le principal dispose d’une autorisation illimitée pour renommer un chemin d’accès au fichier.

Cet article décrit les considérations de sécurité que vous devez prendre en compte dans vos conditions d’attribution de rôle.

Important

Le contrôle d’accès en fonction des attributs Azure (Azure ABAC) est en disponibilité générale (GA) pour contrôler l’accès au Stockage Blob Azure, à Azure Data Lake Storage Gen2 et aux files d’attente Azure à l’aide des attributs request, resource, environment et principal dans les niveaux de performances des comptes de stockage standard et premium. Actuellement, l’attribut de ressource des métadonnées de conteneur et l’attribut de requête d’inclusion de l’opération List Blobs sont en PRÉVERSION. Pour obtenir des informations complètes sur l’état des fonctionnalités d’ABAC pour Stockage Azure, consultez État des fonctionnalités de condition dans Stockage Azure.

Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

Utilisation d’autres mécanismes d’autorisation

Les conditions d’attribution de rôle sont évaluées uniquement lors de l’utilisation d’Azure RBAC pour l’autorisation. Ces conditions peuvent être ignorées si vous autorisez l’accès à l’aide de méthodes d’autorisation alternatives :

De même, les conditions ne sont pas évaluées lorsque l’accès est accordé à l’aide de listes de contrôle d’accès (ACL) dans des comptes de stockage avec un espace de noms hiérarchique (HNS).

Vous pouvez empêcher l’autorisation SAS au niveau de la clé partagée, au niveau du compte et SAS au niveau du service en désactivant l’autorisation de clé partagée pour votre compte de stockage. Étant donné que le SAS de délégation d’utilisateur repose sur le RBAC d’Azure, les conditions d’attribution des rôles sont évaluées lors de l’utilisation de cette méthode d’autorisation.

Sécurisation des attributs de stockage utilisés dans des conditions

Chemin d’accès d’objet blob

Lorsque vous utilisez le chemin d’accès blob en tant qu’attribut @Resource pour une condition spécifique, vous devez également empêcher les utilisateurs de renommer un blob pour accéder à un fichier lorsque des comptes disposant d’un espace de noms hiérarchique sont utilisés. Par exemple, si vous souhaitez créer une condition basée sur le chemin d’accès de l’objet blob, vous devez également restreindre l’accès de l’utilisateur aux actions suivantes :

Action	Descriptif
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action`	Cette action permet aux clients de renommer un fichier à l’aide de l’API Créer le chemin d’accès.
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action`	Cette action permet d’accéder à diverses opérations de système de fichiers et de chemin d’accès.

Balises d’index d’objets blob

Les balises d’index de blob sont utilisées comme attributs de forme libre pour les conditions de stockage. Si vous créez des conditions d’accès à l’aide de ces balises, vous devez également protéger les balises elles-mêmes. Plus précisément, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction permet aux utilisateurs de modifier les balises sur un objet de stockage. Vous pouvez restreindre cette action pour empêcher les utilisateurs de manipuler une clé ou une valeur d’étiquette pour accéder à des objets non autorisés.

En outre, lorsque des balises d’index de blob sont utilisées dans des conditions, les données peuvent se retrouver en situation de vulnérabilité si ces données et les balises d’index associées sont mises à jour dans le cadre d’opérations distinctes. Vous pouvez utiliser des conditions @Request sur les opérations d’écriture de blob pour exiger la définition de balises d’index dans la même opération de mise à jour. Cette approche peut aider à sécuriser les données à partir de l’instant où elles sont écrites dans le stockage.

Étiquettes sur des blobs copiés

Par défaut, les balises d’index d’objet blob ne sont pas copiées à partir d’un objet blob source vers la destination lorsque vous utilisez l’API Copy Blob ou l’une de ses variantes. Pour préserver l’étendue de l’accès au blob après la copie, vous devez également copier les étiquettes.

Balises sur les instantanés

Les étiquettes sur les instantanés de blob ne peuvent pas être modifiées. Par conséquent, vous devez mettre à jour les balises sur un objet blob avant de prendre l’instantané. Si vous modifiez les balises sur un objet blob de base, les balises de son instantané continuent d’avoir leur valeur précédente.

Si une balise sur un objet blob de base est modifiée après la prise d’un instantané, l’étendue de l’accès peut être différente pour l’objet blob de base et l’instantané.

Étiquettes des versions des blobs

Les balises d’index d’objet blob ne sont pas copiées lorsque vous créez une version d’objet blob via les API Put Blob, Put Block List ou Copy Blob. Vous pouvez spécifier des balises via l’en-tête de ces API.

Les balises peuvent être définies individuellement sur un objet blob de base actuel et sur chaque version d’objet blob. Lorsque vous modifiez des balises sur un objet blob de base, les balises des versions précédentes ne sont pas mises à jour. Si vous souhaitez modifier l’étendue de l’accès pour un objet blob et toutes ses versions à l’aide de balises, vous devez mettre à jour les balises sur chaque version.

Limitations d’interrogation et de filtrage des versions et des instantanés

Lorsque vous utilisez des balises pour interroger et filtrer des objets blob dans un conteneur, seuls les objets blob de base sont inclus dans la réponse. Les versions de blob ou les instantanés disposant des clés et des valeurs demandées ne sont pas inclus.

Rôles et autorisations

Si vous utilisez des conditions d’attribution de rôle pour les rôles intégrés Azure, vous devez examiner attentivement toutes les autorisations accordées par le rôle à un principal.

Attributions de rôles héritées

Les attributions de rôle peuvent être configurées pour un groupe d’administration, un abonnement, un groupe de ressources, un compte de stockage ou un conteneur, et sont héritées à chaque niveau dans l’ordre indiqué. Azure RBAC a un modèle additif. Les autorisations effectives sont donc la somme des attributions de rôles à chaque niveau. Si un principal a la même autorisation affectée par plusieurs attributions de rôles, alors l’accès pour une opération avec cette autorisation est évalué séparément pour chaque attribution à chaque niveau.

Étant donné que les conditions sont implémentées en tant que conditions sur les attributions de rôles, toute attribution de rôle inconditionnelle peut permettre aux utilisateurs de contourner la condition. Supposons que vous attribuez le rôle Contributeur de données de stockage blob à un utilisateur pour un compte de stockage et un abonnement, mais que vous ajoutez une condition uniquement à l’attribution du compte de stockage. Le résultat est que l’utilisateur a un accès illimité au compte de stockage via l’attribution de rôle au niveau de l’abonnement.

Par conséquent, vous devez appliquer des conditions de manière cohérente pour toutes les attributions de rôles dans une hiérarchie de ressources.

Autres considérations

Opérations de condition qui écrivent des blobs

De nombreuses opérations qui écrivent des objets blob nécessitent soit l'autorisation Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write, soit l'autorisation Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Les rôles intégrés, tels que propriétaire des données Blob de stockage et Contributeur aux données blob de stockage , accordent les deux autorisations à un principal de sécurité.

Lorsque vous définissez une condition d’attribution de rôle sur ces rôles, vous devez utiliser des conditions identiques sur ces deux autorisations pour garantir des restrictions d’accès cohérentes pour les opérations d’écriture.

Comportement pour Copier un blob et Copier un blob à partir d’une URL

Pour les opérations Copier l’objet blob et Copier l’objet blob à partir de l’URL, les conditions utilisant le chemin d’accès de l’objet blob comme attribut dans l’action @Request et ses sous-opérations sont évaluées uniquement pour l’objet blob de destination.

Pour les conditions du blob source, les conditions @Resource de l'action Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read sont évaluées.

Partager via