Comment l'accès conditionnel et PIM arrêtent réellement les attaques?

Les stratégies de mots de passe arrêtent les attaques par force brute. Elles ne font rien contre un jeton de session volé, une invite MFA phishée, ou un compte administrateur permanent qui a les droits d'administrateur global depuis deux ans. L'accès conditionnel et la gestion des identités privilégiées (PIM) sont les deux contrôles Azure AD / Entra ID qui traitent réellement ces lacunes, et ils fonctionnent mieux ensemble.

Ce que l'accès conditionnel fait en arrière-plan

L'accès conditionnel est un moteur si-cela-alors-cela évalué au moment de la connexion. Le côté "si" (signaux) comprend l'appartenance à un utilisateur ou un groupe, l'état de conformité de l'appareil, la localisation réseau, le risque de connexion (à partir d'Identity Protection), l'application en cours d'accès, et le type d'application cliente (navigateur ou protocole legacy). Le côté "alors" (contrôles) comprend: exiger MFA, exiger un appareil conforme, exiger une application cliente approuvée, bloquer l'accès complètement, ou exiger l'acceptation des conditions d'utilisation.

Une stratégie qui compte dans presque tous les locataires: bloquer l'authentification legacy. Les protocoles comme POP, IMAP, et les anciennes versions de SMTP ne prennent pas en charge les défis MFA modernes, donc c'est la première chose que les outils de credential stuffing essaient. Vérifiez les journaux de connexion filtrés par "Client App = Other clients" avant de bloquer — vous trouverez souvent un ancien scanner ou une ancienne imprimante multifonction qui s'authentifie encore avec basic auth.

Une deuxième qui vaut la peine d'avoir dès le départ: exiger MFA pour tous les utilisateurs, définie avec un groupe d'exclusion pour les comptes break-glass seulement. Ne définissez pas MFA sur "juste les administrateurs." Les comptes utilisateur standard compromis sont comment les attaquants obtiennent leur premier point d'appui avant même l'escalade de privilèges.

Risque de connexion vs risque utilisateur — des signaux différents, des réponses différentes

Identity Protection (qui fait partie d'Entra ID P2) génère deux scores de risque distincts et c'est facile de les confondre:

• Risque de connexion — cette tentative d'authentification spécifique semble anormale (voyage impossible, adresse IP anonyme, propriétés de connexion non familières).
• Risque utilisateur — ce compte a été signalé pour une raison liée à l'identité elle-même (identifiants fuites trouvés dans un corpus de fuite, activité de compromission confirmée).

Une stratégie d'accès conditionnel répondant au risque de connexion devrait généralement contester avec MFA — si l'utilisateur réel peut compléter le défi, laissez-le passer. Une stratégie répondant au risque utilisateur devrait forcer une réinitialisation de mot de passe, car MFA seul n'aide pas si l'identifiant lui-même est déjà compromis.

Pourquoi l'accès administrateur permanent est le plus gros problème

Même avec un accès conditionnel étanche, un compte qui détient en permanence l'administrateur global est une cible bien visible dans l'annuaire. Quiconque le compromet hérite du contrôle total du locataire sans étape supplémentaire requise. PIM supprime la partie "permanent".

Avec PIM, les rôles administratifs sont assignés comme éligibles plutôt qu'actifs. L'utilisateur doit explicitement activer le rôle, ce qui déclenche une justification requise, un flux d'approbation optionnel, une re-confirmation MFA, et une fenêtre limitée dans le temps — généralement 1 à 8 heures — après laquelle le rôle se désactive automatiquement. Personne, pas même le propriétaire du compte, n'a l'administrateur global permanent sauf s'il l'utilise activement.

Une configuration PIM minimale qui est réellement utilisable

• Chaque rôle au-dessus d'administrateur du support technique: éligible, pas permanent.
• Administrateur global et administrateur de rôle privilégié: exiger l'approbation d'un deuxième administrateur, pas juste l'auto-activation.
• MFA d'activation requise, pas d'exceptions.
• Durée d'activation maximale de 4 heures force les gens à réactiver pour des sessions de travail véritablement distinctes, ce qui produit aussi des pistes d'audit plus nettes.
• Révisions d'accès tous les 90 jours sur tous les assignements éligibles — les comptes sont ajoutés pour un projet et jamais supprimés autrement.

Où les équipes se trompent

L'échec le plus courant n'est pas la conception de la stratégie, c'est la liste d'exclusion. Une stratégie d'accès conditionnel avec un groupe "exclure ces utilisateurs parce que l'application ne prend pas en charge MFA" en constante croissance finit par exclure la moitié du locataire. Suivez les exclusions comme un élément du backlog avec un propriétaire et une date de suppression, pas un compartiment permanent.

L'deuxième échec est les comptes break-glass qui ne sont pas réellement testés. Deux comptes d'urgence, exclus de l'accès conditionnel et PIM, avec de longs mots de passe aléatoires stockés hors ligne et des alertes sur toute connexion — et quelqu'un devrait essayer de se connecter avec tous les trimestres pour confirmer qu'ils fonctionnent encore.

L'accès conditionnel et PIM ne sont pas une case à cocher pour un audit de conformité. C'est la différence entre une identifiant phishée qui est une gêne et elle étant un compromis complet du locataire. Si vous cartographiez les contrôles d'identité dans le cadre d'une construction Blue Team, les segments Cloud et Blue Team de Korra Studio couvrent le côté détection — à quoi les événements de risque d'Identity Protection ressemblent réellement dans Sentinel et comment alerter sur les modèles d'activation PIM impossibles.