💡 Activer l’accès conditionnel sans planification, c’est comme retirer les airbags pour installer un ABS : vous gagnez en contrôle, mais vous perdez une protection passive essentielle.

L’accès conditionnel (Conditional Access – CA) est souvent présenté comme le mécanisme de sécurité avancé d’Entra ID.
Dans les faits, il est surtout un changement de modèle, avec des conséquences immédiates — et parfois invisibles — sur le niveau de sécurité réel d’un tenant Microsoft 365.

Le risque à comprendre dès le départ

⚠️ Activer l’accès conditionnel sans reconstruire explicitement les protections des Security Defaults entraîne une baisse effective du niveau de sécurité.

Ce risque est :

• contre-intuitif,
• fréquent,
• rarement documenté,
• et régulièrement observé lors d’audits ou d’incidents.

Le problème n’est pas l’accès conditionnel en lui-même, mais la transition mal maîtrisée entre deux modèles de sécurité.

Security Defaults : un socle souvent sous-estimé

Les Security Defaults ne sont ni sophistiqués ni personnalisables.
Ils constituent cependant un socle de sécurité de base, conçu pour couvrir les scénarios d’attaque les plus courants.

Concrètement, ils imposent notamment :

• l’activation du MFA pour les utilisateurs,
• une exigence renforcée pour les comptes administrateurs,
• le blocage des protocoles d’authentification non-sécurisés (POP, IMAP, SMTP AUTH, etc.),
• une application globale, sans exception implicite.

Ce modèle a deux qualités essentielles :

• il est prévisible,
• il est difficile à affaiblir par erreur.

Le basculement critique : ce que fait réellement l’accès conditionnel

🚨 Dès qu’au moins une politique d’accès conditionnel est activée, les Security Defaults sont automatiquement désactivés.

Ce point est fondamental.

À partir de ce moment :

• Microsoft ne fournit plus aucun socle implicite,
• aucune protection n’est « conservée »,
• seules les politiques CA définissent le niveau de sécurité du tenant.

Autrement dit :

tout ce qui n’est pas explicitement configuré n’existe plus.

Pourquoi ce basculement crée un faux sentiment de sécurité

Dans la réalité opérationnelle, on observe fréquemment les situations suivantes :

• une ou deux politiques CA « principales » créées rapidement,
• des exclusions larges pour éviter les blocages,
• un périmètre limité aux utilisateurs « standards »,
• des administrateurs gérés à part, voire oubliés,
• des scénarios non couverts (legacy auth, comptes de service, invités).

Visuellement, le tenant semble plus sécurisé.
Techniquement, il peut l’être moins qu’avant.

Cas concrets observés sur le terrain

Quelques exemples récurrents :

• MFA absent pour certains utilisateurs car non inclus dans les groupes ciblés
• Protocoles non-sécurisés encore autorisés car aucune règle explicite ne les bloque
• Comptes administrateurs non soumis au MFA « pour éviter les blocages »
• Comptes invités totalement hors périmètre
• Politiques CA empilées sans logique globale

Dans ces cas, le tenant aurait été plus sécurisé avec les Security Defaults activés.

L’accès conditionnel n’est pas une protection, c’est un framework

C’est un point souvent mal compris.

L’accès conditionnel :

• ne protège rien par défaut,
• n’impose aucune règle minimale,
• ne garantit aucune cohérence globale.

Il fournit :

• des conditions,
• des contrôles,
• et une liberté totale.

Cette liberté implique une responsabilité :
concevoir un modèle de sécurité avant d’écrire des règles.

La mesure : reconstruire le socle avant d’optimiser

Avant toute politique avancée, l’objectif doit être simple :

Recréer au minimum le niveau de protection offert par les Security Defaults.

1. Comptes brise-glace : non négociable

Les comptes brise-glace doivent :

• être exclus de toutes les politiques CA,
• être fortement sécurisés (mot de passe long, stockage hors ligne, surveillance),
• être documentés,
• être testés régulièrement.

Ils ne sont pas là pour le confort, mais pour la résilience opérationnelle.

2. Reproduire explicitement le socle Security Defaults

Cela implique au minimum :

• MFA obligatoire pour tous les utilisateurs
• MFA renforcé pour les rôles à privilèges
• Blocage explicite de la legacy authentication
• Couverture globale, sans dépendance implicite

Chaque point doit être :

• visible dans Entra ID,
• vérifiable,
• explicable à un tiers.

3. S’appuyer sur une baseline structurée

Plutôt que d’inventer un modèle, il est pertinent de s’inspirer de baselines existantes, par exemple :

• la Conditional Access Baseline de Joey Verlinden :
  • politiques atomiques,
  • séparation claire des objectifs,
  • lisibilité dans le temps,
  • approche progressive.

L’objectif n’est pas la conformité à une baseline, mais la cohérence du modèle.

4. Tester, mesurer, ajuster

Toute politique CA doit :

• être testée sur un groupe pilote,
• être validée sur les scénarios critiques,
• être observée via les journaux de connexion,
• être ajustée avant déploiement global.

🧪 En accès conditionnel, le test est une mesure de sécurité à part entière.

Gouvernance : le vrai sujet derrière la technique

L’activation de l’accès conditionnel n’est pas un changement purement technique.
C’est une décision de gouvernance de l’identité.

Elle implique :

• des règles documentées,
• des objectifs clairs,
• une responsabilité identifiée,
• une revue régulière.

Sans gouvernance, CA devient :

• une dette technique,
• un risque latent,
• un angle mort en cas d’incident.

À retenir

• Les Security Defaults fournissent un socle minimal mais robuste
• L’accès conditionnel désactive ce socle sans avertissement fonctionnel
• Toute protection non recréée est perdue
• CA doit être conçu avant d’être activé
• La sécurité de l’identité est avant tout une question de gouvernance

Cet article sert de point de départ à la série 1 risque / 1 mesure.
Les épisodes suivants iront plus loin dans les scénarios d’attaque modernes, où ce socle devient indispensable.