Aller au contenu principal

Introduction : pourquoi cet article technique ?

Notre page gestion des identités et accès conditionnel explique pourquoi le contrôle des identités est la première ligne de défense de votre PME. Cet article va plus loin : il détaille comment fonctionne le moteur d'accès conditionnel de Microsoft Entra ID, quels mécanismes techniques protègent vos comptes et comment architecturer une politique Zero Trust réaliste pour une entreprise de 20 à 250 collaborateurs.

Selon le Verizon Data Breach Investigations Report 2025, 81 % des compromissions impliquent des identifiants volés ou faibles. L'identité est devenue le périmètre de sécurité. Ce n'est plus le pare-feu.

Le modèle Zero Trust : ne jamais faire confiance, toujours vérifier

Le paradigme fondamental

Le Zero Trust repose sur un principe simple mais radical : aucune connexion n'est de confiance par défaut, qu'elle vienne du bureau, du VPN ou du réseau interne. Chaque tentative d'accès est évaluée en temps réel selon un ensemble de signaux contextuels.

Concrètement, le modèle Zero Trust appliqué à l'identité fonctionne en trois étapes :

  1. Vérifier explicitement : chaque authentification est évaluée sur la base de multiples signaux (identité, appareil, localisation, comportement)
  2. Appliquer le moindre privilège : un utilisateur n'obtient que les droits strictement nécessaires, pour une durée limitée
  3. Présumer la compromission : le système se comporte comme si le réseau était déjà infiltré et surveille en continu les anomalies

Ce n'est pas une technologie unique. C'est une architecture qui orchestre l'accès conditionnel, le MFA, la détection de risques et la gestion des privilèges. Microsoft Entra ID est le point d'orchestration central pour les environnements Microsoft 365.

Pourquoi le VPN seul ne suffit plus

Un VPN accorde un accès réseau large après une authentification unique. Une fois connecté, l'utilisateur accède à tout le réseau interne — exactement ce que recherche un attaquant ayant compromis un compte. Le Zero Trust remplace cette logique par un contrôle par ressource, par session, en continu. Chaque accès à SharePoint, Teams, un ERP ou une application métier est évalué indépendamment.

Le moteur d'accès conditionnel Entra ID : évaluation des signaux

Architecture du moteur de décision

L'accès conditionnel Entra ID fonctionne comme un moteur de règles if/then évalué à chaque authentification. Il analyse simultanément cinq catégories de signaux :

1. Signaux liés à l'utilisateur

  • Appartenance à un groupe ou rôle d'annuaire
  • Niveau de risque utilisateur (calculé par Identity Protection)
  • Statut du compte (actif, suspendu, compromis)

2. Signaux liés à la connexion (sign-in risk)

  • Risque de la tentative de connexion en cours
  • Adresse IP source (connue, anonyme, Tor, proxy)
  • Détection de voyage impossible (connexion depuis Paris puis Lagos en 20 minutes)

3. Signaux liés à l'appareil

  • Appareil inscrit dans la gestion de flotte mobile (MDM) ou joint à Entra ID
  • Conformité de l'appareil (chiffrement BitLocker actif, antivirus à jour, OS patché)
  • Type de plateforme (Windows, macOS, iOS, Android, Linux)

4. Signaux liés à l'application cible

  • Application cloud spécifique (Exchange Online, SharePoint, application tierce)
  • Action demandée (lecture, écriture, administration)

5. Signaux de localisation

  • Plages IP de confiance (bureaux, datacenters)
  • Pays d'origine de la connexion
  • Réseau conforme ou non

Sur la base de cette évaluation, le moteur rend une décision : autoriser, bloquer, ou autoriser sous conditions (exiger le MFA, exiger un appareil conforme, limiter la session).

Exemple concret pour une PME

Voici une politique réaliste pour une PME de 50 collaborateurs :

ScénarioSignaux évaluésDécision
Connexion depuis le bureau, PC conformeIP de confiance + appareil géréAutoriser (MFA non requis)
Connexion depuis le domicile, PC personnelIP inconnue + appareil non géréExiger MFA + limiter à l'accès web uniquement
Connexion depuis un pays non autoriséGéolocalisation hors périmètreBloquer
Connexion avec risque élevé détectéSign-in risk = highExiger MFA résistant au phishing (FIDO2)
Accès admin au portail AzureRôle = Global AdminExiger MFA + appareil conforme + PIM activé

Hiérarchie des méthodes MFA : toutes ne se valent pas

Du plus faible au plus résistant

Toutes les méthodes d'authentification multifacteur ne se valent pas. Microsoft les classe désormais par force d'authentification (Authentication Strength) :

SMS (force faible) : un code à 6 chiffres envoyé par SMS. Vulnérable au SIM swapping (l'attaquant convainc l'opérateur de transférer le numéro), à l'interception SS7 et au phishing en temps réel (l'utilisateur saisit le code sur un faux site, l'attaquant le rejoue instantanément). Microsoft et l'ANSSI déconseillent le SMS comme seul facteur secondaire depuis 2023.

TOTP — Time-based One-Time Password (force moyenne) : une application (Microsoft Authenticator, Google Authenticator) génère un code toutes les 30 secondes, basé sur un secret partagé et l'horodatage. Plus sûr que le SMS car non interceptable sur le réseau, mais toujours vulnérable au phishing en temps réel : l'utilisateur peut saisir le code sur un faux site.

Push notification (force moyenne-haute) : Microsoft Authenticator affiche une notification avec un numéro à confirmer (number matching). Résiste au phishing simple, mais reste vulnérable aux attaques de fatigue MFA (l'attaquant envoie des dizaines de notifications jusqu'à ce que l'utilisateur approuve par lassitude). Le number matching réduit ce risque.

FIDO2 / Passkeys (force maximale) : c'est la méthode recommandée par Microsoft, l'ANSSI et le NIST. Et pour cause : elle est résistante au phishing par conception.

Pourquoi FIDO2 est résistant au phishing : explication technique

FIDO2 repose sur la cryptographie asymétrique avec liaison d'origine :

  1. Lors de l'enregistrement, la clé de sécurité (YubiKey, Windows Hello, Touch ID) génère une paire de clés unique pour le domaine login.microsoftonline.com
  2. La clé publique est envoyée à Microsoft, la clé privée reste sur l'appareil (elle n'en sort jamais)
  3. Lors de l'authentification, le navigateur envoie un challenge qui inclut l'origine (le domaine exact du site)
  4. La clé de sécurité ne signe le challenge que si l'origine correspond au domaine enregistré
  5. Un site de phishing sur login-microsoftonline.com (avec un tiret) ne déclenchera jamais la signature

Cette liaison d'origine est gérée par le navigateur au niveau du protocole WebAuthn — l'utilisateur n'a aucune décision à prendre. C'est une protection cryptographique, pas comportementale. L'erreur humaine est éliminée de l'équation.

Pour compléter votre stratégie d'identifiants, un gestionnaire de mots de passe professionnel gère les secrets applicatifs qui ne supportent pas encore le passwordless.

Identity Protection : détection de risques en temps réel

Les signaux analysés par le moteur de risques

Entra ID Identity Protection (inclus dans Entra ID P2) analyse en temps réel des milliards de signaux issus de l'écosystème Microsoft pour calculer un score de risque par utilisateur et par connexion :

Risques liés à la connexion (sign-in risk) :

  • Voyage impossible : connexion depuis Paris à 10h puis depuis Singapour à 10h30
  • Adresse IP anonyme : connexion via Tor, VPN public ou proxy anonymisant
  • Adresse IP malveillante : IP répertoriée dans les bases de threat intelligence Microsoft
  • Propriétés de connexion inhabituelles : navigateur, OS ou localisation jamais observés pour cet utilisateur
  • Password spray détecté : tentatives de connexion avec des mots de passe courants sur plusieurs comptes

Risques liés à l'utilisateur (user risk) :

  • Identifiants divulgués : le couple email/mot de passe détecté dans des bases de données de fuites (dark web monitoring)
  • Anomalie de jeton : durée de vie, émetteur ou claims inhabituels dans le jeton d'authentification
  • Activité suspecte : modifications de boîte aux lettres, règles de transfert créées automatiquement

Ces scores alimentent directement les politiques d'accès conditionnel. Une PME peut configurer : "si le risque de connexion est moyen, exiger le MFA ; si le risque est élevé, bloquer et forcer la réinitialisation du mot de passe."

La détection de menaces est renforcée lorsqu'elle est corrélée avec un EDR/XDR/MDR qui couvre les endpoints et qu'un SOC managé surveille les alertes 24/7.

Privileged Identity Management (PIM) : l'administration just-in-time

Le problème des administrateurs permanents

Dans une PME typique, le responsable IT est Global Admin en permanence. Son compte a les clés du royaume — 24 heures sur 24, 7 jours sur 7. Si ce compte est compromis (phishing, infostealer, session hijacking), l'attaquant obtient immédiatement le contrôle total du tenant Microsoft 365.

Selon IBM Security, le coût moyen d'une compromission impliquant des identifiants privilégiés est de 4,55 millions d'euros en 2025 — soit 20 % de plus que la moyenne globale.

Comment PIM résout le problème

Privileged Identity Management supprime les droits permanents et les remplace par une activation à la demande :

  1. Le responsable IT est éligible au rôle Global Admin (mais ne l'a pas activement)
  2. Quand il a besoin d'effectuer une action administrative, il demande l'activation via le portail PIM
  3. Il fournit une justification obligatoire ("Modification de la politique de rétention SharePoint")
  4. Selon la configuration, un approbateur valide la demande (le dirigeant, un second IT, un prestataire)
  5. Le rôle est activé pour une durée limitée (typiquement 1 à 4 heures)
  6. À l'expiration, les droits sont automatiquement retirés
  7. Chaque activation est journalisée avec justification, durée et actions effectuées

Pour une PME, PIM élimine le scénario catastrophe de l'administrateur compromis en dehors des fenêtres d'activation. C'est le principe du moindre privilège appliqué aux comptes les plus sensibles.

Authentication Strength : imposer la bonne méthode MFA par scénario

Une nouveauté d'Entra ID sous-exploitée

Les politiques d'Authentication Strength permettent de définir quelles méthodes MFA sont acceptables pour un scénario donné, au lieu de simplement exiger "un MFA quelconque".

Exemples de configuration :

ScénarioAuthentication Strength requise
Accès standard à Microsoft 365MFA standard (TOTP, Push ou FIDO2)
Accès aux données financières (SharePoint confidentiel)MFA résistant au phishing (FIDO2 uniquement)
Administration Azure / Entra IDMFA résistant au phishing + appareil conforme
Enregistrement d'une méthode MFA (bootstrap)Temporary Access Pass (TAP)

Cette granularité est essentielle : exiger FIDO2 pour tout le monde dès le premier jour n'est pas réaliste. L'Authentication Strength permet un déploiement progressif en réservant les exigences maximales aux scénarios à haut risque, tout en sécurisant l'ensemble de l'environnement Microsoft 365.

Protocoles legacy : pourquoi IMAP, POP3 et SMTP Basic Auth doivent disparaitre

Le problème technique

Les protocoles de messagerie historiques (IMAP, POP3, SMTP avec authentification basique) transmettent les identifiants en clair (encodés en Base64, ce qui n'est pas du chiffrement). Plus grave encore : ils ne supportent pas le MFA.

Concrètement, si un attaquant obtient le mot de passe d'un utilisateur, il peut se connecter via IMAP depuis n'importe où dans le monde, sans déclencher aucune vérification supplémentaire. L'accès conditionnel ne peut pas protéger ce qui ne passe pas par le flux d'authentification moderne (OAuth 2.0).

Selon Microsoft, les comptes qui autorisent l'authentification legacy sont 3 fois plus susceptibles d'être compromis. C'est la porte dérobée que les attaquants cherchent en premier lors d'une campagne de credential stuffing.

La solution

L'accès conditionnel permet de créer une politique dédiée :

  • Cible : tous les utilisateurs
  • Applications clientes : Exchange ActiveSync, Other clients (IMAP, POP3, SMTP)
  • Décision : bloquer

Cette politique doit être déployée progressivement : identifiez d'abord les applications métier qui utilisent encore ces protocoles (imprimantes multifonctions, anciens CRM, scanners), migrez-les vers OAuth 2.0 ou des comptes de service dédiés, puis bloquez.

Continuous Access Evaluation (CAE) : révocation en quasi-temps réel

La limite des jetons classiques

Dans le modèle OAuth 2.0 traditionnel, un jeton d'accès a une durée de vie fixe (1 heure par défaut pour Microsoft 365). Pendant cette heure, même si le compte est désactivé, le mot de passe changé ou l'utilisateur déconnecté d'Entra ID, le jeton reste valide. L'attaquant a une heure de libre.

Comment CAE change la donne

Le Continuous Access Evaluation établit un canal de communication permanent entre Entra ID et les services Microsoft 365 (Exchange Online, SharePoint, Teams). Quand un événement critique survient :

  • Compte désactivé ou supprimé
  • Mot de passe modifié
  • MFA réinitialisé par un administrateur
  • Localisation IP qui change de manière suspecte

Le service cible est notifié en quelques minutes et invalide le jeton immédiatement, sans attendre son expiration naturelle. Pour un offboarding, cela signifie que l'ancien collaborateur perd l'accès à sa messagerie en 2 à 5 minutes au lieu d'une heure.

Le CAE est activé par défaut sur les tenants Microsoft 365 depuis 2024 et ne nécessite aucune configuration supplémentaire. C'est une amélioration silencieuse mais fondamentale pour la posture de sécurité.

Conformité DORA et NIS2 : ce que couvre l'accès conditionnel

Cartographie des exigences

Les réglementations européennes DORA (secteur financier) et NIS2 (entités essentielles et importantes) imposent des mesures spécifiques que l'accès conditionnel Entra ID adresse directement :

Exigence réglementaireCapacité Entra ID correspondante
Authentification forte pour tous les accès (NIS2 Art. 21)Accès conditionnel + MFA obligatoire
Gestion des accès privilégiés (DORA Art. 9)Privileged Identity Management (PIM)
Surveillance continue des accès (NIS2 Art. 21)Identity Protection + CAE
Principe du moindre privilège (DORA Art. 9)Accès conditionnel basé sur les rôles + PIM
Journalisation des accès (NIS2 Art. 21)Journaux d'audit Entra ID (rétention 30j P1, illimitée avec Log Analytics)
Blocage des protocoles non sécurisés (DORA Art. 9)Politique de blocage legacy authentication
Détection des compromissions d'identité (NIS2 Art. 21)Identity Protection (user risk + sign-in risk)
Révocation rapide des accès (DORA Art. 9)CAE + SCIM provisionnement/déprovisionnement

L'ANSSI recommande dans son guide d'hygiène informatique (42 mesures) l'utilisation de l'authentification forte et la restriction des privilèges d'administration — deux piliers directement couverts par Entra ID P2.

Comparatif des licences : Entra ID P1 vs P2 vs MFA standalone

FonctionnalitéMFA standalone (incl. M365 Business)Entra ID P1 (incl. M365 Business Premium)Entra ID P2
MFA (SMS, TOTP, Push, FIDO2)OuiOuiOui
Accès conditionnelNon (defaults de sécurité uniquement)Oui (complet)Oui (complet)
Authentication StrengthNonOuiOui
Blocage legacy authenticationPartiel (defaults)Oui (granulaire)Oui (granulaire)
Identity Protection (sign-in risk)NonNonOui
Identity Protection (user risk)NonNonOui
Privileged Identity ManagementNonNonOui
Revues d'accès automatiséesNonNonOui
Continuous Access EvaluationOuiOuiOui
Prix indicatif/utilisateur/moisInclus dans M365~6 EUR (ou inclus Business Premium)~9 EUR

Pour une PME de 30 à 100 utilisateurs soumise à NIS2 ou DORA, Entra ID P2 est le choix rationnel. Le surcoût de 3 EUR/utilisateur/mois par rapport à P1 est dérisoire face au coût d'une compromission d'identité — estimé à 165 EUR par enregistrement compromis selon le rapport IBM Cost of a Data Breach 2025.

Conclusion

L'accès conditionnel Entra ID n'est pas une case à cocher. C'est le moteur central d'une stratégie Zero Trust qui transforme chaque authentification en une décision de sécurité contextuelle. Combiné à Identity Protection, PIM et des méthodes MFA résistantes au phishing comme FIDO2, il constitue la fondation sur laquelle construire toute votre posture cybersécurité.

Le déploiement n'a pas besoin d'être un projet titanesque. En 2 à 3 jours, une PME peut passer d'un tenant Microsoft 365 avec des defaults de sécurité basiques à une architecture Zero Trust opérationnelle : accès conditionnel granulaire, MFA imposé, protocoles legacy bloqués, administration just-in-time et détection de risques en temps réel.

Si vous souhaitez évaluer votre posture actuelle, nous proposons un audit gratuit de 30 minutes de votre configuration Entra ID. Contactez-nous.


Cet article est le complément technique de notre page Gestion des identités et accès conditionnel. Pour une vue d'ensemble orientée business, consultez-la directement.

Valentin Bourgeois, fondateur Dhala Cyberdéfense

Valentin Bourgeois

Fondateur — Dhala Cyberdéfense

Expert en cybersécurité et infogérance pour PME depuis plus de 10 ans. J'accompagne les dirigeants dans la protection de leur système d'information.

Demander un audit gratuit

Reprenez le contrôle de votre parc informatique

Découvrez comment nous pouvons vous aider à sécuriser votre entreprise.
Audit gratuit
Photo Valentin
ParisLyonBordeauxNancyCannesAngletMegèveReimsRouenMadridMilanMunichLondresBruxellesMontréalNew YorkSan FranciscoLas VegasDenverBrasovParisLyonBordeauxNancyCannesAngletMegèveReimsRouenMadridMilanMunichLondresBruxellesMontréalNew YorkSan FranciscoLas VegasDenverBrasovParisLyonBordeauxNancyCannesAngletMegèveReimsRouenMadridMilanMunichLondresBruxellesMontréalNew YorkSan FranciscoLas VegasDenverBrasov