Considérations relatives à la sécurité pour les conditions d'attribution de rôle Azure dans le service Stockage Blob Azure
Pour que les ressources bénéficient d’une sécurité optimale via le contrôle d’accès en fonction 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 de fichier, vous devez vous méfier du fait que l’accès peut être compromis si le principal dispose d’une autorisation illimitée pour renommer un chemin de fichier.
Cet article décrit les considérations de sécurité à 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 des blobs de liste 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.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
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 :
- Autorisation de clé partagée
- Signature d’accès partagé (SAP) du compte
- SAP de service.
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 les comptes de stockage avec un espace de noms hiérarchique (HNS).
Vous pouvez empêcher les autorisations de clés partagées, SAP 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 la signature d’utilisateur SAS dépend d’Azure RBAC, les conditions d’affectation de rôles sont évaluées lors de l’utilisation de cette méthode d’autorisation.
Sécurisation des attributs de stockage utilisés dans les conditions
Chemin d’accès d’objet blob
Quand vous utilisez un chemin d’objet blob en tant qu’attribut @Resource pour une condition, vous devez également empêcher les utilisateurs de renommer un objet blob pour accéder à un fichier quand ils utilisent des comptes ayant un espace de noms hiérarchique. Par exemple, si vous souhaitez créer une condition basée sur le chemin d'un objet blob, vous devez également restreindre l'accès de l'utilisateur aux actions suivantes :
| Action | Description |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
Cette action permet aux clients de renommer un fichier à l’aide de l’API Path Create. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Cette action permet d’accéder à différentes opérations en lien avec le système de fichiers et le chemin d’accès. |
Étiquettes d’index d’objet 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 proprement dites. Plus précisément, l'action Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction permet aux utilisateurs de modifier les balises sur un objet de stockage. Vous pouvez limiter cette action pour empêcher les utilisateurs de manipuler une clé ou une valeur de balise 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 d’objet blob pour exiger la définition de balises d’index dans la même opération de mise à jour. Cette approche peut contribuer à sécuriser les données à partir du moment où elles sont écrites dans le stockage.
Balises des objets blob copiés
Par défaut, les balises d’index de blob ne sont pas copiées de l’objet blob source vers la destination lorsque l’API Copy Blob ou l’une de ses variantes est utilisée. Pour préserver l’étendue de l’accès au blob lors de la copie, vous devez également copier les étiquettes.
Balises des instantanés
Les balises des instantanés d’objets blob ne peuvent pas être modifiées. Vous devez donc mettre à jour les balises de l'objet blob avant de prendre l'instantané. Si vous modifiez les balises d’un objet blob de base, les balises de sa capture instantanée continuent d’avoir leur valeur précédente.
Si une étiquette sur un blob de base est modifiée après la prise d’un instantané, l’étendue de l’accès peut être différente pour le blob de base et l’instantané.
Balises des versions des objets blob
Les balises d'index de blob ne sont pas copiées lorsqu'une version d'un objet blob est créée 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 de l’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 d’un objet blob et de toutes ses versions à l’aide de balises, vous devez mettre à jour les balises de l’objet blob sur toutes ses versions.
Limitations de l'interrogation et du filtrage pour les versions et les instantanés
Lorsque vous utilisez des balises pour interroger et filtrer les objets blob dans un conteneur, seuls les objets blob de base sont inclus dans la réponse. Les versions des objets 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 que le rôle accorde à un principal.
Attributions de rôle 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 celles-ci sont héritées à chaque niveau dans l'ordre indiqué. Le contrôle Azure RBAC repose sur un modèle additif, de sorte que les autorisations effectives correspondent à la somme des attributions de rôle de chaque niveau. Si un principal se voit attribuer la même autorisation par le biais de plusieurs rôles, l’accès d’une opération utilisant cette autorisation est évalué séparément pour chaque attribution à chaque niveau.
Comme les conditions sont implémentées en tant que conditions sur les attributions de rôle, 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 pour le compte de stockage. Le résultat est que l’utilisateur dispose d’un accès sans restriction au compte de stockage via l’attribution de rôle au niveau de l’abonnement.
C’est pourquoi vous devez appliquer les conditions de manière cohérente pour toutes les attributions de rôles dans une hiérarchie de ressources.
Autres éléments à prendre en compte
Opérations de condition qui écrivent des objets blob
De nombreuses opérations qui écrivent des objets blob requièrent l’autorisation Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Des rôles intégrés, tels que Propriétaire des données Blob du stockage et Contributeur aux données Blob du stockage accordent ces 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 afin de garantir des restrictions d'accès cohérentes pour les opérations d'écriture.
Comportement pour Copy Blob et Copy Blob from URL
Pour les opérations Copy Blob et Copy Blob From URL, les conditions @Request utilisant un chemin d'objet blob comme attribut sur l'action Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write et ses sous-opérations sont uniquement évaluées pour l'objet blob de destination.
Pour les conditions de l'objet blob source, les conditions @Resource de l'action Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read sont évaluées.