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
- Les correctifs sans redémarrage du noyau Linux permettent d'appliquer des correctifs de sécurité à un noyau en cours d'exécution, ce qui évite d'avoir à attendre le redémarrage pour que les mesures correctives prennent effet.
- Dans cet article de blog, nous nous intéressons à une équipe de cinq personnes chargée de gérer environ 10 000 systèmes de trading critiques sans qu'un seul redémarrage soit nécessaire pour appliquer les correctifs.
- Les intervalles entre les redémarrages ont doublé, passant d'environ six mois à environ un an, et sont désormais des opérations de maintenance facultatives.
- La suppression de la dépendance au redémarrage a permis de réduire la coordination entre les équipes et d'éviter que les mesures correctives liées à la norme PCI DSS ne figurent dans le calendrier de maintenance.
Une plateforme de trading peut résister à de nombreux incidents. Un redémarrage du noyau en plein milieu de l'exécution d'un ordre n'en fait toutefois pas partie.
Il existe un décalage entre le moment où un correctif du noyau est disponible et celui où le système de production est effectivement protégé. Une fois la mise à jour déployée, il faut trouver un créneau, obtenir l'autorisation d'appliquer la modification, coordonner les responsables des applications et redémarrer la machine. Les correctifs sans redémarrage du noyau Linux comblent ce décalage en appliquant les correctifs de sécurité éligibles au noyau en cours d'exécution, de sorte que la protection ne dépend plus du redémarrage.
Maintenant, imaginez l'ampleur du problème. Cinq ingénieurs. Environ 10 000 systèmes critiques répartis dans plusieurs centres de données, principalement basés sur RHEL et, pour la plupart, sur AlmaLinux. À cela s’ajoute la norme PCI DSS, ainsi que d’autres normes de sécurité et d’audit qui exigent que les vulnérabilités connues soient corrigées dans un délai bien plus court qu’une échelle de temps géologique.
C'était le cas chez un prestataire mondial de services financiers, où la disponibilité se répercute directement sur le chiffre d'affaires et où la moindre perturbation dans l'exécution des ordres a des répercussions sur les résultats financiers.
Quand la modification du noyau devient un projet opérationnel
Les correctifs nécessitant un redémarrage étaient déployés environ tous les six mois. Non pas parce que l'on considérait qu'une exposition de six mois était acceptable, mais parce que c'était le rythme que la coordination pouvait réellement supporter. La planification d'un seul cycle pouvait mobiliser plusieurs jours du temps du chef d'équipe avant même que l'ensemble de l'entreprise ne soit impliqué, et chaque responsable d'application et chaque responsable chargé d'approuver les modifications avait un avis différent sur le moment où un système pouvait être mis hors service.
Six mois, et le résultat n'était toujours pas à la hauteur. Les équipes chargées de la sécurité et de la conformité souhaitaient une correction plus rapide. L'équipe d'ingénieurs était déjà mise à rude épreuve à ce rythme. Ces deux situations étaient vraies en même temps, ce qui est généralement le signe que c'est le processus qui ne fonctionne pas, plutôt que les personnes qui le mettent en œuvre.
La majeure partie de ces coûts n'apparaît jamais dans la file d'attente des tickets. Elle est consacrée à la planification des interventions, à la préparation des retours en arrière et à la vérification des dépendances. Aucune de ces activités ne permet de corriger un seul CVE supplémentaire.
Les calculs relatifs aux créneaux de maintenance n'ont jamais fonctionné
Voici comment le chef d'équipe a décrit le problème de planification :
« Ces systèmes sont essentiels ; on ne peut pas les arrêter. Si on doit les arrêter, ce n’est que pendant certaines fenêtres de maintenance. Or, il était pratiquement impossible de respecter ces fenêtres, car elles sont trop courtes, et il faudrait environ 100 personnes pour tout redémarrer. »
C'est le calcul auquel toute entreprise privilégiant la haute disponibilité est tôt ou tard confrontée. Les délais se raccourcissent à mesure que l'activité s'internationalise, que le parc informatique ne cesse de s'agrandir et que les effectifs restent inchangés.
Avec quelques centaines de serveurs, on peut encore se contenter d’une approche « à la force brute » pour gérer un week-end de redémarrage et considérer cela comme un plan. Mais avec 10 000 systèmes critiques et une équipe de cinq personnes, cette approche n’est plus envisageable, et le retard accumulé dans l’application des correctifs devient une réalité permanente de l’environnement. Embaucher 100 personnes pour chaque vulnérabilité CVE du noyau ne constitue pas une stratégie.
Si votre capacité de redémarrage évolue au rythme de la croissance de votre parc informatique, les créneaux horaires programmés peuvent tout de même fonctionner. Dans le cas contraire, la seule véritable solution consiste à ne plus lier du tout la correction des vulnérabilités aux redémarrages.
Ce qu'a changé la mise à jour sans redémarrage pour une équipe de cinq personnes
Après avoir évalué plusieurs options, l'organisation a choisi la solution KernelCare de TuxCare et l'a déployée sur environ 10 000 de ses systèmes les plus critiques. Les tests ont démontré la fiabilité et la cohérence de la distribution des correctifs, et le déploiement a été géré de manière centralisée via ePortal, ce qui a permis à cinq personnes d'en assurer la supervision globale.
Le nombre de redémarrages obligatoires liés à l'application de correctifs est tombé à zéro. Des redémarrages ont toujours lieu, mais leur fréquence est passée d'environ six mois à environ un an, et leur objectif a évolué au fil du temps. Ils sont devenus des opérations de maintenance facultatives, et non plus des étapes préalables indispensables à la correction des vulnérabilités du noyau. La coordination entre les équipes pour l'application des correctifs du noyau a pratiquement disparu, tout comme la phase de planification qui la précédait autrefois.
La mise en place des correctifs a également évolué. Au lieu de voir les correctifs accumulés être déployés en une seule période critique, ceux-ci sont désormais appliqués en continu, ce qui évite que les risques ne s'accumulent sur les systèmes en service depuis longtemps.
Pourquoi cela est-il important pour la norme PCI DSS et les éléments probants d'audit ?
Les cadres de conformité mesurent le temps écoulé. L'effort fourni n'entre pas en ligne de compte. La norme PCI DSS exige que les correctifs de sécurité destinés à corriger les vulnérabilités critiques et à haut risque soient installés dans un délai défini après leur publication, et un auditeur demande des preuves attestant que ce délai a été respecté, plutôt qu'une explication des raisons pour lesquelles la fenêtre de maintenance a pris du retard.
Un cycle de six mois garantit un délai entre la mise à disposition d'un correctif et son application. Sur 10 000 systèmes, ce délai est consigné dans chaque rapport d'analyse, trimestre après trimestre. En supprimant le redémarrage de la procédure, on boucle le cycle sans ajouter la moindre fenêtre d'intervention au calendrier.
À qui s'adresse cet ouvrage ?
Quiconque exploite un système Linux à haute disponibilité soumis à des contrôles rigoureux avec une équipe plus réduite que ce que l'on pourrait considérer comme nécessaire mérite sans doute cette situation. Les plateformes de trading en sont l'exemple le plus évident, mais le même raisonnement s'applique aux bases de données, aux charges de travail en cluster, aux télécommunications, au traitement des paiements et à tout service en contact avec la clientèle où « il suffit de redémarrer » ne constitue pas une stratégie de sécurité.
Cette étude de cas explique pourquoi le cycle de six mois est devenu insoutenable, ce que l'équipe a pris en compte lors de l'évaluation de la mise en place de correctifs sans redémarrage, et comment cela a modifié la conformité et la charge de travail quotidienne par la suite, en reprenant en grande partie les propres termes de l'organisation. Il s'agit d'un texte concis, qui s'appuie davantage sur des chiffres que sur des descriptions.
Lire l'étude de cas dans son intégralité :
Assurer la sécurité des systèmes de trading mondiaux sans compromettre la disponibilité →
