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

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. ABAC vous permet d’accorder à un principal de sécurité l’accès à une ressource selon les attributs. Azure ABAC fait référence à l’implémentation d’ABAC pour Azure.

Que sont 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 permet de gérer qui des utilisateurs ont accès aux ressources Azure, ce qu’ils peuvent en faire et à quels emplacements ils peuvent accéder. Dans la plupart des cas, Azure RBAC assure la gestion des accès dont vous avez besoin grâce à des définitions de rôle et des attributions de rôle. En revanche, dans certains cas, vous pouvez avoir besoin de disposer d’une gestion des accès plus précise ou de simplifier la gestion de centaines d’attributions de rôle.

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 autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore 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 oblige un objet à porter une étiquette spécifique pour être lu. Vous ne pouvez pas refuser explicitement l’accès à des ressources spécifiques en utilisant des conditions.

Pourquoi utiliser des conditions ?

L’utilisation de conditions d’attribution de rôle revêt trois principaux avantages :

  • Fournir un contrôle d’accès plus précis : Une attribution de rôle utilise une définition de rôle comprenant 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 à des fins de contrôle d’accès plus précis. Vous pouvez aussi ajouter des conditions à des actions spécifiques. Par exemple, vous pouvez octroyer à John un accès en lecture aux objets blob de votre abonnement uniquement si ces objets blob sont étiquetés Project=Blue.
  • Contribuer à réduire le nombre d’attributions de rôle : Chaque abonnement Azure est soumis à une limite d’attributions de rôle. Dans certains scénarios, des milliers d’attributions de rôle sont nécessaires. Toutes ces attributions de rôle ont besoin d’être gérées. Dans ces scénarios, vous pouvez éventuellement ajouter des conditions pour utiliser considérablement moins d’attributions de rôle.
  • Utiliser des attributs qui ont du sens pour votre entreprise : Les conditions vous permettent d’utiliser des attributs qui ont un intérêt particulier pour vous en termes de contrôle d’accès. Par exemple, les attributs peuvent être le nom du projet, la phase de développement d’un logiciel et des niveaux de classification. Les valeurs de ces attributs de ressource sont dynamiques et évoluent à mesure que les utilisateurs passent d’une équipe à l’autre et d’un projet à l’autre.

Exemples de scénarios pour les conditions

Dans plusieurs scénarios, vous pouvez avoir besoin d’ajouter une condition à votre attribution de rôle. Voici quelques exemples.

  • Accès en lecture aux objets blob portant l’étiquette Project=Cascade.
  • Les nouveaux objets blob doivent inclure l’étiquette Project=Cascade.
  • Les objets blob existants doivent être étiquetés avec au moins une clé Project ou une clé Program.
  • Les objets blob existants doivent être étiquetés avec une clé Project 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 manière de créer ces exemples, consultez Exemples de conditions d’attribution de rôle Azure pour 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. Comme pour les attributions de rôle, vous devez avoir des autorisations Microsoft.Authorization/roleAssignments/write pour ajouter une condition.

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

  • Nom du compte
  • Étiquettes d’index d’objet blob
  • Chemin d’accès d’objet blob
  • Préfixe de blob
  • Nom du conteneur
  • Nom de l’étendue de chiffrement
  • 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 est aussi ajoutée. Elle autorise uniquement l’accès en lecture aux objets blob dont l’étiquette est Project=Cascade.

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

Si Chandra tente de lire un objet blob qui ne porte pas l’étiquette Project=Cascade, l’accès n’est pas autorisé.

Le diagramme de l’accès refusé avec une condition.

Voici à quoi ressemble la condition dans le portail Azure :

Capture d’écran de l’éditeur de conditions sur le Portail Azure montrant que les objets blob existants doivent posséder des valeurs et une clé de balise d’index de blob.

Voici à quoi ressemble la condition exprimée sous forme de 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 Format et syntaxe des conditions d’attribution de rôle Azure.

État des fonctionnalités de condition

Le tableau suivant répertorie l’état des fonctionnalités de condition :

Fonctionnalité Statut Date
Utiliser des attributs d’environnement dans une condition GA Avril 2024
Ajoutez des conditions à l’aide de l’éditeur de conditions dans le Portail Azure GA Octobre 2022
Ajouter des conditions à l’aide d’Azure PowerShell, d’Azure CLI ou de l’API REST GA Octobre 2022
Utilisez des attributs de ressource et de requête pour des combinaisons spécifiques de ressources de stockage Azure, de types d’attributs d’accès et de niveaux de performances de compte de stockage. Pour plus d’informations, consultez État des fonctionnalités de condition dans stockage Azure. GA Octobre 2022
Utiliser des attributs de sécurité personnalisés sur un principal dans une condition GA Novembre 2023

Conditions et Privileged Identity Management (PIM) Microsoft Entra

Vous pouvez également ajouter des conditions aux attributions de rôles admissibles à l’aide de Microsoft Entra Privileged Identity Management (PIM Microsoft Entra) 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 PIM Microsoft entra vous permet non seulement de limiter l’accès d’un utilisateur à une ressource à l’aide de conditions affinées, mais également d’utiliser PIM Microsoft Entra pour la sécuriser avec un paramètre de durée, un workflow d’approbation, une piste d’audit, etc. 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 référer à la liste suivante de termes.

Terme Définition
contrôle d’accès en fonction des 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. ABAC vous permet d’accorder à un principal de sécurité l’accès à une ressource selon les attributs.
Azure ABAC Fait référence à l’implémentation d’ABAC pour Azure.
condition d’attribution de rôle Autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis.
attribut Dans ce contexte, paire clé-valeur comme Project=Blue, dans laquelle Project est la clé de l’attribut et Blue la valeur de l’attribut. Les attributs et les étiquettes 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 <attribut><opérateur><valeur>.

Limites

Voici certaines limites des conditions.

Ressource Limite Notes
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, le principal n’apparaît pas dans la Source de l’attribut lors de l’ajout d’une condition.

Étapes suivantes