Les arguments en faveur de stratégies intégrées de sécurité des applications et des API
C’est une évidence, la sécurité des applications et des API est de plus en plus spécialisée. Les API ne sont plus seulement des points d’entrée dans une application basés sur des URI. Elles se sont développées pour devenir une entité distincte avec leurs propres besoins en matière de sécurité.
La plupart de ces besoins de sécurité sont liés à la nature des interactions avec les API. En effet, les API doivent être autorisées pour chaque transaction, ce qui est très différent des applications, qui mettent généralement une autorisation en place pour une session complète.
Le taux d’interaction est également plus élevé dans le cas des API, et bien d’autres caractéristiques posent des défis particuliers en matière de sécurisation.
| Application | API | |
|---|---|---|
| Maîtrise du format des messages | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binaire, XML, formats de données |
| Interactions | Statiques, changements peu fréquents | Dynamiques, changements fréquents |
| Données | Structurées, transactionnelles | Non structurées, en continu et transactionnelles |
| Utilisateur | Humain | Logiciel, humain |
| Agent utilisateur | Navigateurs, applications | Logiciels, appareils, scripts, applications, navigateurs |
| Authentification | Maîtrise des protocoles | À l’échelle de la transaction (plus proche d’une approche ZT) |
| Maîtrise des protocoles | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
La comparaison entre les applications et les API illustre les différences qui expliquent la divergence des besoins en matière de sécurité.
Cela dit, certains risques de sécurité communs aux applications et aux API doivent être pris en compte lors de la mise en œuvre de solutions de sécurité. Par exemple, l’API Security Top 10 2023 de l’OWASP, récemment mis à jour, montre clairement un sous-ensemble de risques partagés avec les applications :
- Contrôles d’authentification/d’autorisation faibles
- Mauvaise configuration
- Abus de logique métier (credential stuffing, prise de contrôle de compte)
- Server-Side Request Forgery (SSRF).
Outre ces risques, un nombre important d’attaques continuent de cibler la disponibilité : les attaques DDoS sont communes aux applications et aux API, car elles partagent généralement les mêmes dépendances à l’égard de TCP et de HTTP, deux protocoles sujets à une variété d’attaques visant à perturber l’accès et la disponibilité.
Pour relever les défis de la sécurisation des applications, des API et de l’infrastructure qui les supporte, une approche consiste à déployer plusieurs solutions : protection contre les robots et la fraude, protection DDoS, sécurité des applications et sécurité des API. Bien que cette approche permette de relever les défis de sécurité, elle pose des problèmes opérationnels et rend plus complexes de nombreuses tâches liées à la sécurité, à commencer par la gestion des changements de politique et la réponse aux menaces qui affectent à la fois les applications et les API. La complexité n’est pas seulement l’ennemie de la sécurité, elle est aussi l’ennemie de la rapidité.
Selon notre étude annuelle, la rapidité de réaction aux menaces émergentes est l’un des principaux facteurs d’adoption de la sécurité en tant que service. Chaque solution qui nécessite un correctif, une mise à jour ou le déploiement d’une nouvelle politique pour atténuer une menace émergente augmente la charge de travail et le risque d’une mauvaise configuration ou d’une erreur. Le temps nécessaire pour atténuer une menace augmente avec la complexité, en particulier si une organisation exploite plusieurs environnements (informatique hybride) et utilise des solutions de sécurité différentes d’un environnement à l’autre. Je ne prendrai pas le temps de calculer si cette augmentation est linéaire ou exponentielle : honnêtement, tout ce qui augmente le temps de réponse à une menace imminente est à proscrire.
C’est pourquoi une meilleure approche consiste à combiner les solutions : les fonctions de lutte contre les menaces partageront les mêmes outils de gestion opérationnelle et de gestion de la sécurité, tandis qu’on mettra en œuvre des stratégies de sécurité spécifiques pour traiter les protocoles et les charges utiles propres aux applications et aux API.
Le résultat : une stratégie intégrée de sécurité des applications et des API, dans laquelle les fonctions globales sont mises en commun avec une granularité et une spécificité croissantes à mesure qu’on s’approche de l’application ou de l’API. Un robot reste un robot, et leur incidence sur la qualité des données, le coût de livraison et le profil de risque des applications et des API est une préoccupation pour tous les acteurs. De même, un DDoS reste un DDoS. Exploiter le double de services pour résoudre un même problème est inefficace à tous points de vue.
Une stratégie intégrée de sécurité des applications et des API est aussi pertinente du point de vue opérationnel et financier qu’architectural.