๐ 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 ?