Pratique de Sécurité dans les Architectures Microservices

L’avènement des Architectures Microservices requiert une approche différente dans la mise en place des pratiques de sécurité. Si vous êtes amenés à construire ce type d’Architecture, gardez à l’esprit que la sécurité doit être adaptée à ces nouvelles règles.

« Ne faire qu’une seule chose, et la faire bien » – voilà comment nous pourrions définir la philosophie d’une Architecture Microservices (notez au passage qu’il s’agit aussi de la philosophie des systèmes Unix/Linux). Si nous appliquons ce concept à la construction d’une application, nous devons alors repenser la sécurité informatique.

Principes des Microservices

Une application regroupe un ensemble de fonctions liées les unes avec les autres. On parle d’Architecture Microservices si toutes ces fonctions sont décomposées dans un service distinct. Cette approche architecturale permet alors de répondre aux grands principes de rapidité, d’agilité et d’évolutivité.

Chaque service est créé, managé et surveillé par une seule équipe aux multiples compétences (mouvance DevOps). Les services sont déployés ou détruits rapidement via des procédures automatisées.

Ces services reposent sur des images systèmes légères appelés communément conteneurs. Il s’agit d’instance système fournissant uniquement les outils nécessaires pour exécuter correctement le service (système de fichiers, variables, bibliothèques, etc.).

Tous ces services peuvent s’interconnecter entre-eux via principalement le protocole applicatif HTTP (avec activation du chiffrement). Ceci, au travers d’interface de programmation applicative (appelés plus généralement API).

Avec cette nouvelle Architecture, la mise en pratique de la sécurité doit être revue impérativement.

Nouveaux défis pour les équipes

Le premier aspect à prendre en compte avec une Architecture Microservices est que la sécurité est partagée entre le(s) équipe(s) dédiée(s) à la sécurité et les équipes qui livrent le(s) nouveau(x) service(s). Cet aspect organisationnel est souvent négligé, voir complétement oublié. Et pourtant, il s’agit du socle de base pour sécuriser efficacement les Microservices.

Pour un Microservice donné, l’équipe en charge doit définir sa couche technique (Framework) : le(s) langage(s) utilisé(s), son dépôt de données, les mécanismes de déploiement, les mécanismes d’échanges avec les autres Microservices, etc.

Cette équipe doit donc se poser plusieurs questions. Comme par exemple :

  • Quelle taille doit faire notre Microservice ?
  • Que doit contenir notre Microservice comme logiciels ?
  • Pour un langage donné, quels sont les principes de développement sécurisés ?
  • Pour un outil de déploiement donné, y-a-t-il des alertes de sécurité ? Si oui, sont-elles installées ?
  • Quels sont les autres Microservices qui échangent avec le nôtre ? Que devons-nous échanger ? De quelle manière allons-nous échanger cette information ?
  • Quelles informations doivent être échangées ? Devons-nous échanger des données confidentielles (type secret) ?
  • Partageons-nous un dépôt de données avec un autre Microservice ?
  • Quel est le framework utilisé avec les microservices avec qui nous échangeons nos données ?
  • Etc

La liste, non exhaustive, dépend bien évidemment du contexte de votre système d’information. Dans certains cas, le ou les langages de développement est/sont imposé(s), les outils de déploiement dépendent d’équipes transverses, le conteneur de base est unique pour toutes les équipes, etc.

Dans tous les cas, l’équipe en charge du microservice doit impérativement être consciente des risques liés à une mauvaise application des règles de sécurité.

Nouveaux principes

La visibilité sur l’activité des microservices est primordiale. La majorité des outils de sécurité n’ont pas la capacité de visualiser l’activité d’une Architecture Microservices. En effet, les réseaux entre microservices sont le plus souvent isolés. Or ces flux de données entre microservices doivent être eux-aussi surveillés pour identifier rapidement des attaques informatiques.

La volatilité des microservices modifie significativement la surface d’attaque au sein du système d’information. Le nombre de microservices peut croitre ou diminuer selon les besoins du métier.

La détection, la prévention et la réponse sur incident doivent être automatisées. Avec des microservices volatiles et un nombre de communication entre microservices fluctuant selon le nombre déployé, il est nécessaire de collecter l’ensemble des données nécessaires pour identifier, analyser et corréler les potentiels incidents de sécurité.

Avec ces nouveaux principes, il convient de mettre en place des nouveaux programmes de sécurité pour répondre à cette architecture. Il est possible de distinguer deux phases : la phase de création et déploiement et la phase d’exécution.

Phase de création et déploiement

Cette phase regroupe d’une part la création des conteneurs ainsi que leur déploiement dans le système informatique via des procédures automatisée.

Il convient donc d’appliquer les règles de sécurité suivantes :

  • Avoir une taille d’image la plus petite possible afin de limiter la surface d’attaque et de déployer plus rapidement le service. Il convient d’installer uniquement les logiciels nécessaires à l’exécution du service.
  • Avoir une image à jour. Tous les logiciels installés dans le conteneur doivent être mis à jour avec les derniers fixes de sécurité de manière automatisée.
  • Automatiser la recherche de vulnérabilités de ces images. Il est nécessaire de valider régulièrement les images avec les nouvelles failles de sécurité.
  • Automatiser les audits sur les images via des standards de sécurité (NIST, PCI-DSS, etc.) ou via vos propres références.
  • Utiliser uniquement des logiciels Open-Source dans les images. L’audit de logiciel propiétaire devient plus complexe à maintenir.
  • Mettre en place un système de signature des images afin de valider leur intégrité.
  • Restreindre les accès aux systèmes hôtes hébergeant les conteneurs mais aussi restreindre les accès entre les microservices uniquement si des échanges d’informations sont nécessaires.
  • Eviter d’utiliser le réseau pour segmenter les microservices entre-eux et utiliser de préférence la segmentation applicative.
  • Protéger efficacement les données échangées entre microservices (chiffrement, authentification, vérification d’autorisation).
  • Mise en place d’une authentification unique entre les microservices. (Quid des échanges de secrets entre les microservices).
  • Automatiser les tests de sécurité dans la livraison des microservices. Comme par exemple des tests de variables en entrée du service (fuzzing).
  • Standardiser et automatiser les déploiements des microservices via des chaines de déploiement fiables et sécurisées.

L’intégration de la sécurité uniquement dans la phase de création et déploiement n’est pas suffisante. En effet, la résolution des incidents de sécurité avant même l’activation des microservices n’est malheureusement pas possible. C’est pourquoi il convient aussi d’appliquer la sécurité dans la phase d’exécution.

Phase d’exécution

La sécurité dans la phase d’exécution englobe toutes les fonctions de surveillance, d’analyse d’incident, de réponse à incident ainsi que des fonctions avancées comme la corrélation d’incidents. Les équipes en charge des microservices peuvent être accompagnées par des équipes de sécurité (ou via le centre opérationnel de sécurité).

Un point extrêmement important pour conduire à bien cette phase : l’ensemble de l’activité de chaque microservice doit être correctement horodaté et enregistré de manière centralisée. Ceci afin de permettre une prise en charge complète et efficace des fonctions de sécurité.

Par exemple, lors de l’investigation d’un incident de sécurité dans une Architecture Microservice, il est propable que les microservices ayant déclenchés cette alerte n’existent plus (suppression des microservices après une utilisation temporaire). S’il n’existe pas de journalisation efficace il sera alors impossible d’investiguer correctement sur cet incident de sécurité.

Les points suivants sont à prendre en compte dans la mise en place des fonctions de sécurité :

  • Capturer l’ensemble des données de journalisation en temps réel. Les difficultés résident principalement dans la diversité des données et leur multitude.
  • Surveiller l’activité de votre Architecture Microservices via des indicateurs classiques et via des mécanismes comportementales (par exemple un microservice qui tente d’accéder via une API à un microservice non définie dans son contexte d’application, ou alors la création de plusieurs microservices sans activité métier spécifique).
  • Corréler les indicateurs de menace. Les attaques informatiques peuvent être complexes et utilisent différents vecteurs potentiels sur différentes cibles possibles. Etre en capacité d’identifier rapidement les relations pour chacune d’entre-elles permet une meilleure approche dans l’analyse et la résolution de ces failles.

Avec une réponse sur incident automatisée et liée à un moteur d’apprentissage automatique, il est par exemple possible de bloquer rapidement un flux réseau malicieux entre plusieurs Microservices. Ou fixer une faille de sécurité dans les images pour pouvoir les déployer sans impacter l’application.

Magasins de données

Concernant les magasins de données, il existe deux approches distinctes qui selon le choix de l’une ou l’autre modifie les principes de sécurité :

  • Chaque microservice est construit avec un magasin de données. Le principal avantage pour la sécurité provient du fait que peu de données transiteront entre les microservices. Le désavantage c’est qu’il faudra prendre en compte dans chaque microservice les éléments de sécurité du magasin de données. Sachant que chaque microservice peut avoir éventuellement une solution de stockage différente.
  • Un magasin de données est partagé entre plusieurs microservices. L’avantage principal pour la sécurité, c’est que la surface d’attaque à analyser est plus réduite. Mais inversement, les autorisations d’accès aux données, la segmentation des données, la sécurisation des échanges de données sont des aspects importants qu’il ne faut pas négliger.

Conclusion

Plus personne n’est à convaincre concernant l’utilisation d’une Architecture Microservices. Elle offre une multitude d’avantages pour répondre efficacement aux demandes métiers (agilité, rapidité, évolution).

Cependant, ce changement architectural impose une revue profonde des principes de sécurité. Avec une surface d’attaque volatile, une réorganisation des rôles au sein des équipes de développement et de support, l’utilisation de différents logiciels, une gestion particulière des magasins de données, il est important de reconsidérer la sécurité informatique dans son ensemble pour répondre à ces nouveaux défis.

Les principes évoqués plus haut permettent de définir une feuille de route pour mettre en pratique ces nouveaux principes. Nous reviendrons prochainement en détail sur la configuration de certains éléments.

A propos de The 8Brains

The 8Brains est une société Québécoise basée à Montréal. Une équipe de plus de vingt professionnels expérimentés. Pentesters, architectes techno et sécurité, une équipe de développeurs (IA, SecDevOps…), un pôle cyber intelligence. Une équipe de passionnés, des experts qui accumulent plus de 300 ans d’expérience et plus d’une centaine de certifications.

Missions : Informer, Innover, Sécuriser tout en changeant le paradigme de la sécurité au bénéfice de ses clients, en mettant a leur disposition des équipes multidisciplinaires et transverses !

Les solutions The 8Brains sont innovantes et encore jamais rencontrées ailleurs.

The 8Brains emploie plus de 20 personnes hautement qualifiées, son siège social est implanté́ à Montréal (Québec). Pour en savoir plus : https://www.8brains.ca

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *