Qu’il s’agisse de créer des outils automatisés pour la certification des systèmes d’exploitation ou d’explorer eBPF comme moyen de préserver la sécurité de la chaîne d’approvisionnement en production, la cybersécurité occupe une place croissante dans les emplois de SRE.
Dans un contexte de transformation numérique et d’aggravation constante des cyberattaques, le renforcement des opérations DevSecOps est devenu une priorité pour les SRE.
Au fur et à mesure que l’approche DevSecOps s’est développée, les professionnels de l’IT se sont d’abord concentrés sur le « déplacement de la sécurité vers la gauche » (Shift Left en VO), à l’étape du développement logiciel du processus DevOps et sur la sécurisation des applications dès la conception. Mais récemment, les ingénieurs chargés de la fiabilité des sites (Site Reliability Engineer ou SRE) ont également consacré une plus grande partie de leur attention au « déplacement vers la droite », c’est-à-dire à l’automatisation de la supervision de sécurité en production et à la transmission aux développeurs de feedbacks fondés sur les données de surveillance.
L’idée que la sécurité est la responsabilité de tous n’est pas nécessairement nouvelle, mais elle devient de plus en plus urgente pour les SRE qui se sont exprimés lors de la SRECon à San Francisco, du 14 au 16 mars 2022.
« Le nombre de CVE [vulnérabilités et expositions communes] ouvertes chaque année a augmenté de plus de 400 % depuis 2010 [et il y a eu] un bond gigantesque entre 2016 et 2017 », déclare Adam Debus, staff SRE du réseau social professionnel LinkedIn, lors d’une présentation à la conférence, citant des statistiques de l’Institut national des sciences et des technologies. « Le monde entier commençait ses migrations vers le cloud… cela a introduit une tonne de vulnérabilités de sécurité alors que les gens retravaillaient leurs paradigmes ».
« Je considère que nous ne pouvons pas avoir un environnement fiable ou résilient, si l’infrastructure que nous construisons pour cela n’est pas sécurisée. »
Adam DebusStaff SRE du réseau social professionnel LinkedIn
En 2019, alors que LinkedIn entrait dans les dernières étapes de sa croissance, passant de 65 millions à 800 millions de membres, et commençait à migrer son infrastructure vers Microsoft Azure, Adam Debus explique qu’il était devenu évident que la sécurité et la conformité étaient des domaines dans lesquels les SRE pouvaient jouer un rôle crucial.
« Nous nous concentrons beaucoup sur le R dans SRE – fiabilité, résilience – mais je considère que nous ne pouvons pas avoir un environnement fiable ou résilient si l’infrastructure que nous construisons pour cela n’est pas sécurisée », lance Adam Debus.
Les SRE de LinkedIn rationalisent les tests des systèmes d’exploitation
Lors d’une autre migration effectuée en 2019, Adam Debus a repéré un moyen de réduire les conséquences d’un effort conséquent. LinkedIn souhaitait se départir des distributions standards du kernel Linux pour adopter des versions optimisées, plus performantes. Les nouveaux kernels devaient être testés pour garantir la conformité aux politiques de sécurité de LinkedIn dans l’ensemble de son infrastructure cloud. Un travail considérable.
Le nombre de membres de LinkedIn a augmenté de 1 200 % entre 2010 et 2022. Le nombre de ressources d’infrastructure gérées par l’entreprise a connu une croissance disproportionnée de 6 000 % au cours de cette même période. Dans le même temps, l’entreprise utilisait divers processus manuels pour ce type de tests de certification de sécurité, ce qui serait intenable pour un projet aussi vaste et complexe.
« Vous avez des dizaines, voire une centaine de personnes qui aurait dû laisser de côté leur travail de développement pour certifier un nouveau système d’exploitation, et ce n’était pas viable », explique le responsable SRE.
L’équipe SRE d’Adam Debus a créé un processus standardisé et automatisé afin de réduire ce labeur et de garantir que la certification de sécurité et les tests de performance soient complets avant le déploiement de nouvelles images de système d’exploitation en production.
Le nouveau processus commence par le test des snapshots de l’OS sur les dizaines de configurations matérielles que l’entreprise utilise dans ses déploiements sur site et en cloud, puis sur les pilotes tiers. Le processus a ensuite renforcé l’OS, conformément aux politiques de sécurité standard de l’entreprise, et analysé les vulnérabilités connues, avant que le snapshot de l’OS ne soit soumis aux pipelines DevOps et aux processus de gestion de la configuration de LinkedIn, puis testé dans divers environnements de langage de programmation et, enfin, testé aux côtés des applications de l’entreprise.
Aujourd’hui, les membres de l’équipe SRE maintiennent le cadre d’automatisation, et les développeurs y intègrent leurs propres tests, explique M. Debus.
« Il s’agit d’une relation symbiotique », assure le responsable à propos du travail de son équipe avec les développeurs pour créer le système de test. « Nous sommes allés les voir et leur avons dit : “Écoutez, nous avons développé une plate-forme et un cadre d’automatisation vraiment flexibles que vous pouvez utiliser pour écrire vos tests – vous pouvez faire tout ce que vous voulez, il vous suffit d’appeler ces trois fonctions” ».
Au cours des neuf mois pendant lesquels le framework de test a été utilisé en production, il a permis de réduire de 70 % le temps total de certification d’un nouveau snapshot de système d’exploitation, selon le responsable.
« Mais ce n’est que la partie émergée de l’iceberg », ajoute-t-il. « Il s’agit du même processus de test, encore et encore, ce qui signifie qu’il est défendable, ce qui facilite la gestion de la sécurité. Nous avons également ajouté de nouveaux paradigmes de test, en supprimant une grande partie la nécessité pour un humain d’examiner [un résultat de test] et de décider s’il est bon ou non ».
EBPF apparaît sur le radar des SRE
D’autres intervenants de la SRECon ont fait écho aux réflexions d’Adam Debus sur l’importance croissante de la sécurité dans leur travail.
« À l’heure actuelle, si vous gérez un service mondial, vous voyez probablement beaucoup de trafic provenant de segments de réseau qui peuvent être hostiles, et vous devez donc trouver un moyen de gérer cela », affirme Shaun Mouton, ingénieur logiciel principal chez Mastercard, lors d’une session de la conférence.
Shaun Mouton fait partie de ceux qui ont évoqué l’importance croissante des filtres de paquets Berkeley étendus (eBPF). Cette collection d’outils a gagné en popularité dans les milieux « cloud-natifs », pour la mise en réseau et l’observabilité des microservices au cours des deux dernières années, et pourrait également être utile aux SRE dans les environnements DevSecOps.
Les entreprises ont souvent besoin de savoir si les attaques de la chaîne logistique logicielle ont modifié le comportement des applications sur le réseau. Cela peut être difficile à détecter, par exemple quand une application est vieillissante et que ses concepteurs ne travaillent plus pour l’entreprise, ou quand un logiciel tiers ne permet pas l’accès à son code source. La présentation de Shaun Mouton a montré comment eBPF pouvait être utilisé pour établir des profils du comportement typique de ces applications, notamment en surveillant les fichiers auxquels elles accèdent habituellement, afin de détecter les changements de comportement suspects.
« Au cours de mes expériences, j’ai constaté qu’eBPF est fantastique pour les snapshots point-in-time du système », observe l’ingénieur logiciel chez Mastercard. « Il est bien conçu pour les événements en continu basés sur des requêtes. Il permet de répondre à des questions telles que “Montrez-moi combien de nouveaux processus sont en train de bifurquer sur ce système” ou “Dites-moi quels sont les aspects intéressants de mon trafic HTTP” ».
Là où l’eBPF est moins efficace jusqu’à présent, c’est le suivi du comportement des applications dans le temps, surtout lorsque le code est modifié ou forké, prévient Shaun Mouton.
« Vous pouvez vous raccrocher à un processus en cours avec eBPF assez facilement », dit-il. « Mais suivre le processus depuis son invocation jusqu’à sa clôture… est un peu plus difficile avec eBPF dans son état actuel ».
« Au cours des deux prochaines années, je pense que beaucoup de gens s’appuieront sur la fonctionnalité LSM pour créer des produits permettant de garantir la sécurité des systèmes. »
Mickael KehoeIngénieur principal en sécurité, Confluent
Dans l’ensemble, eBPF est encore un outil relativement nouveau pour la gestion de la sécurité. Il est habituellement apprécié pour ses fonctions de routage réseau de base en dehors des VM Linux. Cependant, les solutions qui sortent de ce carcan sont peu nombreuses. Par exemple, l’outil d’auto-instrumentation basé sur eBPF de New Relic pour l’observabilité de Kubernetes, Pixie, n’est disponible que depuis environ un an. Les professionnels de IT et les éditeurs explorent encore la manière d’utiliser les capacités disponibles dans les mises à jour du kernel Linux qui intègrent eBPF aux crochets du module de sécurité Linux (LSM).
« Au cours des deux prochaines années, je pense que beaucoup de gens s’appuieront sur la fonctionnalité LSM pour créer des produits permettant de garantir la sécurité des systèmes et d’empêcher que les programmes que nous exécutons sur nos systèmes ne soient compromis », prédit Michael Kehoe, ingénieur principal en sécurité chez Confluent, éditeur et soutien principal d’Apache Kafka, lors d’une présentation au SRECon. « Il y a une intégration profonde [d’eBPF] avec les modules de sécurité Linux pour aller chercher des données de sécurité riches et en temps réel ».
