Azure Policy remediation : corriger la dérive sans casser la production

Une initiative Azure Policy peut signaler une dérive sans que la correction soit immédiate. Des diagnostics settings manquent, des tags obligatoires ne sont pas posés, des configurations DeployIfNotExists n’ont jamais été appliquées, ou un nouveau scope hérite d’une règle plus stricte que prévu. Le danger arrive quand la remédiation est lancée comme un bouton de nettoyage global : l’identité n’a pas les bons droits, les ressources ciblées ne sont pas celles attendues, les exemptions sont ignorées, et l’équipe découvre l’impact seulement après les premiers échecs.

Le cas d’usage est une plateforme Azure qui veut corriger une dérive détectée par Azure Policy sans transformer la gouvernance en changement opaque. L’objectif du runbook est de décider quoi remédier, avec quelle identité, sur quel périmètre, dans quel ordre, avec quelles preuves et quel rollback si la correction produit un effet de bord.

Lire la remédiation comme un changement de production

Une remédiation Azure Policy n’est pas seulement un rapport de conformité. Selon l’effet de la policy, elle peut déployer des ressources, modifier des configurations ou déclencher des opérations sur un grand nombre d’objets. Elle doit donc être traitée comme une automatisation de production.

Avant de lancer
Policy ou initiative concernee
Scope exact: management group, subscription, resource group ou ressource
Effet: DeployIfNotExists, Modify, AuditIfNotExists ou Deny en amont
Ressources non conformes par type et par environnement
Identite managée utilisee par l'assignment
Permissions RBAC necessaires a la correction
Exemptions existantes et justification
Fenetre de changement et proprietaire applicatif

Preuves attendues
Liste des ressources ciblees
Echantillon de ressources exclues ou exemptes
Role assignments de l'identite de remédiation
Premier lot limite et resultat
Logs Activity, Policy et erreurs ARM
Decision: continuer, limiter, corriger la policy ou rollback

La bonne question n’est pas : “combien de ressources sont non conformes ?”. Elle est : “quelles ressources seront modifiées si cette remédiation s’exécute maintenant ?”.

Identifier l’effet réel de la policy

Toutes les policies ne se remédient pas de la même manière. Une règle Audit ou Deny peut signaler ou bloquer, mais ne corrige pas une ressource existante. Les remédiations concernent surtout les policies capables d’appliquer ou de déployer quelque chose, comme DeployIfNotExists ou Modify.

ASSIGNMENT_NAME=deploy-diagnostics-to-law
SCOPE=/subscriptions/00000000-0000-0000-0000-000000000000

az policy assignment show --name "$ASSIGNMENT_NAME" --scope "$SCOPE" --query '{
  name:name,
  displayName:displayName,
  scope:scope,
  policyDefinitionId:policyDefinitionId,
  identity:identity,
  enforcementMode:enforcementMode,
  parameters:parameters
}' -o jsonc

az policy state summarize --policy-assignment "$ASSIGNMENT_NAME" --scope "$SCOPE" -o table

Si l’assignment n’a pas d’identité managée alors que la policy doit déployer ou modifier des ressources, la remédiation échouera ou sera impossible. Si enforcementMode a été désactivé volontairement pour observer avant d’imposer, le runbook doit documenter cette intention avant de corriger.

Construire la liste cible avant l’exécution

La remédiation doit partir d’une liste cible lisible. Un résumé global de conformité ne suffit pas. Il faut voir les ressources, leurs types, leurs groupes, les environnements concernés et les éventuelles exemptions.

ASSIGNMENT_ID=$(az policy assignment show --name "$ASSIGNMENT_NAME" --scope "$SCOPE" --query id -o tsv)

az policy state list --filter "PolicyAssignmentId eq '$ASSIGNMENT_ID' and ComplianceState eq 'NonCompliant'" --query '[].{
  resourceId:resourceId,
  resourceType:resourceType,
  complianceState:complianceState,
  policyDefinitionAction:policyDefinitionAction,
  policyDefinitionReferenceId:policyDefinitionReferenceId
}' -o table

Cette liste sert aussi à repérer les anomalies : une subscription de sandbox dans le scope production, un type de ressource inattendu, une policy ancienne encore assignée, ou une exemption manquante pour un cas temporairement accepté.

Vérifier l’identité de remédiation

Les remédiations échouent souvent parce que l’identité managée de l’assignment n’a pas les rôles nécessaires sur le bon scope. Donner Owner par défaut est rarement défendable. Le rôle doit couvrir l’action réelle : créer un diagnostic setting, ajouter un tag, déployer une extension, activer une configuration ou lier une ressource.

PRINCIPAL_ID=$(az policy assignment show --name "$ASSIGNMENT_NAME" --scope "$SCOPE" --query identity.principalId -o tsv)

az role assignment list --assignee "$PRINCIPAL_ID" --all --query '[].{role:roleDefinitionName,scope:scope}' -o table

Pour une policy qui déploie des diagnostics settings vers un Log Analytics Workspace, l’identité peut avoir besoin de droits sur les ressources cibles et sur le workspace de destination. Pour une policy Modify, elle doit pouvoir écrire le champ concerné. La permission doit être testée avant le lot large.

Démarrer par un lot limité

Le premier lot doit être volontairement petit. Il permet de vérifier les permissions, le comportement de la policy, les logs et l’absence d’effet inattendu. Si la plateforme utilise des tags d’environnement, des resource groups par domaine ou des subscriptions par ligne produit, le lot doit suivre cette découpe.

REMEDIATION_NAME=remediate-diagnostics-prod-batch-01
RESOURCE_GROUP=rg-prod-orders

az policy remediation create --name "$REMEDIATION_NAME" --policy-assignment "$ASSIGNMENT_ID" --resource-group "$RESOURCE_GROUP" --resource-discovery-mode ReEvaluateCompliance --parallel-deployments 5 --failure-threshold 0.1

az policy remediation show --name "$REMEDIATION_NAME" --resource-group "$RESOURCE_GROUP" --query '{provisioningState:provisioningState,createdOn:createdOn,lastUpdatedOn:lastUpdatedOn}' -o jsonc

Le but n’est pas d’aller lentement par principe. Le but est de rendre la première correction interprétable. Si le lot échoue, l’équipe sait si le problème vient de la policy, de l’identité, du scope ou d’une ressource particulière.

Observer les erreurs avec Activity Log et Policy states

Une remédiation qui échoue proprement est exploitable. Une remédiation qui échoue sans logs relisibles ne doit pas être élargie. Il faut regarder les états de conformité après réévaluation et les événements ARM générés par l’identité.

let Window = 4h;
AzureActivity
| where TimeGenerated > ago(Window)
| where OperationNameValue has_any ("Microsoft.PolicyInsights/remediations", "Microsoft.Authorization/policyAssignments")
 or Caller has "Policy"
| project TimeGenerated,
        OperationNameValue,
        ActivityStatusValue,
        ResourceGroup,
        ResourceProviderValue,
        ResourceId,
        Caller,
        CorrelationId,
        Properties
| order by TimeGenerated desc

Selon la configuration Log Analytics, les tables disponibles peuvent varier. L’intention reste la même : retrouver l’opération, la ressource ciblée, l’identité appelante, le statut et le message d’erreur. Un AuthorizationFailed appelle une correction RBAC. Un template invalide appelle une correction de policy. Une ressource non supportée appelle une exclusion ou une condition plus précise.

Traiter les exemptions comme des décisions, pas comme des oublis

Les exemptions ne doivent pas devenir une zone grise. Certaines sont légitimes : contrainte applicative temporaire, service non compatible, migration en cours, exception validée par sécurité. D’autres masquent une policy trop large. Avant un lot plus grand, il faut relire les exemptions et leur date de fin.

az policy exemption list --scope "$SCOPE" --query '[].{
  name:name,
  displayName:displayName,
  exemptionCategory:exemptionCategory,
  expiresOn:expiresOn,
  policyAssignmentId:policyAssignmentId
}' -o table

Une remédiation de production doit respecter les exemptions décidées. Si une exemption empêche une correction maintenant nécessaire, la décision doit être explicite : retirer l’exemption, la remplacer par une exemption plus fine ou corriger la policy pour mieux cibler.

Décider extension, pause ou rollback

Après le premier lot, la décision doit être écrite. Continuer sans regarder les résultats revient à exécuter une automatisation aveugle.

Decision: etendre
Le lot limite est termine
Les ressources ciblees correspondent au scope attendu
Les permissions de l'identite sont suffisantes
Les erreurs sont nulles ou comprises
Les logs permettent de reconstruire l'action

Decision: pause
Des ressources inattendues apparaissent
Des exemptions manquent ou sont ambiguës
Le taux d'echec depasse le seuil accepte
Une equipe applicative doit valider un effet de bord

Decision: rollback ou correction
La policy modifie un champ non voulu
Le template DeployIfNotExists est incorrect
L'identite a ete trop largement autorisee
Une ressource critique est degradee apres correction

Le rollback dépend de l’effet. Pour un tag ou un diagnostic setting, il peut s’agir de restaurer la configuration précédente. Pour un déploiement DeployIfNotExists, il faut savoir quelles ressources ont été créées et si elles peuvent être supprimées sans perdre des logs ou des dépendances. Pour une policy trop large, le vrai rollback est souvent une correction de définition ou de paramètres, puis une nouvelle évaluation.

Conclusion

Azure Policy remediation est utile quand elle reste lisible. Le runbook doit transformer une non-conformité globale en changement borné : effet réel, scope exact, identité de remédiation, liste cible, premier lot, logs, exemptions et décision.

La décision opérationnelle devient alors simple : étendre quand le premier lot est propre, mettre en pause quand le périmètre ou les exemptions sont flous, corriger la policy quand l’effet n’est pas celui attendu, et rollback quand une modification crée un impact de production. La gouvernance reste automatisée, mais elle reste explicable.