- Azure Doctor
- Posts
- 📘 Azure Guide #8 — Rôles (RBAC) Azure
📘 Azure Guide #8 — Rôles (RBAC) Azure
Hicham KADIRI
24th avril 2025
💊 Votre colonne vertébrale Cloud, signée Azure Doctor
📅 Publié le 24 Avril 2025 | ⏱️ Lecture : 6 minutes
🧠 Le Mot du Azure Doctor: "Qui touche à quoi dans ton Cloud ?"
Imagine ton Cloud Azure comme une maison bien rangée : il y a des pièces (VMs, databases), des tiroirs (storage), et des clés (permissions).
Maintenant imagine que tout le monde a les doubles des clés. 🫣
C’est là qu’intervient le héros de la semaine : RBAC — le Role-Based Access Control.
RBAC, c’est le vigile intelligent qui vérifie qui peut entrer, où, et avec quels droits. Et il n'oublie personne, même pas le stagiaire qui a "juste besoin de lire les logs".
🤖 Azure RBAC en version café-croissant ☕
RBAC te permet de dire :
"Michel peut créer des VMs"
"Fatima peut tout faire SAUF gérer les accès"
"Cette appli peut lire les données mais pas les modifier"
C’est littéralement "Qui fait quoi, où" :
🔐 Security Principal : qui ?
🧩 Role Definition : quoi ?
🗺️ Scope : où ?
🧠 Une histoire de rôles (et pas au théâtre)
Azure t’offre des rôles prédéfinis :
Owner : accès total (c’est le chef)
Contributor : il fait tout, sauf inviter les autres
Reader : lecture seule (comme un spectateur au musée)
Custom Role : ton rôle maison, recette 100% sur mesure
🎯 Exemple drôle mais vrai :
“Lucie peut lancer une VM, mais pas la détruire en pleine démo (oups)”
🧑⚕️ Rôles prédéfinis ou sur mesure ? Le Doc t’explique
Tu veux faire du RBAC ? Parfait.
Mais avant de prescrire, il faut comprendre ce que tu as dans la boîte à outils.
🧰 Les rôles intégrés — les classiques bien rodés
Azure te propose plus de 120 rôles prédéfinis prêts à l’emploi. Ils couvrent 80% des besoins du quotidien.
Pas besoin de les bricoler, ils sont gérés, testés, documentés par Microsoft. C’est du béton armé.
Voici une mini-pharmacie des plus utilisés :
💊 Rôle intégré | Ce qu’il permet de faire |
|---|---|
Owner | Accès total, y compris la gestion des accès (attention ⚠️) |
Contributor | Tout faire… sauf gérer les accès |
Reader | Lire, observer, analyser — mais pas toucher |
Virtual Machine Contributor | Gérer les VMs (créer, modifier, démarrer, etc.) |
Storage Blob Data Contributor | Lecture/écriture dans les blobs de stockage |
Key Vault Contributor | Gérer un coffre-fort, sans toucher aux secrets |
Network Contributor | Créer, modifier et connecter des réseaux virtuels |
💡 Pro Tip du Doctor : utilise toujours ces rôles via des groupes AAD, jamais en affectation directe à un utilisateur. Tu me remercieras plus tard.
🧬 Et les Custom Roles alors ?
Parfois, les rôles intégrés ne suffisent pas.
Tu veux donner des droits très spécifiques, genre :
Lancer une VM ✅
Mais pas la supprimer ❌
Lire un Key Vault ✅
Mais pas créer un secret ❌
C’est là qu’interviennent les rôles personnalisés (Custom Roles).
Ils sont 100% configurables : tu choisis les actions autorisées (actions), celles interdites (notActions), et l’étendue (assignableScopes).
🍳 Recette d’un Custom Role – Simple, digeste, efficace
{ "Name": "VM-Limited-Contributor", "Description": "Peut gérer les VMs mais pas les supprimer", "Actions": [ "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/deallocate/action", "Microsoft.Compute/virtualMachines/read", "Microsoft.Compute/virtualMachines/write" ], "NotActions": [ "Microsoft.Compute/virtualMachines/delete" ], "AssignableScopes": [ "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-dev" ] } 🧠 Résultat ?
Un rôle sur-mesure, propre, sans risque de dérapage.
Et surtout : tu respectes le principe du moindre privilège à la virgule près.
🎯 En résumé :
Utilise les Built-in Roles autant que possible (ils sont fiables, à jour, et bien documentés).
Crée un Custom Role uniquement si aucun rôle existant ne couvre ton besoin sans effet secondaire.
Teste ton Custom Role dans un environnement de dev avant de l'injecter en prod (oui, même toi Michel).
📦 Scope : RBAC aime bien les poupées russes 🪆
RBAC applique ses règles par couches :
🌐 Management Group
📁 Subscription
📦 Resource Group
🧱 Resource
🧠 Pro Tip : si tu donnes un rôle au niveau subscription, il est hérité par tous les groupes et ressources. Alors fais pas ça sans réfléchir hein.
RBAC suit un vrai scénario Netflix :
Quelqu’un veut faire une action (genre : “supprimer un disque 😅”)
Azure regarde tous les rôles que cette personne a
Il vérifie si l’action est dans la liste des actions autorisées
S’il y a un "deny" ou une condition non remplie ➡️ Bloqué !
📌 Pas de passe-droit. Même le boss doit suivre les règles 💼
🧪 Cas réels (ou presque)
🧙♂️ Cas 1 : Dev solo sur dev-rg
➡️ "Virtual Machine Contributor" sur dev-rg
🧑🍳 Cas 2 : Le chef de prod (mais pas des accès)
➡️ "Contributor" mais PAS "User Access Admin"
👩🔬 Cas 3 : L'analyste curieuse mais sage
➡️ "Reader" sur data-rg
🧬 Et si tu veux jouer avec les rôles :
az role assignment create \ --assignee [email protected] \ --role "Reader" \ --scope /subscriptions/xxxx/resourceGroups/data-rg
🧰 Tes outils RBAC, façon trousse du Doc 🩺
Outil | Pour quoi faire ? |
|---|---|
Azure Portal | Simple, visuel, rapide |
Azure CLI / PowerShell | Pour les scripts de l’élite |
Azure AD PIM | Accès temporaires = zéro risque |
Resource Graph Explorer | Pour traquer qui a quoi... Sherlock style 🕵️♀️ |
🔐 Best practices pour éviter le chaos 🧯
Toujours assigner au niveau le PLUS bas possible
Jamais d’Owner à la légère (ni de “test-owner” en prod 😬)
Utiliser les groupes AD plutôt que les users individuels
Activer les alertes RBAC via Azure Monitor
💬 Et rappelle-toi : une fois donné, un accès peut coûter cher (en budget ou en sécurité).
🚀 Pourquoi tu DOIS maîtriser Azure RBAC
RBAC, c’est pas une formalité :
✔️ Ça évite les erreurs humaines (du genre "j’ai supprimé toute la prod sans faire exprès")
✔️ Ça structure ton Cloud pour qu’il soit scalable
✔️ C’est la base du Zero Trust
✔️ Et ça permet à ton CISO de dormir tranquille 😴
🔄 Comment RBAC décide ?