La protection des points de terminaison des API rend ces dernières difficiles à sécuriser
Les statistiques concernant la (in)sécurité des API ne manquent pas. Une recherche rapide sur Internet vous permettra d’obtenir à peu près n’importe quel point de vue sur le sujet que vous souhaitez. Il suffit de dire que (a) les attaques API sont en augmentation et (b) certaines de ces attaques réussissent.
Il est également courant de constater que les organisations ont du mal à trouver simplement toutes les API qui se cachent dans leur organisation. Ce n’est pas seulement parce que ces API sont réparties entre le cœur, le cloud et la périphérie. C’est parce qu’à part la célèbre spécification Open API (OAS), il n’existe pas de véritables « normes » sur lesquelles s’appuyer pour définir, et encore moins pour trouver, des API.
Cela ne veut pas dire que nous en avons besoin. Après tout, nous avions SOAP, WSDL et UDDI et, bien que les gens les utilisent toujours et s'appuient sur XML comme format de données, la majeure partie du monde est passée à REST, JSON, GraphQL et gRPC.
Même si nous avions des normes, cela ne changerait pas le fait que les API sont difficiles à sécuriser.
C’est parce que le terme API est un terme générique. Par exemple, l’API OpenTelemetry est simplement une façon de dire : « nous mettons les fonctionnalités d’OpenTelemetry à la disposition des développeurs ». Ce n'est pas comme si vous aviez une politique de sécurité qui pouvait couvrir « l'API Open Telemetry ». Ce serait idéal et cela rendrait les choses beaucoup plus faciles. Mais ce n’est pas ce que nous avons. Ce que nous avons, ce sont des politiques de sécurité qui couvrent les points de terminaison de l'API OpenTelemetry.
Creusons un peu ce sujet, d’accord ?
API et points de terminaison
Utilisons l’API Open AI pour notre exemple, car tout le monde est enthousiasmé par l’IA générative en ce moment.
La première chose que vous réaliserez est que même s’il n’y a qu’une seule API, il existe de nombreux points de terminaison. Combien? Ce nombre change chaque fois que de nouvelles fonctionnalités sont introduites.
Voici une liste (non exhaustive) :
- https://api.openai.com/v1/chat/completions
- https://api.openai.com/v1/audio/speech
- https://api.openai.com/v1/audio/transcriptions
- https://api.openai.com/v1/audio/translations
- https://api.openai.com/v1/embeddings
- https://api.openai.com/v1/fine_tuning/jobs
- https://api.openai.com/v1/files
L'IA générative multimodale ajoute des médias (audio et vidéo) à la liste des types de contenu, mais ajoute de nouveaux points de terminaison pour gérer les demandes de traitement. Des fonctionnalités supplémentaires, telles que l’utilisation d’outils, peuvent également étendre le nombre de points de terminaison. Chaque avancée, chaque nouvelle fonctionnalité qui nous enthousiasme, ajoute généralement un autre point de terminaison à l’API.
Vous remarquerez également le « v1 » dans ces points de terminaison. Cela signifie que lorsque la version 2 sortira, il faudra un autre ensemble de politiques de sécurité pour couvrir ces points de terminaison, et certaines de ces politiques devront changer en fonction de ce qui a changé dans le point de terminaison réel.
Ceci existe également dans la pile informatique, où l’automatisation est réalisée via des API d’appareils. Le nombre de points de terminaison dépend en grande partie de votre environnement. Plus vous gérez d'appareils, plus vous devez gérer et sécuriser de points de terminaison. Oh, et n'oublions pas qu'aucun appareil n'utilise la même API. Ce serait fou, n'est-ce pas ? C’est presque comme si deux fournisseurs de cloud acceptaient d’utiliser la même API. C’est probablement la raison pour laquelle la « complexité » reste la raison la plus souvent invoquée pour justifier le fait de ne pas automatiser un certain nombre de tâches opérationnelles. Trop d’outils et d’API rendent l’automatisation difficile et encore plus difficile la sécurisation.
Mais la sécurité des API doit prendre en compte tous ces points de terminaison, car c'est par eux que les attaquants pénètrent dans le système. Et chaque point de terminaison nécessite un ensemble différent de paramètres qui se retrouvent dans la charge utile sous forme d'objets JSON (ou XML ou GraphQL ou ). Il doit y avoir des limites à ce que chaque paramètre peut contenir : Est-ce alphanumérique ? Des personnages ? Une gamme de valeurs ? Combien de temps cela peut-il durer ? Quels caractères ne sont pas autorisés ? Toutes ces informations sont traduites en une politique qui impose l’apparence du contenu et, ce faisant, empêche les attaques de se faufiler.
L’élaboration d’une politique spécifique à l’API Open AI va prendre un certain temps. Et il ne s'agit que d'une seule API. La plupart des organisations disposent en moyenne de 442,8 API selon notre étude à venir en 2024 , et ce nombre monte en flèche pour les très grandes organisations. Pensez au nombre de points de terminaison (et de versions de points de terminaison) que cela pourrait signifier, et vous comprendrez très vite pourquoi la sécurité des API est si difficile.
Et pourquoi les attaquants réussissent suffisamment pour continuer à les cibler.