Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Il existe cinq types distincts de correctifs : traditionnels, virtuels, de micrologiciel, en direct et dans le cloud/en conteneur, chacun présentant ses propres caractéristiques en matière de temps d'arrêt, de risques et de conformité.
- La plupart des équipes continuent de recourir par défaut à la méthode consistant à appliquer les correctifs puis à redémarrer, ce qui laisse les systèmes exposés pendant des jours, voire des semaines, tandis que les fenêtres de mise à jour s'accumulent.
- La mise à jour à chaud permet d'appliquer des correctifs au noyau et aux bibliothèques sur des systèmes en cours d'exécution sans redémarrage, réduisant ainsi le temps de correction de plusieurs semaines à quelques heures.
- La stratégie de mise à jour appropriée dépend de vos exigences en matière de disponibilité, des accords de niveau de service (SLA) réglementaires et des couches de votre infrastructure dont vous avez effectivement la maîtrise.
Il est 23 h un dimanche soir. Un membre de votre équipe surveille de près une fenêtre de maintenance, car trois serveurs de production ont besoin d’un correctif CVE pour le noyau, et la seule façon sûre de l’appliquer – selon le guide de 2014 – est de redémarrer. Le correctif lui-même pèse deux mégaoctets. L’indisponibilité dure 40 minutes par hôte. Multipliez cela par un parc de quelques centaines de serveurs, et cette « correction de sécurité rapide » se transforme en un quart d’heure que vous ne récupérerez pas.
C'est pourquoi le type de correctif que vous choisissez a une réelle importance. Une approche adéquate peut réduire la fenêtre de maintenance de plusieurs heures à quelques secondes, voire la supprimer complètement. Une mauvaise approche vous expose à une vulnérabilité CVE connue pendant des semaines, car vous ne parvenez pas à obtenir l'autorisation de redémarrer le système.
Certaines méthodes dites de « correction » n'en sont en réalité pas du tout. Voici le guide complet qui vous aidera à y voir plus clair parmi les différentes solutions de correction disponibles.
Qu'est-ce qu'un correctif logiciel ?
La mise à jour logicielle est à la fois un processus informatique et une pratique de sécurité fondamentale. Elle est généralement définie comme le processus consistant à corriger des problèmes ou à ajouter des fonctionnalités à un système donné en ajoutant ou en remplaçant des composants existants par des versions mises à jour. Cela peut se faire à différents niveaux, par exemple en mettant à jour le code au niveau d'un sous-système, d'une dépendance ou d'une fonctionnalité de base. De même, il est possible de mettre à jour des applications spécifiques, des systèmes d'exploitation, des pilotes ou tout autre composant.
Si l'objectif est toujours de disposer d'une version plus récente du logiciel concerné par le correctif, c'est la manière d'y parvenir qui distingue les différentes approches en matière de correctifs ; or, c'est en les considérant comme une seule et même catégorie que les équipes se retrouvent avec des vulnérabilités non corrigées qui persistent pendant des mois dans leur environnement de production.
Comme d'autres termes informatiques, tels que le « débogage », le terme « patching » trouve son origine dans un processus physique. Il faisait référence au fait de boucher les trous des cartes perforées ; en d'autres termes, on « patchait » une partie du code. Cette pratique semble être tombée en désuétude ; nous aborderons donc plutôt les approches plus modernes.
La différence entre un correctif, une mise à jour et une version complète
Avant d'aborder les différents types de correctifs, il convient de clarifier un point terminologique qui prête souvent à confusion dans la pratique. Les termes « correctif », « mise à jour » et « version complète » sont souvent utilisés de manière interchangeable – parfois par une même personne au cours d'une même conversation – alors qu'ils désignent des concepts bien distincts, notamment lorsqu'il s'agit de définir le périmètre d'une intervention ou de s'adresser à un auditeur de conformité.
|
Patch |
Mise à jour |
Communiqué complet |
|
|
Définition |
Correction ciblée pour un bug, un CVE ou une régression spécifique |
Ensemble de correctifs et d'améliorations mineures |
Nouvelle version majeure comportant des modifications architecturales ou des nouvelles fonctionnalités |
|
Champ d'application |
Restreint – il s'agit souvent d'un seul fichier binaire ou d'un seul module du noyau |
Modéré – plusieurs composantes |
Portée étendue – l'ensemble du produit, parfois de nouvelles dépendances |
|
Conséquences des temps d'arrêt |
Très peu, voire pas du tout (avec le live patching, zéro) |
Un redémarrage ou une réinitialisation du service est généralement nécessaire |
Important – peut nécessiter un plan de migration |
|
Déclencheur typique |
Publication d'une vulnérabilité (CVE), correctif, rapport de régression |
Fréquence mensuelle ou trimestrielle |
Étape clé de la feuille de route, fin de vie de la version précédente |
Une règle empirique raisonnable : si vous pouvez décrire la modification en une seule phrase, il s'agit d'un correctif. Si les notes de mise à jour font plus d'un paragraphe, il s'agit d'une mise à jour. Si un guide de migration est fourni, il s'agit d'une version complète.
Il y a toutefois un aspect que le tableau ne reflète pas : les éditeurs de logiciels étiquettent parfois leurs mises à jour de manière trompeuse pour les faire paraître moins perturbantes. Une « mise à jour mineure » qui remplace discrètement le pilote de base de données sous-jacent s'apparente, sur le plan fonctionnel, davantage à une version complète. Lisez le journal des modifications avant de vous fier à l'étiquette.
Principaux types de rapiéçage : un aperçu complet
Les types présentés ci-dessous couvrent la grande majorité des cas auxquels sont confrontées la plupart des équipes de sécurité et de DevOps. Certains se recoupent : un correctif de micrologiciel est également un correctif de sécurité, et l'application de correctifs à chaud s'applique aussi bien aux serveurs Linux traditionnels qu'aux charges de travail conteneurisées. Ces catégories ne s'excluent pas mutuellement, mais chacune décrit un mécanisme de déploiement distinct, avec son propre profil opérationnel.
Patching traditionnel
C'est ce que la plupart des gens appellent le patching. Il s'agit de télécharger des versions mises à jour d'un logiciel donné, puis de remplacer les fichiers correspondants sur le disque par les nouvelles versions.
C'est relativement simple à mettre en œuvre et facile à comprendre : vous disposez d'une ancienne version d'un logiciel donné qui est remplacée par une nouvelle version, soit entièrement, soit partiellement. Vous devez redémarrer l'application ou le système pour que la nouvelle version soit prise en compte, mais il n'y a pas d'autres éléments à prendre en compte. Bien sûr, c'est là que réside le principal inconvénient : le redémarrage des applications ou de l'ensemble du système est une opération lente qui perturbe considérablement les tâches en cours d'exécution. De ce fait, ce n'est pas quelque chose qui peut être fait de manière ponctuelle ; cela se déroule donc généralement pendant ce qu'on appelle une « fenêtre de maintenance », une période pré-approuvée pendant laquelle on s'attend à ce que les systèmes connaissent des problèmes de disponibilité ou de performances.
La mise en place de ce processus est longue et, en cas de problème, il est fréquent que les délais prévus soient dépassés. Selon un rapport du Ponemon Institute commandité par TuxCare, 56 % des organisations mettent entre cinq semaines et un an pour corriger les vulnérabilités critiques ou hautement prioritaires – et plus de 55 % ont déclaré avoir subi un incident de cybersécurité causé par un correctif qui était déjà disponible mais qui n’avait pas été appliqué. Ce retard est principalement dû à la planification des fenêtres de mise à jour, et non à l’installation elle-même.
Utilisez-le lorsque vous disposez d'une fenêtre de maintenance suffisante, d'un environnement de test stable et qu'aucune contrainte de conformité n'exige une correction plus rapide. Ne comptez pas uniquement sur cette stratégie si vous exécutez des applications qui ne supportent pas un redémarrage régulier.
Patching virtuel
Il s'agit d'une solution dont le nom comporte le terme « patch » et qui, à première vue, semble fournir des résultats de correction, mais qui, en réalité, fonctionne à un tout autre niveau. Le « patch virtuel » n'implique en effet aucun remplacement ni aucune correction effective du code. Il consiste à mettre en place une détection des menaces au niveau du pare-feu, afin de bloquer les schémas d'attaque connus. Du point de vue de l'attaquant, l'attaque échoue ; celui-ci peut donc supposer que le système a été corrigé, alors qu'en réalité, ce n'est pas le cas.
Cette méthode de « correctifs » présente plusieurs inconvénients : elle ne permet à aucun moment d'intégrer un code corrigé dans les systèmes, la protection ne couvre que les schémas d'attaque connus – ce qui exclut d'emblée les problèmes d'ordre strictement local – et elle peut être contournée par des modifications du trafic réseau correspondant à une menace donnée.
Si ces inconvénients ne suffisent pas à écarter d'emblée cette approche, ses avantages comprennent l'absence de perturbation (puisqu'aucune intervention n'est effectuée à l'intérieur du système), la possibilité de couvrir plusieurs systèmes avec un seul déploiement, ainsi qu'une protection immédiate contre les nouvelles menaces exclusivement à distance dès leur apparition.
Considérez les correctifs virtuels comme une solution provisoire, et non comme une fin en soi. Lorsqu’une vulnérabilité majeure est révélée et que votre équipe a besoin de quelques jours plutôt que de plusieurs semaines pour déployer le correctif définitif, un correctif virtuel vous offre un répit précieux. Cependant, s’il est toujours en place six mois après la divulgation, cela signifie que vous avez cessé d’appliquer des correctifs et que vous vous êtes lancé dans un jeu de hasard.
Utilisez-le lorsque vous devez atténuer une vulnérabilité CVE plus rapidement que vous ne pouvez appliquer le correctif définitif, ou si vous utilisez un logiciel en fin de vie qui ne reçoit plus de correctifs de la part du fournisseur.
Mise à jour des microprogrammes
La mise à jour du micrologiciel est un cas particulier de la mise à jour traditionnelle, avec cette particularité supplémentaire que l'on modifie du code contenu dans des supports de stockage généralement difficiles à mettre à jour – directement dans des puces EPROM (mémoire morte programmable et effaçable). C'était autrefois la norme pour les premiers appareils intelligents et les appareils IoT de première génération. Le logiciel était chargé en usine et ne recevait que rarement, voire jamais, de mises à jour. Cela s’expliquait en partie par le fait que la mise à jour et la sécurité n’étaient pas des préoccupations majeures comme elles le sont aujourd’hui, mais aussi parce que la manière dont le logiciel était stocké rendait la mise à jour difficile. Les appareils plus récents ont leur code, en tout ou en partie, écrit sur des supports plus courants tels que des SSD, des cartes SD ou similaires, qui sont beaucoup plus faciles à modifier.
Lorsque le code s'exécutait sur des puces qui devaient être connectées à du matériel d'écriture spécialisé, nécessitant des logiciels propriétaires et des câbles spécifiques, cela ajoutait une couche de complexité qui rendait l'ensemble du processus très peu attrayant pour la plupart des équipes informatiques. En conséquence, ces appareils ne recevaient tout simplement jamais de mise à jour pendant toute leur durée de vie utile. Malheureusement, beaucoup d'entre eux sont encore en service : les serveurs d'impression, les caméras IP et les capteurs de centres de données sont tous de bons exemples d'appareils fonctionnant de cette manière.
La mise à jour du micrologiciel est également celle qui présente le plus de risques sur le plan opérationnel. Une mise à jour du BIOS mal exécutée rend la machine inutilisable, et lorsqu'il s'agit de revenir en arrière, la réponse est souvent « impossible ». Les fabricants ne font pas tous preuve de la même cohérence quant à la fréquence de publication des mises à jour de micrologiciel et à la rigueur de leurs tests : les fabricants de serveurs sont généralement fiables, mais il en va tout autrement pour le matériel IoT et grand public.
Pour les appareils IoT et embarqués fonctionnant sous Linux, il existe une solution intermédiaire qui mérite d'être connue. KernelCare IoT de TuxCare permet d'appliquer des correctifs au noyau sans redémarrage sur les appareils ARM64. Cette solution prend en charge les distributions basées sur Raspberry Pi, Ubuntu et Yocto, ainsi que divers chipsets tels que Arm Neoverse, NXP et AWS Graviton, et s'intègre à Microsoft Azure IoT Hub pour la gestion de parcs d'appareils. Elle contourne ainsi complètement le problème classique lié à la mise à jour du micrologiciel au niveau du noyau.
Appliquez-le à une fréquence définie – tous les trimestres est raisonnable pour la plupart des flottes – toujours après avoir effectué des tests sur du matériel représentatif, et ne sautez jamais l'étape de vérification post-flash.
Correctifs en temps réel
Le « live patching » est le processus qui consiste à modifier du code en cours d'exécution et à remplacer des sections ou des fonctions présentant des bogues connus par des versions corrigées de ces mêmes sections. Cette opération s'effectue entièrement en mémoire et ne nécessite pas de redémarrer l'application pour que les nouvelles modifications soient prises en compte. À un moment donné, le logiciel contient un bogue dans une fonction ; l'instant d'après, c'est une version corrigée de cette fonction qui est utilisée à la place.
Il n'y a ni redémarrage, ni réinitialisation, ni interruption. De ce fait, les correctifs peuvent être déployés immédiatement : l'opération ne nécessite pas de fenêtre de maintenance, ce qui permet de réagir plus rapidement aux menaces émergentes. Au lieu d'attendre des semaines, voire des mois, pour qu'un correctif soit déployé, comme c'est le cas avec les procédures traditionnelles, cela peut désormais se faire en quelques heures, voire quelques minutes, dès qu'un correctif est disponible.
La complexité supplémentaire liée au patch en direct réside dans la phase de création du patch. Celui-ci doit être conçu de manière à pouvoir être chargé dans l'espace mémoire approprié, en respectant les mêmes tailles de variables et les mêmes alignements que le code d'origine. Cette complexité est masquée aux utilisateurs d'une solution de patch en direct ; elle n'est visible que pour le fournisseur du patch en direct.
Un sous-système de correction en temps réel permet depuis plus de dix ans désormais de déployer des correctifs au sein du noyau Linux, et plusieurs solutions différentes ont vu le jour. KernelCare de TuxCare est l'une de ces solutions, prenant en charge l'application de correctifs en direct du noyau Linux sur toutes les principales distributions. LibCare étend cette fonctionnalité aux bibliothèques critiques de l'espace utilisateur – notamment OpenSSL et glibc, qui sous-tendent le chiffrement et les appels système de base de pratiquement toutes les charges de travail Linux – sans nécessiter de redémarrage des services. Ensemble, elles couvrent la surface d'attaque la plus à risque sur un serveur Linux sans empiéter sur les fenêtres de maintenance.
Il existe également de nombreuses variantes du correctif en direct, qu'il s'agisse de solutions temporaires ou permanentes, selon que ce processus est mis en œuvre à titre de solution provisoire ou comme alternative plus durable aux correctifs traditionnels.
Utilisez-le lorsque vous utilisez Linux à une échelle significative, que vous gérez des charges de travail réglementées avec des SLA de correction stricts, ou que vos parties prenantes considèrent tout redémarrage imprévu comme un incident critique.
Mises à jour des applications dans le cloud et les conteneurs
Les charges de travail dans le cloud et les conteneurs modifient le modèle d'une manière qu'il convient de bien comprendre, car les principes qui s'appliquent aux serveurs traditionnels ne s'y transposent pas sans difficulté.
La correction des conteneurs s'effectue généralement en reconstruisant l'image et en déployant une nouvelle version : l'ancien conteneur est alors remplacé par un nouveau contenant le correctif. Dans la plupart des workflows, on évite délibérément toute modification en cours d'exécution d'un conteneur ; l'immuabilité est le principe de conception, et c'est un principe judicieux. Cela signifie toutefois qu'une image de base vulnérable peut persister discrètement dans de nombreux conteneurs en cours d'exécution si le processus de reconstruction n'est pas correctement géré.
Dans les environnements cloud, les responsabilités sont réparties selon le modèle de responsabilité partagée. Avec l'IaaS, le fournisseur applique les correctifs à l'hyperviseur et aux hôtes physiques ; vous êtes responsable du système d'exploitation invité, de l'environnement d'exécution et de la couche applicative. Avec le PaaS, le fournisseur gère une plus grande partie de la pile. Avec le SaaS, vous vous occupez principalement des agents et des intégrations. Savoir exactement quelle couche vous incombe, c'est déjà la moitié du chemin : des équipes ont déjà essuyé de lourdes pertes en partant du principe que « le cloud s'en charge » pour quelque chose que le fournisseur ne couvre pas explicitement.
Ce que le modèle de conteneur ne change pas : le noyau Linux sous-jacent au moteur d'exécution du conteneur doit toujours être corrigé. Il s'agit de véritables systèmes exécutant de véritables noyaux comportant de véritables vulnérabilités (CVE), et les correctifs en temps réel s'appliquent à eux comme à n'importe quel autre hôte Linux.
Utilisez cette fonctionnalité lorsque vous utilisez Kubernetes, ECS ou toute autre plateforme d'orchestration de conteneurs. Associez la reconstruction des images à des correctifs en direct ou à des correctifs traditionnels pour le système d'exploitation hôte sous-jacent : l'abstraction du conteneur ne rend pas le noyau sous-jacent magiquement sécurisé.
Comment choisir la bonne stratégie de correction
Il existe de nombreuses façons d'aborder la gestion des correctifs, et aucune méthode ne convient à toutes les situations. Le choix approprié dépend d'une combinaison de facteurs – tant techniques qu'organisationnels – qui, ensemble, vous orientent vers une approche plutôt qu'une autre.
Voici quelques-uns des facteurs les plus importants :
Exigences en matière de disponibilité : Si un redémarrage de 5 minutes n'est pas un problème, les correctifs traditionnels couvrent la plupart des cas. Si une interruption imprévue constitue un incident critique, les correctifs en direct changent considérablement la donne.
Accords de niveau de service (SLA) relatifs à la correction des incidents : Des référentiels tels que PCI DSS et HIPAA précisent dans quels délais les correctifs critiques doivent être appliqués. Si votre SLA est de 30 jours et que vos fenêtres de mise à jour sont mensuelles, vous n'avez aucune marge de manœuvre en cas de problème.
Composition de la pile : Les parcs informatiques à forte composante Linux tirent le meilleur parti des correctifs en direct. Les parcs Windows s'appuient sur les correctifs traditionnels, en recourant aux correctifs virtuels à titre de solution provisoire. Les appareils embarqués et IoT nécessitent des correctifs de micrologiciel, domaine dans lequel la plupart des équipes sous-investissent de manière chronique.
Maturité opérationnelle : Les environnements de test automatisés et les procédures de restauration fiables déterminent quelles stratégies sont viables. Sans eux, chaque type de correctif comporte plus de risques qu'il ne le devrait.
Un cadre pratique pour les situations courantes :
- Disponibilité impérative, parc Linux → application de correctifs en direct pour le noyau et les bibliothèques partagées critiques, application de correctifs traditionnelle pour tout le reste à un rythme plus souple
- Fenêtres de maintenance acceptables, environnement homogène → les correctifs traditionnels, associés à une forte automatisation, couvrent la plupart des besoins
- Vous êtes coincé avec un logiciel en fin de vie que vous ne pouvez pas encore remplacer → le patch virtuel associé à une surveillance intensive est la seule solution provisoire raisonnable
- Le parc comprend des serveurs physiques, des équipements réseau ou des appareils IoT → prévoir un budget pour la mise à jour des micrologiciels en tant que programme distinct, séparé de la mise à jour du système d'exploitation
Pour toute organisation soucieuse, même modestement, de la sécurité de ses systèmes, de ses données et de ses utilisateurs, la gestion des correctifs est l'une des priorités fondamentales qui doit être prise en compte tant au niveau stratégique qu'opérationnel. Chaque environnement présentant ses propres particularités, veillez à choisir le processus le mieux adapté à votre situation spécifique.
Vous devez encore redémarrer pour installer un correctif ? Il existe une meilleure solution.
Si votre processus actuel consiste à « programmer un redémarrage, espérer que tout fonctionne, et recommencer le mois suivant », vous vous imposez une charge de travail inutile et vous acceptez une période d'exposition plus longue qu'il ne le faudrait. Le correctif à chaud existe justement parce que le modèle du redémarrage obligatoire n'est pas une loi physique : c'est une habitude héritée d'une époque où il n'y avait pas d'autre solution.
Les solutions KernelCare et LibCare de TuxCare permettent l'application de correctifs en temps réel pour les noyaux Linux et les bibliothèques partagées critiques – notamment OpenSSL et glibc – sur toutes les principales distributions. Pas besoin de redémarrer les serveurs ni de prévoir de fenêtres de maintenance pour les correctifs de sécurité. Et si votre parc comprend des appareils IoT ou embarqués, KernelCare IoT étend cette fonctionnalité de correctifs sans redémarrage aux appareils ARM64 fonctionnant sous Raspberry Pi, Ubuntu et les distributions basées sur Yocto.
FAQ
Oui. Les correctifs sont du code, et le code comporte des bogues. La régression – c'est-à-dire lorsqu'un correctif perturbe le fonctionnement d'un élément qui marchait auparavant ou introduit un nouveau défaut – est un risque connu et documenté. C'est pourquoi un environnement de test calqué sur l'environnement de production n'est pas facultatif, et pourquoi les déploiements par étapes sont préférables à un déploiement simultané sur l'ensemble du parc.
Cette responsabilité est généralement partagée entre les équipes informatiques, la sécurité et les équipes applicatives chargées de charges de travail spécifiques. Le service de sécurité définit le SLA et établit les priorités en fonction de la gravité des vulnérabilités CVE. L'équipe opérationnelle se charge du déploiement. Les responsables applicatifs vérifient que tout fonctionne correctement. Dans les petites structures, une seule personne assume ces trois rôles.
Correctifs de sécurité critiques : dès que le permet votre SLA, idéalement dans les 7 à 14 jours suivant leur publication par le fournisseur. Mises à jour de routine : une fréquence mensuelle est courante. Micrologiciels : tous les trimestres pour la plupart des parcs. Plus les correctifs peuvent être appliqués rapidement sans causer de dysfonctionnements, plus la fenêtre d'exposition est réduite – et l'application de correctifs en production est le principal moyen de raccourcir ce délai sans compromettre la rigueur des tests.
Les correctifs corrigent des failles de sécurité connues spécifiques en appliquant les modifications de code publiées par les éditeurs. Le renforcement de la sécurité du système réduit la surface d'attaque globale grâce à la configuration : désactivation des services inutilisés, application du principe du moindre privilège, renforcement des règles de pare-feu. Les correctifs comblent les failles connues ; le renforcement de la sécurité rend les failles inconnues plus difficiles à exploiter. Les deux sont indispensables.
Oui. Les conteneurs héritent des vulnérabilités de leurs images de base, et le système d'exploitation hôte sur lequel s'exécute le runtime du conteneur reste un système Linux qui nécessite des correctifs du noyau. Le modèle évolue – il s'agit désormais de reconstruire l'image plutôt que de modifier le conteneur en cours d'exécution –, mais cette obligation ne disparaît pas pour autant. Le modèle de responsabilité partagée répartit la charge des correctifs ; il ne la supprime pas.
