Sécurité de bout en bout pour les API : tout au long du cycle de vie

Akamai a acquis Noname Security en juin 2024. Cet article de blog archivé a été publié à l'origine le 5 octobre 2022.

Sécuriser correctement les interfaces de programmation d'applications (API) est un processus qui va bien au-delà de la sécurité. Ce processus présente des aspects opérationnels et architecturaux liés aux systèmes TI qui déterminent les résultats en matière de sécurité. Pour être efficace, la sécurité des API doit être considérée comme un processus de bout en bout couvrant l'ensemble du cycle de vie du logiciel. Cela commence par le développement et se poursuit pendant la durée d'exécution et la fin du service.

La sécurité des API nous oblige à remettre en question certaines vieilles idées. On suppose, par exemple, que le développement de logiciels s'achève par le déploiement du code dans la production. Ce n'est plus le cas aujourd'hui. Le développement de logiciels dépasse désormais le processus de base consistant à écrire du code.

Le développement est un processus continu représenté par le concept d'intégration et de déploiement continus (CI/CD). Parallèlement, les logiciels sont développés grâce à DevOps, qui combine les étapes séquentielles précédentes de développement de logiciels (Dev) et de déploiement de logiciels dans des produits par les services informatiques (Ops).

Aujourd'hui, dès qu'un morceau de code est déployé en production, l'équipe DevOps se prépare à déployer une nouvelle itération de l'application. Le prochain déploiement peut intervenir une heure plus tard. Avec DevOps, il semble que le processus Dev soit devenu le processus Ops. L'aspect opérationnel du processus ne se distingue plus de l'aspect développement. La sécurité des applications doit donc couvrir les étapes connectées de développement (Dev) et d'exploitation (Ops).

Ajoutons que les logiciels actuels ne se résument pas à un simple code. Il s'agit également d'un ensemble de connexions entre des composants tels que des microservices, des API, des bibliothèques de code, etc. Pour assurer la sécurité des API, il faut comprendre comment ces connexions fonctionnent, où elles se trouvent et comment elles peuvent être vulnérables aux acteurs malveillants. Cette exigence va également au-delà des pratiques de sécurité habituelles et inclut des tâches opérationnelles telles que la création d'inventaires des API et la surveillance du trafic des API.

La sécurité des API doit être opérationnelle au stade du développement d'une application, au moment de la durée d'exécution et au-delà - tout au long du cycle de vie du développement logiciel (SDLC). En commençant par le développement, les développeurs peuvent demander aux applications d'invoquer les fonctionnalités de l'API par le biais d'appels API ou de créer des API qui exposent les fonctionnalités et les données de l'application à d'autres applications logicielles. Les deux modes de fonctionnement des API créent une exposition au risque.

Les risques liés à la sécurité des API sont dus à diverses raisons, mais beaucoup sont liés à des problèmes de configuration des API qui affectent l'authentification et l'autorisation de l'utilisateur. Une API mal configurée peut permettre à un utilisateur inconnu d'accéder à des données sensibles. Par ailleurs, une erreur de configuration peut permettre à un utilisateur d'obtenir des données au-delà de ce qui est autorisé. D'autres problèmes de configuration peuvent permettre à un pirate de surcharger l'API avec des appels et d'exécuter une attaque par déni de service (DoS). 

Pendant l'étape de développement

Les tests de sécurité des API peuvent atténuer les risques liés aux API au stade du développement. Les tests doivent être spécifiques aux API, car les tests d'applications générales ne permettront pas de détecter des problèmes tels qu'une mauvaise configuration de l'API. Une suite de tests de sécurité des API doit identifier les vulnérabilités des API et faciliter leur correction avant que le logiciel ne soit déployé.

Pour fonctionner, les tests de sécurité des API doivent être planifiés au début du processus de développement, c'est ce que l'on appelle l'approche shift-left. La suite de tests doit également s'intégrer au pipeline CI/CD. Sinon, le processus de réparation de sécurité sera trop lourd à gérer pour les membres de l'équipe DevOps.

Pendant la durée d'exécution

Pendant la durée d'exécution, la sécurité de l'API consiste à bloquer les menaces en temps réel. Il faut pour cela contrôler la sécurité de l'API. Une solution de sécurité des API doit rester vigilante sur le trafic des API et alerter les administrateurs lorsqu'elle détecte un comportement anormal ou des signatures d'attaques. La solution peut également prendre des mesures supplémentaires pour bloquer automatiquement l'API lorsqu'elle détecte une menace.

La sécurité pendant la durée d'exécution des API est relativement simple. Toutefois, cela ne fonctionne que si la solution de sécurité des API sait où se trouvent toutes les API. Pour être sécurisées, les API doivent faire l'objet d'une gestion de la posture de l'API, impliquant notamment le processus de découverte de l'API. Il est impossible de défendre une API qui est invisible pour la solution de sécurité. Il est donc nécessaire de dresser l'inventaire des API. La découverte des API est également nécessaire, car les passerelles API et les pare-feux d'applications Web (WAF) ne dressent pas automatiquement l'inventaire de toutes les API dans un environnement, malgré ce que l'on peut penser.

Indésirables, zombies et fantômes : Oh là là !

Le processus de découverte des API conduit inévitablement les administrateurs informatiques à être surpris de constater que leurs environnements contiennent de nombreuses API « indésirables », « zombies » et « fantômes ».

• Une API indésirable est une API qui a été perdue au fil du temps. Il peut s'agir d'une ancienne version d'une API qui n'a jamais été désactivée. Il peut s'agir d'une API exposée dans une application logicielle commerciale dont personne ne connaissait l'existence. 
• Une API zombie est une API fonctionnelle qui est en dehors des écrans radars. 
• Une API fantôme est créée par quelqu'un qui prend l'initiative de créer des API, mais qui n'en informe pas le service informatique.

Ces trois types d'API non découvertes génèrent une exposition au risque. Les politiques de sécurité ne peuvent pas leur être appliquées car les API sont invisibles. Si elles ne sont pas configurées en matière de sécurité, et elles sont généralement mal configurées ou dépourvues de correctifs, elles permettront un accès aux pirates.

Il peut être difficile de savoir quoi faire avec des API inconnues. Si elles doivent continuer de fonctionner, elles doivent être mises en conformité avec les politiques relatives à la configuration, à l'authentification, etc. Fermer une API qui vient d'être découverte peut être la meilleure option, mais cela peut poser des problèmes.

Par exemple, si une version antérieure d'une API est toujours utilisée, bien qu'elle ait été remplacée par une autre, sa désactivation pourrait entraîner le dysfonctionnement des applications. Toute personne qui prend la décision de mettre l'API hors ligne s'expose à des ennuis. Il faut un ensemble d'outils qui donne aux administrateurs les informations dont ils ont besoin pour prendre la bonne décision.

Pour assurer la sécurité des API de bout en bout, il faut disposer des bons outils. Une solution de sécurité des API de bout en bout efficace est une solution capable de gérer les tests de sécurité des API, la sécurité pendant la durée d'exécution des API, ainsi que la gestion et l'inventaire de la posture de sécurité des API. Soyez vigilant avec les outils existants, car la plupart des WAF et des passerelles API ne couvrent pas le développement, les tests, la surveillance pendant la durée d'exécution et l'inventaire.

Idéalement, la solution de sécurité des API doit également fonctionner de manière à ne pas affecter les performances du réseau ou des API. Par exemple, les solutions de sécurité des API d'Akamai fonctionnent en surveillant une copie du trafic réseau. Elles peuvent repérer les appels d'API dans ce trafic réseau copié, en identifiant ainsi les API inconnues et les menaces de sécurité.

La sécurité des API doit couvrir toutes les phases de la vie d'une API, du développement au retrait, en passant par la durée d'exécution. La sécurité dépend en partie de processus qui ne sont pas techniquement liés à la sécurité, notamment les inventaires des API. Les API inconnues créant une exposition au risque, leur identification permet de sécuriser leurs applications. Il s'agit d'une proposition de bout en bout. Plus les mesures de sécurité des API sont complètes, plus l'environnement informatique sera sécurisé.