TuxCare ELS : continuer à exploiter les anciennes versions de Linux de manière contrôlée

Ce qui complète TuxCare ELS

Lorsque le support régulier d'une distribution Linux prend fin, un serveur ne continue pas nécessairement à recevoir des mises à jour de sécurité via les sources de paquets habituelles. Cela pose un problème particulier lorsqu'une application métier reste liée à l'ancien environnement. Une assistance étendue peut permettre de gagner du temps pour une migration contrôlée, sans pour autant annuler la fin du support régulier.

TuxCare Assistance tout au long du cycle de vie for OS fournit des mises à jour de sécurité et certaines corrections de bogues pour les anciennes distributions prises en charge. Selon l'éditeur, cette offre couvre le noyau et une sélection de paquets importants, propre à chaque distribution. Elle n'installe pas de nouvelle version majeure de Linux : le serveur conserve sa version de distribution actuelle et bénéficie d'une maintenance supplémentaire pour les composants couverts.

Pour l'entreprise, cela peut constituer une solution transitoire importante : au lieu de devoir immédiatement migrer une application incompatible, il est possible de préparer la migration tout en installant les correctifs de sécurité disponibles pour les paquets concernés. Cela suppose toutefois que les paquets réellement nécessaires, l'architecture et l'offre choisie soient compatibles entre eux.

Le Couvercle de colis ne doit pas être assimilée à la sécurité de l'ensemble du serveur. Une application installée par vos soins, une extension ou un service provenant d'une autre source de paquets peut ne pas faire partie de l'offre du système d'exploitation. De même, les erreurs de configuration et les services inutilement accessibles ne disparaissent pas grâce à un abonnement ; ils doivent continuer à être vérifiés et sécurisés.

Même pour les paquets couverts, le niveau de gravité est déterminant : TuxCare prévoit des correctifs de sécurité pour les risques élevés et critiques à partir d'un score CVSS de 7. Pour les risques moyens, compris entre 4,0 et 6,9 sur l'échelle CVSS, des correctifs sont envisagés, selon le fournisseur, s'il n'existe aucune mesure d'atténuation et si la demande des clients est suffisante. TuxCare se réserve en outre le droit de proposer une mesure d'atténuation plutôt qu'une correction directe du code. Le fait qu'un paquet soit couvert ne signifie donc pas que toutes les vulnérabilités connues qu'il contient seront corrigées.

Ce qui est déterminant, ce n'est donc pas seulement de savoir si la distribution figure sur une liste de prise en charge. Pour Sécurité sous Linux recense les composants utilisés sur le serveur concerné, vérifie si des correctifs adaptés sont disponibles et si ceux-ci sont effectivement installés. ELS complète le processus de correction, mais ne remplace ni l'inventaire ni un plan de migration.

Vérifier la couverture et l'inventaire des serveurs

Avant de choisir TuxCare ELS, il faut Inventaire des serveurs. Notez la distribution, la version exacte, l'architecture et le noyau en cours d'exécution. Documentez également les sources de paquets configurées et les services accessibles au public ou depuis d'autres réseaux. Cela permet de comparer la liste des fabricants avec le système réel, plutôt que de se contenter de cocher le nom de la distribution.

Dans le cas d'un serveur web plus ancien, par exemple, l'inventaire doit inclure le paquet du serveur web, les bibliothèques cryptographiques, le moteur d'exécution PHP et les extensions PHP requises. Notez à chaque fois la provenance du paquet et la version installée. Une extension provenant d'un dépôt tiers peut avoir des conditions de maintenance différentes de celles d'un paquet issu de la distribution d'origine.

Vérifiez chacun de ces composants individuellement par rapport à la liste actuelle des paquets de la distribution concernée. Vérifiez également l'architecture et les conditions de l'offre prévue. Le fait qu’une distribution soit prise en charge ne signifie pas que chaque paquet qui y est installé ou chaque version d’un environnement d’exécution soit automatiquement couvert par ELS for OS. Même pour les paquets couverts, le traitement des vulnérabilités individuelles dépend, entre autres, de leur niveau de gravité.

On a particulièrement tendance à oublier les programmes compilés soi-même et les environnements d'exécution installés séparément. Une image de conteneur comporte également ses propres composants : la maintenance du système d'exploitation hôte ne garantit pas que les paquets contenus dans l'image soient à jour. Pour ces composants, tu as besoin d'une preuve distincte et d'un processus de mise à jour spécifique.

ELS pour OS et ELS pour les applications Il s'agit d'offres distinctes. La possibilité de maintenir une ancienne version de PHP via une offre supplémentaire dépend, entre autres, de la version, du format du paquet, de l'architecture et du mode d'acquisition. L'article consacré à CloudLinux Alt-PHP et ses aspects liés à la sécurité; cela n'est donc pas couvert par un abonnement TuxCare OS.

Bien comprendre les délais d'assistance

La date de fin du support n'a de sens que si elle est associée à la phase de maintenance correspondante. La fin de la maintenance régulière ne signifie pas toujours que toutes les offres payantes ou complémentaires prennent fin simultanément. Pour prendre une décision, tu dois donc noter à la fois la période concernée et les forfaits, architectures et conditions contractuelles couverts.

La documentation TuxCare actuellement disponible indique, pour les systèmes d'exploitation pris en charge, une durée de fonctionnement ELS garantie de 25 ans à compter de la date de fin de support initiale indiquée dans chaque cas. À titre d'exemple, elle cite le 30 juin 2049 pour CentOS 7 et le 31 mai 2048 pour Ubuntu 18.04. Il s'agit là d'informations fournies par l'éditeur concernant la période de support, et non d'un engagement valable pour chaque application installée.

Pour Ubuntu 18.04, Canonical distingue plusieurs phases : la maintenance standard a pris fin en mai 2023 ; Ubuntu Pro est pris en charge jusqu'en mai 2028. Le tableau récapitulatif actuel indique mai 2033 pour la couverture héritée supplémentaire. Ces offres ne sont pas comparables uniquement sur la base de leurs dates d'expiration, car le contenu des packs, l'architecture et les conditions contractuelles propres au serveur concerné sont déterminants.

Dans le cas d'un serveur web Ubuntu, par exemple, vérifiez si les paquets nécessaires sont bien inclus dans la version de maintenance choisie et comment les mises à jour s'intègrent dans le processus opérationnel existant. Une période plus longue n'est pas d'une grande utilité si un délai critique ou une extension dépasse le périmètre convenu.

Les délais mentionnés sont tirés des sites web des fabricants, dont le contenu est mis à jour en temps réel, sur la base des sources consultées au 4 novembre 2026. Il n'est pas toujours possible de vérifier rétrospectivement si toutes les informations actuelles étaient déjà en vigueur à cette date. Vérifie donc à nouveau les délais et les listes de forfaits avant la publication ou la conclusion du contrat, et respecte les nombre de consultations certain. Même un engagement de support à long terme ne garantit pas pour autant la sécurité globale d'un serveur.

Mise en place pratique d'un serveur CentOS 7

Supposons qu'un serveur web CentOS 7 doive continuer à exécuter temporairement une ancienne application métier. Avant de TuxCare ELS En sélectionnant cette option, vous recensez l'état réel du système et les dépendances de l'application. Ce qui importe, ce n'est pas seulement de savoir si CentOS 7 est pris en charge, mais aussi si les composants nécessaires à l'architecture existante sont bien couverts.

Tu peux exécuter les commandes suivantes dans un terminal sur le serveur. Elles permettent de récupérer l'identifiant de la distribution, l'architecture de la machine et la version du noyau en cours d'exécution ; elles ne modifient ni les paquets ni les sources des paquets. Note les résultats dans l'inventaire du serveur et compare-les avec le guide CentOS 7 actuel.

cat /etc/os-release
uname -m
uname -r

Complète ceci Inventaire des serveurs les sources de paquets configurées, les versions de paquets installées et les services accessibles au public. Dans le cas d'un serveur web, cela comprend notamment le paquet du serveur web, les bibliothèques de cryptographie, le moteur d'exécution PHP et les extensions. Notez également quels composants proviennent de sources externes ou ont été compilés par vos soins ; ils ne doivent pas être considérés comme faisant partie de la couverture du système d'exploitation sans avoir été vérifiés.

Pour CentOS 7, TuxCare indique comme conditions préalables une clé de licence valide, un accès root et des connexions HTTPS. Le guide fait également la distinction selon l'architecture : pour aarch64 et i686, il décrit la couverture de l'espace utilisateur, tandis que le correctif en direct du noyau n'est décrit que pour x86_64. Cette restriction concerne le guide CentOS 7 et ne peut pas être généralisée à d'autres distributions.

Pour l'application métier concernée, vérifiez ensuite que chaque paquet nécessaire figure bien dans la liste actuelle et comblez les lacunes restantes en contactant le fournisseur concerné. Même un noyau pris en charge et en cours d'exécution ne garantit pas à lui seul que l'application soit prise en charge, ni que toutes les mises à jour disponibles soient installées et actives.

Configurer le référentiel et déployer les mises à jour

Prévois la mise en place sous contrôle chaîne de contrôle: Tout d'abord, la licence, l'architecture et les paquets requis doivent être compatibles. Ensuite, vérifie si le serveur est autorisé à accéder via HTTPS aux cibles requises pour sa distribution. Pour l'enregistrement et la configuration du dépôt, suis les instructions officielles actuelles spécifiques à la distribution, car les prérequis et les adresses cibles peuvent changer.

Pour CentOS 7, TuxCare explique comment enregistrer le système, ajouter la source de paquets et une clé PGP. Cette source permet ensuite de récupérer les paquets appropriés ; elle n'installe toutefois pas automatiquement toutes les mises à jour disponibles. Après la configuration, vérifie que le dépôt est bien intégré comme prévu et que le gestionnaire de paquets propose les mises à jour appropriées.

Il faut tenir compte dans la planification de l'utilisation d'un proxy ou de règles de pare-feu sortantes restrictives. Pour plusieurs systèmes, un miroir local peut être envisagé après consultation de TuxCare. Ne reprenez pas aveuglément les adresses de destination indiquées dans une FAQ générale : vérifiez-les avant la mise en production en vous référant au guide d'installation actuel de la distribution choisie et au mode de fonctionnement prévu.

Testez d'abord les mises à jour disponibles dans un environnement de test aussi similaire que possible à celui de l'application métier. Vérifiez alors leur démarrage, les processus métier importants et les interfaces. Procédez ensuite à la validation opérationnelle et à l'installation sur le système de production ; documentez les versions des paquets, la date et le résultat, au lieu de considérer la simple activation du référentiel comme la fin de la procédure.

Si une mise à jour attendue n'est pas encore disponible, vérifie également le État du déploiement. Pour plusieurs plateformes, TuxCare déploie les mises à jour de manière échelonnée ; après leur publication dans le dépôt stable, cela peut prendre jusqu'à 14 jours supplémentaires. Si nécessaire, le fournisseur décrit une solution de contournement : n’utilisez-la qu’en suivant les instructions actuelles pour la distribution concernée et la version spécifique, et après validation par l’entreprise. La durée du déploiement n’implique aucune garantie quant au délai total de mise à disposition d’un correctif.

Prévoyez également une solution de secours et une fenêtre de maintenance adaptée. Les clés de licence ne doivent pas figurer dans les exemples de commandes publiés, les tickets ou les journaux non protégés. Pour l'enregistrement proprement dit, vous devez suivre les instructions actuelles du fabricant et ne fournir les identifiants d'accès que via les procédures prévues à cet effet.

Comparaison des différentes options de maintenance

Le choix entre TuxCare ELS et une maintenance étendue par le fabricant dépend de l'inventaire réel des paquets et des conditions contractuelles. Le tableau présente des exemples de présélection et ne constitue en aucun cas un engagement général pour chaque architecture ou chaque paquet. La date de référence de la recherche est le 4 novembre 2026 ; les informations dynamiques fournies par les éditeurs et les listes de paquets doivent être vérifiées à nouveau avant publication.

Pour Ubuntu 18.04, la maintenance standard a pris fin en mai 2023. Canonical indique que le support pour Ubuntu Pro s'étend jusqu'en mai 2028 et, dans son aperçu actuel concernant la couverture héritée supplémentaire, jusqu'en mai 2033. TuxCare indique actuellement le 31 mai 2048 comme date de fin de l'ELS pour Ubuntu 18.04. Ces dates correspondent à des offres différentes ; une date de fin plus tardive n'implique pas automatiquement une couverture de forfait adaptée.

Compare donc le Étendue de la maintenance pour chaque paquet requis et l'architecture effectivement utilisée. Sous Ubuntu, les composants « Main » et « Universe » sont particulièrement importants, tout comme les conditions relatives à « Pro » et à un éventuel module « Legacy ». Notez également comment vérifier la disponibilité des correctifs CVE et si les processus de validation et de mise à jour existants correspondent à l'offre.

Dans les deux exemples, la destination de la migration reste un choix de planification et non une caractéristique du contrat de maintenance. Si l’application métier n’est pas encore opérationnelle sur une plateforme prise en charge, une alternative de maintenance adaptée peut permettre de gagner du temps pour effectuer des tests. Si aucune des offres ne couvre une dépendance critique, cette lacune doit être traitée séparément avant que la poursuite de l’exploitation puisse être envisagée de manière responsable.

Vérifier les alertes CVE et les rétroportages

Si, après une mise à jour, un scanner continue de signaler une vulnérabilité, vérifiez d'abord la distribution et la version exactes, ainsi que le nom, l'architecture et la version installée du paquet concerné. Déterminez également de quelle source de paquets il provient. Un résultat concernant un paquet de distribution ne peut pas être transposé sans autre à une application compilée par vos soins ou à un paquet provenant d'un dépôt tiers.

La raison de ces contradictions apparentes peut être un Rétroportage : Dans ce cas, un correctif de sécurité est intégré dans une version antérieure, sans que le numéro de version en amont visible corresponde à celui de la dernière publication. Un numéro de version antérieur ne prouve donc pas en soi que le paquet soit vulnérable, ni que le message du scanner soit forcément erroné.

Vérifiez que le CVE concerné et la version du paquet installée correspondent aux informations fournies pour votre distribution dans le suivi CVE de TuxCare. „ In Testing “ signifie qu’un correctif est encore en cours de test ; „ In Rollout “ indique qu’il est en cours de distribution via les dépôts Rollout. „ Released “, en revanche, indique que le correctif est entièrement disponible pour tous les utilisateurs. Même dans ce cas, tu dois vérifier si la version appropriée a bien été installée ; „ Not Vulnerable “ signifie que la version TuxCare n'est pas concernée.

Si une mise à jour attendue n'apparaît pas dans le gestionnaire de paquets, vérifie, outre la source du paquet et la version, le État du déploiement. En cas de déploiement sur plusieurs plateformes, la distribution échelonnée après publication dans le dépôt stable peut prendre jusqu'à 14 jours supplémentaires. Un contournement éventuel ne peut être intégré au processus qu’après consultation des instructions d’origine relatives à la distribution et à la version en vigueur, et après validation opérationnelle ; cela n’implique toutefois aucune garantie quant au délai global d’application du correctif.

Examine ensuite la base de données et les résultats d'analyse du scanner. TuxCare fournit des données OVAL pour toute une série de produits ELS ; c'est à toi de vérifier si ton outil utilise les données adaptées au système concerné et les interprète correctement. Note la version du paquet, le statut CVE et l'heure de l'analyse. Si la concordance reste incertaine, continue à traiter le résultat comme non résolu et clarifie-le avec les services spécialisés compétents ou le fournisseur.

Planifier l'application des correctifs et les redémarrages

La mise en place d'un référentiel ne marque pas la fin du processus de mise à jour, mais seulement son début. Déterminez qui doit vérifier régulièrement la disponibilité des mises à jour, qui donne l'autorisation de les installer et comment identifier les mises à jour manquantes. Comparez les versions des paquets effectivement installées avec les mises à jour disponibles et consignez les écarts pour chaque système.

Dans la mesure du possible, teste d'abord les mises à jour sur un système de test similaire, équipé de la même application et des sources de paquets pertinentes. Vérifie notamment le démarrage, la connexion et les interfaces importantes de l'application métier. Ce n'est qu'après validation par le service que tu procèderas au déploiement contrôlé des paquets ; le résultat et les éventuelles erreurs doivent être consignés dans le rapport d'installation.

Prévois également des modifications Fenêtre de maintenance. Même après une mise à jour réussie des paquets, les processus en cours peuvent encore utiliser d'anciennes bibliothèques jusqu'à ce qu'ils soient redémarrés. Les applications peuvent également devoir être redémarrées ; en cas de modifications du noyau, un redémarrage du système peut s'avérer nécessaire. Après le redémarrage, vérifie à la fois le fonctionnement des services ainsi que l'état des paquets et du système.

KernelCare Live Patching est un produit complémentaire qui doit être distingué des mises à jour régulières des paquets ELS. Il permet d'appliquer les correctifs pris en charge du noyau à chaud, mais ne remplace ni l'ensemble des mises à jour, ni tous les redémarrages de services ou du système. Vérifiez le produit, la distribution et l'architecture : pour CentOS 7, TuxCare ne documente le correctif en direct du noyau que pour x86_64. D'autres principes de base sont expliqués dans l'article consacré à KernelCare Patch Feed.

L'édition de uname -r affiche le noyau actuellement en cours d'exécution, mais pas l'état complet des mises à jour du serveur. Un paquet de noyau installé peut, par exemple, ne devenir actif qu'après un redémarrage ; à l'inverse, le résultat ne précise pas si les bibliothèques et les applications ont été mises à jour et redémarrées.

Choisir une solution transitoire ou la migration

C'est en fonction des composants réels et des risques associés à un serveur donné que l'on détermine si TuxCare ELS est suffisant pour celui-ci. Comparez les paquets requis à la couverture disponible et identifiez les lacunes existantes au niveau des applications, des environnements d'exécution et des logiciels tiers. ELS for OS couvre une sélection dépendante de la distribution ; la prise en charge du système d'exploitation n'implique pas la maintenance de toutes les applications qui y sont exécutées.

Vérifiez également les vulnérabilités CVE restantes au sein des paquets déjà couverts. Selon TuxCare, les risques moyens ne sont pris en compte pour un correctif que sous certaines conditions supplémentaires ; en outre, le fournisseur peut prévoir une mesure d'atténuation plutôt qu'une correction directe du code. Évaluez donc, pour la vulnérabilité en question, si un correctif ou une mesure d'atténuation est disponible et si les risques résiduels sont acceptables pour votre activité.

Une solution transitoire peut s'avérer judicieuse lorsqu'une application métier reste, pour l'instant, liée à l'ancienne plateforme et que les risques résiduels sont maîtrisables. Mais comparez également les offres de maintenance proposées par les éditeurs : pour Ubuntu 18.04, selon l’étendue des besoins, Ubuntu Pro et, le cas échéant, l’extension Legacy peuvent être envisagés comme alternatives. Vérifiez les paquets, l’architecture et les conditions contractuelles, et ne vous limitez pas à la date d’expiration.

Pour un service accessible au public dont l'application n'est pas mise à jour ou dont la durée de fonctionnement n'est pas couverte, l'ELS seul peut s'avérer insuffisant. Limitez donc les accès aux réseaux et services réellement nécessaires, supprimez les autorisations inutiles et contrôlez les accès administratifs. Ces Limitation du réseau Cela réduit la surface d'attaque, mais ne remplace pas les mises à jour de sécurité manquantes.

Limite la durée de la poursuite de l'exploitation et définis un objectif de migration en désignant les responsables et en fixant une échéance vérifiable. Prévoyez des tests d'application sur la plateforme cible, le transfert des données et la vérification de toutes les interfaces concernées. Un plan de secours doit préciser dans quelles conditions vous interromprez la migration et comment vous reviendrez au fonctionnement antérieur.

Vérifiez régulièrement le plan à la lumière des nouvelles vulnérabilités des paquets, des changements dans les dépendances des éditeurs et de la charge d'exploitation. Si les composants nécessaires ne peuvent plus être maintenus ou si les accès requis ne peuvent pas être suffisamment limités, une simple prolongation de la maintenance du système d'exploitation pourrait ne pas suffire. Il faudra alors réévaluer la migration, le remplacement de l'application ou une mise hors service contrôlée.