Azure Update Manager : gérer la mise à jour des VMs Windows et Linux

La gestion des correctifs logiciels (patch management) est l'une des obligations de sécurité les plus fondamentales et les moins bien maîtrisées des organisations. Selon le rapport DBIR de Verizon, plus de 60% des violations de données exploitent des vulnérabilités connues pour lesquelles un correctif existait depuis plus de deux ans. Dans les environnements cloud Azure, cette réalité est d'autant plus critique que les VMs exposées sur internet sont constamment sondées par des scanners automatisés dès leur création. Microsoft a profondément remanié son approche de la gestion des mises à jour en 2022 avec le lancement d'Azure Update Manager, successeur de l'ancien Update Management basé sur Azure Automation et Log Analytics. Cette nouvelle solution, native à Azure Resource Manager et sans agent supplémentaire, offre une couverture unififiée des VMs Azure Windows et Linux, mais aussi des serveurs on-premise et multi-cloud via Azure Arc. Ce guide complet explore toutes les facettes d'Azure Update Manager : l'activation, l'évaluation de conformité, la planification des fenêtres de maintenance, le déploiement à la demande, l'extension vers l'on-premise avec Arc, et l'automatisation via Azure Policy — pour une gestion des patchs industrialisée et traçable.

Azure Update Manager vs ancien Update Management — nouveautés et migration

L'ancien Update Management (que les vétérans d'Azure connaissent bien) reposait sur Azure Automation et des workspaces Log Analytics. Chaque VM devait avoir l'agent Microsoft Monitoring Agent (MMA) ou l'agent Azure Monitor installé, connecté à un workspace Log Analytics, et une solution Update Management activée dans Azure Automation. Cette architecture multi-couches était fonctionnelle mais complexe à maintenir et à faire évoluer.

Azure Update Manager adopte une approche radicalement différente :

• Sans agent supplémentaire : fonctionne avec l'extension VM Azure Guest Agent native, déjà présente sur toutes les VMs Azure
• Intégration ARM native : toutes les opérations sont des ressources Azure Resource Manager, gérables via Bicep, Terraform, Azure CLI ou PowerShell
• Couverture unifiée : Azure VMs, Azure Arc (on-premise, AWS, GCP), et groupes de machines dynamiques
• Pas de workspace Log Analytics requis pour les fonctions de base (l'historique des mises à jour est stocké dans Azure directement)
• Maintenance Configurations : remplacement des deployment schedules, plus flexibles et versionnables

Migration depuis l'ancien Update Management : Microsoft maintient les deux solutions en parallèle jusqu'à la dépréciation de l'ancienne (prévue fin 2024). La migration est documentée et relativement simple — les scheduled deployments existants peuvent être recréés en tant que Maintenance Configurations dans Azure Update Manager. Aucune migration de données historiques n'est possible, mais l'historique reste consultable dans l'ancien portail pendant la période de transition.

Pour les environnements ayant investi dans des workbooks Log Analytics personnalisés pour le suivi des patchs, ceux-ci peuvent être adaptés pour interroger les nouvelles tables de logs Azure Update Manager (PatchAssessmentResources et PatchInstallationResources).

Activer Azure Update Manager sur vos VMs (Azure native, pas d'agent supplémentaire)

L'activation d'Azure Update Manager ne nécessite aucune installation d'agent ni configuration complexe. La fonctionnalité est native à toutes les VMs Azure exécutant Windows Server 2008 R2+ ou Linux avec les distributions principales supportées (Ubuntu 16.04+, RHEL 7+, Debian 10+, SLES 12+).

Depuis le portail Azure, naviguez vers votre VM et dans le menu de gauche, cliquez sur "Updates" (dans la section Operations). Si Azure Update Manager n'est pas encore configuré sur cette VM, vous verrez un écran d'invitation à activer la fonctionnalité.

Via Azure CLI :

# Vérifier l'état de la gestion des patchs sur une VM
az vm show \
  --resource-group MonRG \
  --name MaVM \
  --query "osProfile.linuxConfiguration.patchSettings" \
  --output json

# Activer Azure Update Manager (AssessmentMode + PatchMode)
az vm update \
  --resource-group MonRG \
  --name MaVM \
  --set osProfile.linuxConfiguration.patchSettings.assessmentMode=AutomaticByPlatform \
  --set osProfile.linuxConfiguration.patchSettings.patchMode=AutomaticByPlatform

Pour Windows :

az vm update \
  --resource-group MonRG \
  --name MaVM \
  --set osProfile.windowsConfiguration.patchSettings.assessmentMode=AutomaticByPlatform \
  --set osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform

En mode AutomaticByPlatform, Azure Update Manager prend le contrôle des évaluations et installations de patchs. C'est le prérequis pour utiliser les Maintenance Configurations et les déploiements orchestrés. Notez que le mode AutomaticByPlatform pour Linux désactive les mises à jour automatiques du gestionnaire de paquets natif (unattended-upgrades sur Debian/Ubuntu) pour éviter les conflits.

Évaluer l'état des patchs (Assessment, vue de conformité)

L'évaluation de l'état des patchs est la première étape du cycle de vie de la gestion des correctifs. Azure Update Manager distingue deux types d'évaluation :

• Assessment périodique : Azure évalue automatiquement les patchs manquants toutes les 24 heures et stocke les résultats
• Assessment à la demande : déclenchée manuellement pour obtenir une vue fraîche immédiatement

Déclencher une évaluation à la demande via Azure CLI :

az vm assess-patches \
  --resource-group MonRG \
  --name MaVM

Via PowerShell :

Invoke-AzVMPatchAssessment `
  -ResourceGroupName "MonRG" `
  -VMName "MaVM"

Le résultat de l'évaluation classe les patchs manquants par catégorie (Security, Critical, UpdateRollup, ServicePack, Definition, FeaturePack, Tools) et par sévérité (Critical, Important, Moderate, Low, Unspecified). Cette classification est essentielle pour prioriser les déploiements.

La vue de conformité multi-VMs est disponible dans le portail Azure Update Manager (cherchez "Azure Update Manager" dans la barre de recherche). Elle offre un tableau de bord centralisé montrant :

• Nombre de VMs par statut de conformité (compliant, non-compliant, unknown)
• Patchs critiques et de sécurité manquants par VM
• Historique des déploiements récents
• Tendances de conformité dans le temps

Pour une vue agrégée sur plusieurs abonnements Azure, utilisez Azure Resource Graph avec une requête KQL personnalisée :

patchassessmentresources
| where type == "microsoft.compute/virtualmachines/patchassessmentresults"
| extend criticalPatches = properties.availablePatchCountByClassification.critical
| extend securityPatches = properties.availablePatchCountByClassification.security
| summarize sum(criticalPatches), sum(securityPatches) by subscriptionId

Configurer une Maintenance Configuration (planification des mises à jour)

Les Maintenance Configurations sont le mécanisme central de planification des mises à jour dans Azure Update Manager. Elles définissent quand les patchs sont déployés, sur quelles machines, avec quels filtres de classification et de sévérité.

Créer une Maintenance Configuration via Azure CLI :

az maintenance configuration create \
  --resource-group MonRG \
  --resource-name "Maintenance-SecuriteMensuelle" \
  --location "westeurope" \
  --maintenance-scope "InGuestPatch" \
  --recur-every "Month Second Tuesday" \
  --start-date-time "2026-06-10 22:00" \
  --timezone "W. Europe Standard Time" \
  --duration "04:00" \
  --install-patches-linux-parameters \
    classificationsToInclude='["Security","Critical"]' \
    packageNameMasksModeReboot="IfRequired" \
  --install-patches-windows-parameters \
    classificationsToInclude='["SecurityUpdates","CriticalUpdates","UpdateRollup"]' \
    kbNumbersToExclude='[]' \
  --reboot-setting "IfRequired"

Cette configuration correspond au classique "Patch Tuesday mensuel" : le deuxième mardi de chaque mois, à 22h00 heure Europe/Paris, avec une fenêtre de maintenance de 4 heures, en installant uniquement les patchs de sécurité et critiques, avec redémarrage si nécessaire.

Associez des VMs à cette configuration :

az maintenance assignment create \
  --resource-group MonRG \
  --location "westeurope" \
  --maintenance-configuration-id /subscriptions/SUB_ID/resourceGroups/MonRG/providers/Microsoft.Maintenance/maintenanceConfigurations/Maintenance-SecuriteMensuelle \
  --name "Assignment-MaVM" \
  --provider-name "Microsoft.Compute" \
  --resource-group-name "MonRG" \
  --resource-name "MaVM" \
  --resource-type "virtualMachines"

Déployer des mises à jour à la demande (One-time update)

En dehors des fenêtres de maintenance planifiées, Azure Update Manager permet de déployer des mises à jour immédiatement sur une ou plusieurs VMs. C'est indispensable pour répondre à une vulnérabilité critique (0-day) qui ne peut pas attendre la prochaine fenêtre de maintenance.

Déploiement immédiat sur une VM unique :

az vm install-patches \
  --resource-group MonRG \
  --name MaVM \
  --maximum-duration "PT2H" \
  --reboot-setting "IfRequired" \
  --windows-parameters \
    classificationsToInclude='["SecurityUpdates","CriticalUpdates"]' \
  --linux-parameters \
    classificationsToInclude='["Security","Critical"]'

Pour un déploiement en masse sur plusieurs VMs (par exemple, toutes les VMs d'un groupe de ressources), utilisez Azure CLI avec une boucle ou Azure Update Manager "One-time update" depuis le portail :

# Déploiement sur toutes les VMs d'un resource group
for vm in $(az vm list -g MonRG --query "[].name" -o tsv); do
  echo "Patching $vm..."
  az vm install-patches \
    --resource-group MonRG \
    --name $vm \
    --maximum-duration "PT2H" \
    --reboot-setting "IfRequired" \
    --linux-parameters classificationsToInclude='["Security","Critical"]' \
    --no-wait
done

Le flag --no-wait lance les opérations en parallèle sans attendre la fin de chaque VM. Suivez la progression depuis le portail Azure Update Manager ou via :

az vm show \
  --resource-group MonRG \
  --name MaVM \
  --query "storageProfile.osDisk.osType"

Étendre à l'on-premise avec Azure Arc (serveurs physiques et VMs non Azure)

L'un des atouts majeurs d'Azure Update Manager est sa capacité à gérer les serveurs on-premise, les VMs sur d'autres clouds (AWS, GCP) et les équipements physiques, via Azure Arc. Azure Arc projette ces ressources dans Azure Resource Manager, leur permettant de bénéficier des services Azure natifs dont Azure Update Manager.

Installation de l'agent Azure Arc Connected Machine sur un serveur Linux on-premise :

# Télécharger et installer l'agent Azure Arc
curl -o install_linux_azcmagent.sh https://aka.ms/azcmagent-linux
sudo bash install_linux_azcmagent.sh

# Connecter le serveur à Azure
azcmagent connect \
  --resource-group MonRG-OnPrem \
  --tenant-id TENANT_ID \
  --location westeurope \
  --subscription-id SUB_ID \
  --cloud AzureCloud

Une fois connecté, le serveur apparaît dans Azure Portal sous "Azure Arc > Servers". Il devient alors gérable depuis Azure Update Manager exactement comme une VM Azure native. Les Maintenance Configurations peuvent inclure à la fois des VMs Azure et des serveurs Arc dans le même scope de déploiement.

Pour les déploiements d'Arc à grande échelle (des centaines de serveurs), utilisez les scripts de déploiement en masse fournis par Microsoft ou le provider Terraform AzureRM qui supporte la ressource azurerm_arc_machine. La documentation complète est disponible sur learn.microsoft.com/azure/azure-arc.

Azure Arc permet également d'appliquer les politiques de gouvernance Azure Policy aux serveurs on-premise, ce qui est précieux pour imposer les standards de sécurité de manière cohérente entre le cloud et le datacenter. Consultez notre article sur la gouvernance Azure avec Azure Policy pour les détails.

Rapports de conformité et tableaux de bord

La traçabilité est aussi importante que les mises à jour elles-mêmes — les auditeurs de sécurité (NIS 2, ISO 27001, SOC 2) exigent des preuves documentées de la gestion des patchs. Azure Update Manager offre plusieurs niveaux de reporting.

Depuis le portail Azure : le tableau de bord Azure Update Manager affiche la conformité globale, les mises à jour en attente par VM et par sévérité, l'historique des déploiements sur 30 jours glissants, et un drill-down par VM ou par groupe de ressources.

Via Azure Resource Graph : pour des rapports personnalisés et l'export vers des outils tiers :

# Requête KQL pour le rapport de conformité
patchassessmentresources
| where type == "microsoft.compute/virtualmachines/patchassessmentresults"
| extend vmId = split(id, '/providers/')[0]
| extend lastAssessment = properties.lastModifiedDateTime
| extend criticalCount = properties.availablePatchCountByClassification.critical
| extend securityCount = properties.availablePatchCountByClassification.security
| project vmId, lastAssessment, criticalCount, securityCount
| where criticalCount > 0 or securityCount > 0
| order by criticalCount desc

Exportez ces données vers Power BI pour des tableaux de bord de direction, ou vers Azure Monitor Workbooks pour des rapports techniques interactifs. Les workbooks Azure Update Manager officiels sont disponibles dans la galerie Azure Monitor.

Pour les environnements soumis à des audits réguliers, configurez une exportation automatique mensuelle des rapports de conformité via un Logic App ou une Azure Function qui génère un rapport PDF et l'envoie par email aux parties prenantes.

Intégration avec Microsoft Defender for Cloud (posture sécurité)

Microsoft Defender for Cloud (anciennement Azure Security Center) intègre nativement les données d'Azure Update Manager pour enrichir le score de sécurité (Secure Score) et les recommandations de posture.

Dans Defender for Cloud, la recommandation "System updates should be installed on your machines" est désormais alimentée par les données d'Azure Update Manager. Chaque VM avec des patchs critiques manquants depuis plus de X jours contribue négativement au Secure Score.

Activez le monitoring conjoint depuis le portail Defender for Cloud :

az security auto-provisioning-setting update \
  --name "MicrosoftDefenderForServer" \
  --auto-provision "On"

Defender for Cloud peut également déclencher des workflows automatiques lorsque des patchs critiques sont détectés : envoi d'alertes email, tickets dans ServiceNow ou Jira, démarrage d'une Logic App de remédiation automatique. Cette intégration SOAR (Security Orchestration, Automation and Response) permet de réduire le MTTR (Mean Time To Remediate) des vulnérabilités critiques.

La corrélation entre les CVE connues (via Microsoft Defender Vulnerability Management) et les patchs disponibles dans Azure Update Manager permet à Defender for Cloud de vous montrer exactement quelle mise à jour corrige quelle CVE critique, avec son score CVSS. C'est une aide précieuse pour prioriser les déploiements en cas de multiples vulnérabilités simultanées. Pour aller plus loin sur la gestion des vulnérabilités dans Azure, consultez notre guide sur Microsoft Defender for Cloud et la posture de sécurité Azure.

Gestion des exclusions et reports de patchs

En production, tous les patchs ne peuvent pas être déployés immédiatement. Des contraintes de compatibilité applicative, des périodes de freeze de changement, ou des dépendances entre composants nécessitent parfois d'exclure certains patchs ou de reporter leur application.

Exclure des patchs spécifiques dans une Maintenance Configuration Windows (par numéro KB) :

az maintenance configuration update \
  --resource-group MonRG \
  --resource-name "Maintenance-SecuriteMensuelle" \
  --install-patches-windows-parameters \
    classificationsToInclude='["SecurityUpdates"]' \
    kbNumbersToExclude='["KB5012345","KB5067890"]'

Pour Linux, excluez des packages spécifiques par nom :

--install-patches-linux-parameters \
  classificationsToInclude='["Security"]' \
  packageNameMasksToExclude='["kernel*","libc6"]'

Pour les reports temporaires (période de freeze avant une release majeure), créez une Maintenance Configuration avec une fenêtre future et une durée de 0 (effectivement désactivée), puis réactivez-la après la période critique. Cette approche est auditée dans les logs ARM et prouvable lors d'un audit de sécurité.

Documentez systématiquement les exclusions et reports dans un registre de risques ou un ticket ITSM. Le risque résiduel lié à un patch non appliqué doit être formellement accepté par le responsable sécurité (RSSI) — particulièrement pour les vulnérabilités critiques (CVSS ≥ 9.0). Cette discipline de documentation est exigée par NIS 2 (article 21 sur la gestion des risques) et les frameworks ISO 27001 (contrôle 8.8).

Automatiser avec Azure Policy (auto-assessment, auto-patching)

Azure Policy permet d'imposer et d'automatiser les configurations Azure Update Manager à l'échelle de votre tenant, sans intervention manuelle pour chaque nouvelle VM.

Politiques Azure Update Manager importantes à déployer :

• Configure periodic checking for missing system updates on azure virtual machines : active l'évaluation périodique automatique sur toutes les nouvelles VMs
• Configure automatic VM guest patching for Azure VMs : active le mode AutomaticByPlatform
• Assign built-in user-assigned managed identity to virtual machines : prérequis pour les VMs Arc

Déployez ces politiques via Azure CLI :

# Activer l'évaluation périodique via Policy
az policy assignment create \
  --name "AUM-AutoAssessment" \
  --scope /subscriptions/SUB_ID \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/59efceea-0c96-497e-a4a1-4eb2290dac15" \
  --location "westeurope" \
  --identity-scope /subscriptions/SUB_ID \
  --mi-system-assigned

Pour déployer automatiquement une Maintenance Configuration sur toutes les nouvelles VMs d'un tag donné (ex: Environment: Production), créez une Azure Policy avec effet DeployIfNotExists qui crée l'assignment de maintenance automatiquement. Cette approche "Policy as Code" garantit que toutes les nouvelles VMs sont immédiatement couvertes par votre politique de patch management, sans risque d'oubli humain.

La référence complète d'Azure Update Manager, incluant les schémas REST API, les définitions de Maintenance Configuration et les exemples de templates Bicep/Terraform, est disponible sur learn.microsoft.com/azure/update-manager.

L'automatisation complète du cycle de vie du patch management — de l'évaluation au déploiement en passant par la gestion des exceptions et le reporting — est une exigence de maturité pour toute organisation souhaitant obtenir une certification ISO 27001 ou se conformer aux exigences NIS 2. Azure Update Manager, combiné à Azure Policy et Microsoft Defender for Cloud, constitue un socle solide pour atteindre cet objectif. Consultez notre article sur la conformité NIS 2 et les mesures de sécurité technique pour comprendre comment le patch management s'inscrit dans le cadre réglementaire.

Bonnes pratiques et stratégie de déploiement en production

Une stratégie de patch management Azure mature ne se limite pas à configurer des Maintenance Configurations. Elle implique une approche méthodique qui équilibre sécurité, disponibilité et traçabilité.

La règle d'or est le déploiement en vagues (phased rollout) : commencez par les environnements de développement et de staging, observez les impacts pendant 24 à 48 heures, puis déployez en production. Organisez vos VMs de production en groupes par criticité (tier 1 = VMs critiques, tier 2 = services secondaires) et patchlez tier 2 avant tier 1. Utilisez des tags Azure pour identifier ces groupes :

# Tagger une VM comme tier de patching
az vm update \
  --resource-group MonRG \
  --name MaVM \
  --set tags.PatchGroup=Tier1 tags.PatchWindow=WeekendNight

Créez des Maintenance Configurations distinctes par tier, avec des décalages temporels :

• Dev/Staging : deuxième mercredi du mois à 22h (J+1 après Patch Tuesday)
• Production Tier 2 : troisième lundi du mois à 23h
• Production Tier 1 : troisième vendredi du mois à 1h du matin (weekend)

Automatisez les notifications pre et post-patching vers votre outil ITSM. Une Logic App Azure peut envoyer automatiquement un ticket "Début fenêtre maintenance" dans ServiceNow 30 minutes avant le démarrage d'une Maintenance Configuration, et un ticket "Fin maintenance" avec le rapport de résultat après completion.

Intégrez les rapports d'Azure Update Manager dans votre processus de revue mensuelle de sécurité. La métrique clé à surveiller est le délai moyen entre la publication d'un patch critique et son déploiement effectif sur 100% du parc (Mean Time To Patch — MTTP). Un MTTP inférieur à 72 heures pour les patchs critiques est l'objectif recommandé par les référentiels de sécurité.

Questions fréquentes sur Azure Update Manager

Azure Update Manager est-il inclus dans le prix des VMs Azure ?

Azure Update Manager est inclus gratuitement pour toutes les VMs Azure. En revanche, pour les serveurs connectés via Azure Arc (serveurs on-premise, VMs AWS/GCP), Azure Update Manager est disponible gratuitement pour l'évaluation et les déploiements à la demande, mais les Maintenance Configurations planifiées nécessitent une licence Azure Arc Servers (environ 6 USD/serveur/mois) ou sont incluses dans Microsoft Defender for Servers Plan 2. Vérifiez la page de tarification officielle pour les derniers prix.

Comment Azure Update Manager gère-t-il les redémarrages ?

Azure Update Manager propose trois options de redémarrage : IfRequired (redémarre uniquement si un patch l'exige, recommandé), NeverReboot (n'installe que les patchs ne nécessitant pas de redémarrage), et AlwaysReboot (redémarre systématiquement après installation). Pour les environnements de production critiques, utilisez IfRequired avec une fenêtre de maintenance nocturne suffisamment large pour permettre les redémarrages sans impacter les utilisateurs.

Peut-on utiliser Azure Update Manager avec des VMs dans des availability zones ?

Oui, et c'est une pratique recommandée. Azure Update Manager supporte les groupes de mise à jour en vague (wave-based patching) via les Maintenance Configurations avec des scopes ciblant des VMs par tags. Par exemple, patcher d'abord les VMs de la zone 1, attendre 30 minutes, puis patcher les VMs de la zone 2, pour éviter une indisponibilité simultanée de toutes les instances d'un service distribué.

Comment migrer depuis WSUS vers Azure Update Manager pour les serveurs on-premise ?

Azure Update Manager remplace WSUS pour la gestion des patchs Windows, mais les deux peuvent coexister pendant la migration. La stratégie recommandée est d'onboarder les serveurs sur Azure Arc, de configurer Azure Update Manager avec les Maintenance Configurations appropriées, et de désactiver progressivement les GPO WSUS sur les serveurs migrés. Le rapport de conformité Azure Update Manager remplace les rapports WSUS dans les tableaux de bord de gestion.

Azure Update Manager supporte-t-il les images personnalisées (custom images) ?

Oui, Azure Update Manager fonctionne avec toutes les images Azure (Marketplace et personnalisées) tant que l'OS est dans la liste des distributions supportées et que l'Azure VM Guest Agent est installé et en cours de fonctionnement. Pour les images personnalisées basées sur Ubuntu ou RHEL, vérifiez que waagent (Windows Azure Linux Agent) est installé et correctement configuré. Les images minimales sans guest agent ne sont pas compatibles avec Azure Update Manager.