Identity as Code : Gérer les Conditional Access avec CI/CD

Introduction

Tu gères tes Conditional Access policies comme des 'change requests' ? Voici pourquoi c'est un problème majeur pour la sécurité de ton organisation. La gestion manuelle des politiques Conditional Access dans Microsoft Entra ID expose les environnements à des risques critiques : configuration drift, absence de tests de non-régression, et déploiements inconsistants entre les environnements.

L'Identity as Code (IaC) transforme cette approche artisanale en processus industrialisé, permettant de gérer les Conditional Access comme du code source avec versioning, tests automatisés, et déploiements contrôlés.

Le problème de la gestion manuelle

Configuration Drift et inconsistances

La gestion manuelle via le portail Entra ID génère plusieurs problématiques techniques :

• Dérive de configuration : Les modifications directes créent des écarts entre les environnements
• Absence de traçabilité : Impossible de déterminer qui a modifié quoi et quand
• Tests insuffisants : Aucune validation automatisée avant déploiement
• Rollback complexe : Retour arrière manuel et chronophage

Impact sur la gouvernance

Les équipes IAM font face à :

• Escalades sécuritaires non détectées
• Politiques contradictoires entre elles
• Compliance difficile à maintenir
• Temps de résolution d'incidents élevé

Architecture du pipeline Identity as Code

Workflow de déploiement

Le pipeline GitOps pour Conditional Access suit cette séquence :

Architecture technique

L'infrastructure requise comprend :

• Repository Git : Stockage versioning des configurations
• Pipeline CI/CD : GitHub Actions ou Azure DevOps
• Service Principal : Authentification vers Graph API
• Key Vault : Stockage sécurisé des secrets
• Log Analytics : Monitoring et alerting

Implémentation avec GitHub Actions

Configuration du pipeline

1name: Conditional Access Deployment
2 
3on:
4  pull_request:
5    paths:
6      - 'conditional-access/**'
7  push:
8    branches:
9      - main
10    paths:
11      - 'conditional-access/**'
12 
13jobs:
14  validate:
15    runs-on: ubuntu-latest
16    steps:
17      - uses: actions/checkout@v4
18      
19      - name: Azure Login
20        uses: azure/login@v1
21        with:
22          client-id: ${{ secrets.AZURE_CLIENT_ID }}
23          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
24          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
25      
26      - name: Validate CA Policies
27        run: |
28          az extension add --name account
29          python scripts/validate_ca_policies.py
30      
31      - name: What If Analysis
32        if: github.event_name == 'pull_request'
33        run: |
34          python scripts/whatif_analysis.py --policies ./conditional-access/
35          
36      - name: Deploy Report Mode
37        if: github.ref == 'refs/heads/main'
38        run: |
39          python scripts/deploy_ca_policies.py --mode report-only

Script PowerShell pour l'API Graph

1# Déploiement d'une politique Conditional Access via Graph API
2function Deploy-ConditionalAccessPolicy {
3    param(
4        [Parameter(Mandatory)]
5        [string]$PolicyFile,
6        
7        [Parameter(Mandatory)]
8        [string]$AccessToken,
9        
10        [switch]$ReportOnly
11    )
12    
13    $policy = Get-Content $PolicyFile | ConvertFrom-Json
14    
15    # Configuration du mode
16    if ($ReportOnly) {
17        $policy.state = "enabledForReportingButNotEnforced"
18    } else {
19        $policy.state = "enabled"
20    }
21    
22    $headers = @{
23        'Authorization' = "Bearer $AccessToken"
24        'Content-Type' = 'application/json'
25    }
26    
27    $uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"
28    
29    try {
30        $response = Invoke-RestMethod -Uri $uri -Method POST -Headers $headers -Body ($policy | ConvertTo-Json -Depth 10)
31        Write-Output "Politique déployée : $($response.id)"
32        return $response
33    }
34    catch {
35        Write-Error "Erreur déploiement : $($_.Exception.Message)"
36        throw
37    }
38}
39 
40# Test What If API
41function Test-ConditionalAccessImpact {
42    param(
43        [Parameter(Mandatory)]
44        [hashtable]$TestScenario,
45        
46        [Parameter(Mandatory)]
47        [string]$AccessToken
48    )
49    
50    $headers = @{
51        'Authorization' = "Bearer $AccessToken"
52        'Content-Type' = 'application/json'
53    }
54    
55    $body = @{
56        conditionalAccessWhatIfSubject = @{
57            user = @{
58                id = $TestScenario.UserId
59            }
60        }
61        conditionalAccessWhatIfConditions = @{
62            clientAppType = $TestScenario.ClientApp
63            devicePlatform = $TestScenario.Platform
64            location = @{
65                includeLocations = @($TestScenario.Location)
66            }
67        }
68    } | ConvertTo-Json -Depth 10
69    
70    $uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/whatIf"
71    
72    $response = Invoke-RestMethod -Uri $uri -Method POST -Headers $headers -Body $body
73    return $response
74}

Gouvernance et sécurité du pipeline

Contrôles d'accès (RBAC)

La sécurisation du pipeline nécessite :

• Service Principal avec permissions minimales :

  • Policy.ReadWrite.ConditionalAccess
  • Application.Read.All (pour les tests)
  • User.Read.All (pour la validation)

• Protection des branches Git avec :

  • Reviews obligatoires (minimum 2)
  • Status checks requis
  • Restriction des push directs

Audit et logging

1{
2  "auditEvent": {
3    "timestamp": "2026-05-05T10:30:00Z",
4    "action": "ConditionalAccessPolicyDeployed",
5    "actor": "pipeline@contoso.com",
6    "resource": "CA-RequireMFA-Externals",
7    "details": {
8      "policyId": "12345678-1234-1234-1234-123456789012",
9      "state": "enabledForReportingButNotEnforced",
10      "commitSha": "abc123def456"
11    }
12  }
13}

Tests automatisés avec What If API

Scénarios de test critiques

Les tests automatisés doivent couvrir :

Tests d'accès utilisateur :

• Utilisateur interne depuis le réseau corporate
• Utilisateur externe avec MFA configuré
• Utilisateur privilégié depuis un appareil non-conforme

Tests de continuité :

• Accès break-glass en cas de panne MFA
• Fonctionnement des exclusions d'urgence
• Comportement lors de pannes partielles

Implémentation des tests

1# Suite de tests automatisés
2$TestSuites = @(
3    @{
4        Name = "Internal User Corporate Network"
5        UserId = "user@contoso.com"
6        ClientApp = "browser"
7        Platform = "windows"
8        Location = "Corporate-Network"
9        ExpectedResult = "Allow"
10    },
11    @{
12        Name = "External User Mobile"
13        UserId = "external@partner.com"
14        ClientApp = "mobileAppsAndDesktopClients"
15        Platform = "iOS"
16        Location = "All"
17        ExpectedResult = "RequireMFA"
18    }
19)
20 
21foreach ($test in $TestSuites) {
22    $result = Test-ConditionalAccessImpact -TestScenario $test -AccessToken $token
23    
24    if ($result.applyResult -ne $test.ExpectedResult) {
25        throw "Test failed: $($test.Name) - Expected: $($test.ExpectedResult), Got: $($result.applyResult)"
26    }
27    
28    Write-Output "✓ Test passed: $($test.Name)"
29}

Checklist opérationnelle

• [ ] Service Principal configuré avec permissions minimales
• [ ] Repository Git avec protection des branches activée
• [ ] Pipeline CI/CD avec étapes de validation et tests
• [ ] Secrets management via Key Vault ou GitHub Secrets
• [ ] Tests What If automatisés pour tous les scénarios critiques
• [ ] Monitoring des déploiements via Log Analytics
• [ ] Documentation des processus et procédures d'urgence
• [ ] Formation des équipes sur les nouveaux workflows
• [ ] Plan de rollback automatisé en cas d'incident
• [ ] Tests de disaster recovery incluant les comptes break-glass

Pièges fréquents à éviter

Scope trop large lors de la migration

Erreur courante : Migrer toutes les politiques d'un coup Solution : Approche incrémentale par groupes d'utilisateurs

Absence de break-glass dans les tests

Erreur courante : Ne pas tester les comptes d'urgence Solution : Tests automatisés des exclusions d'urgence

Gestion des secrets défaillante

Erreur courante : Secrets en dur dans le code Solution : Azure Key Vault + Managed Identity

Tests insuffisants en pré-production

Erreur courante : Tests uniquement synthétiques Solution : Période de validation en mode report-only

Plan de déploiement 30/60/90 jours

30 premiers jours - Fondations

• Configuration de l'environnement de développement
• Mise en place du Service Principal et permissions
• Premier pipeline pour 1-2 politiques de test
• Formation de l'équipe core

60 jours - Extension

• Migration de 25% des politiques non-critiques
• Implémentation du monitoring avancé
• Tests de disaster recovery
• Documentation des processus

90 jours - Production complète

• Migration de toutes les politiques
• Optimisation des performances du pipeline
• Formation étendue aux équipes support
• Audit complet du processus

Conclusion

L'Identity as Code transforme la gestion des Conditional Access d'un processus manuel à risque en une approche industrialisée et sécurisée. L'intégration des pipelines CI/CD, des tests automatisés via What If API, et du monitoring continu permet d'atteindre un niveau de maturité DevSecOps pour l'identité.

La clé du succès réside dans une approche incrémentale, une gouvernance rigoureuse, et une culture d'amélioration continue. Les équipes qui adoptent cette démarche constatent une réduction significative des incidents liés aux Conditional Access et une amélioration de leur posture de sécurité globale.

Liens utiles

• Microsoft Graph API - Conditional Access
• Conditional Access What If API
• GitHub Actions pour Azure
• Azure Bicep pour Entra ID

Glossaire

Identity as Code (IaC) : Approche de gestion des identités et accès par le code source, permettant versioning, tests et déploiements automatisés.

What If API : API Microsoft Graph permettant de simuler l'impact des politiques Conditional Access sur des scénarios d'authentification.

GitOps : Méthodologie de déploiement utilisant Git comme source de vérité pour les configurations d'infrastructure.

Service Principal : Identité d'application dans Entra ID permettant l'authentification programmatique aux services Azure.

Break-glass : Comptes d'urgence permettant l'accès administratif en cas de dysfonctionnement des systèmes d'authentification normaux.