Avez-vous déjà entendu parler d'un kit de gel des tuyaux ? A kit de gel des tuyaux forme un bouchon de glace à l'intérieur d'un tuyau d'eau, permettant au plombier d'effectuer des réparations sans couper l'eau.

Comme les canalisations d'eau, il y a des choses que vous ne voulez pas arrêter pour les réparer.

Redémarrer un système pour installer des mises à jour et des correctifs de sécurité n'est pas nécessaire, mais cela arrive tous les jours sous la forme d'un cycle de redémarrage de serveur. À l'inverse, l'installation de correctifs en direct d'un système Linux d'entreprise gèle les unités centrales de traitement (UC) pour installer les correctifs automatiquement, en quelques nanosecondes.

Il existe d'énormes différences entre les correctifs en direct de Linux et les cycles de redémarrage des serveurs.

Le live patching est un service par abonnement où des fournisseurs comme Canonical et KernelCare Enterprise gèrent l'ensemble du processus de gestion des correctifs. Un abonnement de 500 licences peut coûter plus de 10 000 dollars par an. Le cycle de redémarrage des serveurs repose sur le personnel et les ressources internes de l'entreprise, mais cela ne signifie pas qu'il est peu coûteux. Des études montrent qu'il est plus coûteux que le live patching. Au premier coup d'œil, les avantages du "live patching" sont évidents, mais de nombreuses entreprises utilisent encore le "server reboot cycling". Voyons pourquoi.

Avantages des cycles de redémarrage du serveur

Les grandes entreprises équipées de serveurs redondants, de répartiteurs de charge configurés et de contrats de niveau de service financés par des fonds publics disposent de l'infrastructure et des moyens financiers nécessaires pour réduire au minimum les perturbations de leurs opérations Linux.

Inconvénients des cycles de redémarrage du serveur

L'utilisation du cycle de redémarrage du serveur pour la gestion des correctifs présente de nombreux inconvénients.

Des fenêtres de temps critiques sont manquées. A 2019 étude menée par Ponemon Institute montre que sur 3 000 professionnels de l'informatique et de la sécurité, 62 % attribuent une violation de données au fait que leur entreprise n'a pas appliqué un correctif disponible.

La dotation en personnel est également un problème. L'étude révèle également que seuls 36 % des répondants estiment que leur entreprise dispose d'un personnel suffisant pour appliquer les correctifs assez rapidement.

La négociation des temps d'arrêt est compliquée, frustrante et nécessite d'innombrables heures de travail.

Enfin, le fait de pousser les composants à 100 % pendant la séquence d'autotest de mise sous tension (POST) peut entraîner une perte de données et une défaillance du matériel, le temps de démarrage étant la partie la plus problématique du processus de redémarrage de Linux.

C'est également coûteux

Bien que les cycles de redémarrage des serveurs tirent parti du personnel et des ressources internes, ils augmentent considérablement les coûts de gestion d'une entreprise sécurisée.

Les redémarrages perturbent les flux de revenus, en particulier sur les systèmes non redondants. Les heures supplémentaires Les heures supplémentaires payées par les employés pour les nuits et les week-ends augmentent encore plus les coûts. Les demandes répétées de temps d'arrêt érodent le capital politique de l'IT, car elles sont perçues comme exigeantes, ce qui affecte négativement les approbations pour d'autres besoins.

Formules de calcul du coût annuel de la gestion des vulnérabilités de sécurité par l'application de correctifs, support des preuves et études de cas qui montrent qu'à partir de 10 cycles de correctifs par an, les coûts se chiffrent en millions. Cliquez sur ici pour en savoir plus.

Comprendre le Live Patching de Linux

L'application de correctifs en direct consiste à déployer des correctifs dans un noyau Linux alors que le serveur est toujours en cours d'exécution et à le mettre à jour automatiquement. Il n'y a pas de redémarrage et les tâches de correction peuvent être réduites de 60 %.

A 2019 enquête sponsorisée par ServiceNow montre que 70 % des personnes interrogées estiment que l'automatisation est une étape essentielle pour améliorer la gestion des correctifs de leur organisation, et 80 % attribuent à l'automatisation la capacité de leur organisation à répondre aux vulnérabilités en moins de temps.

Ce qu'il est et ce qu'il n'est pas

L'application de correctifs en direct garantit une expérience transparente pour le client et permet un accès continu aux systèmes qui favorisent la productivité, les revenus, la sécurité et la conformité.

Les correctifs en direct du noyau réduisent le risque de perte de données, tandis que les négociations sur les temps d'arrêt, les horaires de travail irréguliers et la rémunération des heures supplémentaires disparaissent. L'attente anxieuse du prochain cycle de correction d'une vulnérabilité connue devient un ennui du passé.

Le prestataire de services de correction en direct teste les correctifs sur ses propres serveurs, dans son propre centre de sécurité des produits, comme la politique de KernelCare qui consiste à effectuer quatre tests sur les correctifs avant de les distribuer aux clients.

Les modifications du système et les corrections matérielles nécessitent des temps d'arrêt et des redémarrages. Ces événements dépassent le cadre du "live patching".

Le Live Patching de Linux est la voie à suivre

L'application de correctifs en direct au noyau Linux permet de sécuriser les systèmes sans temps d'arrêt dû au redémarrage des serveurs. Nos services de correction en direct KernelCare sont conçus pour maximiser la disponibilité du service tout en offrant une protection contre les vulnérabilités de sécurité, comme la tristement célèbre Heartbleed. Les mises à jour de sécurité se font sans douleur grâce à la technologie et au support offerts par les outils Enterprise Linux de KernelCare. Alors passez à l'étape suivante et parlez à un expert dès aujourd'hui !