Qu’est-ce que le contrôle d’accès basé sur des attributs Azure (Azure ABAC) ?

2025-05-20

Le contrôle d’accès en fonction des attributs (ABAC) est un système d’autorisation qui définit l’accès en fonction des attributs associés aux principaux de sécurité, aux ressources et à l’environnement d’une demande d’accès. Avec ABAC, vous pouvez accorder à un principal de sécurité un accès à une ressource en fonction des attributs. Azure ABAC fait référence à l’implémentation d’ABAC pour Azure.

Qu’est-ce que les conditions d’attribution de rôle ?

Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) est un système d’autorisation qui vous aide à gérer qui a accès aux ressources Azure, ce qu’ils peuvent faire avec ces ressources et les zones auxquelles ils ont accès. Dans la plupart des cas, Azure RBAC fournit la gestion des accès dont vous avez besoin à l’aide des définitions de rôles et des attributions de rôles. Toutefois, dans certains cas, vous souhaiterez peut-être fournir une gestion plus fine des accès ou simplifier la gestion des centaines d’attributions de rôles.

Azure ABAC s’appuie sur Azure RBAC en ajoutant des conditions d’attribution de rôle en fonction des attributs dans le contexte d’actions spécifiques. Une condition d’attribution de rôle est une vérification supplémentaire que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès plus précis. Une condition filtre les autorisations accordées dans le cadre de la définition de rôle et de l’attribution de rôle. Par exemple, vous pouvez ajouter une condition qui nécessite qu’un objet ait une balise spécifique pour lire l’objet. Vous ne pouvez pas refuser explicitement l’accès à des ressources spécifiques en utilisant des conditions.

L’utilisation d’Azure RBAC et d’Azure ABAC intègre les avantages des deux modèles de contrôle d’accès. Azure RBAC est plus simple à implémenter en raison de son alignement étroit avec la logique métier, tandis qu’Azure ABAC offre une plus grande flexibilité dans certains scénarios clés. En combinant ces deux méthodes, les organisations peuvent obtenir un niveau d’autorisation plus sophistiqué.

Pourquoi utiliser des conditions ?

Il existe trois principaux avantages pour l’utilisation des conditions d’attribution de rôle :

Fournir un contrôle d’accès plus précis : une attribution de rôle utilise une définition de rôle avec des actions et des actions de données pour accorder des autorisations à un principal de sécurité. Vous pouvez écrire des conditions pour filtrer ces autorisations pour un contrôle d’accès plus précis. Vous pouvez également ajouter des conditions à des actions spécifiques. Par exemple, vous pouvez accorder à John un accès en lecture aux objets blob de votre abonnement uniquement si les objets blob sont marqués comme Project=Blue.
Réduisez le nombre d’attributions de rôles : chaque abonnement Azure a actuellement une limite d’attribution de rôle. Il existe des scénarios qui nécessiteraient des milliers d’attributions de rôles. Toutes ces attributions de rôles doivent être gérées. Dans ces scénarios, vous pouvez éventuellement ajouter des conditions pour utiliser beaucoup moins d’attributions de rôles.
Utilisez des attributs qui ont une signification métier spécifique : les conditions vous permettent d’utiliser des attributs qui ont une signification métier spécifique pour vous dans le contrôle d’accès. Certains exemples d’attributs sont le nom du projet, la phase de développement de logiciels et les niveaux de classification. Les valeurs de ces attributs de ressource sont dynamiques et modifiées à mesure que les utilisateurs se déplacent entre les équipes et les projets.

Exemples de scénarios pour les conditions

Il existe plusieurs scénarios où vous souhaiterez peut-être ajouter une condition à votre attribution de rôle. Voici quelques exemples.

Accès en lecture aux objets blob avec la balise Project=Cascade
Les nouveaux objets blob doivent inclure la balise Project=Cascade
Les objets blob existants doivent être étiquetés avec au moins une clé de projet ou une clé de programme
Les objets blob existants doivent être étiquetés avec une clé de projet et des valeurs Cascade, Baker ou Skagit
Lire, écrire ou supprimer des objets blob dans des conteneurs nommés blobs-example-container.
Accès en lecture aux objets blob dans les conteneurs nommés blobs-example-container avec un chemin readonly.
Accès en écriture aux objets blob situés dans les conteneurs nommés Contosocorp avec un chemin uploads/contoso.
Accès en lecture aux objets blob avec l’étiquette Program=Alpine et un chemin logs.
Accès en lecture aux objets blob avec l’étiquette Project=Baker, l’utilisateur ayant un attribut correspondant Project=Baker.
Accès en lecture à des objets blob pendant une plage de date/heure spécifique.
Accès en écriture à des objets blob uniquement via une liaison privée ou à partir d’un sous-réseau spécifique.

Pour plus d’informations sur la création de ces exemples, consultez Exemples de conditions d’attribution de rôle Azure pour le stockage Blob.

Où les conditions peuvent-elles être ajoutées ?

Actuellement, il est possible d’ajouter des conditions à des attributions de rôles intégrés ou personnalisés qui ont des actions de données Stockage Blob ou de Stockage File d’attente. Les conditions sont ajoutées au niveau de la même étendue que l’attribution de rôle. Tout comme les attributions de rôles, vous devez disposer Microsoft.Authorization/roleAssignments/write des autorisations nécessaires pour ajouter une condition.

Voici les attributs de Stockage Blob que vous pouvez utiliser dans vos conditions.

Nom de compte
Balises d’index d’objets blob
Chemin d’accès d’objet blob
Préfixe de blob
Nom du conteneur
Nom de l'étendue de chiffrement
Est la version actuelle
Prend en charge l'espace de noms hiérarchique
Est une liaison privée
Instantané
UTC maintenant (date et heure actuelles en temps universel coordonné)
ID de version

À quoi ressemble une condition ?

Vous pouvez ajouter des conditions à des attributions de rôle nouvelles ou existantes. Voici le rôle Lecteur des données Blob du stockage qui a été affecté à un utilisateur nommé Chandra à l’étendue d’un groupe de ressources. Une condition a également été ajoutée qui autorise uniquement l’accès en lecture aux objets blob avec la balise Project=Cascade.

Diagramme de l’attribution de rôle avec une condition.

Si Chandra tente de lire un objet blob sans la balise Project=Cascade, l’accès n’est pas autorisé.

Le diagramme de l’accès n’est pas autorisé avec une condition.

Voici à quoi ressemble la condition dans le portail Azure :

Voici à quoi ressemble la condition dans le code :

(
    (
        !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
        AND NOT
        SubOperationMatches{'Blob.List'})
    )
    OR
    (
        @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
    )
)

Pour plus d’informations sur le format des conditions, consultez le format et la syntaxe des conditions d’attribution de rôle Azure.

État des fonctionnalités de condition

Le tableau suivant liste l’état des fonctionnalités de conditionnement :

Caractéristique	Statut	Date (Jour/Mois/Année)
Utiliser des attributs d’environnement dans une condition	Assemblée générale	Avril 2024
Ajouter des conditions en utilisant l'éditeur de conditions dans le portail Azure	Assemblée générale	Octobre 2022
Ajouter des conditions à l’aide d’Azure PowerShell, d’Azure CLI ou d’API REST	Assemblée générale	Octobre 2022
Utilisez des attributs de ressource et de requête pour des combinaisons spécifiques de ressources de stockage Azure, des types d’attributs d’accès et des niveaux de performances de compte de stockage. Pour plus d’informations, consultez État des fonctionnalités de condition dans Stockage Azure.	Assemblée générale	Octobre 2022
Utiliser des attributs de sécurité personnalisés sur un principal dans une condition	Assemblée générale	Novembre 2023

Conditions et Privileged Identity Management (PIM) Microsoft Entra

Vous pouvez également ajouter des conditions aux attributions de rôles éligibles à l’aide de Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) pour les ressources Azure. Avec Microsoft Entra PIM, vos utilisateurs finaux doivent activer une attribution de rôle éligible pour avoir l’autorisation d’effectuer certaines actions. L’utilisation de conditions dans Microsoft Entra PIM vous permet non seulement de limiter l’accès d’un utilisateur à une ressource à l’aide de conditions affinées, mais également d’utiliser Microsoft Entra PIM pour le sécuriser avec un paramètre lié à l’heure, un flux de travail d’approbation, une piste d’audit, et ainsi de suite. Pour plus d’informations, consultez Attribuer des rôles de ressources Azure dans Privileged Identity Management.

Terminologie

Pour mieux comprendre azure RBAC et Azure ABAC, vous pouvez vous reporter à la liste suivante des termes.

Terme	Définition
contrôle d’accès basé sur les attributs (ABAC)	Système d’autorisation qui définit l’accès en fonction des attributs associés aux principaux de sécurité, aux ressources et à l’environnement. Avec ABAC, vous pouvez accorder à un principal de sécurité un accès à une ressource en fonction des attributs.
Azure ABAC	Fait référence à l’implémentation d’ABAC pour Azure.
condition d’attribution de rôle	Vous pouvez ajouter un contrôle supplémentaire à votre attribution de rôle pour fournir un contrôle d’accès plus précis et détaillé.
attribut	Dans ce contexte, une paire clé-valeur telle que Project=Blue, où Project est la clé d’attribut et Blue est la valeur d’attribut. Les attributs et les balises sont synonymes à des fins de contrôle d’accès.
expression	Instruction dans une condition qui prend la valeur true ou false. Une expression a le format de <attribut><opérateur><valeur>.

Limites

Voici quelques-unes des limites des conditions.

Ressource	Limite	Remarques
Nombre d’expressions par condition à l’aide de l’éditeur visuel	5	Vous pouvez ajouter plus de cinq expressions à l’aide de l’éditeur de code

Problèmes connus

Voici les problèmes connus liés aux conditions :

Si vous utilisez Microsoft Entra Privileged Identity Management (PIM) et des attributs de sécurité personnalisés, Principal n’apparaît pas dans la source de l’attribut lors de l’ajout d’une condition.