Les cyber-risques des architectures microservices

Les architectures basées sur des microservices sont de plus en plus courantes et permettent de décentraliser les ressources et fonctionnalités. Plutôt que d’avoir une application monolithique “qui fait tout”, il est parfois préférable de créer des services indépendants les uns des autres, communiquant via des Web Services (RestFul, JSON API…). Ces services, ou microservices, proposent des fonctionnalités ciblées au travers de requêtes/réponses.

On peut citer par exemple :

• un service d’authentification centralisé (CAS).
• un service d’indexation de contenus.
• un service de données temps réel.
• un chatbot.
• un service de paiement.
• un système d’avis des utilisateurs.
• ...

Un microservice ne doit couvrir qu’un seul besoin, mais il doit le faire bien et indépendamment des autres.

Savoir sécuriser un microservice

Chaque microservice est indépendant des autres, par définition. Son isolement fait que l’on ne peut pas sécuriser tous ces services de la même façon. Chacun doit être protégé et testé individuellement. La spécificité de chaque microservice oblige à apporter une solution différente et adaptée. En termes de sécurité, on ne peut donc pas traiter les microservices dans leur ensemble, mais uniquement individuellement.

Quelque soit le service, il faut s’assurer : que l’accès est protégé par un système d’authentification, dans le cas d’un service privé. Ce système d’authentification se doit d’être réputé fiable. que la connexion est sécurisée (HTTPS). Aucun échange de données ne doit se faire en clair. Toutes les communications doivent être chiffrées via les méthodes standards (AES…) que le service est protégé des attaques type DDOS. A partir du moment où un microservice est actif, il est possiblement soumis à des attaques de type DDOS. Ces attaques ont pour but de rendre indisponible un service, en le bombardant de demandes (requête). Il faut donc empêcher ce type d’attaque en filtrant en amont les requêtes illégitimes que les données postées sont valides (format et contenu).

Dans le cas où un microservice reçoit des données (à enregistrer ou à traiter), il est impératif de s’assurer que ces données sont bien formatées, mais aussi qu’en cas de données mal formatées, le système réagit sainement en les écartant. que les données récupérées sont valides (format et contenu). Idem que pour des données postées. que les requêtes sont filtrées en fonction du domaine et/ou de l’IP.

Dans le cas où un microservice n’est censé échanger qu’avec un nombre réduit de systèmes, il est conseillé de filtrer les échanges en fonction des adresses IP ou des domaines. Ainsi on écarte de fait tout trafic indésirable que les mises à jour de sécurité sont appliquées régulièrement.

Lorsqu’un service se base sur des technologies courantes, il faut bien surveiller leurs mises à jour. Par exemple, si on utilise une base de données PostGresQL, il est important de vérifier que cette dernière n’a pas de failles de sécurité connues.

On constate donc que chaque microservice doit être considéré comme une mini-application, et doit être testé et sécurisé comme tel. Cela engendre évidemment du temps supplémentaire par rapport à une application monolithique qui est sécurisée dans sa globalité.

Vous souhaitez bénéficier d'un audit de sécurité ?
Prenez un rendez-vous de 15 minutes pour discuter : 

Elsa Bestault
Directrice Commerciale

Savoir surveiller son architecture microservice

Afin de s’assurer que chacun des micro services fonctionne comme attendu, il est recommandé de mettre en place un monitoring des échanges et des tests automatisés. Cela permet de détecter d’éventuels problèmes : indisponibilité, tentative d'accès frauduleux, données non conformes, temps de réponse anormalement longs… Ainsi, une surveillance continue permet un contrôle en temps réel, et un traitement proactif des risques liés à la sécurité des microservices.

Au-delà de ces systèmes de surveillance, comment pouvons-nous automatiser le rétablissement d’un service défaillant ?

La solution pourrait venir de l’intelligence artificielle (IA). Par exemple, lors d’une attaque par denis de services, une IA serait en mesure de bloquer les accès et de les rouvrir automatiquement. De même, sa connaissance de ce qu’est un trafic d’échange de données normal pourrait aider à filtrer intelligemment les requêtes. Ainsi en fonction de l’analyse continue de l’activité d’un microservice (machine learning), l’IA serait en mesure de filtrer dynamiquement le trafic : telle IP est inconnue, trop de requêtes provenant d’une même source, requêtes POST vers un service de fourniture de données, horaires inhabituels de fonctionnement… Plus le trafic est qualifié, plus il est facile de détecter un fonctionnement inhabituel et donc de réagir. L’IA a certainement un rôle majeur à jouer, non seulement dans l’analyse d’un problème, mais aussi dans la réaction à avoir.

En conclusion : le microservice augmente les risques. Il faut adapter sa cyber protection en conséquence

La mise en place de microservices doit impérativement intégrer le traitement des problématiques de sécurité. Une architecture décentralisée ne simplifie pas vraiment la sécurisation d’un système dans son ensemble. Les microservices ne sont pas exempts d’attaques possibles, soit pour les rendre inopérants, soit pour les compromettre. Il est donc nécessaire de mettre en place, non seulement des tests fonctionnels, mais aussi des protections efficaces pour contrer les attaques, qui tôt ou tard finiront par arriver.