29 octobre 2024
Architecture
Thomas Jardinet
Manager Architecture
Cet article a eu en primo-inspiration mon sentiment qu’IT et Cyber travaillent malheureusement de manière trop souvent silotées. Avec des contraintes de sécurité souvent mal abordées ou insuffisamment partagées. Inspiration également au travers de rencontres de personnes travaillant dans le Cyber, qui peut-être se reconnaîtront.
En effet, la sécurité des API, côté IT, est souvent perçue comme un sujet couvert à partir du moment ou l’on gère bien l’authentification, les droits, et qu’on utilise une API Gateway. Oui bien sûr cela est nécessaire. Mais penser sécurité des API, au regard de ce que ce sujet implique, c’est penser un gros pan de la sécurité de son SI.
Ne venant pas du monde du Cyber, cet article n’aura comme seule prétention d’essayer de se faire rencontrer ces deux mondes. En abordant tous les aspects que la sécurité des API peut couvrir. Et évidemment, cet article est une invitation à vous rapprocher de vos équipes Cyber ! Et de vous fournir une liste de courses aussi synthétique que possible pour échanger entre équipes IT et Cyber. Mais un peu longue quand même. D’où le formalisme très concis choisi pour cet article.
Pour se faire, nous allons dans un premier temps expliciter les risques que nous identifions, pour ensuite aborder la sécurisation des API sur toute leur chaîne de valeur, du DevSecOps aux WAF d’API (WAAP pour Web Application and API Protection). Pour ensuite offrir un panorama de technologies, et enfin finir avec des préconisations. Sur ce, on y va !
Pourquoi la sécurité des API est-elle cruciale ?
- Les données exposées sont très souvent sensibles : Les API renvoient souvent des données confidentielles, rendant leur protection indispensable.
- C’est un vecteur d’attaque privilégié : En tant que point d’entrée unique des données, les APIs sont des points d’attaque de choix.
- Leur complexité est croissante : L’évolution des architectures (microservices, coud, service mesh, …) peut augmenter la surface d’attaque potentielle.
- Les API doivent respecter le cadre réglementaire : RGPD, PCI DSS, PSD2, etc…, autant de réglementations qui exigent une exposition sécurisée des API.
Cela n’arrive qu’aux autres? Et bien non.
2019. Facebook. Fuite de données concernant 540 millions d’utilisateurs à cause de serveurs non sécurisés et accessibles via des API.
2018. Twitter. Une mauvaise gestion des autorisations d’accès a rendu disponibles les messages privés de certains utilisateurs.
Maintenant que ces enjeux sont rappelés, nous allons détailler les risques et solutions.
I. Les risques majeurs liés à la sécurité des API
1.1 Vulnérabilités courantes des API
1.1.1 Injection de code
L’injection de code est l’une des menaces les plus connues, avec
- L’injection SQL par exemple,
Mais aussi par commandes avec l’exemple pas si ancien de la faille Log4J.
1.1.2 Authentification et autorisation inadéquates
Il est primordial d’avoir une politique d’authentification et d’autorisation bien appliquée afin de bloquer au mieux les attaquants. On peut retenir comme principes :
- Les sessions doivent être bien gérées : Sessions non expirées ou mal révoquées.
- Les tokens d’accès doivent être bien sécurisés : Stockage ou transmission non sécurisée des tokens.
- Les contrôles d’accès doivent être bien configurés: Permissions mal configurées permettant des accès non autorisés.
1.1.3 Exposition de données sensibles
Les API peuvent involontairement exposer des données sensibles et inutiles si elles ne sont pas correctement définies, configurées ou sécurisées. Les cas typiques sont :
- Les réponses API sont trop verbeuses : Inclusion de données non nécessaires dans les réponses.
- Les réponses API ne sont pas chiffrées : Transmission de données en clair.
Les erreurs sont mal gérées : Messages d’erreur révélant des informations sensibles sur l’infrastructure.
1.2 Menaces émergentes et sophistiquées
1.2.1 Attaques par force brute et credential stuffing
Stratégie largement connue, consistant à tester des combinaisons de noms d’utilisateur et de mots de passe. Elles sont aussi simples à parer que particulièrement dangereuses car :
- Elles peuvent être automatisées à grande échelle.
- Elles peuvent aussi exploiter des informations d’identification provenant de fuites de données (évitez d’avoir un seul mot de passe…).
1.2.2 Attaques « Man-in-the-Middle » (MITM)
Une attaque MITM consiste à ce que l’attaquant se place entre le client et l’API Gateway pour intercepter ou modifier les échanges. Les risques incluent :
- Le vol de données sensibles : En interceptant des données non chiffrées.
- La manipulation de requêtes : En altérant des données échangées entre le client et le serveur.
- L’usurpation d’identité : En récupérant les certificats serveurs pour se faire passer pour le serveur légitime.
1.2.3 Attaques DDoS
Ces attaques consistent à avoir un très grand nombre d’appels, afin de rendre indisponible l’API. Elles peuvent prendre plusieurs formes :
- Les attaques volumétriques : En saturant la bande passante.
- Les attaques au niveau applicatif : En utilisant des vulnérabilités de l’API pour épuiser les ressources du serveur.
- Les attaques lentes : Cela consiste à maintenir des connexions ouvertes pour épuiser les ressources du serveur.
1.3 Risques spécifiques aux architectures modernes
1.3.1 Microservices et conteneurisation
La conteneurisation et les microservices ajoutent de nouveaux défis de sécurité :
- La complexité exponentielle de la gestion des accès : On doit gérer les exigences de sécurité par microservice.
- Les risques liés à l’orchestration des conteneurs : Les outils d’orchestration peuvent avoir aussi leurs propres vulnérabilités.
L’exposition accrue des API internes : Les API internes ne doivent absolument pas être exposées en externe !
1.3.2 API dans le cloud
Le déploiement d’API dans des environnements cloud présente des risques spécifiques :
- La mauvaise configuration des services cloud : Exposition involontaire d’API ou de données.
- La gestion des identités et des accès complexifiés : Il est nécessaire d’intégrer les mécanismes de sécurité de son cloud provider avec ceux de son API.
- La dépendance vis-à-vis de la sécurité du fournisseur cloud : Il est nécessaire de comprendre et de compléter les mesures de sécurité, selon la politique de son cloud provider.
1.3.3 Shadow API et API zombies
Les « shadow API » (non documentées ou non gérées) et les « API zombies » (obsolètes mais toujours actives) représentent des risques significatifs :
- Le manque de visibilité : Ce qui engendre des difficultés à identifier et à sécuriser ces API.
- Les vulnérabilités non corrigées : Les API obsolètes peuvent contenir des failles de sécurité connues.
Les Accès non contrôlés : Il ya alors un risque d’exploitation par des attaquants sur des systèmes ou des données sensibles.
II. Stratégies et solutions pour sécuriser efficacement les API
2.1 Approche globale de la sécurité des API
2.1.1 Sécurisation de l’API via DevSecOps
L’approche DevSecOps permet de sécuriser une API en amont de son déploiement, via :
- Le Shift-left security : Qui intègre les tests de sécurité dès le début.
- L’automatisation des tests de sécurité : Grâce à des outils d’analyse de code statique (SAST) et dynamique (DAST).
La gestion continue des vulnérabilités : Code, librairies, dépendances, etc… Tous ces éléments peuvent faillir ou contenir des failles découvertes après coup. Il faut donc les détecter et les corriger.
2.1.2 Gouvernance et politiques de sécurité des API
Que serait-on sans gouvernance ? C’est évidemment un point primordial, sur lequel on sera particulièrement vigilant sur les aspects suivants :
- La définition de standards de sécurité : Via documents de bonnes pratiques de développement et de déploiement d’API sécurisées.
- La gestion des accès et des identités (IAM) : Pour couvrir la définition de politiques strictes pour l’authentification et l’autorisation.
Des audits réguliers : Afin d’évaluer de manière continue la conformité des API aux politiques de sécurité.
2.1.3 Formation et sensibilisation des équipes
La sécurité des API repose en grande partie sur les compétences et la vigilance de toutes les équipes, qu’elles soient devops, cyber ou dev :
- Des programmes de formation : Via des sessions dédiées sur les pratiques de sécurité des API.
- Des exercices pratiques : Via des simulations d’attaques et de réponses aux incidents.
Une culture de la sécurité : En encourageant à signaler et à résoudre les problèmes de sécurité.
2.2 Technologies et outils de sécurisation des API
2.2.1 API Gateways et Web Application and API Protection (WAAP)
Les API Gateways (et leurs cousins service mesh et micro-gateway) et les WAAP (WAF pour API, si vous préférez) représentent la première ligne de défense :
- En filtrant du trafic : Via blocage des requêtes malveillantes.
- En gérant les authentifications : En centralisant et en renforçant les mécanismes d’authentification.
- En faisant du rate limiting : En protégeant contre les attaques DDoS.
Et en analysant le trafic : En détectant et en bloquant les comportements suspects.
2.2.2 Solutions de gestion et de protection des API
D’autres outils spécialisés existent, qui ont des fonctionnalités avancées pour la sécurité des API :
- Solutions de découverte automatique des API : Afin de détecter les fameuses Shadow API.
- Solutions d’analyse comportementale : Afin de détecter les anomalies et des comportements suspects.
- Solutions de gestion des versions : Afin de contrôler et de sécuriser les différentes versions d’API.
Solutions de conformité réglementaire : Afin de démontrer la conformité aux règlements de sécurité.
2.2.3 Outils d’analyse de la sécurité des API
Des outils dédiées existent également pour déterminer des failles spécifiques aux API :
- Les scanners de vulnérabilités spécifiques aux API : Comme son nom l’indique.
- Les solutions de fuzzing d’API : Le fuzzing est une technique de test envoyant des données aléatoires et/ou malformées pour identifier les failles.
Outils d’analyse statique et dynamique : Il existe des SAST et DAST adaptés aux API.
2.3 Meilleures pratiques de sécurisation des API
2.3.1 Authentification et autorisation robustes
- Via utilisation de protocoles standards : OAuth 2.0, OpenID Connect.
- Via gestion fine des autorisations : Via implémentation du principe du moindre privilège, au travers des API scope.
- Via rotation régulière des clés et tokens : Pour limiter l’impact en cas de compromission.
2.3.2 Centralisation et découpage des API Gateway
Une API Gateway est à placer idéalement de manière centrale dans son architecture pour ne pas multiplier les points d’entrée. On peut néanmoins avoir deux API Gateway, une “publique” et une autre “privée” afin de mitiger les risques au mieux :
- Point d’entrée unique : Centralisation du trafic API pour une meilleure visibilité et un contrôle accru.
- Gestion des versions : Facilitation de la gestion des différentes versions d’API.
- Transformation et médiation : Adaptation des requêtes et des réponses pour assurer la compatibilité et la sécurité.
2.3.3 Chiffrement et protection des données
- Chiffrement en transit : En utilisant systématiquement le TLS (dans une version non dépréciée). Possiblement aussi signer les données échangées, comme le peut faire Stripe avec son API afin de garantir leur authenticité, intégrité et non-répudiation.
- Chiffrement des données sensibles : Que ce soit des données au repos ou en transit.
- Gestion sécurisée des clés : En gérant les clés de chiffrement tout au long de leur cycle de vie. Il s’agit notamment de :
- l’utilisation de clés solides, générées de manière aléatoire.
- la rotation régulière des clés afin de limiter l’impact des violations potentielles.
- stocker les clés en toute sécurité dans des “Vault”, séparément des données qu’elles protègent.
- mettre en place des contrôles d’accès.
- gérer les identités numériques via des certificats grâce à une PKI, couplé à
- un HSM pour sécuriser des clés cryptographiques dans un environnement matériel.
2.3.4 Gestion des logs et audit
- La journalisation : En enregistrant tous les événements liés à la sécurité.
- La conservation des logs : En conservant les logs pendant une période suffisante pour permettre des analyses dans le passé.
- L’analyse régulière des logs : En mettant en place des processus d’analyse régulière des logs.
- La protection des logs : En empêchant toute modification non autorisée pour garantir leur intégrité en cas d’audit.
2.3.5 Surveillance en temps réel
- L’analyse comportementale : Pour détecter les anomalies dans le trafic API.
- Les alertes en temps réel : Pour réagir rapidement aux incidents de sécurité.
- Le monitoring continu : Pour surveiller en permanence la disponibilité des API et détecter rapidement les attaques.
2.3.6 Tests de pénétration et validation de la sécurité
- Des tests réguliers.
- Des scénarios réalistes qui s’inspirent de cas réels.
- Une validation continue via la chaîne CI/CD.
Conclusion
Comme on peut le voir, la sécurité des API demandent des compétences dans diverses équipes, mais également un engagement de tous. Des solutions informatiques existent, mais elles ne sont rien sans une politique de sécurité partagée à tous et pour tous. Et aussi et surtout l’établissement des bonnes pratiques définies en interne, comme nous l’avons partagées dans cet article.
Pour aller plus loin, on pourra aussi se reporter au RGS de l’ANSSI (https://cyber.gouv.fr/le-referentiel-general-de-securite-rgs), mais aussi faire de la veille sur les outils de découvertes d’API, l’utilisation de l’IA pour la sécurité, et bien sur aller faire un tour sur l’OWASP API Security Project (https://owasp.org/www-project-api-security/)
Devops, Dev, RSSI, c’est à vous !
Articles qui pourraient vous intéresser
22 octobre 2024
Architecture
