eBPF : la confiance à l'épreuve du cloud

Chez Alien6, nous expérimentons depuis quelque temps eBPF pour en faire l'une des fondations de notre architecture applicative, avec trois objectifs : contenir les incidents, faciliter les audits et préserver la continuité de service.

Imaginez un bâtiment où les badges sont parfaitement gérés, mais où les portes intérieures restent ouvertes. Le registre indique qui peut accéder à chaque salle, mais dans les faits, une personne entrée dans le bâtiment peut circuler beaucoup plus librement.

Une architecture applicative peut présenter de tels écarts lorsque ses accès internes sont trop permissifs. Une application de reporting compromise peut alors devenir un point de départ vers des services plus sensibles.

Pour nos clients, ce risque dépasse la défaillance d'une application. Il concerne la propagation de l'incident, l'interruption d'activité et le temps nécessaire pour comprendre ce qui a été exposé.

Ce qu'eBPF permet, concrètement

eBPF est une technologie intégrée au noyau Linux, le cœur du système d'exploitation qui gère notamment les processus et les communications. Elle permet d'y exécuter de petits programmes pour observer l'activité et appliquer certains contrôles de sécurité.

Un programme eBPF peut, par exemple, intervenir lorsqu'une application tente une connexion et la refuser si les règles d'accès l'interdisent, sur le périmètre qu'il contrôle.

Dans notre image du bâtiment, eBPF permet d'installer des tourniquets à certains points de passage. Le registre des autorisations trouve ainsi un prolongement concret dans le système.

Le tourniquet doit continuer à savoir qui est censé passer, même lorsque les occupants changent. Dans le cloud, ces changements font partie du fonctionnement normal. C'est là que commence une part importante de notre expérimentation.

Le mouvement perpétuel

Une application conserve généralement son rôle alors que les éléments qui l'exécutent changent. Ses instances sont remplacées, leur nombre varie et elles se déplacent entre des machines. Une dépendance est ajoutée, une autre disparaît.

La sécurité doit suivre ce mouvement. Une autorisation accordée à un service doit continuer à concerner le bon service après un redémarrage. Elle ne doit pas être transmise à un autre composant qui occuperait sa place. Elle doit également pouvoir disparaître lorsque le besoin qui la justifiait n'existe plus.

Cette continuité paraît naturelle sur un schéma d'architecture. Elle devient plus difficile à maintenir lorsque plusieurs applications évoluent simultanément.

Nos expérimentations autour d'eBPF portent notamment sur cette correspondance entre les services que nous souhaitons autoriser et les composants qui communiquent réellement.

Se rapprocher du noyau augmente aussi la responsabilité

eBPF permet de rapprocher certains contrôles des communications qu'ils doivent encadrer. Intervenir à ce niveau impose toutefois de mesurer les conséquences d'une erreur.

Une règle trop permissive peut laisser un accès indésirable. Une règle trop restrictive peut interrompre un traitement, empêcher une transaction ou rendre une application indisponible.

Pour nos clients, la protection doit rester compatible avec le fonctionnement de l'activité. Pour les équipes d'exploitation, elle doit aussi rester compréhensible. Un refus doit pouvoir être expliqué. Une dégradation doit pouvoir être distinguée d'un problème applicatif ou réseau. Sans cette visibilité, un mécanisme de sécurité peut allonger le diagnostic et compliquer le rétablissement du service.

Nous travaillons donc autant sur la compréhension des contrôles que sur leur capacité à bloquer une communication.

Les transitions révèlent les difficultés

Les situations les plus instructives apparaissent souvent pendant un changement. Une autorisation est retirée alors qu'une connexion est encore active. Un composant redémarre pendant la propagation de nouvelles règles. Un service est déclaré prêt, tandis qu'un autre ne dispose pas encore des informations nécessaires pour le reconnaître.

Nos essais d'intégration ont déjà fait apparaître ce décalage entre l'état annoncé par un composant et l'état effectivement disponible ailleurs dans le système. Le registre est à jour ; le tourniquet n'a pas encore reçu la nouvelle consigne.

La difficulté augmente lorsqu'une partie du système de contrôle devient indisponible. Les applications doivent continuer à fonctionner autant que possible, sans que cette continuité prolonge silencieusement des droits qui ne devraient plus exister.

Ces situations placent la sécurité et la disponibilité dans une même équation. Elles occupent une part importante de notre R&D, car leurs conséquences se traduisent directement dans le fonctionnement des applications.

Des composants qui deviennent les fondations de nos projets

L'identité des services, la maîtrise de leurs communications et la compréhension de leurs dépendances concernent chacun de nos projets. À mesure que les architectures se développent, ces exigences doivent conserver une cohérence d'ensemble.

Les composants issus de notre R&D deviennent progressivement ce socle partagé. L'expérimentation eBPF trouve naturellement sa place, parce qu'elle nous oblige à confronter les règles que nous définissons aux échanges qui se produisent réellement.

Ce travail influence la conception de nos nouveaux projets : les accès prévus dès le départ, les dépendances acceptées et les garanties que nous voulons pouvoir vérifier.

C'est ainsi que nous construisons les fondations Zero Trust de nos projets, avec des exigences de sécurité reliées aux contraintes d'exploitation et aux risques de nos clients.