Concepts Azure | Gestion des droits

RBAC, AAD, Management group, policies ! La sécurité est nichée à tous les étages de la plateforme Azure. Dans cet article je vais dresser une vue généraliste des concepts liés à la gestion des droits utilisateurs depuis le modèle « classique » jusqu’au modèle, plus moderne, basé sur les rôles RBAC et l’annuaire Azure Active Directory.

Vue d’ensemble des mécanismes de gestion des droits

La gestion des droits au sein de la plateforme Microsoft Azure est l’un des sujets qui m’a posé le plus de difficulté d’apprentissage. Cette difficulté était liée au fait que la gestion des droits est un domaine qui a fortement évolué depuis la première version de la plateforme et qu’il existe aujourd’hui une cohabitation entre trois mécanismes fondamentaux :

• La gestion des droits « classique »
• Le gestion des droits basée sur les mécanismes RBAC (Role Based Access Control)
• La gestion des droits au sein de l’AAD (Azure Active Directory)

Ces mécanismes n’ont pas tous le même périmètre d’application comme indiqué dans le schéma ci-dessous

La gestion des droits via RBAC peut être vue comme une extension de la gestion des droits « classique ». La gestion des droits au sein de l’AAD est spécifique à la gestion des annuaires (tenants) azure.

Dans la suite de cet articles, nous allons préciser chacun de ces mécanismes et souligner les éléments à retenir pour une correcte prise en main de la gestion des autorisations sur Azure.

Le modèle « classique »

Ce modèle s’applique au niveau des abonnements Azure. Il s’agit du modèle historique implémentée dans la première version de la plateforme. Même si Microsoft met en avant le modèle RBAC, le modèle « classique » est toujours présent et doit être compris pour assurer une bonne gestion des autorisations.

Avec l’approche « classique », il existe 3 trois rôles d’administration pour la gestion des abonnements (et des ressources appartenant aux abonnements) :

• Le rôle « Account Administrator »
• Le rôle « Service Administrator »
• Le rôle « Co-administrator

Le tableau ci-dessous résume le droits, limitations et le périmètre fonctionnel de ces rôles.

Le terme « Azure account » est particulièrement ambigu : Il recouvre la notion de relation commerciale entre l’entreprise cliente, qui souscrit à un abonnement Azure, et Microsoft. La définition donnée par Microsoft est la suivante :

Azure account (Microsoft doc)

« An Azure account represents a billing relationship. An Azure account is a user identity, one or more Azure subscription, and an associated set of Azure ressources »

La gestion de cette « relation » commerciale ne se fait pas directement dans le portail Azure mais au sein de l’un des portail suivants :

• https://ea.azure.com/ pour les entreprises disposant d’un contrat Azure Entreprise,
• https://account.azure.com/ sinon.

Par défaut, l’utilisateur ayant le rôle « Account administrator » possède également le rôle de « Service Administrator » jusqu’à ce qu’il modifie ce point en délégant ce rôle à un autre utilisateur.

Identification des rôles

Ce chapitre détaille la méthode pour identifier les utilisateurs ayant les rôles d’account administrator, service administrator et co-administrator.

Identification du « Account administrator »

Pour identifier l’utilisateur ayant le rôle d’account administrator, vous pouvez suivre le procédure suivante

• Se connecter au portail Microsoft Azure
• Ouvrir le panneau des abonnements
• Sélectionner un abonnement
• Ouvrir le menu settings / properties
• Le champs « Account administrator » permet d’identifier l’utilisateur ayant ce rôle sur l’abonnement

Identification du « Service Administrator » et « co-administrator »

Toujours depuis le panneau de gestion d’un abonnement

• Ouvrir le menu Access Control (IAM)
• Sélectionner l’onglet « Classic Administrators »
• La liste des utilisateurs ainsi que leur rôle est affiché

Gestion des droits avec RBAC

RBAC, pour Role Based Access Control, est un mécanisme de sécurité permettant de configurer des accès fins (Fine grained) aux ressources Azure. Contrairement à la sécurité classique qui propose au final une approche de « tout ou rien », RBAC permet de segmenter les accès sur tout ou partie des ressources Azure. Il est par exemple possible d’autoriser la gestion des ressources réseau uniquement aux équipes en charge de ce sujet et de permettre la gestion des machines virtuelles à une autre équipe.

Par ailleurs, Azure propose le mécanisme des groupes d’administration (management groups) qui permet une organisation des abonnements au sein d’une hiérarchie structurée (voir chapitre plus bas). La combinaison des mécanismes RBAC et des groupes d’administration permettent ainsi de segmenter les accès selon des logiques en adhérence avec l’organisation d’une entreprise. Par exemple une gestion par Business Unit, par zone géographique ou encore par département. Les différents périmètres d’application de RBAC sont schématisés ci-dessous.

RBAC propose un peu plus de 70 rôles par défaut (built-in) et la possibilité de créer des rôles sur mesure. Quatre rôles sont particulièrement adaptés pour une gestion à minima des droits.

Contrairement à la sécurité classique qui ne permet d’attribuer les rôles d’administration uniquement à des individus, RBAC propose d’étendre la gestion des droits à une plus large gamme d’identités : Un groupe d’individus, un principal de service (Service principal) et une identité managée (Managed identity). Ces différentes identités sont regroupées sous l’appellation de principal de sécurité (Security principal).

Un security principal peut être associé à plusieurs définitions RBAC. Si jamais il y a un chevauchement des droits, c’est la définition accordant le plus de privilèges qui s’applique.

Les groupes d’application (Management Groups)

Les groupes d’administration permettent de gérer les abonnements Azure via une construction hiérarchique répondant à l’organisation d’une société.

Il est possible d’associer à un groupe d’administration des règles de gestion (role assignment RBAC et Azure Policies) qui seront alors automatiquement héritées par les groupes d’administration et abonnements associés enfants.

Par défaut, chaque annuaire (tenant Azure) possède un groupe d’administration racine et sans configuration spécifique les abonnements sont rattachés à ce groupe racine. Le groupe racine est nommé « Tenant Root Group ». La relation entre les abonnements et l’annuaire Azure Active Directory est une relation dite de confiance (Trust Relationship) qui permet à tous les abonnements rattachés de bénéficier des méthodes d’authentification fournies par l’AAD. Un abonnement ne peut être rattaché qu’à un et un seul annuaire AAD, mais un annuaire peut avoir plusieurs abonnements qui lui sont rattachés.

Limitations

• Maximum de 10 000 groupes d’administration au sein d’un annuaire (directory)
• Pas plus de 6 niveaux de profondeur dans l’arborescence (en excluant le niveau racine et le niveau « abonnement »
• Une seule arborescence au sein d’un annuaire
• Un noeud parent peut avoirs plusieurs fils. Un nœud fils ne possède qu’un seul parent.

Audit des accès

Plusieurs méthodes sont possibles pour réaliser un audit des accès au sein de votre environnement Azure. Cette que je recommande est de s’appuyer sur les fonctionnalités liées aux « Azure Policies » qui sont disponibles en standard (i.e sans coût supplémentaire) et qui proposent à la fois de l’audit et de la correction (remediation).

https://www.thomasmaurer.ch/2020/03/keep-control-of-your-azure-environment-with-azure-policy/

Il est également possible de s’appuyer sur les fonctionnalités de PIM (Privileged Identity Management) qui sont accessibles avec un abonnement Azure Active Directory P2.

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

Enfin, vous pouvez travailler sur des scripts s’appuyant sur les commandes Powershell et AZ CLI suivantes :

#Powershell AZ Module
get-azRoleAssignment

#AZ CLI
az role assignment list -o table

Gestion des droits Azure Active Directory (AAD)

Azure Active Directory (AAD) possède son propre périmètre de sécurité afin de permettre une gestion fine des objets présents dans Azure Active Directory. Le fonctionnement de la sécurité AAD étant similaire à celui de RBAC (gestion par rôle), il est possible de les confondre. Cependant ce n’est absolument pas le cas et il s’agit bien de deux concepts de sécurité distincts.

Les deux modèles de sécurité (RBAC et AAD) ne se chevauchent pas :

• RBAC permet de gérer les accès aux ressources Azure
• La sécurité AAD permet de la gérer la gestion des droits sur les objets de l’annuaire (comptes utilisateurs, groupe, service principals, applications…)

Le tableau ci-dessous présente les rôles principaux sur AAD.

Il existe une exception à cette séparation des périmètres de sécurité entre RBAC et AAD. En effet il est possible pour un utilisateur ayant le rôle AAD « Global Administrator » de s’octroyer un accès complet à toutes les ressources Azure inscrites au sein de l’annuaire (tenant). Pour ce faire, il faut que l’utilisateur réalise une élévation de privilèges de type « Access Management ».

Cette élévation de privilèges est mise à disposition par Microsoft afin de traiter les situations suivantes :

• Impossibilité de gérer un abonnement avec le compte ayant le rôle classique « Account Administrator » (perte des identifiants)
• Il est nécessaire d’opérer un changement sur le groupe d’administration racine

L’élévation de privilège se fait avec la procédure suivante :

• Se connecter au portail Azure avec un compte possédant le rôle AAD « Global Administrator »
• Ouvrir le panneau Azure Active Directory
• Ouvrir le menu « properties »
• En bas de la page, cliquer sur « YES »
• Se reconnecter au portail Azure afin que l’élévation de privilège soit prise en compte

Lectures conseillées

https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles

https://docs.microsoft.com/fr-fr/azure/role-based-access-control/overview

https://docs.microsoft.com/fr-fr/azure/role-based-access-control/role-assignments-portal