RBAC vs ABAC : deux modèles complémentaires pour sécuriser vos accès

Le contrôle d'accès est l'un des piliers de toute stratégie IAM (Identity and Access Management). Pendant longtemps, assigner un rôle suffisait. Aujourd'hui, les environnements hybrides, le télétravail généralisé et les exigences Zero Trust ont rendu cette logique insuffisante. Cet article s'adresse aux administrateurs et ingénieurs cloud qui gèrent des identités dans Microsoft Entra ID et qui cherchent à comprendre — et à implémenter — une approche d'autorisation moderne.

RBAC : la fondation universelle du contrôle d'accès

Le RBAC (Role-Based Access Control) est le modèle d'autorisation le plus répandu dans les environnements Microsoft. Le principe est direct : on attribue à un utilisateur un rôle, et ce rôle porte un ensemble de permissions prédéfinies.

Dans Microsoft Entra ID, cela se traduit concrètement par :

• Des rôles intégrés comme Global Administrator, User Administrator ou Security Reader
• Des rôles personnalisés créés pour restreindre au périmètre exact nécessaire
• Des rôles Azure RBAC pour les ressources ARM (Azure Resource Manager), distincts des rôles Entra ID

La force du RBAC est sa lisibilité : il est facile d'auditer qui a accès à quoi, de révoquer des accès en masse par rôle, et de déléguer l'administration à des équipes.

Sa limite ? Il répond à la question « qui peut accéder ? » mais pas à « dans quelles conditions ? ». Un compte compromis portant le bon rôle obtient exactement les mêmes droits qu'un utilisateur légitime.

ABAC : l'autorisation par le contexte

L'ABAC (Attribute-Based Access Control) étend le modèle en évaluant des attributs au moment de la demande d'accès. Au lieu de se limiter à l'identité et au rôle, le moteur d'autorisation examine un ensemble de signaux contextuels.

Dans l'écosystème Microsoft, ces attributs peuvent inclure :

• Conformité de l'appareil : l'appareil est-il géré par Intune et conforme aux politiques ?
• Attributs utilisateur : département, localisation déclarée, type de contrat
• Localisation réseau : IP dans une plage nommée, connexion depuis un pays autorisé
• Niveau de risque : score de risque calculé par Microsoft Entra ID Protection (sign-in risk, user risk)
• Heure et plage horaire : accès autorisé uniquement en heures ouvrées
• Méthode d'authentification : MFA satisfait, force d'authentification requise

Ces signaux sont évalués dynamiquement à chaque tentative d'accès, ce qui aligne naturellement ABAC avec les principes Zero Trust : ne jamais faire confiance implicitement, toujours vérifier.

RBAC et ABAC : des modèles complémentaires, pas concurrents

L'erreur classique est de les opposer. En pratique, ils opèrent à deux niveaux différents de la décision d'accès :

En architecture production, le flux de décision ressemble à ceci :

1. L'utilisateur demande l'accès à une ressource
2. RBAC vérifie qu'il dispose du rôle ou de la permission appropriée
3. ABAC (Conditional Access) évalue les signaux contextuels et décide si l'accès est accordé, bloqué, ou conditionné (MFA, changement de mot de passe, etc.)

Supprimez l'une des deux couches et vous obtenez soit un système trop permissif (RBAC seul), soit un système impossible à gérer à l'échelle (ABAC seul sans hiérarchie de rôles).

Mise en œuvre

L'exemple suivant illustre comment auditer, depuis PowerShell, les attributs clés qui alimentent une décision ABAC dans Entra ID : rôles attribués à un utilisateur, statut de conformité de ses appareils, et niveau de risque courant. Ces trois informations couvrent les piliers RBAC et ABAC d'une revue d'accès.

Prérequis :

• Module : Microsoft.Graph (v2.x recommandé)
• Permissions minimales (application ou déléguées) : User.Read.All, Directory.Read.All, DeviceManagementManagedDevices.Read.All, IdentityRiskyUser.Read.All
• Rôle Entra ID minimum : Security Reader + Intune Administrator (lecture seule)

1# Installer le module si nécessaire
2# Install-Module Microsoft.Graph -Scope CurrentUser
3 
4# Connexion avec les scopes nécessaires
5Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All", `
6    "DeviceManagementManagedDevices.Read.All", `
7    "IdentityRiskyUser.Read.All"
8 
9# Paramètre : UPN de l'utilisateur à auditer
10$userUpn = "john.doe@contoso.com"
11 
12# --- 1. Récupérer l'utilisateur ---
13$user = Get-MgUser -Filter "userPrincipalName eq '$userUpn'" `
14    -Property Id, DisplayName, UserPrincipalName, Department, JobTitle
15 
16if (-not $user) {
17    Write-Error "Utilisateur introuvable : $userUpn"
18    return
19}
20 
21Write-Host "`n=== Identité ==="
22Write-Host "Nom         : $($user.DisplayName)"
23Write-Host "Département : $($user.Department)"
24Write-Host "Fonction    : $($user.JobTitle)"
25 
26# --- 2. Rôles Entra ID attribués (RBAC) ---
27Write-Host "`n=== Rôles Entra ID attribués ==="
28$roleAssignments = Get-MgUserMemberOf -UserId $user.Id | `
29    Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.directoryRole' }
30 
31if ($roleAssignments) {
32    $roleAssignments | ForEach-Object {
33        Write-Host "  - $($_.AdditionalProperties['displayName'])"
34    }
35} else {
36    Write-Host "  Aucun rôle Entra ID direct détecté."
37}
38 
39# --- 3. Appareils et conformité Intune (signal ABAC) ---
40Write-Host "`n=== Appareils enregistrés et conformité ==="
41$devices = Get-MgUserOwnedDevice -UserId $user.Id
42 
43foreach ($deviceRef in $devices) {
44    # Récupérer les détails de conformité via le endpoint managedDevices
45    $managed = Get-MgDeviceManagementManagedDevice `
46        -Filter "azureADDeviceId eq '$($deviceRef.Id)'" `
47        -Property DeviceName, ComplianceState, OperatingSystem, LastSyncDateTime `
48        -ErrorAction SilentlyContinue
49 
50    if ($managed) {
51        Write-Host "  Appareil   : $($managed.DeviceName)"
52        Write-Host "  OS         : $($managed.OperatingSystem)"
53        Write-Host "  Conformité : $($managed.ComplianceState)"
54        Write-Host "  Dernière synchro : $($managed.LastSyncDateTime)"
55        Write-Host ""
56    }
57}
58 
59# --- 4. Risque utilisateur Entra ID Protection (signal ABAC) ---
60Write-Host "=== Niveau de risque utilisateur ==="
61$riskyUser = Get-MgRiskyUser -Filter "userPrincipalName eq '$userUpn'" `
62    -Property RiskLevel, RiskState, RiskLastUpdatedDateTime -ErrorAction SilentlyContinue
63 
64if ($riskyUser) {
65    Write-Host "  Niveau de risque : $($riskyUser.RiskLevel)"
66    Write-Host "  État             : $($riskyUser.RiskState)"
67    Write-Host "  Dernière MAJ     : $($riskyUser.RiskLastUpdatedDateTime)"
68} else {
69    Write-Host "  Aucune donnée de risque disponible (licence ou permission manquante)."
70}
71 
72Write-Host "`nAudit terminé pour $userUpn"

Conditional Access : là où ABAC prend vie dans Entra ID

Les politiques d'accès conditionnel sont le moteur d'évaluation ABAC natif d'Entra ID. Chaque politique définit :

• Conditions (qui ? depuis quoi ? depuis où ? avec quel risque ?)
• Contrôles d'accès (bloquer, exiger MFA, exiger un appareil conforme, limiter la session)

Une architecture Zero Trust minimale combine toujours les deux couches :

1Utilisateur  →  [RBAC : a-t-il le rôle ?]  →  [ABAC : Conditional Access passe ?]  →  Ressource

Les conditions évaluées par Conditional Access couvrent nativement :

• Plateformes d'appareil : Windows, iOS, Android, macOS, Linux
• Applications client : navigateur, client moderne, Exchange ActiveSync
• Plages IP nommées (Named Locations) : listes d'IP ou pays
• Risque de connexion et risque utilisateur : niveaux low, medium, high
• Rôles d'annuaire : appliquer des contrôles renforcés aux comptes privilégiés
• Filtre sur appareils : attributs d'appareil comme extensionAttribute ou trustType

ABAC natif pour Azure Storage : les conditions d'attribution de rôle

Depuis 2023, Microsoft a introduit des conditions d'attribution de rôle ABAC pour Azure Blob Storage, disponibles en disponibilité générale. Elles permettent d'affiner une attribution RBAC existante avec des conditions sur les attributs des ressources.

Exemple concret : attribuer le rôle Storage Blob Data Reader uniquement sur les blobs dont le tag d'index confidentiality vaut public.

1# Prérequis : module Az.Resources
2# Rôle requis : User Access Administrator sur le scope cible
3 
4$condition = `
5"((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})) " + `
6"OR (@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:confidentiality<`$key_case_sensitive`$>] StringEquals 'public'))"
7 
8New-AzRoleAssignment `
9    -ObjectId "<ObjectId-du-groupe-ou-utilisateur>" `
10    -RoleDefinitionName "Storage Blob Data Reader" `
11    -Scope "/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Storage/storageAccounts/<storage-account>" `
12    -Condition $condition `
13    -ConditionVersion "2.0"

Cette capacité est documentée sur la page Vue d'ensemble du contrôle d'accès basé sur les attributs Azure dans Microsoft Learn.

Dépannage des erreurs courantes

Get-MgRiskyUser retourne un résultat vide sans erreur → Vérifiez que la licence Entra ID P2 est bien assignée à l'utilisateur cible ET au tenant. Vérifiez également que le scope IdentityRiskyUser.Read.All est bien consenti.

La politique Conditional Access ne s'applique pas à un utilisateur spécifique → Consultez les Sign-in logs dans le portail Entra ID, onglet Conditional Access. Chaque politique liste son résultat (Success, Failure, Not applied) avec la raison. Les exclusions de groupe ou les exclusions de compte de service sont les causes les plus fréquentes.

New-AzRoleAssignment échoue avec InvalidConditionVersion → Assurez-vous que -ConditionVersion "2.0" est bien spécifié. La version 1.0 est dépréciée et ne supporte plus de nouvelles conditions.

Latence après attribution de rôle RBAC → Les attributions de rôles Entra ID se propagent généralement en moins de 15 minutes, mais peuvent prendre jusqu'à 60 minutes dans des tenants à fort volume. Les tokens JWT existants ne sont pas révoqués immédiatement : l'utilisateur peut conserver ses anciens droits jusqu'à l'expiration du token (1 heure par défaut pour les access tokens).

1# Révoquer immédiatement toutes les sessions actives d'un utilisateur
2# Permission requise : User.ReadWrite.All
3Revoke-MgUserSignInSession -UserId "john.doe@contoso.com"

Ce que vous faites dès lundi

Si votre organisation s'appuie encore exclusivement sur le RBAC sans couche ABAC, voici les trois actions prioritaires :

1. Auditez vos attributions RBAC avec le script fourni — identifiez les comptes à risque élevé qui portent des rôles sensibles sans contrôle contextuel.
2. Activez Conditional Access en mode Report-only sur vos applications critiques. Commencez par une politique exigeant un appareil conforme pour l'accès aux données sensibles.
3. Évaluez Entra ID P2 si ce n'est pas encore le cas : sans les signaux de risque, votre couche ABAC est aveugle aux comportements anormaux.

Si votre organisation utilise Azure Storage pour des données multi-sensibilité, les conditions d'attribution de rôle ABAC permettent de remplacer des comptes de service multipliés par une politique d'accès fine sur un seul rôle — réduisant drastiquement la surface d'exposition.

RBAC et ABAC ne se remplacent pas : l'un définit le périmètre des droits, l'autre valide chaque demande d'accès dans son contexte. C'est leur combinaison qui produit un modèle d'autorisation réellement résilient.