Au cours des dernières années, l’architecture de microservices est devenue une tendance émergente dans le monde du développement logiciel afin d’offrir un développement rapide, une meilleure évolutivité et des services faiblement couplés. Cependant, plusieurs services autonomes utilisent différentes technologies, outils, langages et cadres dans chaque domaine d’affaires. Des communications continues ont lieu entre ces services indépendants déployés dans des environnements multi-cloud. Ainsi, cela peut causer divers problèmes de sécurité comme l’incohérence des données, les fuites de données et d’autres attaques de surface. En utilisant la sécurité des logiciels, nous protégeons contre la perte de données, l’interruption des services, les fuites de données et les incohérences de données.
Qu’est-ce qu’un microservice ?
Un microservice est une approche architecturale et organisationnelle pour le développement d’applications où le logiciel est composé de petits services indépendants qui communiquent par une interface bien définie en utilisant des API légères.
Ces services sont hautement maintenables, faiblement couplés, déployables de façon indépendante, évolutifs, et organisés en fonction des capacités d’affaires. Cela aide à automatiser les tests et le déploiement et offre de courts cycles de déploiement avec un temps d’arrêt minimal de l’application.
Processus d’architecture sécurisée
Pour rendre notre système aussi sécurisé que possible, la conception du système doit être sécurisée. Une bonne conception peut aider à développer un bon système de sécurité. Ce processus commence au début du cycle de vie du système et ne se termine jamais. L’étape de modélisation des menaces est une étape cruciale pour esquisser toutes les menaces possibles pour le système. C’est la première étape qui joue un rôle important pour s’assurer que notre système soit aussi sécurisé que possible. Voici les étapes du processus d’architecture de sécurité.
- Modélisation des menaces
- Architecture sécurisée
- SDLC
- Tests
- Production
Modélisation des menaces
La modélisation des menaces est le processus par lequel les menaces potentielles telles que les vulnérabilités structurelles peuvent être identifiées et énumérées, et les contre-mesures priorisées. Le but de la modélisation des menaces est de fournir aux défenseurs une analyse systématique des contrôles ou des défenses à inclure, selon la nature du système, le profil probable de l’attaquant, les vecteurs d’attaque les plus probables et les actifs les plus recherchés par un attaquant.
Architecture sécurisée
Définir une architecture sécurisée en fonction des menaces identifiées dans la modélisation des menaces. Le processus d’architecture pour le développement d’applications est le suivant :
- Comprendre les exigences du système
- Comprendre les exigences non fonctionnelles
- Cartographier les composants
- Sélectionner la pile technologique
- Concevoir l’architecture
- Documents de l’architecture sécurisée
Identité sécurisée des microservices
Lors de l’appel de microservices, le service appelé doit savoir qui l’appelle et si l’appel est permis ou non (authentification et autorisation).
- Identité du service : Le service appelé reçoit l’identité du service qui l’appelle et décide si cet appel est permis. Ceci est utile pour gérer la communication service à service. Cela limite l’accès en fonction des services appelants. L’identité du service est utilisée dans des scénarios non interactifs comme l’absence d’écran de connexion pour l’utilisateur final. Le service appelant doit posséder un jeton pouvant être utilisé pour l’authentification. Les données de ce jeton représentent l’appelant autorisé auprès d’un service. Ce jeton se présente habituellement sous une ou deux formes, soit une clé API ou un jeton d’accès.
- Clé API : La clé API est fournie par le service appelé ou la gestion centrale de l’identité. Elle est envoyée avec la requête et le service appelé la valide et décide si l’accès est autorisé.
- Jeton d’accès : Le jeton d’accès est fourni dans le cadre du processus d’authentification OAuth2. Dans ce flux, avant d’appeler le service, on s’adresse au serveur d’authentification, on s’identifie avec l’identifiant de l’application et quelques secrets, puis on reçoit le jeton d’accès. Ce jeton est envoyé dans la requête de service, et le service appelé le valide en appelant le serveur d’authentification. Ce jeton est limité dans le temps. Il nécessite une intégration profonde avec le serveur d’authentification.
- Identité de l’utilisateur : Le service appelé reçoit l’identité de l’utilisateur final qui l’appelle et décide si cet appel est permis et c’est utile pour l’audit des actions utilisateur dans le système. L’accès est limité selon les permissions de l’utilisateur final. L’interaction utilisateur (page de connexion) est requise pour l’identité utilisateur. Le résultat de l’authentification est généralement un JWT. Ce JWT est transmis au service appelé, qui le valide.
Sécurisation des données des microservices
Sécuriser les données des microservices n’est pas différent de l’architecture classique. Peu importe le nombre de bases de données dans le système, toutes les données doivent être chiffrées. Il faut toujours réfléchir pour choisir la base de données cloud ou non cloud adéquate et sécurisée selon les besoins de l’application.
Meilleures pratiques d’architecture de microservices
Lorsque plusieurs applications clientes communiquent avec de grandes ou complexes applications basées sur des microservices, tous les microservices doivent être exposés à l’extérieur, ce qui augmente la surface d’attaque comparativement à si l’on masquait les microservices qui ne sont pas directement sollicités par les applications clientes. La meilleure solution pour réduire la surface d’attaque est la passerelle d’API.
Passerelle d’API
La principale fonction de la passerelle d’API est de router les requêtes API entrantes vers les bons microservices. Elle peut être utilisée comme porte d’entrée et point d’application lors de l’exposition des API à divers consommateurs (tels que partenaires externes ou développeurs internes).
La passerelle d’API peut ajouter de la valeur et faciliter l’exposition de vos services à vos consommateurs en appliquant un ensemble standard de politiques de sécurité à toutes les API. La passerelle d’API agit comme un point d’application pour les flux entrants, sortants et internes. Elle maintient la segmentation entre les API de microservices en utilisant des contrôles à la fois au niveau de la sécurité réseau et de la gestion des identités et des accès.
Architecture de microservices utilisant une passerelle d’API :
- L’accès client aux API est authentifié et autorisé selon les standards industriels (OpenID Connect/OAuth2). Une fois authentifié, la passerelle d’API échange un jeton « externe » contre un jeton « interne » (émis par le service de jeton sécurisé) avant de faire suivre les messages vers les microservices API ou les systèmes en aval.
- S’assurer que les requêtes d’API passent par la passerelle d’API. Appliquer une signature numérique dans l’en-tête de la requête pour les requêtes API transmises aux API en aval.
- Les API publiques anonymes ne nécessitent pas d’authentification ni d’autorisation. L’exposition de ces API est séparée des points de terminaison authentifiés.
- Les contrôles d’accès au niveau des ressources sont validés dans la passerelle d’API selon les jetons d’accès « externes ». Les accès granulaires sont validés dans le microservice d’API selon les jetons d’accès « internes ».
- Les points de terminaison exposés par les passerelles d’API génèrent des journaux d’audit d’authentification et d’autorisation pour toutes les transactions API.
- Maintenir des paramètres de configuration séparés pour différents points de terminaison exposés sur la passerelle d’API (interne, public, partenaire).
- Exiger des clients qu’ils accèdent aux identifiants à partir d’une liste blanche d’autorités d’identité fiables.
- Effectuer régulièrement des analyses de vulnérabilité des points de terminaison exposés par les passerelles d’API pour identifier d’éventuelles faiblesses ou défaillances dans la configuration TLS ou HTTP.
- La protection contre les attaques de déni de service (DoS) et de déni de service distribué (DDoS) est mise en œuvre pour se protéger contre l’abus du protocole réseau et HTTP.
- Appliquer des compteurs de performance, seuils et limitations de débit pour protéger la disponibilité des API et des ressources en arrière-plan.
- Imposer l’utilisation de protocoles sécurisés pour la transmission de données.
- Exposer des points de terminaison séparés aux consommateurs d’API provenant de différents domaines de confiance (p. ex. : interne, partenaire, public). Appliquer des règles de pare-feu d’API pour contrôler l’accès aux API.
- S’assurer de la prise en charge des requêtes API mettant en œuvre le chiffrement au niveau du message ou du champ.
- Appliquer des règles de pare-feu applicatif Web pour inspecter les messages API. S’assurer que les messages API contenant des données binaires ou servant au transfert de fichiers sont contrôlés contre les charges malveillantes ou les malwares.
- Les points de terminaison exposés aux domaines publics externes ou partenaires utilisent une autorité de certification tierce de confiance. Les points de terminaison exposés au domaine interne peuvent utiliser une autorité de certification privée interne.
Tests de sécurité des microservices
L’architecture de microservices nécessite beaucoup plus d’attention lors des tests de nos services. Des approches DAST (Dynamic Application Security Testing) et SAST (Static Application Security Testing) sont utilisées pour tester les applications et détecter les vulnérabilités de sécurité pouvant rendre notre système vulnérable aux attaques.
- SAST
- DAST
SAST est une méthodologie de test en boîte blanche : elle analyse le code pour détecter les failles logicielles et les vulnérabilités telles que l’injection SQL, l’exposition de données sensibles, le cross-site scripting (XSS), les mauvaises configurations de sécurité, les composants obsolètes, la journalisation de la sécurité, les défaillances d’identification et d’authentification, etc. Quelques outils utiles pour identifier les vulnérabilités de sécurité comme 42Crunch, Checkmarx, FOSSA, etc.
DAST est une méthode de test en boîte noire qui examine une application en cours d’exécution pour trouver des vulnérabilités qu’un attaquant pourrait exploiter.
Dans l’architecture de microservices, chaque service est séparé et isolé. Lorsque plusieurs applications clientes communiquent avec des applications basées sur des microservices, tous les microservices doivent être exposés à l’extérieur
Résumé
Les microservices apportent une grande évolutivité et agilité au monde numérique actuel. La complexité de l’architecture de microservices s’accompagne d’une grande surface d’attaque. Si l’on souhaite un système plus sécurisé, la conception de nos microservices et la communication doivent être aussi sécurisées que possible. Pour sécuriser les microservices, il faut intégrer la sécurité à l’architecture. Les stratégies de sécurisation des microservices présentées ici devraient donner une bonne compréhension de la conception de microservices pour sécuriser nos services. Ce n’est pas un processus ponctuel pour sécuriser nos services lors de la conception de notre système; il doit être amélioré au fil du temps selon le type d’attaques de sécurité rencontrées.
Références
- Microservices - Wikipédia
- Comment rédiger un « security pattern » – Microservices API (securitypatterns.io)
- SAST vs. DAST : Quelle est la différence ? | Synopsys
- https://owasp.org/www-community/Threat_Modeling
- https://en.wikipedia.org/wiki/Threat_model
- https://securitypatterns.io/docs/05-api-microservices-security-pattern/
