Conditional Access Azure Entra ID : Guide Complet 2026

Le Conditional Access d'Azure Entra ID (anciennement Azure AD) constitue le moteur de décision central de toute stratégie Zero Trust Microsoft en entreprise. La documentation officielle Microsoft et le repo GitHub de design patterns sont les références essentielles pour l'implémentation. En évaluant dynamiquement chaque tentative d'authentification selon des signaux contextuels multiples — identité de l'utilisateur, état de conformité de l'appareil via Intune, localisation géographique, niveau de risque détecté par Identity Protection, application cible et comportement de la session — les politiques d'accès conditionnel permettent d'appliquer le principe du moindre privilège de manière granulaire et adaptative. Ce guide complet couvre la conception des politiques, l'intégration MFA contextuelle, le device compliance, les named locations, les session controls, et la méthodologie de dépannage pour les scénarios complexes impliquant des chaînes de politiques multiples.

En 2026, la gestion des accès conditionnels dans Microsoft Entra ID (anciennement Azure Active Directory) constitue le socle fondamental de toute stratégie Zero Trust appliquée aux environnements cloud Microsoft. Les politiques de Conditional Access déterminent en temps réel si un utilisateur, un appareil ou une identité de charge de travail peut accéder à une ressource donnée, en évaluant simultanément des dizaines de signaux contextuels — localisation géographique, état de conformité du terminal, niveau de risque de la session, appartenance à un groupe, sensibilité de l'application cible. Cette orchestration fine des décisions d'accès transforme radicalement l'approche périmétrique traditionnelle en substituant le concept de confiance implicite par une vérification continue et contextuelle. Cet article décortique l'architecture complète des politiques Conditional Access, depuis les fondamentaux jusqu'aux configurations avancées incluant le Continuous Access Evaluation, les identités de charge de travail et l'automatisation via Microsoft Graph API, en s'appuyant sur des retours d'expérience concrets issus de déploiements en environnement de production.

Architecture fondamentale du Conditional Access dans Entra ID

Le Conditional Access repose sur un moteur d'évaluation de politiques qui intercepte chaque tentative d'authentification transitant par Microsoft Entra ID. Ce moteur fonctionne selon un modèle déclaratif où chaque politique définit un ensemble de conditions (assignments) et un ensemble de contrôles d'accès (access controls) appliqués lorsque les conditions sont remplies. La compréhension approfondie de cette architecture est indispensable pour concevoir des politiques efficaces sans créer de conflits ou de failles de sécurité.

Le flux d'évaluation suit un ordre précis. Lorsqu'un utilisateur tente d'accéder à une ressource protégée, la requête d'authentification arrive au service Entra ID qui identifie toutes les politiques Conditional Access applicables. Chaque politique est évaluée indépendamment selon ses conditions d'affectation : utilisateurs et groupes concernés, applications cloud ciblées, conditions de connexion (plateforme, localisation, risque). Si les conditions d'une politique sont satisfaites, ses contrôles d'accès sont collectés. L'ensemble des contrôles requis par toutes les politiques applicables est agrégé, et le résultat le plus restrictif s'applique — c'est le principe du « most restrictive wins ».

Cette mécanique d'agrégation implique une conséquence fondamentale : une politique qui bloque l'accès (Block) prévaut toujours sur une politique qui autorise l'accès avec des contrôles (Grant with conditions). Cette hiérarchie stricte impose une conception rigoureuse des politiques pour éviter les blocages involontaires. Un administrateur qui crée une politique Block visant « All users » sur « All cloud apps » sans exclusion appropriée se retrouvera lui-même verrouillé hors du tenant — un scénario malheureusement fréquent en production.

Les composants structurels d'une politique Conditional Access se décomposent en trois sections principales. Les Assignments définissent le « qui » et le « quoi » : utilisateurs, groupes, rôles d'annuaire, identités externes, applications cloud ou actions spécifiques (enregistrement d'appareil, enregistrement de sécurité). Les Conditions affinent le « quand » et le « comment » : plateformes d'appareils, localisations réseau, applications clientes, niveaux de risque utilisateur et de connexion, filtres d'appareil. Les Access Controls spécifient le « alors quoi » : bloquer, autoriser avec MFA, exiger un appareil conforme, exiger une application approuvée, contrôler la session.

Point fondamental : Le Conditional Access évalue TOUTES les politiques applicables simultanément et applique le résultat le plus restrictif. Une seule politique Block suffit à empêcher l'accès, même si dix autres politiques Grant l'autorisent. Concevez vos politiques en partant du principe que chaque politique Block est une porte définitivement fermée.

Named Locations : géolocalisation et réseaux de confiance

Les Named Locations constituent le mécanisme par lequel Entra ID identifie la provenance géographique et réseau des tentatives d'authentification. Deux types de Named Locations coexistent : les localisations basées sur des plages d'adresses IP et les localisations basées sur des pays ou régions. Chaque type répond à des cas d'usage distincts et présente des limitations qu'il convient de maîtriser pour éviter des contournements de sécurité.

Les IP-based Named Locations permettent de définir des plages d'adresses IPv4 et IPv6 que l'organisation considère comme fiables. Typiquement, les adresses IP publiques des bureaux de l'entreprise, les plages de sortie des VPN corporatifs et les adresses des datacenters hébergeant des services internes sont déclarées comme « trusted locations ». Cette déclaration permet ensuite de créer des politiques différenciées : exiger le MFA uniquement hors du réseau de confiance, ou bloquer les connexions depuis des localisations non approuvées pour les comptes à privilèges.

La configuration des plages IP exige une attention particulière aux formats acceptés. Entra ID supporte la notation CIDR pour IPv4 (exemple : 203.0.113.0/24) et IPv6 (exemple : 2001:db8::/32). Les plages individuelles (/32 pour IPv4, /128 pour IPv6) sont autorisées mais consomment rapidement le quota de 195 Named Locations avec un maximum de 2000 plages IP par Named Location. Pour les organisations disposant de nombreux sites, la consolidation des plages en supernets est recommandée.

# Création d'une Named Location via Microsoft Graph API (PowerShell)
$params = @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    displayName = "Bureaux France - Production"
    isTrusted = $true
    ipRanges = @(
        @{
            "@odata.type" = "#microsoft.graph.iPv4CidrRange"
            cidrAddress = "203.0.113.0/24"
        },
        @{
            "@odata.type" = "#microsoft.graph.iPv4CidrRange"
            cidrAddress = "198.51.100.0/24"
        },
        @{
            "@odata.type" = "#microsoft.graph.iPv6CidrRange"
            cidrAddress = "2001:db8:abcd::/48"
        }
    )
}
New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params

Les Country-based Named Locations utilisent la géolocalisation IP de Microsoft pour associer une adresse IP à un pays. Cette approche est moins précise que les plages IP explicites car elle dépend de bases de données de géolocalisation qui peuvent contenir des erreurs, particulièrement pour les adresses IP de fournisseurs cloud ou de services VPN commerciaux. Microsoft recommande de ne pas s'appuyer uniquement sur la géolocalisation par pays pour des décisions de blocage critique, mais de la combiner avec d'autres signaux.

Un piège courant concerne le paramètre « Include unknown countries/regions ». Par défaut, ce paramètre est désactivé, ce qui signifie que les connexions depuis des adresses IP non géolocalisables ne sont pas couvertes par la politique. Un attaquant utilisant un proxy dont l'IP n'est pas dans les bases de géolocalisation contournerait ainsi une politique de blocage géographique. L'activation de ce paramètre est généralement recommandée pour les politiques de blocage, tout en prévoyant des mécanismes d'exception pour les cas légitimes.

Politiques et règles

Les Named Locations interagissent également avec les Compliant Network Check disponibles via Global Secure Access. Cette fonctionnalité vérifie non seulement l'adresse IP source mais aussi la présence d'un tunnel sécurisé vers le réseau Microsoft, offrant une assurance nettement supérieure à la simple vérification d'adresse IP. Le déploiement de Global Secure Access est particulièrement pertinent pour les organisations ayant adopté le travail hybride, où les adresses IP des collaborateurs varient constamment. Pour approfondir la sécurisation des accès dans les environnements cloud Microsoft, consultez notre guide détaillé sur la sécurisation d'Entra ID.

Device Compliance : intégration avec Microsoft Intune

L'exigence de conformité d'appareil dans les politiques Conditional Access représente l'un des contrôles les plus puissants pour garantir que seuls des terminaux gérés et sécurisés accèdent aux ressources de l'organisation. Ce contrôle repose sur l'intégration entre Entra ID et Microsoft Intune (ou un MDM tiers compatible) qui évalue en permanence l'état de chaque appareil inscrit.

La conformité d'un appareil est déterminée par des compliance policies définies dans Intune. Ces politiques vérifient un ensemble de critères configurables : version minimale du système d'exploitation, présence et état d'un antivirus, activation du chiffrement du disque (BitLocker sur Windows, FileVault sur macOS), absence de jailbreak ou root, complexité du code PIN, délai maximal sans synchronisation. Chaque critère non satisfait marque l'appareil comme non conforme, ce qui déclenche immédiatement le blocage par les politiques Conditional Access exigeant la conformité.

L'architecture de cette intégration mérite une attention particulière. Lorsqu'un appareil s'authentifie, Entra ID interroge le statut de conformité stocké dans son annuaire. Ce statut est mis à jour par Intune lors des cycles de synchronisation (par défaut toutes les 8 heures, mais configurable). Il existe donc un délai de propagation entre le moment où un appareil devient non conforme et le moment où Conditional Access bloque effectivement l'accès. Ce délai constitue une fenêtre de vulnérabilité que le Continuous Access Evaluation (CAE) permet de réduire significativement, comme nous le verrons ultérieurement.

// Exemple de compliance policy Intune via Graph API (JSON)
{
    "@odata.type": "#microsoft.graph.windows10CompliancePolicy",
    "displayName": "Windows 10/11 - Production Compliance",
    "description": "Politique de conformité pour les postes de travail production",
    "passwordRequired": true,
    "passwordMinimumLength": 12,
    "passwordRequiredType": "alphanumeric",
    "osMinimumVersion": "10.0.22631",
    "secureBootEnabled": true,
    "bitLockerEnabled": true,
    "codeIntegrityEnabled": true,
    "antivirusRequired": true,
    "firewallEnabled": true,
    "defenderEnabled": true,
    "scheduledActionsForRule": [
        {
            "ruleName": "PasswordRequired",
            "scheduledActionConfigurations": [
                {
                    "actionType": "block",
                    "gracePeriodHours": 24,
                    "notificationTemplateId": "compliance-warning-template"
                }
            ]
        }
    ]
}

Pour les appareils non gérés par Intune — scénario fréquent pour les prestataires externes, les appareils personnels en BYOD ou les terminaux sous des systèmes d'exploitation non supportés — le Conditional Access offre des alternatives graduées. L'exigence d'une application protégée par des politiques MAM (Mobile Application Management) permet de sécuriser les données d'entreprise au niveau applicatif sans gérer l'appareil entier. Les Session Controls offrent une autre approche en limitant les actions possibles dans la session plutôt que de bloquer l'accès.

La stratégie de device compliance doit également prendre en compte les device filters, une fonctionnalité permettant de cibler ou exclure des appareils selon leurs attributs (modèle, fabricant, propriété, extension attributes). Les filtres d'appareils utilisent une syntaxe d'expression spécifique qui évalue les propriétés de l'objet appareil dans Entra ID. Par exemple, le filtre device.model -startsWith "Surface" cible uniquement les appareils Microsoft Surface, tandis que device.trustType -eq "ServerAD" cible les appareils joints via Hybrid Azure AD Join. Cette granularité permet des politiques différenciées par type de matériel — exiger des contrôles plus stricts sur les appareils mobiles que sur les stations de travail fixes, par exemple.

Politiques et règles

Session Controls : contrôle granulaire des sessions actives

Les Session Controls permettent de moduler le comportement d'une session après l'authentification, offrant un niveau de contrôle intermédiaire entre le blocage complet et l'accès sans restriction. Cette capacité est fondamentale pour les scénarios où l'organisation souhaite autoriser l'accès à une ressource tout en limitant ce que l'utilisateur peut faire pendant sa session.

Le Sign-in Frequency contrôle la durée après laquelle un utilisateur doit se réauthentifier. Par défaut, Entra ID maintient des sessions de longue durée grâce aux tokens de rafraîchissement (refresh tokens) dont la durée de vie peut atteindre 90 jours. Le Sign-in Frequency permet de réduire cette durée pour des applications sensibles ou des contextes à risque. Une configuration typique impose une réauthentification toutes les 4 heures pour les applications financières ou toutes les heures pour les portails d'administration. La valeur « Every time » force une authentification à chaque accès, mais son usage doit être limité aux cas les plus critiques pour ne pas dégrader l'expérience utilisateur au point de provoquer la fatigue MFA.

Le Persistent Browser Session contrôle si le navigateur conserve la session après sa fermeture. Par défaut, Entra ID propose le choix « Stay signed in? » (KMSI - Keep Me Signed In) qui, s'il est accepté par l'utilisateur, maintient la session. Le Session Control peut forcer le comportement en « Always persistent » ou « Never persistent », ce dernier étant recommandé pour les accès depuis des appareils partagés ou non gérés.

L'intégration avec Microsoft Defender for Cloud Apps (anciennement MCAS) débloque des contrôles de session avancés via le Conditional Access App Control. Ce mécanisme interpose un proxy inverse entre l'utilisateur et l'application, permettant l'inspection et le contrôle en temps réel du contenu échangé. Les capacités incluent le blocage du téléchargement de documents sensibles détectés par DLP, la prévention du copier-coller vers des applications non gérées, l'application de filigranes sur les documents visualisés, et le monitoring détaillé de toutes les actions effectuées dans la session.

# Configuration d'une politique Conditional Access avec Session Controls
# via Microsoft Graph API (PowerShell)

$policy = @{
    displayName = "Finance Apps - Session Restrictions"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @(
                "app-id-sap-finance",
                "app-id-erp-production"
            )
        }
        users = @{
            includeGroups = @("group-id-finance-team")
        }
        clientAppTypes = @("browser")
        locations = @{
            includeLocations = @("All")
            excludeLocations = @("named-location-id-bureaux")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "compliantDevice")
    }
    sessionControls = @{
        signInFrequency = @{
            value = 4
            type = "hours"
            isEnabled = $true
            authenticationType = "primaryAndSecondaryAuthentication"
            frequencyInterval = "timeBased"
        }
        persistentBrowser = @{
            mode = "never"
            isEnabled = $true
        }
        cloudAppSecurity = @{
            cloudAppSecurityType = "blockDownloads"
            isEnabled = $true
        }
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

Le Customize continuous access evaluation est un Session Control plus récent qui permet de désactiver sélectivement le CAE pour certains scénarios. Bien que cette option semble contre-intuitive — pourquoi désactiver un mécanisme de sécurité avancé ? — elle s'avère nécessaire dans certains cas de compatibilité applicative où le CAE provoque des déconnexions intempestives. La compréhension fine de cette option nécessite de maîtriser le fonctionnement du CAE, détaillé dans une section dédiée ci-après.

Analyse complémentaire

Les Application Enforced Restrictions délèguent le contrôle de session à l'application elle-même. SharePoint Online et Exchange Online supportent ce mécanisme et peuvent, lorsqu'il est activé, restreindre les fonctionnalités disponibles selon le contexte d'accès. Par exemple, SharePoint peut autoriser la consultation de documents en lecture seule depuis un navigateur non géré, tout en bloquant le téléchargement et la synchronisation via OneDrive. Ce contrôle est particulièrement utile dans les scénarios BYOD où l'on souhaite fournir un accès limité aux données sans exposer l'organisation au risque de fuite vers des appareils non contrôlés.

MFA Enforcement : stratégies d'authentification multifacteur

L'authentification multifacteur reste le contrôle d'accès le plus efficace en termes de ratio coût-bénéfice pour la protection contre la compromission de comptes. Microsoft estime que le MFA bloque 99,9% des attaques automatisées de compromission de comptes. Le Conditional Access offre une flexibilité considérable dans la manière dont le MFA est exigé, permettant d'adapter le niveau de friction à la sensibilité du contexte d'accès.

La stratégie MFA la plus couramment déployée en 2026 est l'exigence universelle : MFA pour tous les utilisateurs, toutes les applications, depuis toutes les localisations. Cette approche « MFA everywhere » est devenue la recommandation standard de Microsoft, matérialisée par les Security Defaults qui l'activent automatiquement pour les tenants sans licence premium. Cependant, les organisations disposant de licences Entra ID P1 ou P2 bénéficient d'un contrôle beaucoup plus granulaire via le Conditional Access.

L'évolution majeure de 2025-2026 concerne les Authentication Strengths, un mécanisme qui permet de spécifier non seulement que le MFA est requis, mais quel type de MFA est acceptable. Les Authentication Strengths prédéfinies incluent « MFA strength » (tout type de MFA), « Passwordless MFA strength » (Windows Hello, FIDO2, Certificate) et « Phishing-resistant MFA strength » (FIDO2, Certificate, Windows Hello uniquement). Les organisations peuvent également créer des Authentication Strengths personnalisées combinant les méthodes de leur choix.

Méthode d'authentification	MFA Strength	Passwordless MFA	Phishing-resistant	Résistance au phishing
SMS + mot de passe	Oui	Non	Non	Faible
Microsoft Authenticator push	Oui	Non	Non	Moyenne
Microsoft Authenticator passwordless	Oui	Oui	Non	Moyenne-haute
TOTP (application tierce)	Oui	Non	Non	Moyenne
Windows Hello for Business	Oui	Oui	Oui	Haute
Clé FIDO2	Oui	Oui	Oui	Très haute
Certificate-based auth (CBA)	Oui	Oui	Oui	Très haute
Passkeys (Authenticator)	Oui	Oui	Oui	Très haute

L'exigence de MFA résistant au phishing mérite une attention particulière pour les comptes à privilèges. Les attaques de type Adversary-in-the-Middle (AiTM) utilisant des frameworks comme Evilginx2 contournent efficacement le MFA basé sur SMS, TOTP et même Microsoft Authenticator push. Seules les méthodes liées cryptographiquement au domaine d'authentification — FIDO2, Windows Hello for Business, Certificate-based authentication — résistent à ces attaques. La politique recommandée pour les administrateurs globaux et les rôles privilégiés exige donc explicitement l'Authentication Strength « Phishing-resistant MFA ».

La MFA registration policy dans Conditional Access contrôle les conditions dans lesquelles un utilisateur peut enregistrer une nouvelle méthode MFA. Cette politique est distincte des politiques d'accès aux applications et cible l'action « Register security information ». Une configuration sécurisée exige que l'enregistrement MFA initial se fasse depuis un appareil conforme ou une localisation de confiance, empêchant un attaquant ayant compromis un mot de passe d'enregistrer sa propre méthode MFA depuis n'importe où. Ce scénario de « MFA registration hijack » est un vecteur d'attaque documenté que de nombreuses organisations négligent de protéger.

Analyse complémentaire

La fatigue MFA constitue un risque opérationnel réel. Des politiques trop agressives — MFA à chaque accès, sans mémoire de session, combinées à des applications déclenchant de multiples authentifications — conduisent les utilisateurs à approuver machinalement les demandes MFA, y compris celles initiées par un attaquant. Le number matching dans Microsoft Authenticator atténue ce risque en exigeant la saisie d'un code affiché à l'écran, mais la conception des politiques doit trouver l'équilibre entre sécurité et usabilité. L'utilisation du Sign-in Frequency combiné à des localisations de confiance permet de réduire le nombre de prompts MFA sans compromettre la sécurité. Pour une vue d'ensemble sur les architectures de sécurité multi-cloud intégrant le MFA, notre article sur la sécurisation des architectures multi-cloud apporte un éclairage complémentaire.

Risk-based Policies : intégration avec Identity Protection

Les politiques basées sur le risque exploitent les signaux de Microsoft Entra ID Protection pour adapter dynamiquement les exigences d'accès au niveau de menace détecté. Identity Protection analyse en permanence les connexions et les comptes pour identifier des comportements suspects, attribuant un niveau de risque « Low », « Medium » ou « High » qui peut ensuite être utilisé comme condition dans les politiques Conditional Access.

Le Sign-in Risk évalue la probabilité qu'une tentative de connexion spécifique ne soit pas initiée par le propriétaire légitime du compte. Les signaux analysés incluent les connexions depuis des adresses IP anonymes (Tor, VPN commerciaux), les déplacements impossibles (connexion depuis Paris puis Tokyo en 30 minutes), les propriétés de connexion inhabituelles (navigateur, système d'exploitation, localisation jamais utilisés), les adresses IP liées à des activités malveillantes connues, et les connexions depuis des environnements infectés par des malwares. Le niveau de risque est calculé en temps réel et influence la décision d'accès pour cette connexion spécifique.

Le User Risk évalue la probabilité que le compte d'un utilisateur soit compromis. Contrairement au Sign-in Risk qui est éphémère et lié à une tentative de connexion, le User Risk persiste jusqu'à ce qu'il soit remédié. Les signaux incluent la détection de credentials dans des fuites de données (dark web monitoring), des patterns de connexion anormaux sur une période étendue, et des activités suspectes dans la boîte mail (règles de transfert automatique, accès API anormal). Un User Risk élevé déclenche des actions de remédiation comme l'exigence de changement de mot de passe sécurisé ou le blocage complet du compte.

# Politique Conditional Access basée sur le risque
# Risque de connexion moyen ou élevé -> MFA obligatoire
$riskPolicy = @{
    displayName = "Sign-in Risk - Require MFA for Medium+ Risk"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @("All")
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-account-1-id", "break-glass-account-2-id")
        }
        signInRiskLevels = @("medium", "high")
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("mfa")
    }
}

# Risque utilisateur élevé -> Changement de mot de passe + MFA
$userRiskPolicy = @{
    displayName = "User Risk - Require Password Change for High Risk"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @("All")
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-account-1-id", "break-glass-account-2-id")
        }
        userRiskLevels = @("high")
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "passwordChange")
    }
}

La combinaison des politiques basées sur le risque avec les Authentication Strengths produit des configurations particulièrement robustes. Par exemple, une politique peut exiger le MFA standard pour un risque de connexion « Low », le MFA passwordless pour un risque « Medium », et le MFA phishing-resistant pour un risque « High ». Cette graduation proportionnelle adapte le niveau de friction au niveau de menace réel, offrant une expérience optimale pour les connexions légitimes tout en élevant les barrières face aux connexions suspectes.

Analyse complémentaire

L'intégration avec des solutions SIEM comme Microsoft Sentinel permet d'enrichir l'analyse des risques avec des signaux externes. Les alertes Identity Protection peuvent déclencher des playbooks automatisés qui investiguent l'activité du compte compromis, révoquent les sessions actives, notifient l'équipe sécurité et créent un incident de sécurité — le tout en quelques secondes après la détection. Cette orchestration est détaillée dans notre guide sur l'utilisation de l'IA dans les playbooks de réponse à incident.

Recommandation critique : Ne configurez JAMAIS les politiques basées sur le risque en mode « Block » pour le risque « Low ». Le taux de faux positifs à ce niveau est trop élevé et provoquerait des blocages massifs d'utilisateurs légitimes. Réservez le blocage au risque « High » et exigez le MFA pour le risque « Medium ». Le risque « Low » peut être traité par un Sign-in Frequency réduit.

Break-glass Accounts : comptes d'urgence et résilience

Les comptes break-glass (ou comptes d'accès d'urgence) sont des comptes administratifs hautement privilégiés conçus pour être utilisés exclusivement lorsque les mécanismes d'authentification normaux sont indisponibles. Leur conception et leur protection constituent un élément critique de la résilience opérationnelle du tenant Entra ID, et leur interaction avec le Conditional Access requiert une planification minutieuse.

Le scénario justifiant les comptes break-glass est celui d'un verrouillage total de l'administration du tenant. Les causes possibles incluent une panne du service MFA (indisponibilité de Microsoft Authenticator, panne réseau téléphonique empêchant la réception de SMS), une erreur de configuration Conditional Access bloquant tous les administrateurs, la compromission simultanée des comptes de tous les administrateurs, ou une défaillance de la fédération d'identités (ADFS, Okta) empêchant l'authentification. Sans comptes break-glass correctement configurés, ces scénarios nécessiteraient l'ouverture d'un ticket de support Microsoft — un processus qui peut prendre plusieurs heures, voire plusieurs jours.

La configuration recommandée prévoit deux comptes break-glass avec les caractéristiques suivantes. Les comptes sont des comptes cloud-only (non synchronisés depuis Active Directory) pour éliminer la dépendance à l'infrastructure on-premises. Ils portent le rôle Global Administrator assigné de manière permanente (pas via PIM) pour garantir l'accès immédiat. Les mots de passe sont longs (25+ caractères), aléatoires, et stockés en deux parties dans deux coffres-forts physiques distincts. Un des comptes utilise une clé FIDO2 comme méthode MFA (indépendante du service Authenticator), tandis que l'autre est exclu de toute politique MFA pour le cas où même FIDO2 serait indisponible.

# Exclusion des comptes break-glass de TOUTES les politiques Conditional Access
# Script d'audit PowerShell vérifiant les exclusions

$breakGlassAccounts = @(
    "bg-admin-01@contoso.onmicrosoft.com",
    "bg-admin-02@contoso.onmicrosoft.com"
)

$bgUserIds = $breakGlassAccounts | ForEach-Object {
    (Get-MgUser -Filter "userPrincipalName eq '$_'").Id
}

$policies = Get-MgIdentityConditionalAccessPolicy -All
$missingExclusions = @()

foreach ($policy in $policies) {
    if ($policy.State -eq "enabled") {
        $excludedUsers = $policy.Conditions.Users.ExcludeUsers
        foreach ($bgId in $bgUserIds) {
            if ($bgId -notin $excludedUsers) {
                $missingExclusions += [PSCustomObject]@{
                    PolicyName = $policy.DisplayName
                    PolicyId = $policy.Id
                    MissingAccount = $bgId
                }
            }
        }
    }
}

if ($missingExclusions.Count -gt 0) {
    Write-Warning "ALERTE: Comptes break-glass non exclus des politiques suivantes:"
    $missingExclusions | Format-Table -AutoSize
} else {
    Write-Host "OK: Tous les comptes break-glass sont correctement exclus." -ForegroundColor Green
}

Le monitoring des comptes break-glass est impératif. Toute connexion à ces comptes en dehors d'un exercice planifié constitue un incident de sécurité majeur. La configuration minimale inclut une alerte Azure Monitor déclenchée à chaque connexion réussie ou échouée sur ces comptes, une notification immédiate envoyée à plusieurs canaux (email, SMS, Teams, PagerDuty) pour éviter qu'une alerte unique soit ignorée, et une procédure d'investigation documentée qui vérifie la légitimité de la connexion, change les mots de passe et génère un rapport d'incident.

Détection et alerting

Les exercices de test des comptes break-glass doivent être réalisés trimestriellement. L'exercice vérifie que les mots de passe sont toujours valides, que les clés FIDO2 fonctionnent, que les exclusions Conditional Access sont en place, et que les alertes de monitoring se déclenchent correctement. Un compte break-glass qui n'a pas été testé depuis six mois offre un faux sentiment de sécurité — le mot de passe peut avoir expiré, la clé FIDO2 peut être défectueuse, ou une nouvelle politique Conditional Access peut avoir été créée sans l'exclusion appropriée.

Conditional Access pour les Workload Identities

L'extension du Conditional Access aux identités de charge de travail (Workload Identities) représente une avancée majeure dans la sécurisation des applications, services et automatisations qui accèdent aux ressources Microsoft. Jusqu'à récemment, les service principals et managed identities étaient exemptés du Conditional Access, créant un angle mort significatif dans la posture de sécurité. Les Workload Identities Conditional Access comblent cette lacune en permettant d'appliquer des politiques de localisation aux identités non humaines.

Les identités de charge de travail éligibles au Conditional Access incluent les single-tenant service principals (applications enregistrées dans le tenant) et les managed identities (system-assigned et user-assigned). Les applications multi-tenant tierces et les service principals créés par des connecteurs Microsoft ne sont pas encore couverts. Cette limitation est importante à comprendre car elle signifie que les applications SaaS accédant au tenant via leurs propres service principals restent hors du périmètre du Conditional Access pour workload identities.

Les conditions disponibles pour les politiques workload identities sont plus limitées que pour les identités utilisateur. En 2026, seules les conditions de localisation réseau (Named Locations) et de risque de service principal sont supportées. Les conditions de plateforme d'appareil, de compliance et de risque de connexion ne s'appliquent pas — logiquement, puisqu'une identité de charge de travail n'utilise pas un appareil au sens traditionnel. Le contrôle d'accès disponible est limité à Block — il n'est pas possible d'exiger le MFA pour un service principal.

# Politique Conditional Access pour Workload Identities
# Bloquer les service principals accédant depuis des IP non approuvées

$workloadPolicy = @{
    displayName = "Workload Identity - Block Non-Trusted Locations"
    state = "enabled"
    conditions = @{
        clientApplications = @{
            includeServicePrincipals = @("All")
            excludeServicePrincipals = @(
                "sp-id-azure-devops",
                "sp-id-github-actions"
            )
        }
        locations = @{
            includeLocations = @("All")
            excludeLocations = @("named-location-id-azure-datacenters", "named-location-id-bureaux")
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("block")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $workloadPolicy

Le risque de service principal est évalué par Microsoft Entra Workload ID, une fonctionnalité premium qui détecte les comportements anormaux des identités de charge de travail. Les signaux incluent les connexions depuis des localisations inhabituelles, les patterns d'accès anormaux (accès à des ressources jamais consultées), les credentials suspectes ajoutées à un service principal, et les activités consécutives à un ajout de credentials. L'intégration de ce risque dans les politiques Conditional Access permet de bloquer automatiquement un service principal compromis sans intervention humaine.

La gestion des credentials des workload identities constitue un défi opérationnel majeur. Les service principals utilisant des secrets clients (client secrets) sont particulièrement vulnérables car ces secrets, contrairement aux mots de passe utilisateur, ne bénéficient pas du MFA. La recommandation forte est de privilégier les managed identities lorsque la charge de travail s'exécute dans Azure (pas de credentials à gérer), les federated identity credentials pour les charges de travail externes (GitHub Actions, Kubernetes), et de n'utiliser les client secrets ou certificats qu'en dernier recours avec une rotation automatisée fréquente (90 jours maximum).

Automatisation

Continuous Access Evaluation (CAE) : évaluation en continu

Le Continuous Access Evaluation transforme fondamentalement le modèle de sécurité des tokens OAuth 2.0 en permettant la révocation quasi-instantanée des accès en réponse à des événements critiques. Sans CAE, un token d'accès OAuth est valide jusqu'à son expiration (typiquement 60-90 minutes), créant une fenêtre pendant laquelle un token volé peut être utilisé même après la détection de la compromission. Le CAE réduit cette fenêtre à quelques minutes en établissant un canal de communication bidirectionnel entre Entra ID et les resource providers.

L'architecture du CAE repose sur deux mécanismes complémentaires. L'évaluation d'événements critiques (critical event evaluation) permet à Entra ID de notifier les resource providers lorsqu'un événement de sécurité se produit sur un compte : désactivation du compte, changement de mot de passe, révocation des refresh tokens, activation d'un risque utilisateur élevé par Identity Protection. À la réception de cette notification, le resource provider invalide immédiatement les tokens d'accès existants et exige une nouvelle authentification. Ce mécanisme fonctionne pour Exchange Online, SharePoint Online, Teams et Microsoft Graph.

Le second mécanisme est l'évaluation de la localisation (IP address evaluation), qui vérifie en continu que l'adresse IP de la session correspond aux localisations autorisées par les politiques Conditional Access. Si un token d'accès est utilisé depuis une adresse IP qui n'est pas dans les Named Locations de confiance alors qu'une politique exige une localisation de confiance, le resource provider rejette la requête et force une réauthentification. Cette vérification se produit à chaque requête API, pas uniquement lors de l'authentification initiale.

// Vérification du support CAE dans un token d'accès
// Le claim "xms_cc" indique que le client supporte CAE

// Décodage du token JWT (JavaScript)
function checkCAESupport(accessToken) {
    const parts = accessToken.split('.');
    const payload = JSON.parse(atob(parts[1]));

    // Vérifier le claim xms_cc (client capabilities)
    if (payload.xms_cc && payload.xms_cc.includes("cp1")) {
        console.log("Token émis avec support CAE");
        console.log("Durée de vie étendue: ~28 heures (au lieu de 60-90 min)");
    } else {
        console.log("Token standard sans CAE");
        console.log("Durée de vie: 60-90 minutes");
    }

    // Vérifier la durée de vie
    const exp = new Date(payload.exp * 1000);
    const iat = new Date(payload.iat * 1000);
    const lifetime = (exp - iat) / (1000 * 60 * 60);
    console.log(`Durée de vie du token: ${lifetime.toFixed(1)} heures`);

    return payload;
}

Un aspect contre-intuitif du CAE est que les tokens compatibles CAE ont une durée de vie plus longue que les tokens standard — jusqu'à 28 heures au lieu de 60-90 minutes. Cette extension est sécurisée par le fait que la validité du token est vérifiée en continu, rendant la durée de vie nominale moins pertinente. Le bénéfice est une réduction significative du trafic d'authentification et une meilleure résilience en cas d'indisponibilité temporaire du service d'authentification.

Analyse complémentaire

Les limitations du CAE doivent être comprises pour éviter un faux sentiment de sécurité. Le CAE ne fonctionne qu'avec les applications qui le supportent — en 2026, cela couvre les applications Microsoft 365, Microsoft Graph API et les applications utilisant MSAL (Microsoft Authentication Library) avec le support CAE activé. Les applications tierces utilisant des tokens OAuth mais ne supportant pas les claims challenges du CAE continueront à fonctionner avec le modèle de token classique. De plus, le CAE ne couvre pas tous les types de tokens : les tokens SAML, par exemple, ne sont pas couverts, ce qui signifie que les applications fédérées utilisant SAML ne bénéficient pas de cette protection.

Le Strict location enforcement est une option CAE qui mérite une attention particulière. Lorsqu'elle est activée, elle applique rigoureusement les restrictions de localisation à chaque requête, même pour les applications qui ne supportent pas nativement le CAE. Cette stricte application peut provoquer des déconnexions inattendues lorsque l'adresse IP source change (basculement entre Wi-Fi et réseau mobile, par exemple) et doit être testée soigneusement avant le déploiement en production.

What If Tool : simulation et validation des politiques

Le What If Tool est l'outil de simulation intégré au portail Entra ID qui permet de prédire quelles politiques Conditional Access s'appliqueraient dans un scénario donné. Cet outil est indispensable pour valider la conception des politiques avant leur activation, pour diagnostiquer les problèmes d'accès des utilisateurs, et pour comprendre les interactions entre politiques multiples.

L'utilisation du What If Tool commence par la définition d'un scénario de simulation. Les paramètres configurables incluent l'utilisateur ou le service principal, l'application cloud cible, l'adresse IP source, la plateforme d'appareil, l'état de l'appareil (conforme, joint à Entra ID, joint en hybride), le niveau de risque de connexion et utilisateur, l'application cliente (navigateur, application mobile, client desktop) et le pays de connexion. Chaque paramètre influence l'évaluation des politiques, et la combinaison de tous les paramètres produit un résultat détaillé.

Le résultat de la simulation affiche trois catégories de politiques. Les politiques qui s'appliqueront (will apply) sont celles dont toutes les conditions sont satisfaites et dont les contrôles d'accès seront exigés. Les politiques qui ne s'appliqueront pas (will not apply) sont celles dont au moins une condition n'est pas satisfaite, avec l'indication de la condition spécifique qui exclut la politique. Les politiques en Report-only qui se seraient appliquées sont affichées séparément pour faciliter l'évaluation des politiques en phase de test.

# Simulation What If via Microsoft Graph API
# Utile pour l'automatisation des tests de politiques

$whatIfBody = @{
    conditionalAccessWhatIfConditions = @{
        userPrincipalName = "alice.dupont@contoso.com"
        cloudAppId = "00000003-0000-0000-c000-000000000000"  # Microsoft Graph
        ipAddress = "185.45.67.89"  # IP externe
        clientAppType = "browser"
        devicePlatform = "windows"
        country = "FR"
        signInRiskLevel = "low"
        userRiskLevel = "none"
        deviceInfo = @{
            isCompliant = $true
            trustType = "azureADJoined"
        }
    }
}

$result = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/evaluate" `
    -Body ($whatIfBody | ConvertTo-Json -Depth 10)

# Analyser les résultats
foreach ($policy in $result.appliedPolicies) {
    Write-Host "APPLIQUÉE: $($policy.displayName)" -ForegroundColor Yellow
    Write-Host "  Contrôles requis: $($policy.enforcedGrantControls -join ', ')"
    Write-Host "  Contrôles de session: $($policy.enforcedSessionControls -join ', ')"
}

foreach ($policy in $result.notAppliedPolicies) {
    Write-Host "NON APPLIQUÉE: $($policy.displayName)" -ForegroundColor Gray
    Write-Host "  Raison: $($policy.notAppliedReason)"
}

Au-delà du portail, le What If peut être invoqué programmatiquement via Microsoft Graph API (endpoint beta), permettant l'intégration dans des pipelines CI/CD. Cette approche est particulièrement précieuse pour les organisations qui gèrent leurs politiques Conditional Access en tant que code (Infrastructure as Code). Avant de déployer une modification de politique, un script de test automatisé exécute une batterie de scénarios What If couvrant les cas d'usage critiques et vérifie que les résultats attendus sont obtenus. Si un scénario produit un résultat inattendu — par exemple, un administrateur se retrouvant bloqué — le déploiement est interrompu automatiquement.

Automatisation

Les scénarios de test recommandés pour une validation complète incluent au minimum : l'accès d'un utilisateur standard depuis le réseau corporate, l'accès du même utilisateur depuis un réseau externe, l'accès d'un administrateur privilégié depuis chaque type de localisation, l'accès depuis un appareil non conforme, l'accès avec différents niveaux de risque, l'accès des comptes break-glass dans toutes les conditions, et l'accès des service principals depuis des IP attendues et inattendues. La constitution de cette matrice de test et son exécution systématique avant chaque changement de politique constituent une pratique DevSecOps mature.

Automatisation via Microsoft Graph API

La gestion des politiques Conditional Access via Microsoft Graph API est la méthode recommandée pour les organisations opérant à grande échelle ou adoptant une approche Infrastructure as Code. L'API permet la création, la lecture, la modification et la suppression de politiques, ainsi que la gestion des Named Locations et des Authentication Strengths, le tout de manière programmatique et reproductible.

L'approche Infrastructure as Code pour le Conditional Access s'articule typiquement autour d'un dépôt Git contenant les définitions JSON des politiques, un pipeline CI/CD qui déploie les modifications après validation, et un mécanisme de drift detection qui alerte lorsqu'une modification manuelle via le portail diverge de la définition en code. Cette approche élimine les modifications ad hoc non documentées, permet le rollback rapide en cas de problème, et fournit un historique d'audit complet des changements.

# Pipeline de déploiement Conditional Access (Azure DevOps / GitHub Actions)
# Étape 1 : Authentification avec un Service Principal

$clientId = $env:AZURE_CLIENT_ID
$clientSecret = $env:AZURE_CLIENT_SECRET
$tenantId = $env:AZURE_TENANT_ID

$tokenBody = @{
    grant_type    = "client_credentials"
    client_id     = $clientId
    client_secret = $clientSecret
    scope         = "https://graph.microsoft.com/.default"
}
$tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody
$accessToken = $tokenResponse.access_token

# Étape 2 : Lecture des politiques existantes
$headers = @{ Authorization = "Bearer $accessToken" }
$existingPolicies = (Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Headers $headers).value

# Étape 3 : Comparaison avec les définitions en code
$desiredPolicies = Get-ChildItem -Path "./policies/*.json" | ForEach-Object {
    Get-Content $_.FullName | ConvertFrom-Json
}

foreach ($desired in $desiredPolicies) {
    $existing = $existingPolicies | Where-Object { $_.displayName -eq $desired.displayName }

    if (-not $existing) {
        # Création d'une nouvelle politique en mode Report-only
        $desired.state = "enabledForReportingButNotEnforced"
        $body = $desired | ConvertTo-Json -Depth 10
        Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
            -Method POST -Headers $headers -ContentType "application/json" -Body $body
        Write-Host "CRÉÉE (Report-only): $($desired.displayName)"
    } else {
        # Mise à jour de la politique existante
        $body = $desired | ConvertTo-Json -Depth 10
        Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/$($existing.id)" `
            -Method PATCH -Headers $headers -ContentType "application/json" -Body $body
        Write-Host "MISE À JOUR: $($desired.displayName)"
    }
}

# Étape 4 : Détection des politiques non gérées (drift)
$managedNames = $desiredPolicies | ForEach-Object { $_.displayName }
$unmanagedPolicies = $existingPolicies | Where-Object { $_.displayName -notin $managedNames }

if ($unmanagedPolicies.Count -gt 0) {
    Write-Warning "DRIFT DÉTECTÉ: Politiques non gérées par le code:"
    $unmanagedPolicies | ForEach-Object { Write-Warning "  - $($_.displayName) [$($_.id)]" }
}

Les permissions Microsoft Graph nécessaires pour la gestion du Conditional Access sont Policy.Read.All et Policy.ReadWrite.ConditionalAccess pour les opérations de lecture et d'écriture. Pour les Named Locations, l'autorisation supplémentaire Policy.ReadWrite.AuthenticationMethod peut être nécessaire. Le service principal utilisé pour l'automatisation doit lui-même être exclu des politiques Conditional Access qui bloqueraient son fonctionnement — créant une dépendance circulaire qui doit être gérée avec précaution.

Politiques et règles

Le versioning des politiques mérite une attention particulière. Chaque modification doit transiter par un état Report-only avant l'activation en mode Enabled. Le pipeline de déploiement typique crée les nouvelles politiques en Report-only, attend une période d'observation (24-72 heures), analyse les Sign-in Logs pour vérifier l'impact potentiel, et ne passe en mode Enabled qu'après validation explicite. Cette approche progressive réduit considérablement le risque de blocage massif des utilisateurs suite à une erreur de configuration.

Pour les organisations multi-tenant (MSP, groupes internationaux), la gestion cross-tenant des politiques Conditional Access est possible via Microsoft Graph API avec des delegated permissions ou via Lighthouse pour les MSP. La standardisation des politiques entre tenants assure une posture de sécurité cohérente tout en permettant les adaptations locales nécessaires (Named Locations spécifiques à chaque pays, par exemple).

Erreurs courantes et anti-patterns du Conditional Access

L'implémentation du Conditional Access est jonchée de pièges qui peuvent compromettre la sécurité ou paralyser les opérations. L'identification et la prévention de ces erreurs communes est aussi importante que la maîtrise des fonctionnalités elles-mêmes. Voici les anti-patterns les plus fréquemment rencontrés en environnement de production, avec les solutions recommandées.

Anti-pattern 1 : l'absence de comptes break-glass. Étonnamment fréquent, ce scénario est découvert lorsque tous les administrateurs sont verrouillés suite à une modification de politique. La résolution implique un appel au support Microsoft avec vérification d'identité approfondie — un processus pouvant prendre 24 à 48 heures. La solution est triviale : créer deux comptes break-glass, les exclure de toutes les politiques, et tester trimestriellement leur fonctionnement.

Anti-pattern 2 : le « Block All » sans exclusion. Une politique bloquant « All users » sur « All cloud apps » sans exclusion des comptes break-glass verrouille immédiatement l'intégralité du tenant. Même en mode Report-only, une activation accidentelle (clic malheureux dans le portail) provoque une interruption totale. La solution consiste à toujours exclure les comptes break-glass et à utiliser un groupe d'exclusion dédié dont la modification est auditée et alertée.

Anti-pattern 3 : la confiance excessive dans la géolocalisation. Utiliser uniquement la restriction géographique comme contrôle d'accès est insuffisant. Les VPN commerciaux, les proxies résidentiels et les relais Tor permettent de simuler une connexion depuis n'importe quel pays. La géolocalisation est un signal complémentaire, pas un contrôle unique. Elle doit être combinée avec le MFA, la conformité d'appareil et l'évaluation du risque.

Anti-pattern 4 : les exclusions excessives. Chaque exclusion dans une politique Conditional Access est une brèche potentielle. Les demandes d'exclusion s'accumulent au fil du temps — un prestataire qui ne peut pas utiliser le MFA, une application legacy incompatible, un VIP qui refuse la friction — jusqu'à ce que la politique couvre moins de la moitié des utilisateurs. La solution est de refuser les exclusions permanentes, de n'accorder que des exclusions temporaires avec date d'expiration, et de les auditer mensuellement.

Anti-pattern 5 : l'ignorance des Legacy Authentication protocols. Les protocoles d'authentification legacy (SMTP, IMAP, POP3, ActiveSync avec Basic Auth) ne supportent pas le MFA et contournent donc toute politique MFA. Microsoft a désactivé Basic Auth pour la plupart des protocoles en 2023, mais certains tenants conservent des exceptions actives. Une politique explicite bloquant les « Other clients » et les « Exchange ActiveSync clients » utilisant Basic Auth est indispensable.

Politiques et règles

Anti-pattern 6 : la non-couverture des actions d'enregistrement. Les politiques couvrant « All cloud apps » ne couvrent PAS les actions « Register security information » et « Register or join devices ». Un attaquant ayant compromis un mot de passe peut enregistrer sa propre méthode MFA ou joindre un appareil au tenant si ces actions ne sont pas protégées par des politiques dédiées.

Erreur courante	Impact	Fréquence	Solution
Pas de comptes break-glass	Verrouillage total du tenant	Très fréquente	2 comptes exclus de toutes les politiques
Block All sans exclusion	Interruption de service immédiate	Fréquente	Groupe d'exclusion obligatoire audité
Géoloc comme seul contrôle	Contournement par VPN	Fréquente	Combiner avec MFA + compliance
Exclusions permanentes	Érosion progressive de la couverture	Très fréquente	Exclusions temporaires avec expiration
Legacy Auth non bloquée	Contournement du MFA	Fréquente	Politique Block explicite
Actions non couvertes	Enregistrement MFA non protégé	Fréquente	Politique dédiée pour les actions
Pas de monitoring Report-only	Activation aveugle avec impacts	Moyenne	Phase Report-only de 72h minimum
Named Locations obsolètes	Blocage des sites ou faux trusted	Moyenne	Revue mensuelle des IP ranges

Audit indispensable : Exécutez mensuellement un script qui vérifie que (1) les comptes break-glass sont exclus de TOUTES les politiques actives, (2) aucune politique active ne cible « All users » sans exclusion, (3) une politique bloque explicitement l'authentification legacy, (4) les actions d'enregistrement MFA et d'inscription d'appareils sont couvertes par des politiques dédiées.

Modèle de déploiement progressif en production

Le déploiement du Conditional Access en environnement de production exige une approche méthodique pour éviter les interruptions de service. Le modèle recommandé s'articule en cinq phases, chacune avec des critères de validation avant passage à la suivante.

Phase 1 — Inventaire et préparation (2-4 semaines). Cette phase consiste à cartographier l'existant : identifier toutes les applications cloud utilisées dans le tenant, recenser les flux d'authentification (utilisateurs interactifs, service principals, automatisations), documenter les protocoles d'authentification legacy encore actifs, et identifier les populations d'utilisateurs (internes, externes, prestataires, VIP). L'analyse des Sign-in Logs sur 30 jours fournit une base factuelle pour cette cartographie. Cette phase inclut également la création des comptes break-glass et la configuration des Named Locations.

Phase 2 — Politiques fondamentales en Report-only (2-4 semaines). Les politiques suivantes sont créées en mode Report-only : blocage de l'authentification legacy, MFA pour tous les utilisateurs sur toutes les applications, MFA phishing-resistant pour les rôles administratifs, blocage des connexions depuis des localisations non autorisées pour les administrateurs. Le mode Report-only permet d'observer l'impact potentiel dans les Sign-in Logs sans affecter les utilisateurs. Chaque politique est analysée quotidiennement pour identifier les utilisateurs qui auraient été bloqués ou qui auraient dû satisfaire des contrôles supplémentaires.

Phase 3 — Activation graduée (4-8 semaines). Les politiques sont activées une par une, en commençant par les moins impactantes. Le blocage de l'authentification legacy est généralement activé en premier car il affecte peu d'utilisateurs si la Phase 1 a correctement identifié les dépendances legacy. Le MFA pour les administrateurs est activé ensuite, suivi du MFA pour les utilisateurs standards. Chaque activation est suivie d'une période de stabilisation de 48-72 heures avec une surveillance renforcée des tickets de support et des alertes de blocage.

Phase 4 — Politiques avancées (4-8 semaines). Cette phase déploie les politiques de conformité d'appareil, les Session Controls, les politiques basées sur le risque et les politiques pour workload identities. Ces politiques sont plus complexes et nécessitent souvent des prérequis techniques (inscription des appareils dans Intune, déploiement de FIDO2, configuration d'Identity Protection). Le déploiement suit le même cycle Report-only puis activation.

Phase 5 — Optimisation continue (permanent). Les politiques sont révisées trimestriellement pour intégrer les nouvelles fonctionnalités, ajuster les seuils de risque, supprimer les exclusions expirées et adapter la couverture aux changements organisationnels. Les KPI suivis incluent le taux de couverture (pourcentage de connexions évaluées par au moins une politique), le taux de blocage (pourcentage de connexions bloquées), le taux de MFA (pourcentage de connexions nécessitant le MFA), et le nombre d'exclusions actives.

Politiques et règles

Ce modèle de déploiement s'applique aux environnements de toute taille, de la PME au grand groupe international. Pour les organisations déployant simultanément Conditional Access et une architecture de sécurité cloud complète, notre article sur les services de sécurité AWS essentiels offre un parallèle intéressant avec l'approche Microsoft.

Monitoring et reporting avancé des politiques

Le monitoring du Conditional Access ne se limite pas à vérifier que les politiques sont actives. Une stratégie de monitoring mature couvre la détection des anomalies d'authentification, le suivi des tendances d'utilisation, l'identification des politiques inefficaces et la conformité réglementaire. Les Sign-in Logs d'Entra ID constituent la source de données principale, enrichie par les Audit Logs pour le suivi des modifications de politiques.

Les Sign-in Logs capturent pour chaque tentative d'authentification le détail des politiques Conditional Access évaluées, avec leur résultat (Success, Failure, Not Applied) et les contrôles spécifiques exigés et satisfaits. Ces logs sont accessibles via le portail Entra ID, via Microsoft Graph API, et peuvent être exportés vers Azure Monitor, Log Analytics, Microsoft Sentinel, ou un SIEM externe via les Diagnostic Settings.

# Requêtes KQL pour le monitoring du Conditional Access dans Log Analytics

// Connexions bloquées par Conditional Access dans les 24 dernières heures
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "53003" // Blocked by Conditional Access
| summarize BlockCount = count() by UserPrincipalName, AppDisplayName,
    ConditionalAccessPolicies = tostring(ConditionalAccessPolicies)
| order by BlockCount desc
| take 20

// Politiques Conditional Access avec le plus de blocages (7 jours)
SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand ConditionalAccessPolicies
| extend PolicyName = tostring(ConditionalAccessPolicies.displayName),
         PolicyResult = tostring(ConditionalAccessPolicies.result)
| where PolicyResult == "failure"
| summarize FailureCount = count() by PolicyName
| order by FailureCount desc

// Détection des connexions sans aucune politique CA appliquée
SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "notApplied"
| where ResultType == "0" // Connexion réussie
| summarize Count = count() by UserPrincipalName, AppDisplayName,
    ClientAppUsed, DeviceDetail_browser = tostring(DeviceDetail.browser)
| where Count > 5
| order by Count desc

// Utilisation des comptes break-glass (alerte immédiate)
SigninLogs
| where TimeGenerated > ago(1h)
| where UserPrincipalName in ("bg-admin-01@contoso.onmicrosoft.com",
    "bg-admin-02@contoso.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress,
    Location, AppDisplayName, DeviceDetail

L'intégration avec Microsoft Sentinel permet de créer des règles analytiques spécifiques au Conditional Access. Les scénarios d'alerte recommandés incluent toute modification d'une politique Conditional Access (création, modification, suppression, changement d'état), toute connexion réussie sans politique CA appliquée pour un utilisateur privilégié, un volume anormal de blocages CA (potentiel indicateur d'attaque par force brute ou de misconfiguration), et toute connexion aux comptes break-glass. Pour approfondir la création de règles de détection dans un SIEM, consultez notre guide sur les use cases SIEM et règles de détection essentielles.

Le Conditional Access Insights Workbook dans Azure Monitor fournit des visualisations prêtes à l'emploi pour l'analyse de l'impact des politiques. Ce workbook affiche les tendances de connexions par politique, le détail des contrôles exigés versus satisfaits, et les populations d'utilisateurs affectées. Il est particulièrement utile pour la Phase 2 du déploiement (Report-only) car il permet de quantifier l'impact d'une politique avant son activation.

Politiques et règles

Conditional Access et Zero Trust : architecture de référence

Le Conditional Access constitue le plan de contrôle central d'une architecture Zero Trust basée sur l'écosystème Microsoft. Dans le modèle Zero Trust, chaque demande d'accès est évaluée explicitement en fonction de l'identité, de l'appareil, de la localisation, du contexte et de la sensibilité de la ressource — exactement ce que fait le Conditional Access. L'architecture de référence positionne le Conditional Access comme le point de décision politique (PDP) et les différents services Microsoft comme les points d'application politique (PEP).

L'architecture Zero Trust Microsoft s'articule autour de six piliers fondamentaux, chacun interagissant avec le Conditional Access. Le pilier Identités est couvert par les politiques d'authentification et de risque. Le pilier Appareils est couvert par les exigences de conformité et les filtres d'appareils. Le pilier Applications est couvert par les Session Controls et l'intégration avec Defender for Cloud Apps. Le pilier Données est couvert indirectement via les contrôles de session DLP et les Application Enforced Restrictions. Le pilier Infrastructure est couvert par les politiques pour workload identities. Le pilier Réseau est couvert par les Named Locations et l'intégration avec Global Secure Access.

La maturité Zero Trust d'une organisation peut être évaluée par la couverture et la sophistication de ses politiques Conditional Access. Le niveau initial couvre le MFA basique pour les administrateurs. Le niveau intermédiaire étend le MFA à tous les utilisateurs et ajoute la conformité d'appareil. Le niveau avancé intègre les politiques basées sur le risque, le CAE, les contrôles de session et les workload identities. Le niveau optimal ajoute le MFA phishing-resistant universel, le Global Secure Access, et l'automatisation complète via Graph API avec détection de drift.

L'intégration avec Global Secure Access (Security Service Edge de Microsoft) représente l'évolution la plus significative de l'architecture Zero Trust Microsoft en 2025-2026. Global Secure Access remplace le modèle traditionnel de VPN par un accès réseau Zero Trust (ZTNA) intégré nativement avec le Conditional Access. L'agent Global Secure Access installé sur les appareils établit un tunnel sécurisé vers le réseau Microsoft, permettant au Conditional Access de vérifier non seulement l'adresse IP mais aussi l'intégrité du canal de communication. Les « Compliant Network » Named Locations validées via Global Secure Access offrent une assurance nettement supérieure aux simples plages IP statiques.

Scénarios avancés et cas d'usage spécialisés

Au-delà des configurations standard, le Conditional Access offre des possibilités avancées pour des scénarios spécialisés. Ces configurations nécessitent une compréhension approfondie des interactions entre composants et sont fréquemment rencontrées dans les environnements d'entreprise complexes.

Scénario : accès aux ressources depuis des appareils partagés (kiosques, salles de réunion). Les appareils partagés posent un défi unique car ils sont utilisés par de multiples utilisateurs sans personnalisation. La stratégie recommandée combine plusieurs éléments : inscription de l'appareil partagé dans Intune avec un profil de kiosque dédié, création d'un device filter ciblant les appareils marqués comme « shared » dans les extension attributes, politique Conditional Access spécifique exigeant le MFA à chaque connexion (Sign-in Frequency = « Every time »), Session Controls forçant la session non persistante, et Application Enforced Restrictions limitant l'accès en lecture seule pour les données sensibles.

Scénario : accès des prestataires externes via B2B. Les utilisateurs B2B (invités) accèdent au tenant via leurs propres identités, ce qui signifie que leur MFA peut être géré par leur tenant d'origine ou par le tenant hébergeant les ressources. La politique recommandée exige le MFA dans le tenant ressource (pas de confiance dans le MFA du tenant invité) et restreint l'accès aux seules applications explicitement partagées. L'utilisation du Cross-tenant Access Settings permet de configurer la confiance MFA et device compliance par tenant partenaire pour les relations de confiance établies.

Scénario : protection des APIs et des automatisations. Les API exposées via Azure API Management ou directement par des applications peuvent être protégées par Conditional Access via l'authentification des service principals. La politique combine la restriction de localisation (seules les IP des environnements de déploiement autorisés) avec le risque de service principal. Pour les pipelines CI/CD utilisant GitHub Actions ou Azure DevOps, les federated identity credentials évitent la gestion de secrets tout en étant couverts par les politiques Conditional Access pour workload identities.

Scénario : conformité réglementaire (RGPD, NIS2, DORA). Les exigences réglementaires imposent souvent des contrôles d'accès spécifiques : authentification forte pour les systèmes traitant des données personnelles (RGPD), restrictions géographiques pour les systèmes critiques (NIS2), traçabilité complète des accès aux systèmes financiers (DORA). Le Conditional Access permet de traduire ces exigences en politiques techniques, tandis que les Sign-in Logs fournissent les preuves d'audit nécessaires. Notre article sur l'impact de DORA sur la finance en France détaille les exigences spécifiques du règlement et leur implémentation technique.

Politiques et règles

# Exemple de politique pour conformité DORA
# Systèmes financiers critiques : MFA phishing-resistant + appareil conforme
# + localisation de confiance + session courte

$doraPolicy = @{
    displayName = "DORA - Critical Financial Systems"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @(
                "app-id-core-banking",
                "app-id-trading-platform",
                "app-id-risk-management"
            )
        }
        users = @{
            includeGroups = @("group-id-finance-ops")
            excludeUsers = @("break-glass-1", "break-glass-2")
        }
        locations = @{
            includeLocations = @("All")
            # Uniquement depuis les bureaux et le datacenter
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("compliantDevice")
        authenticationStrength = @{
            id = "auth-strength-id-phishing-resistant"
        }
    }
    sessionControls = @{
        signInFrequency = @{
            value = 2
            type = "hours"
            isEnabled = $true
        }
        persistentBrowser = @{
            mode = "never"
            isEnabled = $true
        }
    }
}

FAQ

Quelle est la différence entre les Security Defaults et le Conditional Access dans Entra ID ?

Les Security Defaults constituent un ensemble prédéfini et non modifiable de politiques de sécurité activables en un clic, incluant le MFA obligatoire pour tous les utilisateurs, le blocage de l'authentification legacy et la protection des actions administratives. Le Conditional Access, disponible avec les licences Entra ID P1 et P2, offre une granularité totale : choix des utilisateurs, applications, conditions, contrôles d'accès et contrôles de session. Les Security Defaults et le Conditional Access sont mutuellement exclusifs — l'activation du Conditional Access désactive automatiquement les Security Defaults. Pour les organisations disposant de licences premium, le Conditional Access est systématiquement recommandé car il permet d'adapter les contrôles au contexte plutôt que d'appliquer une politique unique et rigide.

Comment protéger efficacement les comptes break-glass contre les abus tout en garantissant l'accès d'urgence ?

La protection des comptes break-glass repose sur un équilibre entre accessibilité d'urgence et prévention des abus. Les mots de passe doivent être longs (25+ caractères), aléatoires, et stockés physiquement dans deux coffres-forts distincts accessibles uniquement aux responsables désignés. Un des comptes utilise une clé FIDO2 physique stockée séparément du mot de passe. Les deux comptes sont exclus de toutes les politiques Conditional Access sans exception. Le monitoring est le contrôle principal : toute tentative de connexion (réussie ou échouée) déclenche une alerte immédiate sur plusieurs canaux (email, SMS, Teams, PagerDuty). Les comptes sont testés trimestriellement dans un exercice documenté. L'accès au coffre-fort est lui-même audité et nécessite l'approbation de deux personnes distinctes (double custody).

Le Continuous Access Evaluation (CAE) remplace-t-il la nécessité de configurer le Sign-in Frequency ?

Non, le CAE et le Sign-in Frequency couvrent des scénarios complémentaires. Le CAE permet la révocation quasi-instantanée des tokens en réponse à des événements critiques (désactivation du compte, changement de mot de passe, changement de localisation), mais il ne force pas de réauthentification périodique. Le Sign-in Frequency, lui, force une réauthentification à intervalles réguliers indépendamment de tout événement de sécurité — ce qui est pertinent pour les applications sensibles nécessitant une vérification régulière de la présence de l'utilisateur. De plus, le CAE ne fonctionne qu'avec les applications qui le supportent (Microsoft 365, Graph API), tandis que le Sign-in Frequency s'applique à toute application protégée par Entra ID. Les deux mécanismes doivent être configurés conjointement pour une protection complète.

Comment gérer le Conditional Access dans un environnement multi-tenant avec des identités B2B ?

La gestion multi-tenant du Conditional Access implique plusieurs niveaux de configuration. Dans le tenant ressource (celui qui héberge les applications), les politiques Conditional Access s'appliquent aux utilisateurs B2B invités de la même manière qu'aux utilisateurs internes — sauf si des conditions spécifiques les excluent ou les ciblent via le filtre « Guest or external users ». Le Cross-tenant Access Settings permet de configurer la confiance MFA entre tenants : si vous faites confiance au MFA du tenant partenaire, l'utilisateur B2B n'aura pas à refaire le MFA dans votre tenant. Pour les organisations multi-tenant appartenant au même groupe, le Cross-tenant Synchronization automatise la gestion des identités B2B et permet d'appliquer des politiques Conditional Access cohérentes. La recommandation par défaut est de ne PAS faire confiance au MFA des tenants externes sauf en cas de relation de partenariat formelle avec vérification de la posture de sécurité du partenaire.

Renforcement de la sécurité

Quelles sont les limitations du What If Tool et comment les contourner ?

Le What If Tool présente plusieurs limitations significatives. Il ne simule pas le Continuous Access Evaluation — il montre uniquement la décision au moment de l'authentification initiale, pas les révocations en cours de session. Il ne prend pas en compte les Authentication Context, une fonctionnalité permettant d'associer des labels de sensibilité aux applications. Il ne simule pas les interactions avec les politiques MAM (Mobile Application Management) d'Intune. Il ne permet pas de simuler des scénarios avec des niveaux de risque futurs — uniquement le risque actuel du compte. Pour contourner ces limitations, combinez le What If Tool avec l'analyse des Sign-in Logs en mode Report-only pour les scénarios complexes, utilisez l'API Graph pour automatiser des batteries de tests couvrant de multiples combinaisons de paramètres, et maintenez un tenant de test miroir du tenant de production pour les validations les plus critiques.

Comment détecter et prévenir le contournement du Conditional Access par des applications legacy ?

Les applications legacy utilisant l'authentification basique (Basic Authentication) contournent le MFA car ces protocoles ne supportent pas l'authentification interactive nécessaire au challenge MFA. La détection commence par l'analyse des Sign-in Logs filtrés sur les client app types « Exchange ActiveSync », « IMAP4 », « POP3 », « SMTP » et « Other clients ». Toute connexion réussie avec ces types de clients depuis un compte qui devrait être soumis au MFA indique un contournement. La prévention est double : premièrement, créer une politique Conditional Access explicite bloquant tous les « Legacy authentication clients » pour tous les utilisateurs ; deuxièmement, désactiver les protocoles legacy au niveau du service (Exchange Online, par exemple) via les Authentication Policies. La migration des applications dépendantes vers des protocoles modernes (OAuth 2.0) doit être planifiée comme prérequis, avec un suivi des exceptions temporaires via un processus formel.

Quelle est la stratégie recommandée pour le déploiement du MFA phishing-resistant à grande échelle ?

Le déploiement du MFA phishing-resistant (FIDO2, Windows Hello for Business, Certificate-based Authentication) à grande échelle nécessite une approche pragmatique en vagues. La première vague cible les comptes à privilèges (Global Administrators, rôles d'administration Exchange, SharePoint, Security) qui représentent la surface d'attaque la plus critique — typiquement 50 à 200 comptes. La deuxième vague étend aux utilisateurs manipulant des données sensibles (finance, RH, juridique). La troisième vague couvre l'ensemble des utilisateurs. Pour chaque vague, le processus inclut la distribution des clés FIDO2 ou la configuration de Windows Hello, l'enregistrement supervisé des méthodes d'authentification, une période de coexistence où le MFA standard et le MFA phishing-resistant sont tous deux acceptés, puis la restriction via Authentication Strength pour n'accepter que le MFA phishing-resistant. Le coût des clés FIDO2 (25-50 euros par clé, deux clés par utilisateur recommandées) doit être budgété. Windows Hello for Business est une alternative sans coût matériel supplémentaire pour les postes Windows 10/11 gérés.

Comment intégrer le Conditional Access avec des solutions IAM tierces comme Okta ou Ping Identity ?

L'intégration avec des solutions IAM tierces s'effectue principalement via la fédération d'identités. Lorsque Entra ID est configuré pour fédérer l'authentification vers un IdP tiers (Okta, Ping Identity, OneLogin), les politiques Conditional Access d'Entra ID s'appliquent après l'authentification par l'IdP tiers. Cela signifie que le MFA peut être géré par l'IdP tiers et validé par Entra ID via les claims du token SAML. Cependant, les politiques basées sur le risque d'Identity Protection sont limitées car Entra ID ne dispose pas des signaux d'authentification gérés par l'IdP tiers. L'intégration optimale utilise le protocole WS-Federation ou SAML 2.0 pour la fédération, configure les policies Conditional Access pour exiger des claims spécifiques émis par l'IdP tiers (amr claim indiquant le type de MFA effectué), et complète avec des politiques basées sur la localisation et la conformité d'appareil qui ne dépendent pas de l'IdP. Pour les organisations en migration d'un IAM tiers vers Entra ID, la période de coexistence nécessite une attention particulière aux doublons de politiques qui pourraient créer des conflits.

Authentication Context et classifications de sensibilité

L'Authentication Context (contexte d'authentification) est une fonctionnalité avancée du Conditional Access qui permet d'associer des niveaux de sensibilité aux actions spécifiques au sein d'une application, plutôt qu'à l'application entière. Ce mécanisme résout le problème des applications multi-fonctions où certaines actions (consulter un document public) ne nécessitent pas le même niveau de sécurité que d'autres (modifier un document confidentiel). L'Authentication Context permet d'exiger des contrôles d'accès supplémentaires uniquement lors de l'exécution d'actions sensibles, sans imposer ces contrôles pour l'accès à l'application elle-même.

Le fonctionnement repose sur la définition de contextes d'authentification dans Entra ID (jusqu'à 25 contextes personnalisables, identifiés C1 à C25) et leur association à des politiques Conditional Access spécifiques. Lorsqu'une application détermine qu'une action nécessite un niveau d'authentification supérieur, elle émet un claims challenge contenant l'identifiant du contexte requis. Le navigateur ou l'application cliente redirige l'utilisateur vers Entra ID pour satisfaire les contrôles associés à ce contexte, puis l'utilisateur retourne à l'application avec un token enrichi du claim prouvant la satisfaction du contexte.

# Configuration d'Authentication Context via Graph API

# 1. Créer un contexte d'authentification
$authContext = @{
    id = "c1"
    displayName = "Accès données confidentielles"
    description = "Contexte requis pour les actions sur les données classifiées Confidentiel"
    isAvailable = $true
}
Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/authenticationContextClassReferences" `
    -Body ($authContext | ConvertTo-Json)

# 2. Créer une politique CA ciblant ce contexte
$contextPolicy = @{
    displayName = "Require Phishing-Resistant MFA for Confidential Data"
    state = "enabled"
    conditions = @{
        applications = @{
            includeAuthenticationContextClassReferences = @("c1")
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-1", "break-glass-2")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("compliantDevice")
        authenticationStrength = @{
            id = "phishing-resistant-mfa-strength-id"
        }
    }
    sessionControls = @{
        signInFrequency = @{
            value = 1
            type = "hours"
            isEnabled = $true
        }
    }
}

# 3. Association avec Microsoft Purview Information Protection
# Les labels de sensibilité Microsoft Purview peuvent être liés aux Authentication Contexts
# Label "Confidentiel" -> Authentication Context C1
# Tout accès à un document labellisé "Confidentiel" dans SharePoint/OneDrive
# déclenchera la politique Conditional Access associée à C1

L'intégration avec Microsoft Purview Information Protection représente le cas d'usage le plus puissant de l'Authentication Context. Les labels de sensibilité (Public, Interne, Confidentiel, Hautement Confidentiel) peuvent être associés à des Authentication Contexts, créant un lien direct entre la classification des données et les exigences d'accès. Un document labellisé « Hautement Confidentiel » dans SharePoint Online déclenchera automatiquement l'Authentication Context correspondant, exigeant par exemple un MFA phishing-resistant, un appareil conforme et une localisation de confiance — même si l'accès initial à SharePoint n'exigeait qu'un MFA standard.

Les applications personnalisées peuvent également exploiter l'Authentication Context en implémentant le mécanisme de claims challenge. Lorsqu'un utilisateur tente d'effectuer une action sensible (approuver une transaction financière, modifier des paramètres de sécurité, accéder à des données médicales), l'application déclenche un challenge insufficient_claims avec le contexte requis. La bibliothèque MSAL gère automatiquement la redirection vers Entra ID et le renouvellement du token avec les claims nécessaires. Ce mécanisme est transparent pour l'utilisateur qui voit simplement une demande d'authentification supplémentaire lors des actions sensibles.

Token Protection et Proof of Possession

Le Token Protection (anciennement Token Binding) est une fonctionnalité de Conditional Access qui lie cryptographiquement un token d'accès à l'appareil qui l'a demandé. Cette liaison empêche le vol de token par relais (token replay attack) car un token volé ne peut pas être utilisé depuis un autre appareil — sa validité est liée à la clé cryptographique de l'appareil d'origine.

Le mécanisme sous-jacent repose sur le Proof of Possession (PoP). Lors de l'authentification initiale, l'appareil génère une paire de clés RSA éphémère et inclut la clé publique dans la requête de token. Le token d'accès émis par Entra ID est signé avec cette clé publique (encodée dans le claim cnf — confirmation). À chaque utilisation du token, l'appareil doit prouver qu'il possède la clé privée correspondante en signant un nonce fourni par le resource provider. Un attaquant qui intercepte le token ne peut pas reproduire cette preuve de possession sans accès à la clé privée stockée sur l'appareil d'origine.

# Politique Conditional Access avec Token Protection
$tokenProtectionPolicy = @{
    displayName = "Require Token Protection for Exchange Online"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @(
                "00000002-0000-0ff1-ce00-000000000000"  # Exchange Online
            )
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-1", "break-glass-2")
        }
        clientAppTypes = @("browser", "mobileAppsAndDesktopClients")
    }
    sessionControls = @{
        signInTokenProtection = @{
            isEnforceable = $true
            tokenType = "accessToken"
            isEnabled = $true
        }
    }
}

# Vérification dans le token JWT
# Un token avec Token Protection contient le claim "cnf":
# {
#   "cnf": {
#     "kid": "device-key-id",
#     "xms_ksl": "sw"  // sw = software key, hw = hardware (TPM)
#   }
# }
# Le resource provider vérifie la preuve de possession à chaque requête

Le Token Protection est particulièrement pertinent pour contrer les attaques Adversary-in-the-Middle (AiTM) et le vol de tokens via des malwares. Dans un scénario AiTM classique avec Evilginx2, l'attaquant intercepte le token de session après que l'utilisateur a complété le MFA. Sans Token Protection, ce token est immédiatement utilisable depuis la machine de l'attaquant. Avec Token Protection, le token est lié à la clé de l'appareil de l'utilisateur légitime et ne peut pas être rejoué depuis un autre appareil. Cette protection complète le MFA phishing-resistant en ajoutant une couche de défense même dans le cas où le MFA est contourné.

Les limitations actuelles du Token Protection incluent sa compatibilité : en 2026, il est supporté pour les connexions de bureau (Windows avec le navigateur Edge ou les applications Microsoft 365) et partiellement pour les applications mobiles. Les clients legacy, les applications tierces et certains navigateurs ne supportent pas encore le mécanisme de preuve de possession. La politique doit donc être déployée avec des conditions ciblant les plateformes compatibles, sous peine de bloquer les accès depuis des clients non supportés.

Global Secure Access : convergence réseau et identité

Microsoft Global Secure Access (anciennement Entra Internet Access et Entra Private Access) représente l'évolution architecturale la plus significative de l'écosystème Conditional Access en 2025-2026. Cette solution Security Service Edge (SSE) intègre les fonctionnalités de Secure Web Gateway (SWG), Zero Trust Network Access (ZTNA) et Cloud Access Security Broker (CASB) directement dans le tissu d'identité Microsoft Entra, créant une convergence sans précédent entre le plan de contrôle réseau et le plan de contrôle d'identité.

L'agent Global Secure Access, installé sur les appareils gérés, établit un tunnel sécurisé vers le réseau Microsoft pour le trafic sélectionné (Microsoft 365, applications privées, ou tout le trafic Internet). Ce tunnel permet à Conditional Access de vérifier non seulement l'identité de l'utilisateur mais aussi l'intégrité du chemin réseau emprunté par la requête. Les Compliant Network Named Locations, basées sur la validation du tunnel Global Secure Access, offrent une assurance réseau nettement supérieure aux simples vérifications d'adresse IP qui peuvent être contournées par des proxies ou VPN.

L'intégration de Global Secure Access avec Conditional Access se manifeste à travers plusieurs mécanismes complémentaires. Les Security Profiles de Global Secure Access sont déclenchés par les politiques Conditional Access, créant un chaînage où la décision d'accès conditionnel détermine le profil de sécurité réseau appliqué à la session. Les politiques de filtrage web, de DLP inline et de contrôle d'accès aux applications privées sont orchestrées par les mêmes conditions (utilisateur, appareil, localisation, risque) que les politiques Conditional Access traditionnelles.

# Architecture Global Secure Access + Conditional Access

# 1. Politique CA exigeant un réseau conforme (Compliant Network)
$gsaPolicy = @{
    displayName = "Require Compliant Network for Microsoft 365"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @("Office365")
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @("break-glass-1", "break-glass-2")
            excludeGroups = @("group-excluded-from-gsa")
        }
        locations = @{
            includeLocations = @("All")
            excludeLocations = @("AllTrusted")  # AllTrusted inclut Compliant Network
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("compliantDevice")
        # OU l'appareil est conforme, OU il passe par Compliant Network
    }
}

# 2. Traffic forwarding profile pour Microsoft 365
# Configure quels flux transitent par le tunnel Global Secure Access:
# - Microsoft 365 traffic (Exchange, SharePoint, Teams)
# - Private Access traffic (applications internes)
# - Internet Access traffic (navigation web générale)

# 3. Conditional Access pour Private Access (ZTNA)
# Remplace le VPN traditionnel par un accès Zero Trust aux applications internes
$privateAccessPolicy = @{
    displayName = "Private App Access - Require Device Compliance + MFA"
    state = "enabled"
    conditions = @{
        applications = @{
            includeApplications = @("private-app-segment-id")
        }
        users = @{
            includeGroups = @("group-private-app-users")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "compliantDevice")
    }
    sessionControls = @{
        signInFrequency = @{
            value = 8
            type = "hours"
            isEnabled = $true
        }
    }
}

La valeur de Global Secure Access pour le Conditional Access réside dans la résolution de trois problèmes historiques. Premièrement, la dépendance aux adresses IP statiques pour les Named Locations : avec le travail hybride, les utilisateurs se connectent depuis des adresses IP dynamiques rendant les politiques de localisation IP inefficaces. Le Compliant Network vérifie la présence du tunnel plutôt que l'adresse IP. Deuxièmement, l'absence de visibilité sur le trafic réseau post-authentification : Global Secure Access inspecte le trafic en continu, pas uniquement au moment de l'authentification. Troisièmement, la nécessité d'un VPN pour accéder aux applications internes : Private Access offre un ZTNA natif intégré à Conditional Access, éliminant les VPN et leur surface d'attaque associée.

Troubleshooting avancé des politiques Conditional Access

Le diagnostic des problèmes d'accès liés au Conditional Access requiert une méthodologie rigoureuse et la maîtrise de plusieurs outils complémentaires. Les Sign-in Logs constituent la source de données principale, mais leur interprétation demande une compréhension fine des codes d'erreur, des états de politique et des interactions entre conditions.

Les codes d'erreur les plus fréquents liés au Conditional Access sont documentés mais leur interprétation en contexte peut être complexe. Le code 53000 indique que l'appareil doit être conforme ou joint à Entra ID. Le code 53001 signifie que l'appareil n'est pas conforme selon Intune. Le code 53003 indique un accès bloqué par une politique Conditional Access. Le code 530003 apparaît lorsqu'un appareil doit être conforme mais ne l'est pas encore (synchronisation Intune en attente). Le code 700082 signale un refresh token expiré qui nécessite une réauthentification interactive. La distinction entre ces codes permet de diriger rapidement l'investigation vers la bonne cause racine.

# Diagnostic avancé via PowerShell et Graph API

# 1. Récupérer les détails d'une connexion spécifique avec le résultat CA
$signIn = Get-MgAuditLogSignIn -Filter "id eq 'sign-in-event-id'"

# Analyser les politiques appliquées
$signIn.ConditionalAccessPolicies | ForEach-Object {
    Write-Host "Politique: $($_.DisplayName)"
    Write-Host "  Résultat: $($_.Result)"  # success, failure, notApplied
    Write-Host "  Contrôles de session: $($_.EnforcedSessionControls)"
    Write-Host "  Contrôles d'accès: $($_.EnforcedGrantControls)"
    Write-Host "  Conditions non satisfaites: $($_.ConditionsNotSatisfied)"
    Write-Host "  Conditions satisfaites: $($_.ConditionsSatisfied)"
    Write-Host ""
}

# 2. Requête KQL pour identifier la cause exacte d'un blocage
# SigninLogs
# | where TimeGenerated > ago(1h)
# | where UserPrincipalName == "user@example.com"
# | where ResultType != "0"
# | extend CADetails = parse_json(ConditionalAccessPolicies)
# | mv-expand CADetails
# | where CADetails.result == "failure"
# | project TimeGenerated, UserPrincipalName, AppDisplayName,
#           PolicyName = tostring(CADetails.displayName),
#           GrantControls = tostring(CADetails.enforcedGrantControls),
#           ConditionsNotMet = tostring(CADetails.conditionsNotSatisfied),
#           ResultType, ResultDescription,
#           DeviceDetail, LocationDetails, ClientAppUsed

# 3. Vérification de l'état de conformité d'un appareil
$device = Get-MgDevice -Filter "displayName eq 'LAPTOP-USER01'"
$device | Select-Object DisplayName, IsCompliant, TrustType,
    ApproximateLastSignInDateTime, OperatingSystem, OperatingSystemVersion

# 4. Vérification du statut MFA d'un utilisateur
$authMethods = Get-MgUserAuthenticationMethod -UserId "user@example.com"
$authMethods | ForEach-Object {
    Write-Host "$($_.AdditionalProperties['@odata.type'])"
}

# 5. Simulation What If pour reproduire le scénario exact
# Reproduire les conditions exactes de la connexion échouée
# en utilisant les paramètres extraits des Sign-in Logs

Les scénarios de troubleshooting les plus complexes impliquent des interactions entre plusieurs politiques. Un utilisateur peut être bloqué non pas par une seule politique mais par l'agrégation de contrôles de plusieurs politiques dont la satisfaction simultanée est impossible. Par exemple, une politique exigeant un appareil conforme ET une autre exigeant une application approuvée (qui ne fonctionne que sur des appareils non gérés) créent un conflit logique : l'utilisateur ne peut satisfaire les deux conditions simultanément. L'identification de ces conflits nécessite la visualisation de toutes les politiques applicables et de leurs contrôles agrégés.

Le Sign-in diagnostic intégré dans le portail Entra ID simplifie le troubleshooting en analysant automatiquement un événement de connexion et en fournissant une explication en langage naturel de la cause du blocage, avec des recommandations de résolution. Cet outil est particulièrement utile pour les équipes support de niveau 1 qui n'ont pas la connaissance approfondie de toutes les politiques Conditional Access mais doivent résoudre rapidement les problèmes d'accès des utilisateurs.

Pour les organisations gérant un grand nombre de politiques, la visualisation sous forme de matrice (utilisateurs × applications × conditions = contrôles) permet d'identifier les zones de couverture insuffisante et les conflits potentiels. Des outils tiers comme Conditional Access Policy Documentor et les workbooks Azure Monitor personnalisés fournissent ces visualisations qui ne sont pas disponibles nativement dans le portail Entra ID.

Méthodologie de troubleshooting : Face à un blocage Conditional Access, suivez cette séquence : (1) Identifier l'événement dans les Sign-in Logs par corrélation ID. (2) Examiner le code d'erreur (ResultType) et sa description. (3) Lister toutes les politiques avec Result=failure et leurs conditions non satisfaites. (4) Vérifier l'état de l'appareil (conformité, trust type) dans Entra ID. (5) Vérifier les méthodes MFA enregistrées de l'utilisateur. (6) Reproduire avec le What If tool. (7) Si le problème est intermittent, vérifier le CAE et la propagation de la conformité Intune.

Conclusion : feuille de route Conditional Access 2026

La maîtrise du Conditional Access dans Entra ID est devenue une compétence incontournable pour tout architecte sécurité opérant dans l'écosystème Microsoft. L'évolution constante des fonctionnalités — Continuous Access Evaluation, Authentication Strengths, Workload Identities, Global Secure Access — exige une veille technique permanente et une adaptation régulière des politiques déployées. Les organisations les plus matures traitent leurs politiques Conditional Access comme du code versionné, testé et déployé via des pipelines automatisés, avec un monitoring continu des indicateurs de couverture et d'efficacité. Cette approche DevSecOps appliquée à la gestion des identités constitue le fondement opérationnel d'une architecture Zero Trust réellement efficace, où chaque accès est évalué dynamiquement en fonction du contexte complet de la requête plutôt que de la seule présentation d'un mot de passe.

Partager cet article

Twitter LinkedIn

Télécharger cet article en PDF

Format A4 optimisé pour l'impression et la lecture hors ligne

Télécharger le PDF

À propos de l'auteur

Ayi NEDJIMI

Auditeur Senior Cybersécurité & Consultant IA

Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense

ayi@ayinedjimi-consultants.fr

25+

ans d'expérience

700+

articles publiés

100+

missions réalisées

Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.

À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.

Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.

Domaines d'expertise

ISO 42001 Lead Auditor ISO 27001 · NIS2 Pentest & Forensics IA / LLM / RAG Cloud & Active Directory

Voir le profil complet Demander un devis

Ressources & Outils de l'auteur

GitHub

Code & projets open source

Hugging Face

Modèles IA & datasets

CertifExpress

Préparez vos certifications IT

WindowsBooster

Optimisation Windows 11

Testez vos connaissances

Mini-quiz de certification lié à cet article — propulsé par CertifExpress

Articles connexes

Audit Sécurité Pipeline CI/CD : SAST, DAST, SCA Intégrés

Les pipelines CI/CD constituent désormais le système nerveux central de toute organisation logicielle. Chaque commit déclenche une cascade d'opérations automatisées — compilation, tests, analyse, déploiement — qui transforme du code source en artefacts de production en quelques minutes. Cette vélocité...

30/04/2026

Cloud IAM : AWS IAM vs Azure RBAC vs GCP IAM — Comparatif

La gestion des identités et des accès (IAM) dans le cloud public est devenue en 2026 le domaine le plus complexe et le plus critique de la sécurité informatique. Les trois hyperscalers — AWS, Azure et Google Cloud Platform —...

29/04/2026

Kubernetes RBAC : Guide Sécurisation des Permissions

Le contrôle d'accès basé sur les rôles (RBAC) dans Kubernetes constitue le mécanisme fondamental de gouvernance des permissions au sein d'un cluster. Chaque requête adressée à l'API Server — qu'elle provienne d'un administrateur exécutant kubectl, d'un pod accédant à des...

28/04/2026

Article précédent

Glossaire Active Directory : 100 Termes Sécurité et Attaques

Article suivant

IDOR : Exploitation et Défense des Références Directes

Commentaires

Aucun commentaire pour le moment. Soyez le premier à commenter !

Laisser un commentaire

Conditional Access Azure : Guide Complet Entra ID 2026

Architecture fondamentale du Conditional Access dans Entra ID

Named Locations : géolocalisation et réseaux de confiance

Politiques et règles

Device Compliance : intégration avec Microsoft Intune

Politiques et règles

Session Controls : contrôle granulaire des sessions actives

Analyse complémentaire

MFA Enforcement : stratégies d'authentification multifacteur

Analyse complémentaire

Risk-based Policies : intégration avec Identity Protection

Analyse complémentaire

Break-glass Accounts : comptes d'urgence et résilience

Détection et alerting

Conditional Access pour les Workload Identities

Automatisation

Continuous Access Evaluation (CAE) : évaluation en continu

Analyse complémentaire

What If Tool : simulation et validation des politiques

Automatisation

Automatisation via Microsoft Graph API

Politiques et règles

Erreurs courantes et anti-patterns du Conditional Access

Politiques et règles

Modèle de déploiement progressif en production

Politiques et règles

Monitoring et reporting avancé des politiques

Politiques et règles

Conditional Access et Zero Trust : architecture de référence

Scénarios avancés et cas d'usage spécialisés

Politiques et règles

FAQ

Quelle est la différence entre les Security Defaults et le Conditional Access dans Entra ID ?

Comment protéger efficacement les comptes break-glass contre les abus tout en garantissant l'accès d'urgence ?

Le Continuous Access Evaluation (CAE) remplace-t-il la nécessité de configurer le Sign-in Frequency ?

Comment gérer le Conditional Access dans un environnement multi-tenant avec des identités B2B ?

Renforcement de la sécurité

Quelles sont les limitations du What If Tool et comment les contourner ?

Comment détecter et prévenir le contournement du Conditional Access par des applications legacy ?

Quelle est la stratégie recommandée pour le déploiement du MFA phishing-resistant à grande échelle ?

Comment intégrer le Conditional Access avec des solutions IAM tierces comme Okta ou Ping Identity ?

Authentication Context et classifications de sensibilité

Token Protection et Proof of Possession

Global Secure Access : convergence réseau et identité

Troubleshooting avancé des politiques Conditional Access

Conclusion : feuille de route Conditional Access 2026

À propos de l'auteur

Ayi NEDJIMI

Ressources & Outils de l'auteur

Testez vos connaissances

Articles connexes

Audit Sécurité Pipeline CI/CD : SAST, DAST, SCA Intégrés

Cloud IAM : AWS IAM vs Azure RBAC vs GCP IAM — Comparatif

Kubernetes RBAC : Guide Sécurisation des Permissions

Commentaires