Microservices : sécurité et attaques ciblées

Les microservices désignent une architecture logicielle dans laquelle une application est décomposée en services autonomes, chacun exposant ses fonctionnalités via des API REST ou gRPC. La sécurité des microservices est un enjeu critique car chaque service constitue une surface d'attaque indépendante. Contrairement à une architecture monolithique, les communications inter-services transitent sur le réseau interne, souvent sans chiffrement ni authentification forte par défaut. Un attaquant ayant compromis un premier service peut pivoter latéralement vers d'autres composants sans rencontrer de contrôle de sécurité supplémentaire. Cette exposition est amplifiée dans les environnements conteneurisés orchestrés par Kubernetes, où la densité des services et la rotation rapide des instances compliquent la visibilité. Chaque service possède son propre cycle de vie, ses dépendances et ses configurations. Une mauvaise gestion des secrets, des tokens JWT faibles ou des politiques réseau absentes suffisent à compromettre l'ensemble du système. Le modèle zero trust, appliqué aux microservices, impose une authentification et une autorisation explicites à chaque appel inter-service, réduisant ainsi le rayon d'explosion en cas de compromission.

La détection des attaques ciblant les microservices repose sur une instrumentation fine de chaque service et de ses communications. Côté SOC, l'analyse des logs d'accès API permet de repérer des appels anormaux : volumes inhabituels, accès à des endpoints non documentés, tokens JWT réutilisés depuis des IP inattendues ou présentant des claims falsifiés. Sur Kubernetes, les événements d'audit de l'API server (activés via l'audit policy) exposent les créations de pods, modifications de ServiceAccount et accès aux secrets. Les outils de service mesh comme Istio ou Linkerd génèrent des métriques de trafic est-ouest exploitables dans un SIEM : latence anormale, erreurs 403/401 en rafale, ou flux entre services normalement isolés. Falco, déployé en tant que DaemonSet, détecte les comportements suspects au niveau syscall dans les conteneurs, comme un shell spawné depuis un processus applicatif. Les indicateurs de compromission clés incluent des appels inter-services sortant du graphe de dépendances attendu, des montages de volumes sensibles non prévus, ou des requêtes vers l'API de métadonnées cloud (IMDS) depuis un pod applicatif. Une baseline du trafic normal entre services est indispensable pour rendre ces détections opérationnelles.

Côté Red Team, l'exploitation des microservices commence souvent par la reconnaissance des endpoints exposés via des outils comme Kiterunner ou ffuf adaptés aux schémas d'API REST. Si une API Gateway est absente ou mal configurée, des appels directs aux services internes deviennent possibles. Les tokens JWT sont une cible privilégiée : algorithme 'none', secret faible bruteforcé avec jwt-cracker, ou injection de claims arbitraires. La compromission d'un service permet ensuite un lateral movement vers d'autres services en abusant des ServiceAccount Kubernetes dont les tokens sont montés automatiquement dans les pods. L'accès à l'API server avec un ServiceAccount trop permissif permet l'escalade de privilèges via la création de RoleBinding. Les contre-mesures de durcissement prioritaires incluent l'activation des Network Policies Kubernetes pour segmenter le trafic est-ouest, le recours à mTLS via un service mesh pour authentifier chaque service, la rotation automatique des secrets avec HashiCorp Vault, et la restriction des ServiceAccount au strict nécessaire via le principe du moindre privilège. L'analyse statique des images conteneur avec Trivy ou Grype détecte les vulnérabilités dans les dépendances avant déploiement.