Qu'est-ce que la gestion des accès privilégiés Azure ?
L'accès privilégié Azure est l'ensemble des identités, rôles, politiques et workflows qui contrôlent le pouvoir d'administration dans Microsoft Entra ID, Microsoft 365, Azure et les services connectés. Dans Microsoft Entra ID, des rôles comme Administrateur Global, Administrateur de Rôle Privilégié, Administrateur de l'Accès Conditionnel, Administrateur de la Sécurité et Administrateur d'Application peuvent modifier les paramètres de sécurité, attribuer des privilèges, gérer des applications ou créer des chemins d'accès durables.
Cela fait de l'accès privilégié un enjeu de plan de contrôle du tenant. Une identité privilégiée compromise peut modifier les politiques d'Accès Conditionnel, ajouter ou modifier des attributions de rôles, enregistrer des applications, altérer les méthodes d'authentification et affaiblir les contrôles sur lesquels s'appuient les défenseurs pendant une réponse à incident.
Privileged Identity Management (PIM) réduit l'exposition permanente en permettant aux administrateurs d'utiliser des attributions éligibles et une activation limitée dans le temps plutôt que de conserver des rôles puissants actifs en permanence. PIM n'est pas seulement une fonctionnalité d'interface. C'est un modèle de contrôle : activer uniquement en cas de besoin, exiger une authentification renforcée ou une approbation lorsque c'est pertinent, enregistrer la raison, et revoir le rôle après usage.
Comment l'accès privilégié Azure échoue
Les mêmes défaillances d'accès privilégié reviennent régulièrement dans les tenants réels :
- trop d'Administrateurs Globaux
- des attributions de rôles permanentes là où des attributions éligibles suffiraient
- des comptes admin sans couverture d'authentification forte
- des comptes d'urgence qui existent mais ne sont ni surveillés ni testés
- des principaux de service et applications privilégiés exclus des revues d'administration humaine
- PIM déployé pour certains rôles mais pas pour ceux qui intéressent les attaquants
- des exclusions d'Accès Conditionnel qui retirent des comptes admin du chemin de contrôle prévu
Le risque ne tient pas uniquement au nombre d'administrateurs. Un tenant avec peu d'Administrateurs Globaux peut rester exposé si ces identités sont permanentes, phishables, réutilisées pour le travail quotidien, ou exclues des politiques. Un tenant avec de nombreux administrateurs scoped peut être plus sûr si chaque rôle est justifié, éligible, surveillé et protégé par une authentification forte.
Pourquoi Administrateur Global est différent
Microsoft documente Administrateur Global comme un rôle hautement privilégié capable de lire et modifier presque tous les paramètres d'administration dans Microsoft Entra ID, à quelques exceptions près, et pouvant aussi lire et modifier presque tous les paramètres d'administration de Microsoft 365. Administrateur Global peut également élever l'accès dans certains scénarios. Cela le distingue d'un rôle opérationnel restreint comme Administrateur des Utilisateurs ou Lecteur de Rapports.
Utilisez le rôle le moins privilégié capable d'accomplir la tâche. Si le travail concerne le consentement d'application, un changement d'Accès Conditionnel, l'administration Exchange ou une investigation de sécurité, attribuez le rôle qui correspond à la tâche plutôt que de recourir par défaut à Administrateur Global. Cela réduit le rayon d'impact quand un compte, une session ou un workflow d'approbation échoue.
La chaîne d'attaque
Étape 1 - Énumérer les accès privilégiés
Un attaquant disposant d'une visibilité en lecture sur l'annuaire commence souvent par énumérer les rôles d'annuaire, les membres de rôles, les groupes privilégiés, les applications et les principaux de service. Il recherche des comptes avec un pouvoir permanent, une authentification faible, ou des propriétaires inactifs.
Étape 2 - Cibler le chemin admin le plus faible
La cible la plus facile n'est pas forcément l'Administrateur Global évident. Cela peut être un Administrateur de Rôle Privilégié obsolète, un propriétaire d'application avec des permissions applicatives larges, un compte d'urgence faiblement surveillé, ou un compte admin exclu de l'Accès Conditionnel à cause d'une panne passée.
Étape 3 - Convertir l'accès en persistance
Une fois l'accès privilégié obtenu, l'attaquant peut tenter d'ajouter une autre attribution de rôle, changer les méthodes d'authentification, affaiblir une politique, créer un identifiant applicatif, ou ajouter un chemin de permission de principal de service. Le chemin de persistance dépend des rôles détenus par l'identité compromise.
Étape 4 - Se dissimuler dans l'administration légitime
Les changements privilégiés sont souvent rares mais légitimes. Les attaquants en profitent quand le tenant n'a aucune référence sur qui active PIM, qui approuve les demandes, quels comptes devraient être permanents, et quelles applications sont autorisées à détenir un privilège élevé.
Détection
Événements des journaux d'audit Entra ID
Surveillez les changements administratifs qui modifient le plan de contrôle du tenant :
| Domaine d'opération | Ce qu'il faut examiner |
|---|---|
| Attributions de rôles | Nouveaux membres ajoutés à des rôles privilégiés, en particulier Administrateur Global et Administrateur de Rôle Privilégié |
| Activité PIM | Activations, approbations, demandes refusées, et changements de paramètres de rôle |
| Méthodes d'authentification | Changements sur les méthodes d'authentification des utilisateurs privilégiés |
| Accès Conditionnel | Création, mise à jour, suppression de politique, ou changements d'exclusion |
| Applications | Nouveaux enregistrements d'application, nouveaux identifiants, nouveaux propriétaires, et consentement à privilège élevé |
| Comptes d'urgence | Toute connexion, changement d'identifiant, ou changement de rôle |
Signaux d'activité PIM
PIM devrait rendre le privilège plus observable. Examinez :
- une activation en dehors des horaires ou fenêtres de maintenance habituels
- une activation pour des rôles que l'utilisateur n'utilise pas normalement
- une activation sans justification utile là où une justification est requise
- une approbation par un approbateur inattendu
- une activation répétée par des comptes qui présentent aussi des signaux de risque de connexion
- des attributions permanentes créées après un déploiement PIM
Limites de la détection
Ne traitez pas un seul événement d'audit comme une preuve de compromission. Une attribution de rôle peut faire partie d'un projet légitime. L'alerte doit inclure du contexte : acteur, cible, rôle, type d'attribution, durée d'activation, chemin d'approbation, appareil, localisation, niveau de risque, et si l'utilisateur exerce normalement ce rôle.
Remédiation
L'objectif n'est pas de supprimer toute administration. L'objectif est de supprimer le privilège permanent inutile et de rendre l'accès privilégié explicite, limité dans le temps, fortement authentifié et révisable.
1. Réduire le nombre d'Administrateurs Globaux
Listez toutes les attributions d'Administrateur Global et classez chaque compte :
- administrateur humain normal
- compte d'accès d'urgence
- compte de service ou identité d'automatisation
- compte obsolète
- identité externe ou invitée
- propriétaire inconnu
Les administrateurs humains normaux ne devraient généralement pas avoir besoin d'un Administrateur Global actif permanent. Convertissez-les vers des rôles plus étroits ou des attributions éligibles via PIM lorsque la licence et les opérations le permettent. Gardez l'exception d'accès d'urgence séparée plutôt que de la traiter comme un modèle d'administration routinier.
2. Configurer les paramètres de rôle PIM
Pour les rôles à forte valeur, configurez les paramètres PIM délibérément :
- attribution éligible plutôt que permanente active pour les administrateurs normaux
- durée d'activation adaptée au rôle
- contexte d'authentification MFA ou Accès Conditionnel à l'activation lorsque requis
- approbation pour les rôles particulièrement sensibles
- justification métier et informations de ticket là où le processus a besoin d'auditabilité
- notifications à l'équipe propriétaire du rôle
- revues d'accès régulières pour les attributions permanentes et éligibles
Les paramètres de rôle PIM de Microsoft prennent en charge des contrôles comme l'approbation, la justification, les informations de ticket, et la durée d'attribution. L'information de ticket est un champ informatif, pas une validation automatique contre un système de ticketing, donc ne supposez pas qu'elle prouve à elle seule l'autorisation du changement.
3. Protéger correctement les comptes d'accès d'urgence
Les comptes d'accès d'urgence sont volontairement différents. Microsoft recommande deux comptes d'accès d'urgence cloud-only ou plus pour les scénarios de secours (break-glass), et la documentation Microsoft indique que ces attributions d'Administrateur Global devraient être actives permanentes plutôt qu'éligibles dans PIM. Cela évite qu'une dépendance à PIM ne verrouille le tenant pendant une panne.
Cette exception ne signifie pas des contrôles faibles. Les comptes d'urgence doivent être cloud-only, protégés par une authentification résistante au phishing quand c'est possible, stockés de façon sécurisée, surveillés à chaque connexion, et validés régulièrement. Ils ne doivent pas servir à l'administration courante.
4. Imposer une authentification forte pour les utilisateurs privilégiés
Exigez une authentification forte pour les utilisateurs et rôles privilégiés. Pour les rôles à plus forte valeur, privilégiez les méthodes résistantes au phishing lorsque la licence, le support des appareils et les opérations le permettent. Vérifiez aussi que les admins ne contournent pas la politique via des emplacements de confiance, des groupes exclus, des comptes de test obsolètes, ou des workflows historiques.
5. Inclure les applications et principaux de service
L'accès privilégié n'est pas uniquement humain. Passez en revue les principaux de service, les enregistrements d'application, les identifiants, les propriétaires et les permissions applicatives. Un tenant peut avoir une liste d'Administrateurs Globaux propre et posséder malgré tout un chemin applicatif capable de lire les données de l'annuaire, modifier des objets, ou maintenir une persistance.
Fréquence de revue et ownership
L'accès privilégié doit avoir un propriétaire et une fréquence de revue. PIM réduit l'accès permanent, mais ne prouve pas automatiquement que chaque attribution éligible est encore justifiée. Au moins une fois par cycle de revue, comparez chaque attribution de rôle privilégié avec le modèle opérationnel actuel : qui possède le rôle, quelle tâche le nécessite, si l'attribution doit rester éligible, si les paramètres d'activation sont encore assez stricts, et si l'utilisateur appartient toujours à la population admin.
Passez aussi en revue les changements après des migrations, des fusions, une réponse à incident, un usage des accès d'urgence, et les intégrations SaaS majeures. Ce sont les moments où les chemins admin temporaires deviennent souvent permanents.
Validation après le déploiement de PIM
Après le nettoyage, validez la sécurité effective plutôt que l'existence de la politique :
- confirmez que les administrateurs normaux sont éligibles, et non actifs en permanence, pour les rôles à forte valeur
- confirmez que les comptes d'urgence sont les seules exceptions d'Administrateur Global permanent intentionnelles
- effectuez une activation contrôlée et confirmez que le MFA, l'approbation, la durée et la journalisation se comportent comme attendu
- passez en revue les journaux d'audit pour les nouvelles attributions de rôle après le nettoyage
- vérifiez que l'Accès Conditionnel n'exclut pas les comptes privilégiés involontairement
- passez en revue les principaux de service et enregistrements d'application pour un privilège équivalent aux rôles admin
- confirmez que l'alerting se déclenche sur la connexion d'un compte d'urgence et l'attribution d'un rôle privilégié
Un bon test de validation demande : si ce mot de passe ou cette session admin est volé aujourd'hui, quel privilège l'attaquant obtient-il immédiatement, et quels contrôles supplémentaires doit-il satisfaire avant d'exercer davantage de privilège ?
Comment EtcSec détecte cela
EtcSec audite la configuration de l'accès privilégié Azure à chaque scan et se concentre sur les conditions qui transforment un compte compromis en contrôle total du tenant.
PA_TOO_MANY_GLOBAL_ADMINS identifie les tenants avec un nombre excessif d'Administrateurs Globaux.
PA_PERMANENT_ADMIN_ASSIGNMENTS signale les attributions privilégiées permanentes qui devraient être revues pour conversion en accès éligible.
PA_PIM_NOT_ENABLED identifie les tenants où le contrôle d'accès privilégié juste-à-temps est absent ou inefficace.
PA_GLOBAL_ADMIN_NOT_MFA identifie les comptes Administrateur Global sans couverture d'authentification forte.
Contrôles associés
Passez en revue l'accès privilégié en lien avec Sécurité des identités Azure : le MFA seul ne suffit pas, Azure Identity Protection : bloquer les identifiants divulgués, Failles d'Accès Conditionnel Azure : contournement du MFA, Comptes invités Azure : la surface d'attaque oubliée de votre tenant, et Applications Azure sur-privilégiées dans votre tenant. Le privilège admin permanent est rarement le seul problème d'un tenant.
Références principales
Explorez les pages identité liées à ce sujet