Les dernières violations mettent en évidence les brèches de sécurité liées à l'intégration

Version imprimable, PDF et e-mail

La vieille maxime selon laquelle l'intégration est l'ennemie de la sécurité n'a jamais été aussi évidente à la lumière d'une série de violations de sécurité très médiatisées qui ont ébranlé la confiance dans les technologies de l'information ces dernières semaines.

Les exploits des chaînes logistiques logiciels ont conduit à une série d'incidents qui illustrent trop clairement comment les dépendances qui existent entre de multiples services peuvent avoir un impact dévastateur en aval, qui peut être attribué à une seule violation.

 Malheureusement, les choses risquent d'empirer avant de s'améliorer. La plupart des nouveaux logiciels sont créés de façon plus modulaire à l'aide de microservices qui permettent aux entreprises de créer et de mettre à jour plus rapidement des applications. Plutôt que d'avoir à mettre à jour un seul logiciel monolithique, de nouvelles fonctionnalités peuvent être ajoutées à une application en extrayant et en remplaçant ces microservices. Cette approche rend également l'application plus résiliente, car au lieu de planter, les demandes de services sont redirigées vers un autre microservice chaque fois qu'une partie de l'application n'est pas disponible.

Du point de vue de la sécurité, cette approche de création des logiciels peut présenter de nombreux défis.  De multiples dépendances se créent entre toutes les interfaces de programmation (API) qui se sont développées pour permettre aux microservices de communiquer entre eux. Si un microservice est compromis, un pirate informatique peut accéder à tous les autres composants logiciels auxquels le microservice compromis est autorisé à accéder. En peu de temps, les logiciels malveillants se répandent latéralement dans tout l’environnement applicatif.

Pour éviter cela, les entreprises doivent utiliser les meilleures pratiques DevSecOps lors de la création de logiciels. À mesure que chaque microservice est déployé et mis à jour, il doit être analysé pour détecter les vulnérabilités. Dans un monde idéal, les développeurs analysent les vulnérabilités lorsqu'ils écrivent le code qui constitue le microservice.

La bonne nouvelle, c'est qu'au lieu de corriger une application monolithique entière, il suffit d'extraire et de remplacer les conteneurs dès qu'une vulnérabilité est détectée. De nombreuses vulnérabilités découvertes aujourd'hui ne sont souvent pas corrigées simplement parce que les développeurs d'applications n'ont pas le temps nécessaire pour corriger des applications monolithiques entières.

Le passage à une architecture de microservices augmente aussi considérablement la surface d'attaque, car ce qui était auparavant une simple demande et une réponse provenant d'un seul serveur Web implique maintenant des dizaines de demandes et de réponses concernant plusieurs hôtes. Les équipes informatiques devront également déployer des pare-feux et des passerelles d'interface de programmation (API) pour s'assurer que les microservices sont vraiment isolés les uns des autres. Les équipes informatiques doivent s'assurer qu'elles ont implémenté des contrôles d'identité et d'accès tels que le protocole OATH pour s'assurer que tout appel passé au microservice est légitime.

Heureusement, il existe également des initiatives qui promettent de donner à chaque microservice sa propre identité unique. La Cloud Native Computing Foundation (CNCF), par exemple, a adopté la spécification open source SPIFFE (Secure Production Identity Framework For Everyone) et l'environnement d'exécution SPIFFE (SPIRE) pour authentifier les services logiciels à l'aide d'identités cryptographiques adaptées à la plateforme. Au cœur de la spécification SPIFFE se trouvent des documents d'identité cryptographique à vie courte appelés SVID invoqués via une API. Les charges de travail utilisent un SVID lors de l'authentification à d'autres charges de travail en établissant une connexion TLS ou en signant et en vérifiant un jeton Web JSON (JWT).

Quel que soit le niveau d'expertise en cybersécurité actuelle d'une entreprise, il y a de fortes chances que la plupart des entreprises, en ce début d'année, sous-estiment ce qui est nécessaire pour sécuriser les environnements applicatifs qui seront bientôt constitués de milliers de microservices. Malheureusement, les cybercriminels travaillant pour le compte d'États nations ont déjà montré à quel point ils comprennent bien comment les logiciels modernes sont conçus. Il ne s'agit donc que d'une question de temps avant que de nombreuses violations similaires ne soient découvertes.

  

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Remonter en haut de page
Tweeter
Partager
Partager