Framework de test pour les politiques d'accès conditionnel : éviter les blocages en production

Introduction

Les erreurs de configuration des politiques d'accès conditionnel peuvent coûter extrêmement cher aux entreprises. Une société du Fortune 500 a vu ses 10 000 employés bloqués pendant quatre heures à cause d'une seule politique mal configurée. Une autre organisation a passé huit jours et plus de 60 appels de support pour récupérer l'accès administrateur après un dysfonctionnement d'une politique MFA résistante au phishing.

Avec des coûts d'arrêt d'entreprise variant entre 300 000 et 1 million de dollars par heure, déployer des politiques d'accès conditionnel non testées représente un risque inacceptable. La solution réside dans l'implémentation d'un framework de test basé sur PowerShell qui simule tous les scénarios de connexion avant qu'une politique n'atteigne la production.

L'API What If révolutionne les tests de politiques

L'ancien outil What If du portail Entra était utile mais manuel. La version API Graph (POST /v1.0/identity/conditionalAccess/evaluate) transforme les tests de politiques en opération automatisable et scriptable. L'applet de commande PowerShell Test-MgIdentityConditionalAccess du module Microsoft.Graph.Identity.SignIns encapsule cette API de manière élégante.

Voici un test prêt pour la production qui simule une connexion Android à haut risque vers SharePoint :

1# Requires: Microsoft.Graph.Identity.SignIns v2.6+
2# Permission: Policy.Read.All (application ou délégué)
3Connect-MgGraph -Scopes 'Policy.Read.All'
4 
5$params = @{
6    signInIdentity  = @{
7        "@odata.type" = "#microsoft.graph.userSignIn"
8        userId        = "15dc174b-f34c-4588-ac45-61d6e05dce93"
9    }
10    signInContext    = @{
11        "@odata.type"       = "#microsoft.graph.applicationContext"
12        includeApplications = @("00000003-0000-0ff1-ce00-000000000000")
13    }
14    signInConditions = @{
15        devicePlatform = "android"
16        clientAppType  = "browser"
17        signInRiskLevel = "high"
18        country         = "US"
19        ipAddress       = "40.77.182.32"
20        deviceInfo      = @{ isCompliant = $false }
21    }
22    appliedPoliciesOnly = $false  # Retourne TOUTES les politiques avec statut d'évaluation
23}
24 
25$results = Test-MgIdentityConditionalAccess -BodyParameter $params
26$results | Where-Object { $_.policyApplies -eq $true } |
27    Format-Table displayName, state, @{
28        N='Controls'; E={$_.grantControls.builtInControls -join ', '}
29    }

Points clés de l'API

L'API évalue chaque politique activée et en mode rapport uniquement dans votre tenant. Chaque résultat inclut un booléen policyApplies et des analysisReasons expliquant précisément pourquoi une politique correspond ou non, avec des valeurs comme users, application, platform, ou notEnoughInformation.

Créer des tests de régression avec Maester

Les appels API bruts vérifient des scénarios individuels. Le framework open-source Maester (maester.dev) transforme ces scénarios en tests de régression répétables basés sur Pester qui s'exécutent dans CI/CD. Développé par Merill Fernando (PM Microsoft) et les MVP sécurité Fabian Bader et Thomas Naunheim, Maester inclut plus de 20 tests d'accès conditionnel prêts à l'emploi.

1Install-Module Maester
2 
3Describe "Suite de régression CA Contoso" {
4    It "L'accès SharePoint nécessite MFA pour tous les utilisateurs" {
5        $userId = (Get-MgUser -UserId 'utilisateur@contoso.com').Id
6        $result = Test-MtConditionalAccessWhatIf -UserId $userId `
7            -IncludeApplications '67ad5377-2d78-4ac2-a867-6300cda00e85'
8        $result.grantControls.builtInControls | Should -Contain "mfa"
9    }
10 
11    It "Portail Azure bloqué pour les utilisateurs non-admin" {
12        $userId = (Get-MgUser -UserId 'standard@contoso.com').Id
13        $result = Test-MtConditionalAccessWhatIf -UserId $userId `
14            -IncludeApplications 'c44b4083-3bb0-49c1-b47d-974e53cbdf3c'
15        $result.grantControls.builtInControls | Should -Contain "block"
16    }
17}

Pipeline de déploiement anti-blocage

Les organisations qui se retrouvent bloquées partagent un modèle commun : elles ignorent le mode rapport uniquement, oublient les exclusions break-glass, ou déploient directement dans le portail sans contrôle de version.

Architecture de pipeline recommandée

1SigninLogs
2| mv-expand ConditionalAccessPolicies
3| where ConditionalAccessPolicies["result"] == "reportOnlyFailure"
4| project TimeGenerated, UserPrincipalName, AppDisplayName,
5    PolicyName = ConditionalAccessPolicies["displayName"]
6| summarize BlockCount = count() by UserPrincipalName, PolicyName
7| sort by BlockCount desc

Garde-fous essentiels pour l'entreprise

Comptes break-glass obligatoires

Maintenez au moins deux comptes d'accès d'urgence cloud-only sur votre domaine onmicrosoft.com, exclus de toute politique CA, avec des clés FIDO2 stockées dans un coffre ignifuge. Testez-les trimestriellement.

Alertes sur les modifications de politiques

Configurez des alertes sur chaque changement de politique avec cette requête KQL dans Azure Monitor :

1AuditLogs
2| where OperationName in (
3    "Add conditional access policy",
4    "Update conditional access policy",
5    "Delete conditional access policy")
6| extend Actor = tostring(parse_json(
7    tostring(InitiatedBy.user)).userPrincipalName)
8| extend PolicyName = tostring(TargetResources[0].displayName)

Conformité réglementaire

N'oubliez pas l'aspect conformité. Le contrôle SOC 2 CC8.1 exige une gestion documentée des changements avec tests avant déploiement. Le contrôle ISO 27001:2022 A.8.9 mandate explicitement des politiques de gestion de configuration pour les changements affectant la sécurité.

Plan d'action immédiat

Commencez petit mais efficace. Exportez vos politiques actuelles en JSON et commitez-les dans un repo privé - cela vous donne déjà sauvegarde et piste d'audit. Ajoutez les appels API What If pour vos trois scénarios à plus haut risque :

• Accès au portail admin
• Tentatives d'authentification legacy
• Connexions d'appareils non-conformes

Intégrez Maester dans une GitHub Action planifiée. En quelques semaines, vous aurez un framework de test qui transforme les changements de politiques CA de "espérons que ça marche" en "prouvons que ça marche".

Liens utiles

• Microsoft Graph What If API Reference – Documentation officielle pour le endpoint conditionalAccess/evaluate avec exemples de requêtes/réponses
• Maester Framework Documentation – Framework PowerShell open-source pour tester la sécurité Microsoft 365 avec tests d'accès conditionnel intégrés
• Plan Your Conditional Access Deployment – Guide de planification complet Microsoft incluant mode rapport uniquement, comptes break-glass et bonnes pratiques
• Emergency Access Account Management – Guidance officiel sur la configuration et sécurisation des comptes break-glass
• Microsoft.Graph.Identity.SignIns Module – Documentation du module PowerShell pour gérer les politiques d'accès conditionnel via Graph API
• Conditional Access Report-Only Mode – Documentation Microsoft sur les tests de politiques sans enforcement
• Azure Monitor KQL Query Language – Documentation de référence pour écrire des requêtes de surveillance des événements d'accès conditionnel
• ISO 27001:2022 Control A.8.9 – Exigences de gestion de configuration pour les changements critiques de sécurité

Glossaire des termes

API What If : Interface de programmation Microsoft permettant de simuler l'évaluation des politiques d'accès conditionnel sans les appliquer réellement.

Break-glass accounts : Comptes d'accès d'urgence exclus des politiques de sécurité, utilisés uniquement en cas de défaillance système critique.

FIDO2 : Standard d'authentification forte sans mot de passe utilisant la cryptographie à clé publique pour une sécurité renforcée.

Maester : Framework open-source de tests automatisés pour l'écosystème Microsoft 365, spécialisé dans la validation des configurations de sécurité.

Mode rapport uniquement : État d'une politique d'accès conditionnel qui évalue les conditions sans bloquer l'accès, générant uniquement des logs d'audit.

Pester : Framework de tests unitaires PowerShell permettant de valider la configuration et le comportement des scripts et systèmes.

Workload Identity Federation : Méthode d'authentification Azure permettant aux workloads externes d'accéder aux ressources Azure sans gérer de secrets.