Improving the Security of Containerized Workloads using Transparency and Traceability Services

Imaginez l'internet comme une ville immense et bouillonnante où le logiciel est la nourriture que tout le monde consomme. Pour acheminer cette nourriture aux gens, des chefs (les développeurs) utilisent des lignes d'assemblage automatisées appelées pipelines CI/CD pour concocter des plats numériques connus sous le nom de « charges de travail conteneurisées ». Ces plats sont emballés dans des boîtes numériques appelées « images », stockés dans de gigantesques garde-manger numériques appelés « registres », puis expédiés vers des restaurants partout dans le monde, des grandes cuisines de cloud aux minuscules stands de rue (environnements edge). Le problème est que si un saboteur s'introduit dans la ligne d'assemblage, il peut remplacer un repas sain par un plat empoisonné, et parce que la ligne d'assemblage est si rapide et automatisée, le poison est expédié à des milliers de clients avant que quiconque ne s'en aperçoive. C'est le monde de la sécurité de la chaîne d'approvisionnement logicielle : un jeu à enjeux élevés consistant à garantir la sécurité de la nourriture numérique contre les manipulations, le vol et les acteurs malveillants.

Pour comprendre comment arrêter cela, nous avons besoin de deux outils principaux. Premièrement, nous avons besoin d'intégrité, qui est comme un sceau d'inviolabilité sur un pot de confiture ; si le sceau est brisé ou si la confiture à l'intérieur est remplacée, vous le savez immédiatement. Deuxièmement, nous avons besoin de transparence, qui est comme un journal public et inaltérable où, chaque fois qu'un pot est scellé, l'événement est consigné avec une encre qui ne peut être raturée ; si quelqu'un tente de sceller un pot empoisonné, le journal montrera l'événement, et le public pourra vérifier le journal pour voir si le sceau correspond à l'entrée. Sans ces outils, un pirate qui vole la clé d'un chef pourrait sceller un pot empoisonné avec un sceau « valide », et personne ne ferait la différence avant qu'il ne soit trop tard.

Cet article introduit un nouveau système ingénieux pour résoudre exactement ce problème. Les auteurs, une équipe de chercheurs en sécurité, proposent un « Service de Transparence » qui agit comme un notaire automatisé ultra-sécurisé pour ces boîtes de nourriture numérique. Au lieu de laisser la ligne d'assemblage détenir une clé maîtresse permanente (ce qui, si elle est volée, est un désastre), le système génère une nouvelle clé, à usage unique, pour chaque plat numérique préparé. Il scelle ensuite immédiatement le plat, inscrit l'événement dans un journal public inaltérable (le Registre de Transparence), puis jette la clé. Lorsque le plat arrive dans un restaurant, le gestionnaire ne se contente pas de vérifier le sceau ; il vérifie également le journal public pour s'assurer que le sceau a bien été enregistré et que le chef qui l'a signé était autorisé à le faire.

Les chercheurs ont construit un prototype fonctionnel de ce système, en le connectant à des outils de codage populaires comme GitHub Actions et GitLab. Ils l'ont testé face à des scénarios réalistes où des pirates tentent de voler des clés ou d'introduire du code malveillant. Leurs simulations montrent que cette approche arrête efficacement le déploiement de logiciels malveillants dans de nombreux cas, comme lorsqu'ils tentent d'utiliser des identifiants volés d'un utilisateur non autorisé. Cependant, si un pirate parvient à voler les identifiants d'un développeur autorisé, le système pourrait initialement laisser passer le logiciel malveillant lors des contrôles de sécurité car la signature et l'identité semblent valides. Dans ce scénario spécifique, la force du système réside dans sa capacité à détecter l'usage abusif rapidement. Parce que chaque événement de signature est enregistré dans le journal public, un « moniteur » peut repérer l'activité suspecte et alerter l'organisation. Cela leur permet de bloquer le logiciel malveillant et de révoquer les identifiants compromis avant qu'ils ne causent des dommages étendus, bien que la vitesse de cette détection dépende de la fréquence à laquelle le journal est consulté.

L'histoire de la cuisine numérique

Plongeons dans le fonctionnement de cela, en utilisant l'analogie d'une cuisine de haute technologie et automatisée.

Le Problème : Le piège de la clé maîtresse
Dans les anciens temps, imaginez une chaîne de restaurants où chaque chef possédait une clé maîtresse permanente et robuste pour la porte d'entrée. Si un cambrioleur volait cette clé, il pouvait entrer, cuisiner un ragoût empoisonné et le mettre au menu. Parce que la clé était « réelle », le garde de sécurité à la porte laisserait passer le ragoût. Dans le monde numérique, c'est ce qui arrive lorsqu'un pirate vole le mot de passe d'un développeur ou la clé secrète d'un serveur. Ils peuvent utiliser cette clé volée pour signer une mise à jour logicielle malveillante, et parce que la signature semble valide, le logiciel est installé sur des millions d'ordinateurs.

La Solution : Le ticket à usage unique
Les auteurs de cet article disent : « Fini les clés maîtresses ! » Au lieu de cela, ils proposent un système où le chef ne détient aucune clé du tout. Voici le nouveau processus :

1. La Commande : Un chef (un développeur) veut cuisiner un nouveau plat (construire une image de conteneur). Il envoie la recette à une « Machine Notaire » spéciale et ultra-sécurisée (le Service de Transparence).
2. La Clé à usage unique : La Machine Notaire vérifie l'identité du chef. S'il est autorisé à cuisiner, la machine crée instantanément une toute nouvelle clé à usage unique juste pour ce plat spécifique. Elle signe le plat avec cette clé, puis détruit immédiatement la clé. Pouf ! Disparue.
3. Le Journal Public : La Machine Notaire écrit une note dans un journal géant et public inaltérable (le Registre de Transparence). La note dit : « À 14h00, le Chef Alice a signé le Plat n°123 avec la Clé X. » Le journal est comme une blockchain ou un registre public ; une fois qu'une page est écrite, elle ne peut être ni déchirée ni modifiée.
4. Le Reçu : La machine donne au chef un reçu qui comprend la signature, le nom du chef et une « Preuve d'Inclusion ». Cette preuve est comme un reçu mathématique qui dit : « Oui, je peux prouver que cette entrée figure bien dans le journal. »

Le Point de Contrôle : Le Gardien de Sécurité
Maintenant, le plat arrive au restaurant (le site de déploiement, comme un serveur cloud). Le garde de sécurité (un moteur de politique) ne se contente pas de regarder la signature. Il effectue un contrôle en trois étapes :

1. Le sceau est-il réel ? Il vérifie que la signature correspond au plat.
2. Le chef est-il autorisé ? Il vérifie le nom du chef par rapport à une liste de personnel autorisé.
3. Est-il dans le journal ? C'est la partie magique. Il prend la « Preuve d'Inclusion » et vérifie le journal public pour s'assurer que l'événement a bien eu lieu. Si le plat n'est pas dans le journal, ou si l'entrée du journal ne correspond pas au plat, le garde le rejette.

Pourquoi est-ce une révolution ?
L'article montre que ce système est incroyablement difficile à briser. Même si un pirate vole le mot de passe d'un chef et tente de tromper la Machine Notaire pour signer un plat empoisonné, le système possède deux filets de sécurité :

• La Clé à usage unique : Puisque la clé est détruite immédiatement, le pirate ne peut pas l'utiliser à nouveau pour signer d'autres plats empoisonnés.
• Le Journal Public : Si un pirate parvient à obtenir une signature valide (par exemple, en volant l'identifiant d'un chef autorisé), l'événement est enregistré dans le journal public. Un « moniteur » (comme un chien de garde) surveille le journal 24h/24 et 7j/7. S'il voit une entrée suspecte — comme un chef signant un plat qu'il ne devrait pas — il peut alerter le restaurant. Le restaurant peut alors bloquer ce plat spécifique avant qu'il n'atteigne les clients. Cependant, la vitesse de cette alerte dépend de la fréquence à laquelle le moniteur consulte le journal ; il existe un délai entre l'événement de signature et la détection, qui peut varier de quelques minutes à l'intervalle de surveillance complet.

Le Compromis : Attendre que l'encre sèche
L'article souligne également un petit bémol. Parce que le journal public est si sécurisé, il faut un peu de temps pour écrire une nouvelle entrée. Dans le monde réel, il peut s'écouler environ 12 minutes avant qu'une nouvelle entrée n'apparaisse dans le journal. Cela signifie qu'il existe une petite fenêtre où un plat peut être signé mais pas encore visible dans le journal. Les auteurs suggèrent que les restaurants peuvent instaurer une « période de refroidissement » — attendre quelques minutes après la création de la signature avant de laisser entrer le plat. Cela garantit que l'entrée dans le journal est solide avant que la nourriture ne soit servie.

L'Essentiel
Cet article ne se contente pas de suggérer une théorie ; les auteurs ont construit une version fonctionnelle de celle-ci et l'ont testée. Ils ont découvert qu'en combinant des clés à usage unique, des journaux publics et des règles strictes, ils peuvent arrêter la plupart des méthodes courantes utilisées par les pirates pour empoisonner la chaîne d'approvisionnement logicielle. C'est comme transformer une cuisine numérique en une forteresse où chaque repas est suivi, chaque chef est vérifié et toute tentative de manipulation est enregistrée dans un livre que tout le monde peut lire. Bien que cela ajoute une légère complexité et un court temps d'attente, la tranquillité d'esprit de savoir que votre nourriture numérique est sûre en vaut la peine.