Identités et accès : Entra ID, RBAC, MFA et identités managées

Dans Azure, tout accès passe par une identité de Microsoft Entra ID (l'annuaire cloud de Microsoft, appelé Azure Active Directory jusqu'en 2023) et par un rôle attribué sur une étendue : c'est le contrôle d'accès en fonction du rôle, ou RBAC (Role-Based Access Control). Les applications, elles, reçoivent des identités managées, qui leur évitent de stocker des mots de passe. Ce chapitre explique l'annuaire, les deux familles de rôles, la MFA et les comptes d'administration, les identités managées, et la façon de relier l'Active Directory de Sorbier à Entra ID.

Microsoft Entra ID, l'annuaire du cloud

Le locataire Entra ID de Sorbier (sorbier.onmicrosoft.com, avec le domaine vérifié sorbier.example) contient :

• des utilisateurs : créés directement dans le cloud, ou synchronisés depuis l'Active Directory local (plus bas) ;
• des groupes, auxquels on attribue les droits plutôt qu'aux personnes ;
• des invités (B2B) : le compte d'un prestataire, qui garde son propre annuaire ;
• des applications et leurs principaux de service, les identités des programmes, dont les identités managées.

Entra ID parle les protocoles du web, OAuth 2.0 et OpenID Connect (cours Authentification), et n'a ni OU ni GPO : ce n'est pas un Active Directory dans le cloud. La comparaison détaillée des deux annuaires est dans le cours Windows Server. Les fonctions avancées demandent une licence : Entra ID P1 pour l'accès conditionnel, P2 pour la protection des identités et l'élévation de privilèges juste-à-temps (PIM).

Deux familles de rôles à ne pas confondre

Un administrateur d'utilisateurs Entra ne peut pas créer de VM ; un propriétaire d'abonnement ne peut pas réinitialiser le mot de passe d'un salarié. Deux métiers, deux familles de rôles.

Le RBAC d'Azure : qui, quoi, où

Une attribution de rôle associe trois éléments :

1. Qui : un principal de sécurité (utilisateur, groupe, principal de service, identité managée) ;
2. Quoi : une définition de rôle, c'est-à-dire une liste d'actions permises ;
3. Où : une étendue : groupe d'administration, abonnement, groupe de ressources ou ressource.

Les attributions s'héritent vers le bas (la hiérarchie du chapitre 6) et s'additionnent : un utilisateur Lecteur sur l'abonnement et Contributeur sur un groupe de ressources peut tout lire partout et tout modifier dans ce groupe.

On applique le moindre privilège (cours Authentification) : des rôles attribués à des groupes, à l'étendue la plus petite possible, et le moins possible de propriétaires.

# Un groupe pour les développeurs du suivi des livraisons
az ad group create --display-name "Azure-Dev-Livraisons" --mail-nickname azure-dev-livraisons
GROUPE=$(az ad group show --group "Azure-Dev-Livraisons" --query id --output tsv)

# Contributeur sur l'environnement de test, lecteur sur la production
az role assignment create --assignee-object-id "$GROUPE" --assignee-principal-type Group \
  --role "Contributor" \
  --scope "$(az group show --name rg-livraisons-test-frc --query id --output tsv)"

az role assignment create --assignee-object-id "$GROUPE" --assignee-principal-type Group \
  --role "Reader" \
  --scope "$(az group show --name rg-livraisons-prod-frc --query id --output tsv)"

# Vérifier les droits du groupe
az role assignment list --assignee "$GROUPE" --all --output table

MFA, accès conditionnel et comptes d'administration

• La MFA est obligatoire pour administrer Azure (portail depuis octobre 2024, CLI, PowerShell et API depuis le 1er octobre 2025, chapitre 6). Pour les autres usages, les paramètres de sécurité par défaut, gratuits, imposent la MFA à tous les utilisateurs du locataire ; l'accès conditionnel (licence P1) permet des règles plus fines : « MFA résistante à l'hameçonnage pour les administrateurs », « bloquer les connexions depuis tel pays ».
• Préfère une MFA résistante à l'hameçonnage pour les comptes d'administration : clés de sécurité FIDO2 ou clés d'accès (passkeys), plutôt qu'un code reçu par SMS (cours Authentification).
• Des comptes d'administration à part, créés dans le cloud, jamais synchronisés depuis l'annuaire local, et des droits élevés activés seulement au moment du besoin avec PIM (Privileged Identity Management, licence P2).
• Deux comptes d'accès d'urgence (break glass), cloud uniquement, avec une MFA par clé FIDO2 : depuis la MFA obligatoire, ils doivent eux aussi passer une MFA.
• Les journaux de connexion et d'activité d'Entra ID et d'Azure (Activity Log) sont envoyés vers le SIEM, chez Sorbier vers Wazuh (cours Wazuh).

Les identités managées : plus de secret dans le code

Une application qui lit des blobs a besoin d'une identité. La mauvaise solution : une clé d'accès du compte de stockage dans un fichier de configuration, qui finira un jour dans un dépôt Git. La bonne : une identité managée, une identité Entra ID attachée à la ressource Azure elle-même. Azure crée et fait tourner ses secrets en interne : ni toi ni le code ne les voyez jamais.

Pour que l'API du chapitre 10 lise les bons de livraison du chapitre 8 :

# 1. Donner une identité à l'application et récupérer son identifiant
az webapp identity assign --name app-parc-jc42 --resource-group rg-cloud-lab
PRINCIPAL=$(az webapp identity show --name app-parc-jc42 --resource-group rg-cloud-lab --query principalId --output tsv)

# 2. Lui attribuer la lecture des blobs, sur ce seul compte de stockage
az role assignment create --assignee-object-id "$PRINCIPAL" --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope "$(az storage account show --name stsorbierlabjc42 --resource-group rg-cloud-lab --query id --output tsv)"

Dans le code, la bibliothèque @azure/identity trouve seule l'identité : l'identité managée quand le code tourne dans Azure, ton compte az login quand il tourne sur ton poste.

import { DefaultAzureCredential } from '@azure/identity';
import { BlobServiceClient } from '@azure/storage-blob';

const compte = process.env.STORAGE_ACCOUNT; // par exemple stsorbierlabjc42
const client = new BlobServiceClient(
  `https://${compte}.blob.core.windows.net`,
  new DefaultAzureCredential(), // identité managée dans Azure, ton compte az login sur ton poste
);

const conteneur = client.getContainerClient('bons-livraison');
for await (const blob of conteneur.listBlobsFlat({ prefix: '2026/11/' })) {
  console.log(blob.name, blob.properties.accessTier);
}

Aucune clé, aucun mot de passe : si le code fuit, il ne donne accès à rien. Les identités managées s'utilisent de la même façon pour lire un secret dans Azure Key Vault, ou pour se connecter à Azure Database for MySQL avec l'authentification Entra ID au lieu d'un mot de passe MySQL. Pour un programme qui tourne hors d'Azure, comme un pipeline GitHub Actions, on utilise un principal de service avec une fédération d'identité (OIDC), là encore sans secret permanent (cours Intégration continue).

L'identité hybride : relier l'Active Directory de Sorbier

L'Active Directory de Sorbier (ad.sorbier.example, contrôleurs srv-ad et srv-ad2) reste la source d'autorité : un compte créé, modifié ou désactivé là-bas doit l'être aussi dans Entra ID. Microsoft propose deux outils de synchronisation :

Pour Sorbier, PME à une seule forêt, Cloud Sync convient : un agent sur srv-ad et un sur srv-ad2 assurent la redondance. Sur pfSense, une seule règle est nécessaire : autoriser ces deux serveurs à sortir en HTTPS vers Internet (cours pfSense). On choisit les OU synchronisées (pas les comptes d'administration ni les comptes de service), on passe les UPN sur le domaine vérifié sorbier.example, et l'on active la synchronisation du hachage du mot de passe (PHS), la méthode recommandée : Entra ID vérifie lui-même les mots de passe, même si les contrôleurs de domaine sont injoignables. Les détails (suffixes UPN, méthodes d'authentification, jonction des postes) sont dans le cours Windows Server.

Exercices