Changement de paradigme pour le patching


Tout temps d'arrêt, qu'il soit planifié ou non, représente toujours une situation fâcheuse pour les équipes des centres de données SAP, mais aussi pour les services spécialisés ou les utilisateurs dans les entreprises.
En ce qui concerne les temps d'arrêt planifiés, nous sommes toujours estimés à cinq jours en moyenne par an, ce qui n'est pas une mauvaise valeur. Au fil des années, les processus de patching ont été quasiment ritualisés et on procède selon des scénarios standard : les intervalles de patching sont relativement fixes et les patchs ont souvent lieu le week-end.
Pratiquement tous les départements d'exploitation informatique sont impliqués et les temps d'arrêt planifiés sont convenus avec les départements spécialisés.
Pour les temps d'arrêt non planifiés dans les centres de calcul SAP, il n'y a pas de dates fixes et on ne peut pas non plus se rabattre sur les week-ends. Il n'est pas possible de se concerter avec les services spécialisés.
En règle générale, lors d'un temps d'arrêt non planifié, seul un problème spécifique peut être résolu. Pour minimiser les temps d'arrêt non planifiés, il existe toute une série de concepts et de solutions - seuls ou combinés : RAS (Reliability, Availability, Serviceability), la virtualisation, les clusters HA/GEO, le Systemrollback ou le Live/Online Patching.
À l'époque du Realtime Business, nous sommes amenés à viser un véritable fonctionnement 7X24 ou un "Towards Zero Downtime". Il est dans la nature des choses que des mises à jour logicielles (et de temps en temps aussi des mises à jour matérielles) doivent être effectuées dans un centre de données SAP.
La sécurité est plus importante que par le passé. Ce que l'on appelle les CVE (Common Vulnerabilities and Exposures) concernent également les systèmes d'exploitation.
Les CVE décrivent, sur la base de conventions uniformes, les failles de sécurité et autres vulnérabilités ; ici, la vulnérabilité des plateformes de systèmes d'exploitation, y compris le noyau. Linux n'y échappe pas.
Par exemple, 24 CVE classées comme graves ont été identifiées pour Linux en 2014. Il y en avait davantage pour d'autres systèmes d'exploitation. Il faut s'attendre à ce que le nombre total de CVE continue d'augmenter.
Le patching de sécurité a des répercussions sur les temps d'arrêt planifiés et non planifiés. Il ne faut pas que les mises à jour de sécurité ou une sorte de thérapie CVE entraînent un freinage complet de l'informatique ou de SAP.
L'objectif doit être le suivant : Appliquer des correctifs sans redémarrage du système, y compris des accords avec les services spécialisés sur les temps d'arrêt, par exemple avec une non-utilisation de SAP pendant un certain temps.
Il s'agit de mettre en place un Live Patching, qui met fin aux concepts traditionnels et augmente durablement la disponibilité des services informatiques pour les applications SAP critiques. Depuis des années, Suse s'efforce de mettre à disposition un patching en direct ou en ligne du noyau Linux dans l'environnement de l'entreprise - sans justement un stop-and-go typique du système.
Le projet de développement kGraft a étendu la mise à jour dynamique classique des logiciels (DSU), principalement utilisée pour les correctifs de sécurité et les correctifs de taille limitée, dans le but de fournir une solution standard de mise à jour en direct pour l'utilisation de Linux Enterprise.
kGraft est basé sur les technologies Linux les plus modernes, notamment le code auto-modifiant INT3/IPI-NMI, un mécanisme de mise à jour de type RCU, l'allocation d'espace NOP basée sur le montage et les mécanismes standard de chargement/liaison de modules du noyau.
Dans le cadre du Sapphire de cette année, Suse a présenté sa solution certifiée SAP, Suse Linux Enterprise Live Patching, qui est depuis disponible pour les serveurs x86-64. De plus, elle est livrée avec SLES 12 Service Pack 1 for SAP Applications (Hana, NetWeaver et autres plateformes SAP).
Avec Suse Linux Enterprise Live Patching, Suse donne aux entreprises un levier pour tourner le dos aux concepts de patching dépassés. Pour mettre en pratique des concepts d'exploitation de sécurité sans temps d'arrêt planifiés et avec des temps d'arrêt non planifiés minimisés (grâce aux CVE).
Parallèlement, il est possible d'améliorer la gestion des risques, de minimiser de manière proactive le potentiel d'attaque par des logiciels malveillants et surtout d'améliorer la qualité des services informatiques.