Un compte protégé commence par un poste fiable
Un administrateur peut utiliser une excellente méthode MFA et quand même exposer une session depuis un ordinateur compromis. Un poste d’administration sécurisé réduit les occasions de voler les identifiants, d’intercepter les actions ou de réutiliser les sessions. Conditional Access contrôle les conditions d’accès; Privileged Identity Management (PIM) limite la disponibilité des privilèges. Ces mécanismes doivent fonctionner ensemble.
Ce guide propose une architecture pour les administrateurs humains de Microsoft 365. Les identités applicatives, les scripts sans utilisateur et l’administration Active Directory locale nécessitent des contrôles complémentaires. Les noms de groupes et les durées ci-dessous sont des exemples à adapter.
1. Inventorier les chemins d’administration
Un compte de messagerie quotidien ne doit pas servir de raccourci pour les tâches privilégiées. Un second profil de navigateur facilite la séparation des sessions, mais ne crée pas une frontière de sécurité contre un système d’exploitation compromis.
- Recenser les rôles Entra actifs et admissibles, les groupes assignables à des rôles, les invités et les délégations partenaires.
- Lister les portails réellement utilisés : Entra, Exchange, Intune, Defender, SharePoint, Purview et Azure.
- Inclure Microsoft Graph PowerShell, Exchange Online PowerShell, les outils tiers et leurs ressources d’authentification.
- Identifier les comptes d’urgence, les approbateurs PIM et les personnes capables de modifier Conditional Access ou Intune.
- Séparer les comptes administratifs nominatifs des comptes quotidiens. Aucun compte partagé pour les opérations courantes.
2. Définir une architecture exploitable
Pour une petite équipe, commencer avec deux postes dédiés peut être plus simple que construire une infrastructure de rebond complexe. Si un bureau distant est utilisé, protéger aussi le terminal depuis lequel la session démarre. Une machine virtuelle d’administration hébergée sur le poste quotidien hérite de la confiance accordée à cet hôte.
Valider les droits de licence pour Conditional Access, Intune, Defender et PIM. Ne pas supposer que la présence de Microsoft 365 donne automatiquement accès à toutes ces fonctions; vérifier les abonnements et les utilisateurs concernés.
| Composant | Rôle | Point à valider |
|---|---|---|
| Poste dédié | Windows pris en charge, géré par Intune, protégé par MDE | Approvisionnement et récupération maîtrisés |
| Identité administrative | Compte nominatif réservé à l’administration | Méthodes fortes et privilèges minimaux |
| Conditional Access | Authentification, conformité et origine autorisée | Portails ET outils PowerShell couverts |
| PIM | Activation temporaire des rôles | Approbateurs disponibles et journalisation |
| Compte d’urgence | Récupération indépendante | Test hors du chemin normal |
3. Préparer le poste avant de bloquer les autres accès
Construire un profil Intune dédié et y inscrire les appareils d’administration. Définir séparément les paramètres de configuration et les critères de conformité : une configuration assignée ne prouve pas à elle seule que l’appareil est conforme.
Un poste conforme ordinaire n’est pas automatiquement un poste d’administration. Il faut également distinguer les appareils autorisés à ce rôle et protéger la gestion de cette liste.
- Activer Secure Boot, BitLocker et les protections de virtualisation compatibles avec le matériel; vérifier la récupération BitLocker.
- Déployer les correctifs, MDE, le pare-feu et les règles ASR validées en pilote.
- Retirer les droits administrateur local permanents; organiser la récupération avec Windows LAPS.
- Limiter les applications et extensions de navigateur aux outils approuvés; tester le contrôle d’application avant son application générale.
- Réserver le poste aux destinations et tâches administratives. Utiliser le poste quotidien pour les courriels et la navigation générale.
- Protéger aussi les personnes qui peuvent modifier les profils Intune, les applications déployées et les exclusions Defender.
4. Exiger une authentification résistante à l’hameçonnage
Enregistrer et tester les méthodes appropriées avant de créer la restriction : passkeys FIDO2, Windows Hello for Business ou authentification par certificat selon la force d’authentification choisie et le scénario. Prévoir une méthode de secours indépendante et une procédure d’enrôlement contrôlée.
Dans Entra ID > Conditional Access > Policies, créer CA-ADM-Authentication. Cibler un groupe pilote contenant les comptes administratifs, sélectionner les ressources nécessaires et Grant access > Require authentication strength > Phishing-resistant MFA. Commencer en Report-only.
Pour des comptes exclusivement administratifs, All resources offre une portée large à tester. Une restriction visant uniquement un portail peut laisser des chemins d’accès via API. Le ciblage Directory roles ne couvre pas tous les types de rôles : vérifier explicitement les rôles personnalisés et ceux limités à une unité administrative.
5. Combiner conformité et poste autorisé
Créer d’abord une stratégie de conformité Intune et vérifier qu’au moins un appareil pilote la satisfait. Dans CA-ADM-CompliantDevice, exiger Require device to be marked as compliant pour les mêmes comptes et ressources. Si plusieurs contrôles sont réunis dans une stratégie, choisir Require all the selected controls lorsque les exigences doivent se cumuler.
Ajouter une stratégie de blocage distincte, CA-ADM-ApprovedDevice, qui cible ces comptes et ressources et exclut uniquement les appareils identifiés comme postes autorisés. Microsoft illustre ce modèle avec un filtre sur extensionAttribute1. L’exclusion de cette stratégie de blocage ne dispense pas des autres stratégies d’authentification et de conformité.
- Attribuer le marqueur seulement après validation de l’appareil et limiter les droits permettant de le modifier.
- Ne pas utiliser uniquement le nom du poste comme preuve de confiance.
- Tester un appareil non enregistré : ses propriétés de filtre sont nulles.
- Tester un poste conforme sans marqueur, un poste marqué non conforme et un poste quotidien.
- Vérifier le navigateur et le client PowerShell : l’identité de l’appareil doit être transmise au service.
device.extensionAttribute1 -eq "SAW"6. Remplacer les rôles permanents par des activations PIM
Dans ID Governance > Privileged Identity Management > Microsoft Entra roles, inventorier les attributions avant toute suppression. Choisir le rôle minimal requis pour chaque fonction et créer une attribution admissible lorsque le besoin n’est pas permanent.
Dans Roles > Role settings, définir une durée courte compatible avec le travail, une justification, les notifications et une approbation pour les rôles sensibles. Une durée d’une heure est un exemple de départ pour une opération ponctuelle, pas une règle universelle. Tester l’activation avant de retirer l’attribution permanente correspondante.
Prévoir plusieurs approbateurs disponibles pendant les périodes de soutien. Les rôles Entra, les rôles Azure et les permissions propres aux services ont des portées différentes : une configuration PIM dans Entra ne couvre pas automatiquement tout le reste.
7. Protéger l’activation elle-même
PIM peut exiger un contexte d’authentification Conditional Access lors de l’activation. Créer le contexte, lui associer une stratégie qui exige les contrôles voulus, puis sélectionner ce contexte dans les paramètres du rôle.
Cibler cette stratégie sur les utilisateurs admissibles ou leur groupe, pas uniquement sur le rôle qu’ils essaient d’activer : ils ne le possèdent pas encore à cette étape. Conserver également les restrictions sur les ressources après activation. Une simple exigence MFA PIM peut être satisfaite par une authentification déjà présente dans la session; elle ne garantit pas un nouveau défi à chaque activation.
Ne pas assimiler l’expiration du rôle à une coupure instantanée de toutes les sessions ouvertes. Tester le comportement des services et prévoir la révocation et la réponse à incident séparément.
8. Valider avec une matrice de tests
Report-only fournit des résultats sans appliquer la restriction. Examiner Success, Failure, User action required et Not applied; ce dernier résultat ne démontre pas qu’un contrôle a réussi. Utiliser What If pour préparer les scénarios, puis réaliser les connexions réelles. Les tests d’une seule session navigateur ne suffisent pas.
Passer une politique à la fois en On sur le pilote. Tester ensuite une nouvelle session, les outils administratifs et le chemin de récupération avant d’étendre le groupe.
| Scénario | Résultat attendu |
|---|---|
| Poste approuvé et conforme, méthode forte, rôle activé | Opération autorisée dans la portée du rôle |
| Poste quotidien conforme | Accès administratif refusé par la restriction des postes |
| Poste approuvé devenu non conforme | Accès refusé lorsque la conformité est évaluée |
| Méthode ne satisfaisant pas la force requise | Authentification supplémentaire ou refus |
| Utilisateur admissible sans rôle activé | Activation possible depuis le chemin prévu; opération privilégiée refusée |
| Compte d’urgence | Récupération possible selon la procédure testée |
| Graph ou Exchange PowerShell | Même objectif de protection que les portails |
9. Surveiller les connexions et les changements
Acheminer les journaux Entra vers Log Analytics si cette collecte est disponible et autorisée. Définir la rétention et les coûts; les requêtes suivantes supposent que SigninLogs est alimentée. Remplacer les comptes d’exemple par l’inventaire réel. Cette sélection explicite ne découvre pas automatiquement tous les administrateurs.
La première requête cherche les connexions réussies où le signal de conformité est absent ou faux. C’est un point de départ d’enquête, pas une preuve de compromission. Corréler l’appareil, la ressource, la politique évaluée et les exceptions prévues.
- Alerter sur l’utilisation des comptes d’urgence et les changements d’exclusions Conditional Access.
- Surveiller les modifications des rôles, des paramètres PIM et du groupe administratif.
- Contrôler les changements du marqueur d’appareil et les administrateurs capables de l’écrire.
- Corréler les alertes MDE avec les connexions et les activations PIM.
- Tester aussi les journaux non interactifs et les identités applicatives dans une surveillance distincte.
let Admins = dynamic(["admin.alex@contoso.com", "admin.sam@contoso.com"]);
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in~ (Admins)
| where tostring(ResultType) == "0"
| extend DeviceId=tostring(DeviceDetail.deviceId), Compliant=tobool(DeviceDetail.isCompliant)
| where isempty(DeviceId) or isnull(Compliant) or Compliant == false
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, DeviceId, Compliant, ConditionalAccessStatusSigninLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| extend PolicyName=tostring(Policy.displayName), PolicyResult=tostring(Policy.result)
| where PolicyName startswith "CA-ADM-"
| summarize Events=count(), Users=dcount(UserPrincipalName) by PolicyName, PolicyResult
| order by Events desc10. Prévoir l’urgence et le retour arrière
Conserver des comptes d’urgence protégés, surveillés et testés, avec des exclusions documentées des politiques qui pourraient empêcher la récupération. Une exclusion ne signifie pas qu’un compte doit utiliser un mot de passe faible ou être exempté de toute protection.
Avant l’application, exporter la configuration des politiques et consigner leurs identifiants, groupes et exclusions. En cas de blocage, utiliser le chemin de récupération testé pour désactiver seulement la nouvelle restriction responsable, corriger le ciblage et refaire le pilote.
Si un poste d’administration est compromis, l’isoler, examiner ses sessions et les changements exécutés avec ses comptes, puis le reconstruire depuis une source maîtrisée. Ajouter le poste à une exclusion ne constitue pas une remédiation.
Un déploiement en quatre étapes
La réussite se mesure par des opérations administratives possibles depuis un chemin maîtrisé et refusées depuis les autres chemins. Une capture montrant PIM activé ou une politique Conditional Access créée ne suffit pas : il faut pouvoir démontrer les deux résultats.
- Préparer : inventaire des administrateurs, licences, postes, méthodes fortes et récupération.
- Piloter : conformité, authentification, liste de postes autorisés et activation PIM sur un petit groupe.
- Appliquer : politiques activées une à une, opérations réelles et tests de refus documentés.
- Maintenir : revue des privilèges, correctifs, exceptions, alertes et exercices de récupération.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →