Objectif
Réduire le risque qu’un compte ou poste administrateur compromis permette la prise de contrôle du SI, en séparant les usages privilégiés, en appliquant le moindre privilège et une authentification forte, en protégeant les voies d’administration et en maintenant des comptes d’urgence réellement testés.
Prérequis
- Inventaire des rôles et comptes privilégiés : AD, Entra, M365, firewall, hyperviseur
- Liste des administrateurs réels et des comptes partagés ou orphelins.
- Méthodes MFA compatibles et, pour les rôles critiques, méthodes résistantes au phishing lorsque disponibles.
- Deux comptes d’urgence ou mécanisme équivalent avec stockage sécurisé des credentials.
- Poste ou méthode d’administration sécurisée et journaux d’authentification/élévation exploitables.
Procédure pas à pas
Inventorier tous les privilèges et supprimer les inconnus
Exportez les rôles d’administration et identifiez chaque propriétaire. Classez les comptes en nominatifs, partagés, techniques, fournisseurs et urgence. Tout compte dont le propriétaire ou le besoin n’est pas clair doit être investigué avant suppression. Pour Active Directory, commencez par les groupes les plus sensibles ; pour Entra, exportez les affectations de rôles et les rôles éligibles PIM si votre licence le permet.
Get-ADGroupMember "Domain Admins" -Recursive | Select-Object Name,SamAccountName,ObjectClassGet-LocalGroupMember -Group "Administrators"- Chaque privilège a un propriétaire et un motif, et les comptes inconnus sont isolés pour décision.
Séparer le compte quotidien du compte d’administration
Créez pour chaque administrateur une identité privilégiée distincte de son compte de messagerie/productivité. Le compte admin ne doit pas recevoir de courrier, naviguer sur le web ou se connecter à des applications non nécessaires. Utilisez un nommage explicite mais pas une convention facilement devinable si elle augmente l’exposition. Interdisez l’usage partagé sauf exception technique documentée.
- Les tâches quotidiennes et privilégiées utilisent des identités différentes.
Appliquer le moindre privilège et la durée minimale
Remplacez les rôles globaux par des rôles plus spécifiques lorsque possible. Dans les environnements compatibles PIM/JIT, rendez les privilèges éligibles plutôt que permanents pour les comptes nominaux. Pour AD, réduisez l’appartenance permanente aux groupes les plus sensibles. Un administrateur sauvegarde n’a pas besoin d’être administrateur domaine et un administrateur DNS n’a pas nécessairement besoin du rôle global cloud.
- Les comptes possèdent uniquement les droits nécessaires à leurs responsabilités.
Imposer une authentification forte aux administrateurs
Activez le MFA pour toutes les interfaces d’administration humaines. Pour les rôles les plus sensibles, utilisez une méthode résistante au phishing telle qu’une passkey/FIDO2 ou une authentification par certificat lorsque la plateforme le permet. Testez en report-only ou sur un groupe pilote avant généralisation. Supprimez progressivement les méthodes faibles et exceptions non justifiées.
- Chaque administrateur utilise une authentification forte adaptée à la criticité du rôle.
Créer et isoler les comptes d’urgence
Maintenez au moins deux comptes d’accès d’urgence pour les systèmes cloud critiques lorsque le modèle le permet. Microsoft recommande des comptes cloud-only distincts, avec authentification forte et exclusion des politiques qui pourraient bloquer précisément l’accès de secours. Stockez les credentials ou clés dans des emplacements séparés et accessibles aux personnes autorisées. Alertez sur toute connexion.
- Deux voies d’urgence indépendantes sont disponibles et ne dépendent pas du même point de panne que les comptes normaux.
Restreindre les postes et réseaux d’administration
Utilisez un poste d’administration sécurisé, PAW ou au minimum une machine dédiée et gérée pour les accès les plus sensibles. Évitez d’administrer hyperviseurs, sauvegardes et annuaires depuis un poste utilisateur exposé au mail et au web. Restreignez les interfaces d’administration à des VLAN, VPN, bastions ou adresses sources autorisées lorsque la plateforme le permet.
- Les accès privilégiés proviennent de postes et réseaux explicitement approuvés.
Protéger les secrets et comptes techniques
Inventoriez les comptes de service et secrets utilisés par scripts, tâches planifiées, scanners et applications. Remplacez lorsque possible les mots de passe statiques par des identités gérées ou gMSA et limitez les droits. Stockez les secrets dans un coffre avec audit, rotation et accès limité. N’utilisez jamais un compte nominatif d’administrateur comme credential de service.
- Les secrets techniques ne dépendent pas des comptes personnels des administrateurs.
Centraliser les journaux et alertes
Surveillez connexions réussies et échouées, changement de rôle, ajout de méthode MFA, utilisation d’un compte d’urgence, création d’un nouvel administrateur et élévation inhabituelle. Envoyez les événements vers un SIEM ou une plateforme de supervision lorsque disponible. Une alerte doit avoir un propriétaire et un processus de traitement, sinon elle devient du bruit.
Get-WinEvent -FilterHashtable @{LogName="Security";Id=4672;StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated,Id,Message- Toute utilisation anormale d’un compte privilégié peut être détectée et investiguée.
Tester le rollback et les comptes d’urgence
Avant de retirer un ancien mécanisme, simulez la perte de la méthode principale et vérifiez que l’accès d’urgence fonctionne. Les comptes break-glass doivent être testés régulièrement, leurs credentials accessibles et leurs alertes déclenchées. Après un test, consignez l’opération et mettez à jour la documentation si une dépendance inattendue a été découverte.
- Le SI peut être administré même si la méthode principale d’authentification ou de fédération est indisponible.
Organiser une revue périodique des privilèges
Planifiez une revue trimestrielle ou adaptée à votre risque, ainsi qu’une revue immédiate après départ ou changement de fonction. Comparez la liste actuelle à la précédente, retirez les droits devenus inutiles et validez les comptes fournisseurs. Mesurez le nombre de comptes à privilèges permanents, le taux MFA et l’usage des comptes d’urgence pour suivre la réduction du risque.
- La gouvernance empêche le retour progressif des privilèges excessifs.
Validation
La procédure est validée lorsque :
- Les administrateurs possèdent un compte de productivité distinct de leur compte privilégié.
- Le MFA est activé et les rôles critiques utilisent une méthode forte adaptée.
- Les privilèges permanents ont été réduits et les comptes partagés ou orphelins sont traités.
- Les comptes d’urgence sont testés, surveillés et leurs credentials sont stockés séparément.
- Les actions privilégiées et modifications de rôles sont journalisées et supervisées.
Retour arrière
- Conserver un accès de secours jusqu’à validation de chaque nouvelle politique ou restriction.
- Si une policy bloque des administrateurs légitimes, la désactiver via le compte d’urgence puis corriger le périmètre avant réactivation.
- Restaurer temporairement un rôle précis plutôt qu’un privilège global, avec durée et justification limitées.
Dépannage / erreurs fréquentes
- Administrateur bloqué après MFA/Conditional Access : utiliser le compte d’urgence prévu et analyser les sign-in logs avant de modifier plusieurs policies.
- Compte technique cassé après réduction de droits : identifier l’opération réellement refusée et accorder le droit minimal au compte technique, pas au compte humain.
- Trop de comptes Domain Admin/Global Admin : traiter par propriétaire et usage ; ne supprimez pas en masse sans cartographie des dépendances.
- Compte d’urgence inutilisable : traiter comme incident de continuité et corriger immédiatement la dépendance à la fédération, au device ou à une policy.