Le correctif compte vraiment, vraiment, c’est ce qui empêche les solutions technologiques de devenir comme de gros blocs de fromage suisse, avec des vulnérabilités de sécurité sans fin qui perforent trou après trou dans des solutions critiques.

Mais quiconque a passé un certain temps à maintenir des systèmes sait que l’application de correctifs est souvent plus facile à dire qu’à faire.

Oui, dans certains cas, vous pouvez simplement exécuter une ligne de commande pour installer ce correctif, et c’est tout. Ces instances sont cependant de plus en plus rares – étant donné la complexité de l’environnement technologique, vous êtes plus susceptible d’être confronté à un processus complexe pour appliquer les meilleures pratiques en matière de correctifs.

Dans cet article, nous expliquerons pourquoi les correctifs de bases de données sont importants (oui, les bases de données sont également vulnérables !), expliquerons le problème avec les correctifs de bases de données et indiquerons une nouvelle solution qui simplifie le correctif de bases de données.

Attention, vos services de base de données sont également vulnérables

Nous savons que les services de base de données sont essentiels – les bases de données sous-tendent les opérations informatiques de nombreuses manières, en travaillant en arrière-plan. Pourtant, les bases de données ne sont tout simplement pas les parties les plus intéressantes de la pile technologique, ce qui est l’une des raisons pour lesquelles les correctifs de base de données peuvent être négligés. Dans un récent sondage d’Imperva, la société a découvert que près de 50 % des bases de données sur site étaient vulnérables à un exploit connu.

Les cybercriminels, cependant, n’ignorent pas les bases de données. Comme tout autre élément de la pile technologique, les bases de données regorgent de vulnérabilités. Un seul service de base de données a plus d’un millier de vulnérabilités associées.

Considérez quelques exemples. En septembre 2016, CVE-2016-6662 a été signalé, une vulnérabilité qui permet aux attaquants d’injecter des paramètres de configuration MySQL malveillants dans le service de base de données d’une victime. Cela a également affecté les clones MySQL – y compris MariaDB, qui a été contraint de publier ici les mesures d’atténuation détaillées.

Un autre exemple: en 2020, une vulnérabilité de base de données a été identifiée où les attaquants pourraient lancer une attaque d’escalade de privilèges en raison de la façon dont certaines versions de MariaDB ont géré « setuid » au stade de l’installation.

Dans nos deux exemples, l’application de correctifs – ou la mise à niveau vers une version plus récente du service de base de données – fermerait la vulnérabilité. Mais c’est là que réside le problème : les correctifs ne se produisent pas aussi systématiquement qu’ils le devraient, et pas seulement parce que les équipes techniques sont paresseuses – ou parce que les services de base de données sont oubliés.

Lancez-vous simplement dans la gestion des correctifs, n’est-ce pas… ?

Pas assez. Il y a une deuxième raison pour laquelle l’application de correctifs à une base de données est négligée : l’application de correctifs à une base de données peut être incroyablement difficile, avec des instructions contradictoires et ambiguës. Ce problème est particulièrement répandu lorsque les implémentations de bases de données sont assez complexes.

Prenez les clusters MySQL, par exemple. La base de données open source MySQL a un article officiel décrivant comment les utilisateurs doivent corriger un cluster MySQL – mais les instructions sont complexes et ne prennent en compte qu’une configuration particulière du cluster MySQL, InnoDB, lorsqu’il existe d’autres stratégies de cluster MySQL.

Les instructions MySQL ci-dessus omettent également quelques aspects importants de l’application de correctifs. Il ne traite pas de la manière dont le processus de correction peut affecter d’autres applications, ni comment il peut affecter d’autres systèmes de votre solution technologique. Il ne peut pas offrir ce conseil, bien sûr, car chaque environnement est différent et les auteurs ne savent pas à quoi ressemble votre environnement.

Et c’est là que réside un problème majeur avec les meilleures pratiques en matière de correctifs, et les meilleures pratiques de base de données en général : il est presque impossible de tenir compte des variations pratiques infinies – des différences de configuration de la base de données aux différents niveaux de connaissances techniques.

Les meilleures pratiques en matière de correctifs sont adaptées à l’objectif

Le résultat net peut être que la mise en œuvre des meilleures pratiques de correctifs publiées est un exercice très ambigu et incertain. Les administrateurs système peuvent facilement décider que les risques et les implications d’un mauvais correctif sont beaucoup plus importants que le risque d’une cyberattaque sur la base de données. Ainsi, alors qu’en théorie, il est facile de simplement « s’occuper du patch », la réalité est très différente.

Même lorsque les équipes ont les connaissances techniques et la certitude pratique de réussir l’application de correctifs de base de données, il existe toujours la réalité qu’un service de base de données doit se déconnecter pendant un certain temps pour effectuer l’application de correctifs.

Sans haute disponibilité, les temps d’arrêt sont l’effet secondaire le plus perturbateur lorsque les services technologiques sont mis hors ligne, perturbant ainsi le travail.

Configurations haute disponibilité peut garantir qu’il n’y a pas de temps d’arrêt, mais même ceux-ci sont susceptibles de subir une dégradation du service car certains serveurs d’un cluster sont hors ligne et incapables de prendre en charge la demande ou de fournir une protection adéquate pendant que certains nœuds sont en panne pour maintenance.

Les procédures de correctifs complexes consomment également beaucoup de temps, ce qui enlève des ressources à d’autres tâches importantes – et dans certains cas, les ressources peuvent tout simplement ne pas être là pour assurer un correctif cohérent.

Enfin, mettre des bases de données hors ligne pour appliquer des correctifs et gérer des processus de migration complexes comporte toujours un risque de problème. La corruption des données peut s’infiltrer pendant la migration, ou certains serveurs peuvent ne pas reprendre vie après la mise à jour. Ces risques ne peuvent être ignorés et sont intrinsèques aux pratiques actuelles d’application de correctifs aux bases de données qui nécessitent des redémarrages.

Patch de base de données en direct comme alternative

Jusqu’à récemment, l’application de correctifs à un service technologique nécessitait presque toujours un redémarrage, mais l’application de correctifs en direct est de plus en plus répandue. Avec le patch en direct, les outils de patch effectuent un échange sur place du code patché : le service patché continue de fonctionner pendant que le patch a lieu, sans redémarrage requis.

C’est exactement le rôle de DatabaseCare, la nouvelle solution de TuxCare. Grâce à DatabaseCare, vous pouvez effectuer des correctifs complets aussi souvent que vous le souhaitez, car DatabaseCare corrige votre base de données pendant qu’elle est en cours d’exécution et sert des données.

Comment cela marche-t-il? C’est simple en pratique. Votre serveur se connecte au portail électronique DatabaseCare sur site où les correctifs sont stockés en toute sécurité. Dès qu’une nouvelle vulnérabilité est enregistrée, un agent communique avec le portail électronique, qui extrait ensuite la mise à jour de DatabaseCare. L’agent gèle alors momentanément votre service de base de données en mode sans échec et applique de manière transparente le correctif en mémoire. Ce « gel » est si rapide qu’il ne perturbe même pas les connexions réseau au service de base de données ou l’exécution de requêtes.

Le résultat : vos bases de données sont automatiquement mises à jour avec les derniers correctifs de sécurité, sans temps d’arrêt, avec un minimum de perturbations et de risques – et sans aucun effort continu de la part de vos équipes techniques.

Comment DatabaseCare vous profite-t-il ?

Examinons plus clairement les avantages de l’application de correctifs en direct, par rapport aux meilleures pratiques d’application de correctifs telles qu’elles existent.

Nous avons déjà souligné la complexité de l’application de correctifs aux bases de données, en particulier pour les bases de données distribuées à haute disponibilité. DatabaseCare remplace un ensemble complexe d’étapes impliquant des procédures de migration délicates par une étape unique, simple et unique, qui est également facilement automatisée.

Il supprime l’ambiguïté de patcher vos bases de données. Suivez-vous les bonnes instructions ? Cela fonctionnera-t-il, même si vous le faites parfaitement ? Toutes ces questions ont maintenant disparu – le patch se fait automatiquement et en arrière-plan. Et donc oui, le risque lié à l’application de correctifs aux bases de données est désormais considérablement atténué, ce qui réduit l’hésitation à appliquer un correctif.

Dans le même temps, l’application de correctifs automatisés signifie également que vous n’avez pas besoin d’essayer d’intégrer l’application de correctifs parmi une autre longue liste de tâches informatiques épuisantes. Et, lorsque les correctifs ne sont pas en concurrence pour les ressources, cela se produit plus régulièrement. D’autres unités commerciales au sein de l’organisation apprécieront le fait que vous n’avez plus besoin de longues fenêtres de maintenance pour vos opérations de correctifs.

Nous savons tous ce que signifie l’application régulière de correctifs : une sécurité renforcée. Réduisez la fenêtre entre la date de publication d’un correctif et le moment où ce correctif est appliqué, et vous réduisez la fenêtre d’opportunité pour les attaquants d’exploiter une vulnérabilité.

Les meilleures pratiques sont importantes, mais DatabaseCare déverrouille une sécurité cohérente

L’application de correctifs aux services de base de données n’est pas nouvelle – les instructions relatives aux meilleures pratiques existent depuis un certain temps. Mais il existe des difficultés pratiques à corriger les meilleures pratiques en l’état, et ces difficultés pratiques laissent une fenêtre pour les cyber-attaquants.

DatabaseCare comble le vide – il ne perturbe pas vos opérations, il ne pose pas de risque d’échec et vous n’avez pas besoin de ressources pour le faire fonctionner. À son tour, votre sécurité devient beaucoup plus solide. L’installation de DatabaseCare est également simple. Pour en savoir plus, il suffit de consulter le Page d’entretien de la base de données sur le site TuxCare.