Patch management d’un parc de postes hétérogène

Gérer les correctifs d’un parc hétérogène ne consiste pas à cliquer sur « installer » dans trois consoles et espérer que les pilotes graphiques restent polis. Le compromis central oppose délai de réduction d’exposition et risque d’interrompre le métier : pour les failles exploitées activement, la vitesse l’emporte, mais elle doit s’appuyer sur un inventaire, un anneau de test et un rollback réellement exécutable.

→ Lire l’explication complète de la marmotte

Inventaire de parc et autorité de vérité

Un outil de distribution de correctifs ne voit que les machines qui lui parlent. Cette évidence devient coûteuse dès qu’un poste hors réseau, une machine virtuelle oubliée ou un ordinateur personnel enrôlé à moitié échappe au périmètre. L’inventaire n’est donc pas une liste d’actifs figée : c’est une assertion datée, corrélée entre plusieurs sources, sur l’existence, l’état et le propriétaire d’un terminal.

Conserver au minimum, pour chaque poste, un identifiant matériel stable, le système d’exploitation et sa version, l’architecture processeur, le niveau de correctif, le statut de chiffrement, l’utilisateur principal, l’unité métier, le groupe de déploiement et la dernière date de contact. Sur Windows, l’identifiant de périphérique géré et le numéro de série servent de corrélation. Sur macOS, le numéro de série et l’identifiant de gestion sont plus fiables que le nom d’hôte. Sur Linux, une identité d’agent associée à une empreinte de machine évite de confondre des clones de machines virtuelles.

Aucune source unique n’est suffisante. Réconcilier la gestion des terminaux, l’annuaire, le contrôle d’accès réseau, le service de détection et réponse sur les terminaux, ainsi que l’inventaire de configuration. L’annuaire décrit souvent une intention administrative. L’agent de sécurité décrit une machine observée. Le réseau décrit une machine présente. Lorsqu’ils divergent, l’équipement doit passer dans une file d’exception, pas disparaître dans un graphique vert très zen.

Définir une autorité de vérité par attribut. L’outil de gestion des terminaux fait foi pour la version installée et la réussite du déploiement. La gestion des identités fait foi pour le propriétaire métier. La base de gestion de configuration fait foi pour la criticité de service. Sans cette séparation, une donnée erronée peut être recopiée dans quatre systèmes et devenir vraie par épuisement collectif.

Les postes non joignables depuis plus d’une durée définie doivent être distingués des postes simplement éteints. Une échéance de 14 jours est souvent défendable pour un terminal nomade, sous réserve que l’agent puisse recevoir les politiques hors réseau interne. Au-delà, suspendre les accès sensibles ou imposer une réinscription. Un poste absent trois mois n’est pas « conforme parce qu’il n’a rien signalé » : c’est un meuble informatique avec un compte actif.

L’architecture d’identité conditionne aussi le patching. Un appareil non conforme doit perdre l’accès aux applications à risque sans bloquer les mécanismes permettant sa remédiation. Les règles d’accès conditionnel, les certificats machine et les groupes de conformité doivent donc préserver les flux vers le service de gestion, les dépôts de paquets et le relais d’authentification. La page sur les identités et contrôles d’accès aide à cadrer cette dépendance.

Priorisation des correctifs exploités activement

La sévérité technique seule ne pilote pas un déploiement. Un score de vulnérabilité élevé mesure des caractéristiques de la faille, pas l’exposition réelle du parc ni son exploitation. Prioriser en premier les vulnérabilités exploitées activement, puis celles qui permettent une élévation de privilèges locale, une exécution de code à distance ou un contournement de contrôle sur un logiciel effectivement installé.

La liste des vulnérabilités connues comme exploitées, publiée notamment par la Cybersecurity and Infrastructure Security Agency (CISA), est un bon signal de départ. Elle ne remplace pas l’analyse locale : un correctif pour un composant absent n’a aucune urgence opérationnelle, tandis qu’une faille moins médiatisée dans un outil d’administration présent partout peut justifier une action immédiate. Croiser quatre éléments :

preuve ou renseignement d’exploitation active ;
présence du produit et de la version vulnérable ;
exposition, par exemple navigateur, messagerie, accès distant ou privilège local ;
capacité de confinement si le correctif doit attendre.

La règle de décision doit être écrite avant l’incident. Pour une vulnérabilité exploitée activement sur un logiciel exposé et installé, lancer le test accéléré immédiatement, puis déployer largement dès validation des fonctions critiques. Ne pas attendre le prochain cycle mensuel par fidélité à un calendrier. Les attaquants lisent aussi les calendriers, avec une discipline qui force un respect assez pénible.

Les correctifs du système d’exploitation ne doivent pas évincer ceux des navigateurs, lecteurs de documents, outils de visioconférence, environnements d’exécution et clients d’accès distant. Dans un parc hétérogène, les applications tierces constituent souvent la plus grande surface d’attaque, parce que chaque éditeur a inventé sa propre idée de la mise à jour discrète. Centraliser leur état ou bloquer les versions obsolètes est préférable à la chasse manuelle.

Une mesure de conformité doit distinguer « correctif téléchargé », « installé », « redémarrage requis » et « version vérifiée après redémarrage ». Un poste qui attend son redémarrage depuis dix jours reste vulnérable si le correctif ne charge ses composants qu’au démarrage. Compter ce poste comme conforme revient à déclarer un parachute opérationnel tant qu’il est dans son emballage.

Pour relier cette discipline à la détection et à l’exposition, consulter les pages sur les menaces et les failles. Le patch management réduit une fenêtre d’exploitation, il ne détecte ni une compromission déjà présente ni un abus d’identifiants valides.

Fenêtres de test et anneaux de déploiement

Un anneau de déploiement est un groupe de postes recevant les correctifs avant le reste du parc. Il ne doit pas être composé uniquement de volontaires techniques, de machines de laboratoire ou de postes récemment réinstallés. Ces groupes produisent de jolis taux de succès et ne détectent pas les incompatibilités qui frappent les applications métier, les pilotes spécialisés, les périphériques USB et les configurations anciennes que personne n’ose regarder de trop près.

Constituer au moins trois anneaux :

un anneau pilote, représentatif des systèmes, modèles matériels, applications critiques et profils réseau ;
un anneau étendu, couvrant chaque unité métier et chaque classe matérielle ;
un anneau général, pour le reste du parc.

Un quatrième anneau d’urgence est nécessaire pour les correctifs exploités activement. Il doit contenir des postes représentatifs avec des propriétaires joignables, sans être réduit aux équipes informatiques. La qualité d’un test dépend de la représentativité de ses conditions, pas du nombre de tableaux de bord produits autour.

Avant chaque vague, définir des critères d’arrêt observables : échec d’installation supérieur à un seuil, hausse des incidents applicatifs, démarrage anormalement long, échec de connexion réseau, perte de certificat, boucle de redémarrage ou déclenchement d’alerte de sécurité. Définir aussi la durée de l’observation. Pour les mises à jour applicatives, quelques heures peuvent suffire si les parcours métier sont joués. Pour un noyau Linux, un pilote ou une mise à jour majeure de système, attendre au moins un cycle d’usage réel incluant veille, reprise, impression, accès distant et redémarrage.

La fenêtre de test n’est pas une permission d’attendre indéfiniment. Une faille exploitée activement impose une fenêtre courte et instrumentée. À l’inverse, une mise à jour de fonctionnalité sans bénéfice de sécurité immédiat mérite un anneau pilote long. La question qui tranche n’est pas « quelle est la meilleure pratique ? », formule qui finit toujours dans une slide, mais « quelle perte est la plus irréversible : exposition connue ou interruption de service ? ».

Documenter les dépendances de distribution : capacité des relais, accès aux dépôts externes, certificats de proxy, authentification machine, espace disque, alimentation électrique pour les portables, et disponibilité des sauvegardes. Un correctif téléchargé via un proxy qui intercepte le trafic sans chaîne de certificats déployée échoue souvent de manière intermittente. Intermittent est le mot poli pour désigner une investigation qui mange trois jours.

Exemple de contrôle et rollback Windows

Le rollback doit être préparé avant le déploiement, mais jamais présumé possible. Certaines mises à jour cumulatives Windows peuvent être désinstallées, d’autres exigent une restauration système ou une image de récupération. Une mise à jour de micrologiciel, une migration de version majeure ou une modification de structure de disque n’offre pas nécessairement de retour arrière propre.

L’exemple suivant vérifie la présence d’un correctif Windows identifié par son numéro de base de connaissances, puis le désinstalle avec l’outil natif. L’exécuter uniquement sur un groupe de récupération validé, avec droits administrateur locaux et après vérification que le correctif ciblé est bien celui qui provoque l’incident.

# Vérifier que le correctif KB5039999 est installé avant toute désinstallation.
$hotfix = Get-HotFix -Id KB5039999 -ErrorAction SilentlyContinue

if ($null -eq $hotfix) {
    Write-Host "Correctif KB5039999 absent : aucun rollback à lancer."
    exit 0
}

# Désinstaller le package Windows Update et laisser le système demander un redémarrage.
Start-Process -FilePath "wusa.exe" `
    -ArgumentList "/uninstall /kb:5039999 /quiet /norestart" `
    -Wait

# La vérification finale doit intervenir après redémarrage.
Write-Host "Désinstallation demandée. Redémarrer puis contrôler Get-HotFix."

Ce mécanisme ne remplace pas une restauration de données. Il retire un package, pas les effets d’une corruption applicative, d’une migration de schéma ou d’un pilote ayant endommagé un périphérique. Pour macOS et Linux, préférer les mécanismes natifs documentés par la distribution ou l’éditeur de gestion, avec un cache local de la version antérieure lorsque le paquetage le permet.

Exploitation, secrets et reprise

Le service de patching détient souvent des privilèges élevés sur chaque poste. Son compte de service, ses jetons d’API (Application Programming Interface), ses certificats d’authentification et ses clés de signature forment une cible prioritaire. Séparer les rôles de création de paquet, approbation et déploiement. Un opérateur capable de pousser un script arbitraire sur tous les postes ne doit pas pouvoir modifier seul l’approbation de sécurité. Sinon, le patch management devient un outil de déploiement de rançongiciel avec une console très bien rangée.

Protéger les secrets dans un coffre dédié, les faire tourner selon une échéance définie et journaliser chaque usage administratif. Vérifier la révocation : un certificat retiré d’une autorité ne coupe pas les sessions déjà établies ni les jetons déjà émis. Le contrôle doit donc inclure des durées de session limitées et une réauthentification des agents.

Sauvegarder la configuration des anneaux, les politiques, les paquetages approuvés, les journaux d’exécution et les procédures de récupération. Une sauvegarde sans test de restauration est une déclaration philosophique, pas un dispositif de reprise. Tester la reconstruction d’une console, le réenrôlement d’un poste, la restauration des politiques et l’accès aux dépôts lorsque le service central est indisponible.

Superviser les indicateurs qui déclenchent une décision : couverture d’inventaire, âge du dernier contact, délai médian de déploiement, taux d’échec par modèle matériel, machines bloquées au redémarrage, taux de rollback et postes non conformes par criticité. Un taux global masque facilement une classe de machines à 0 % de réussite. Les moyennes ont cette élégance : elles noient les problèmes sans faire de bruit.

🐝 Ce qui arrive si on s’en passe

Sans gestion des correctifs, chaque publication d’un éditeur devient une notice d’exploitation : la comparaison entre version corrigée et version vulnérable révèle le code fautif, et l’écart entre publication et installation reste ouvert sans limite sur les postes oubliés. Une élévation de privilèges locale non corrigée transforme alors un simple accès utilisateur, obtenu par exemple via un document piégé, en droits administrateur sur le poste, puis en accès aux secrets de session qui y sont stockés. En réponse à incident, l’absence d’état de version fiable empêche de délimiter l’enquête : impossible de dire quels postes étaient vulnérables, ni depuis quand. Enfin, les systèmes et applications arrivés en fin de support cessent de recevoir tout correctif sans que ce basculement soit constaté, et restent exposés à chaque faille découverte ensuite.

🦫 Explication de la marmotte 🍫

La gestion des correctifs commence par une liste fiable des ordinateurs. Pour chaque appareil, il faut connaître son système, les programmes installés, la personne ou le service qui en dépend et la date à laquelle il a été vu pour la dernière fois. Plusieurs sources sont comparées, car une liste seule peut contenir des appareils disparus ou oublier des appareils réels.

Quand une faille est découverte, la priorité dépend surtout de son exploitation par des attaquants, de la présence du programme concerné et de son exposition. Un problème déjà utilisé contre des victimes est traité avant une faiblesse théorique, surtout si le programme est accessible depuis Internet ou ouvre des documents reçus.

Le correctif est d’abord installé sur un petit groupe de postes représentatifs. On vérifie le démarrage, les programmes métier, le réseau, les imprimantes et les redémarrages. Si les résultats sont bons, le déploiement avance vers un groupe plus grand, puis vers tout le parc. Si un défaut apparaît, on suspend la vague pour éviter de multiplier les pannes.

Le retour arrière doit être prévu avant l’installation. Selon le type de mise à jour, on peut retirer le correctif, restaurer un appareil ou reconstruire son système. Cela ne répare pas automatiquement les données déjà abîmées. Les accès utilisés pour envoyer les correctifs sont très puissants : ils doivent être protégés, surveillés et renouvelés. Enfin, les sauvegardes et la restauration sont testées, car un plan non testé échoue généralement au pire moment.

Pages voisines

La citent

Patch management d’un parc de postes hétérogène

Elle cite

: les deux pages se citent l’une l’autre.

Patch management d’un parc de postes hétérogène

Patch management d’un parc de postes hétérogène

Inventaire de parc et autorité de vérité

Priorisation des correctifs exploités activement

Fenêtres de test et anneaux de déploiement

Exemple de contrôle et rollback Windows

Exploitation, secrets et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines