L'intérêt des stratégies intégrées de sécurité des applications et des API
Il est évident que la sécurité des applications et des API est devenue plus spécialisée. Les API ne sont plus seulement des points d’entrée basés sur des URI dans une application. Les API ont grandi et sont devenues une entité distincte avec leurs propres besoins de sécurité.
La plupart de ces besoins de sécurité sont liés à la nature des interactions API. Autrement dit, les API doivent être autorisées pour chaque transaction. Cela diffère sensiblement des applications, qui appliquent généralement l’autorisation session par session.
Le taux d’interaction est également plus élevé pour les API, tout comme un certain nombre d’autres caractéristiques qui posent des défis particuliers pour la sécurisation des API.
| Application | API | |
|---|---|---|
| Maîtrise du format des messages | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binaire, XML, formats de données |
| Interactions | Statique, changement peu fréquent | Dynamique, changement fréquent |
| Données | Structuré, transactionnel | Non structuré/structuré, en streaming et transactionnel |
| Utilisateur | Humain | Logiciel, humain |
| Agent utilisateur | Navigateurs, applications | Logiciels, appareils, scripts, applications, navigateurs |
| Authentification | Basé sur la session | Basé sur les transactions (plus comme ZT) |
| Maîtrise du protocole | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
Une comparaison des applications et des API illustre les différences qui ont provoqué une divergence dans les besoins de sécurité.
Cela dit, il existe des risques de sécurité communs aux applications et aux API qui doivent être pris en compte lors de la mise en œuvre de solutions de sécurité. Par exemple, le Top 10 de la sécurité des API 2023 récemment mis à jour montre clairement un sous-ensemble de risques partagés avec les applications :
- Contrôles d'authentification/autorisation faibles
- Mauvaise configuration
- Abus de logique métier (bourrage d'identifiants, prise de contrôle de compte)
- Falsification de requête côté serveur (SSRF)
Outre ces risques, un nombre important d’attaques ciblant la disponibilité continuent d’être menées. Il s'agit d'attaques DDoS communes aux applications et aux API, car elles partagent généralement les mêmes dépendances sur TCP et HTTP, qui sont tous deux soumis à une variété d'attaques conçues pour perturber l'accès et la disponibilité.
Une approche pour relever les défis de la sécurisation des applications, des API et de l’infrastructure qui les prend en charge consiste à déployer plusieurs solutions. Défense contre les robots et la fraude, protection DDoS, sécurité des applications et sécurité des API. Bien que cela réponde certainement aux défis de sécurité, cela introduit des défis opérationnels et rend plus complexes de nombreuses tâches liées à la sécurité, telles que la gestion des changements de politique et la réaction aux menaces qui ont un impact sur les applications et les API. La complexité n’est pas seulement l’ennemi de la sécurité, mais aussi l’ennemi de la vitesse.
Selon notre étude annuelle, la rapidité avec laquelle on peut réagir aux menaces émergentes est l’un des principaux facteurs d’adoption de la sécurité en tant que service. Chaque solution nécessitant un correctif, une mise à jour ou le déploiement d’une nouvelle politique pour atténuer une menace émergente ajoute du temps et augmente la possibilité d’une mauvaise configuration ou d’une erreur. Ainsi, le temps nécessaire pour atténuer une menace augmente avec la complexité, en particulier si une organisation opère dans plusieurs environnements (informatique hybride) et exploite des solutions de sécurité par environnement. Je ne fais pas de calculs pour déterminer s’il s’agit d’une augmentation linéaire ou exponentielle car, honnêtement, tout ce qui augmente le temps de réponse à une menace imminente n’est pas une bonne chose.
C’est pourquoi une meilleure approche consiste à combiner les solutions, partageant ainsi la gestion opérationnelle et de sécurité des fonctions conçues pour lutter contre les menaces tout en autorisant des politiques de sécurité spécifiques pour traiter les protocoles et les charges utiles propres aux applications et aux API.
Cela conduit à une stratégie intégrée de sécurité des applications et des API, dans laquelle les fonctions communes sont partagées avec une granularité et une spécificité croissantes appliquées au plus près de l'application ou de l'API. Les robots sont des robots, après tout, et leur impact 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 commune. DDoS est DDoS. Exploiter deux fois plus de services pour résoudre le même problème est inefficace à tous les égards.
Une stratégie intégrée de sécurité des applications et des API est une bonne idée sur le plan opérationnel, financier et architectural.