Microsoft Entra ID et Azure : Gestion des accès, de RBAC et d'Azure Policy

Dans l'écosystème cloud de Microsoft, la frontière entre votre réseau d'entreprise et l'extérieur n'est plus définie par un pare-feu physique, mais par l'Identité. Microsoft Entra ID (anciennement Azure Active Directory) est le cerveau de cette nouvelle architecture de sécurité basée sur le modèle Zero Trust.

Cependant, la gouvernance cloud est souvent source de confusion, notamment lorsqu'il s'agit de différencier les rôles d'annuaire (Entra ID), les rôles sur les ressources (Azure RBAC) et les règles de conformité (Azure Policy). Voici une plongée technique pour structurer vos accès dans les règles de l'art.

1. Gestion des Utilisateurs et Groupes : Le socle Entra ID

Contrairement à l'Active Directory On-Premise (fichiers NTDS.dit, LDAP, Kerberos), Entra ID est un annuaire HTTP/REST basé sur les standards modernes (SAML, OAuth 2.0, OpenID Connect).

Les types d'identités

• Utilisateurs Cloud (Cloud-only) : Créés et gérés directement dans Entra ID.

• Utilisateurs Synchronisés : Provenant de votre AD On-Premise via Entra Connect. Leur source d'autorité reste l'AD local (on ne peut pas modifier leur mot de passe directement dans le cloud, sauf configuration SSPR spécifique).

• Utilisateurs Invités (B2B) : Partenaires externes accédant à vos ressources.

La puissance des Groupes Dynamiques

Ne gérez plus vos groupes manuellement. Entra ID permet de créer des groupes dynamiques basés sur des requêtes. Si le département d'un utilisateur passe de "Marketing" à "IT" dans ses attributs, il est automatiquement retiré des partages marketing et ajouté aux abonnements Azure de l'IT. C'est la clé d'une gestion Role-Based à grande échelle.

2. Le piège classique : Entra ID Roles vs Azure RBAC

C'est l'erreur numéro un des administrateurs débutants : confondre les rôles de l'annuaire et les rôles de l'infrastructure.

1. Rôles Microsoft Entra (L'annuaire) : Ils contrôlent les permissions sur les services Microsoft 365 et sur l'annuaire lui-même.

   • Exemples : Global Administrator, User Administrator, Exchange Administrator.

   • Périmètre : Le tenant Entra ID.

2. Azure RBAC (L'infrastructure) : Le Role-Based Access Control contrôle ce qu'un utilisateur peut faire sur les ressources hébergées dans Microsoft Azure (Machines virtuelles, bases de données, réseaux).

   • Exemples : Owner (Propriétaire), Contributor (Contributeur), Reader (Lecteur).

   • Périmètre : Un Management Group, une Souscription, un Groupe de Ressources ou une ressource spécifique.

Note de sécurité : Un "Global Admin" Entra ID n'a par défaut aucun droit sur les souscriptions Azure. Il doit s'octroyer temporairement le droit d'élever ses accès (Access management for Azure resources) pour agir sur l'infrastructure.

3. Deep Dive : Azure RBAC vs Azure Policy

Si RBAC contrôle les identités, Azure Policy contrôle les ressources. Comprendre comment ils s'imbriquent est vital.

Azure RBAC : "Qui peut faire quoi ?"

RBAC est un modèle d'autorisation basé sur l'action (Allow).

• Exemple : Vous assignez le rôle "Contributeur de Machine Virtuelle" à Alice sur le groupe de ressources "RG-PROD".

• Résultat : Alice a le droit de créer, démarrer ou supprimer n'importe quelle VM dans ce groupe.

Azure Policy : "Quelles sont les règles du jeu ?"

Azure Policy est un modèle de gouvernance basé sur les propriétés de la ressource. Il s'applique indépendamment des droits de l'utilisateur (même à un Propriétaire/Owner). Il définit les garde-fous de votre entreprise.

• Exemple : Vous déployez une politique "Autoriser uniquement la région France Central" sur votre souscription.

• Résultat : Si Alice (qui a pourtant les droits RBAC de Contributeur) tente de créer une VM dans la région "US East", l'API Azure Manager (ARM) bloquera la requête avec une erreur PolicyDeny.

La Matrice de décision (ARM) : Lorsqu'une requête arrive à l'Azure Resource Manager (ex: PUT /subscriptions/.../virtualMachines) :

1. L'API vérifie d'abord RBAC : "L'utilisateur a-t-il le jeton l'autorisant à exécuter cette action ?" -> Oui.

2. L'API vérifie ensuite Policy : "Les propriétés du payload JSON (ex: location, SKU) respectent-elles les règles ?" -> Non.

3. L'action est rejetée.

4. Boîte à outils du SysAdmin : Automatisation PowerShell

Pour gérer ces éléments à l'échelle, les scripts sont indispensables.

Script 1 : Créer un utilisateur et l'ajouter à un groupe (Microsoft Graph)

Depuis l'abandon du module AzureAD, la gestion de l'annuaire passe par le SDK Microsoft Graph.

# Prérequis : Install-Module Microsoft.Graph
Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All"

$PasswordProfile = @{
    Password = "PasswordCompl3xe2026!"
    ForceChangePasswordNextSignIn = $true
}

Write-Host "Création de l'utilisateur dans Entra ID..." -ForegroundColor Cyan
$NewUser = New-MgUser -DisplayName "Jean Dupont" `
                      -UserPrincipalName "j.dupont@votre-domaine.com" `
                      -MailNickname "jdupont" `
                      -AccountEnabled $true `
                      -PasswordProfile $PasswordProfile

# Ajout à un groupe spécifique (ex: Groupe "Equipe IT")
$GroupId = "id-du-groupe-entra-id"
New-MgGroupMember -GroupId $GroupId -DirectoryObjectId $NewUser.Id

Write-Host "Utilisateur créé et ajouté au groupe avec succès." -ForegroundColor Green

Script 2 : Assigner un rôle Azure RBAC (Module Az)

Une fois l'utilisateur créé dans Entra ID, nous lui donnons des droits limités sur une ressource Azure.

# Prérequis : Install-Module Az
Connect-AzAccount

$UPN = "j.dupont@votre-domaine.com"
$ResourceGroup = "RG-App-Production"
$Role = "Virtual Machine Contributor"

Write-Host "Attribution du rôle RBAC Azure..." -ForegroundColor Cyan
New-AzRoleAssignment -SignInName $UPN -RoleDefinitionName $Role -ResourceGroupName $ResourceGroup

Write-Host "Droits accordés sur le groupe de ressources : $ResourceGroup" -ForegroundColor Green

5. Références officielles Microsoft

Pour valider votre architecture Zero Trust et préparer vos certifications (comme l'AZ-104 ou SC-300), consultez ces ressources :

• Documentation Microsoft Entra ID - Concept des identités

• Comprendre les rôles Azure (RBAC)

• Vue d'ensemble d'Azure Policy

Conclusion

Une bonne gouvernance cloud nécessite de maîtriser ces trois piliers : l'identité (Entra ID), les droits d'action (RBAC) et la conformité des ressources (Policy). En attribuant les rôles à des groupes dynamiques plutôt qu'à des individus, et en verrouillant vos standards d'architecture via Azure Policy, vous garantissez un environnement cloud sécurisé, auditable et résilient.