RBAC, Policy et Resource Locks : comment s'articule la gouvernance Azure

En étudiant pour l'AZ-900, ces trois-là n'arrêtaient pas de se mélanger pour moi. Ils parlent tous de restreindre des choses, on les décrit tous comme de la gouvernance, et les lire séparément les faisait ressembler à trois versions de la même feature.

Ce n'est pas le cas. Chacun répond à une question différente, et une fois que j'ai eu les questions au clair, la distinction a arrêté d'être confuse.

RBAC répond à « qui peut faire ça ? »

Le Role-Based Access Control concerne l'identité. Une personne ou un service reçoit une role, cette role a des permissions, et elle s'applique à un scope particulier.

La partie scope, c'est ce que j'ai raté au début. Une attribution de role n'est pas globale, elle est attachée à un niveau : un management group, une subscription, un resource group, ou une resource unique. Attribuez à quelqu'un le rôle Contributor sur un resource group et il pourra faire des choses de contributor sur tout ce qu'il y a dedans, mais rien en dehors.

Trois roles intégrées couvrent la plupart de ce à quoi on s'attendrait :

Owner peut tout faire, y compris accorder l'accès à d'autres personnes
Contributor peut créer et gérer des resources, mais ne peut pas accorder l'accès
Reader peut regarder et ne pas toucher

La distinction entre Contributor et Owner est celle qui est intéressante. Pouvoir gérer chaque resource d'une subscription et pouvoir transmettre cette capacité à quelqu'un d'autre sont des pouvoirs vraiment différents, et les séparer est ce qui rend le least privilege réellement viable.

Azure Policy répond à « est-ce que ça a le droit d'exister ? »

Policy ne concerne pas du tout les personnes, et c'est ce qui a fini par le séparer de RBAC dans ma tête. Il évalue les resources par rapport à des règles, peu importe qui les crée.

Un Owner a pleine permission de créer des resources. Une policy qui dit « les virtual machines ne peuvent être créées que dans ces régions » les arrêtera quand même, parce que la policy ne vérifie pas les permissions, elle vérifie la resource elle-même.

Exemples typiques : restreindre quelles régions peuvent être utilisées, exiger des tags précis sur les resources, bloquer les tailles de VM coûteuses, imposer que les storage accounts exigent le chiffrement.

Policy peut aussi juste signaler plutôt que bloquer. Une policy en mode audit signale les resources non conformes sans les empêcher, ce qui est la façon de découvrir à quel point un environnement existant est mauvais avant de commencer à tout imposer et à tout casser.

Les resource locks répondent à « est-ce que ça devrait être supprimable ? »

Les locks sont les plus simples des trois et celui que j'aurais écarté comme sans importance. Ils existent pour les accidents, pas pour les attaquants.

Deux types :

CanNotDelete autorise les changements mais bloque la suppression
ReadOnly bloque à la fois les changements et la suppression

Le point clé, c'est qu'un lock s'applique à tout le monde, y compris un Owner. Quelqu'un avec des permissions complètes qui lance la mauvaise commande de suppression est quand même arrêté. Ce qui est exactement le but, puisque la personne la plus susceptible de supprimer par erreur un database de production est justement celle qui a la permission de le supprimer.

Pour vraiment supprimer une resource verrouillée, il faut d'abord retirer le lock, délibérément, comme une action séparée. Cette étape en plus, c'est toute la feature.

Pourquoi les trois, et pas juste un

Ensemble, ils couvrent des échecs que les autres ne peuvent pas couvrir.

RBAC empêche quelqu'un de faire quelque chose qu'il ne devrait pas pouvoir faire du tout. Ça ne peut pas empêcher une personne autorisée de faire quelque chose d'autorisé mais de mauvais.

Policy empêche des resources qui ne devraient pas exister sous la forme où elles sont, peu importe qui les crée. Ça ne peut pas empêcher quelqu'un de supprimer quelque chose qui existe déjà et qui est conforme.

Les locks empêchent la destruction accidentelle par des personnes qui ont réellement la permission. Ils ne restreignent pas qui a la permission en premier lieu.

C'est pour ça que ce sont trois features plutôt qu'une seule. Ce ne sont pas des couches de la même restriction, ce sont des réponses à trois façons différentes dont les choses tournent mal.

Où ça rejoint l'écriture de code

L'idée du least privilege est la même que j'applique déjà dans une application, ce qui a rendu RBAC familier plutôt que nouveau. Un compte database auquel mon API se connecte ne devrait pas avoir la permission de drop des tables, pour la même raison qu'un développeur ne devrait pas avoir Owner sur une subscription de production : pas parce que je m'attends à ce qu'il en abuse, mais parce que le simple fait que la permission existe est ce qui rend l'accident possible.

Azure ne fait que le rendre explicite, avec des roles et des scopes que vous pouvez vraiment inspecter, au lieu que ça vive dans une connection string que personne ne relit.