Comment l'IA améliorera la sécurité des API

Les API sont devenues les joyaux de la couronne des initiatives de transformation numérique des organisations, permettant aux employés, partenaires, clients et autres parties prenantes d'accéder aux applications, aux données et aux fonctionnalités commerciales de leur écosystème numérique. Il n'est donc pas étonnant que les pirates informatiques aient multiplié leurs vagues d'attaques contre ces actifs critiques de l'entreprise.

Malheureusement, il semble que le problème ne fera qu'empirer. Gartner a prédit que, «D'ici 2022, les abus d'API seront le vecteur d'attaque le plus fréquent entraînant des violations de données pour les applications Web d'entreprise.»

De nombreuses entreprises ont réagi en mettant en œuvre des solutions de gestion des API qui fournissent des mécanismes tels que l'authentification, l'autorisation et la limitation. Ce sont des fonctionnalités indispensables pour contrôler qui accède aux API dans tout l'écosystème d'API et à quelle fréquence. Cependant, lors de l'élaboration de leurs stratégies d'API internes et externes, les organisations doivent également faire face à la croissance d'attaques plus sophistiquées contre les API en mettant en œuvre une sécurité dynamique basée sur l'intelligence artificielle (IA).

Cet article examine la gestion des API et les outils de sécurité que les organisations doivent intégrer pour garantir la sécurité, l'intégrité et la disponibilité dans leurs écosystèmes d'API.

Mesures de sécurité basées sur des règles et des politiques

Les contrôles de sécurité basés sur des règles et des stratégies, qui peuvent être effectués de manière statique ou dynamique, sont des éléments obligatoires de toute solution de gestion d'API. Les passerelles API servent de point d'entrée principal pour l'accès aux API et gèrent donc généralement l'application des politiques en inspectant les demandes entrantes par rapport aux politiques et règles liées à la sécurité, aux limites de débit, à la limitation, etc. Examinons de plus près certaines vérifications de sécurité statiques et dynamiques pour voir les valeur qu'ils apportent.

Contrôles de sécurité statiques

Les contrôles de sécurité statiques ne dépendent pas du volume de la requête ou des données de requête précédentes, car ils valident généralement les données de message par rapport à un ensemble prédéfini de règles ou de stratégies. Différentes analyses de sécurité statiques sont effectuées dans les passerelles pour bloquer l'injection SQL, les attaques d'analyse cohérente, les attaques d'extension d'entité et l'empoisonnement de schéma, entre autres.

Pendant ce temps, des vérifications de politique statiques peuvent être appliquées à l'analyse de la charge utile, à l'inspection des en-têtes et aux modèles d'accès, entre autres. Par exemple, l'injection SQL est un type d'attaque courant exécuté à l'aide de charges utiles. Si un utilisateur envoie une charge utile JSON (JavaScript Object Notation), la passerelle API peut valider cette demande particulière par rapport au schéma JSON prédéfini. La passerelle peut également limiter le nombre d'éléments ou d'autres attributs dans le contenu selon les besoins pour se protéger contre les données nuisibles ou les modèles de texte dans les messages.

Contrôles de sécurité dynamiques

Les contrôles de sécurité dynamiques, contrairement aux analyses de sécurité statiques, vérifient toujours quelque chose qui varie au fil du temps. Cela implique généralement la validation des données de demande avec des décisions prises à l'aide de données existantes. Des exemples de vérifications dynamiques incluent la validation du jeton d'accès, la détection d'anomalies et la limitation. Ces vérifications dynamiques dépendent fortement du volume de données envoyé à la passerelle. Parfois, ces vérifications dynamiques se produisent en dehors de la passerelle API, puis les décisions sont communiquées à la passerelle. Regardons quelques exemples.

La limitation et la limitation du débit sont importantes pour réduire l'impact des attaques, car chaque fois que les attaquants ont accès aux API, la première chose qu'ils font est de lire autant de données que possible. La limitation des requêtes API, c'est-à-dire la limitation de l'accès aux données, nécessite que nous conservions un décompte des requêtes entrantes dans une fenêtre de temps spécifique. Si le nombre de demandes dépasse le montant alloué à ce moment-là, la passerelle peut bloquer les appels d'API. Avec la limitation de débit, nous pouvons limiter l'accès simultané autorisé pour un service donné.

Authentification

L'authentification aide les passerelles d'API à identifier chaque utilisateur qui appelle une API de manière unique. Les solutions de passerelle API disponibles prennent généralement en charge l'authentification de base, OAuth 2.0, la sécurité JWT (JSON Web Token) et la sécurité basée sur les certificats. Certaines passerelles fournissent également une couche d'authentification en plus de cela pour une validation d'autorisation plus fine supplémentaire, qui est généralement basée sur les langages de définition de stratégie de style XACML (eXtensible Access Control Markup Language). Ceci est important lorsqu'une API contient plusieurs ressources qui nécessitent différents niveaux de contrôle d'accès pour chaque ressource.

Limitations de la sécurité API traditionnelle

Les approches basées sur des politiques en matière d'authentification, d'autorisation, de limitation de débit et d'étranglement sont des outils efficaces, mais elles laissent toujours des failles à travers lesquelles les pirates peuvent exploiter les API. Notamment, les passerelles d'API font face à plusieurs services Web, et les API qu'elles gèrent sont fréquemment chargées avec un nombre élevé de sessions. Même si nous analysions toutes ces sessions à l'aide de politiques et de processus, il serait difficile pour une passerelle d'inspecter chaque demande sans puissance de calcul supplémentaire.

De plus, chaque API a son propre modèle d'accès. Ainsi, un modèle d'accès légitime pour une API peut indiquer une activité malveillante pour une API différente. Par exemple, lorsqu'une personne achète des articles via une application d'achat en ligne, elle effectuera plusieurs recherches avant d'effectuer l'achat. Ainsi, un seul utilisateur envoyant 10 à 20 requêtes à une API de recherche dans un court laps de temps peut être un modèle d'accès légitime pour une API de recherche. Cependant, si le même utilisateur envoie plusieurs demandes à l'API d'achat, le modèle d'accès pourrait indiquer une activité malveillante, telle qu'un pirate informatique essayant de retirer autant que possible en utilisant une carte de crédit volée. Par conséquent, chaque modèle d'accès API doit être analysé séparément pour déterminer la réponse correcte.

Un autre facteur encore est qu'un nombre important d'attaques se produisent en interne. Ici, les utilisateurs disposant d'informations d'identification valides et d'un accès aux systèmes utilisent leur capacité à attaquer ces systèmes. Les capacités d'authentification et d'autorisation basées sur des stratégies ne sont pas conçues pour empêcher ce type d'attaques. 

Même si nous pouvions appliquer plus de règles et de politiques à une passerelle API pour se protéger contre les attaques décrites ici, la surcharge supplémentaire sur la passerelle API serait inacceptable. Les entreprises ne peuvent pas se permettre de frustrer les véritables utilisateurs en leur demandant de supporter les délais de traitement de leurs passerelles API. Au lieu de cela, les passerelles doivent traiter les demandes valides sans bloquer ni ralentir les appels d'API des utilisateurs.

Le cas de l'ajout d'une couche de sécurité IA

Pour combler les lacunes laissées par les protections d'API basées sur des stratégies, les équipes de sécurité modernes ont besoin d'une sécurité d'API basée sur l'intelligence artificielle capable de détecter et de répondre aux attaques dynamiques et aux vulnérabilités uniques de chaque API. En appliquant des modèles d'IA pour inspecter et rapporter en permanence toutes les activités d'API, les entreprises pourraient automatiquement découvrir l'activité et les menaces anormales des API dans les infrastructures d'API que les méthodes traditionnelles manquent.

Même dans les cas où les mesures de sécurité standard sont capables de détecter les anomalies et les risques, les découvertes peuvent prendre des mois. En revanche, en utilisant des modèles prédéfinis basés sur les modèles d'accès des utilisateurs, une couche de sécurité basée sur l'IA permettrait de détecter certaines attaques en temps quasi réel.

Surtout, les moteurs d'IA fonctionnent généralement en dehors des passerelles API et leur communiquent leurs décisions. Étant donné que la passerelle API n'a pas à dépenser de ressources pour traiter ces demandes, l'ajout de la sécurité AI n'a généralement pas d'impact sur les performances d'exécution.

Intégration de la sécurité API basée sur des politiques et basée sur l'IA

Lors de l'ajout d'une sécurité basée sur l'IA à une implémentation de gestion d'API, il y aura un point d'application de la sécurité et un point de décision. En règle générale, ces unités sont indépendantes en raison de la puissance de calcul élevée requise, mais la latence ne doit pas être autorisée à affecter leur efficacité.

La passerelle API intercepte les requêtes API et applique diverses stratégies. Le point d'application de la sécurité est lié à celui-ci, qui décrit les attributs de chaque demande (appel d'API) au point de décision, demande une décision de sécurité, puis applique cette décision dans la passerelle. Le point de décision, alimenté par l'IA, apprend en permanence le comportement de chaque modèle d'accès à l'API, détecte les comportements anormaux et signale les différents attributs de la demande.

Il devrait y avoir une option pour ajouter des politiques au point de décision si nécessaire et appeler ces politiques - qui peuvent varier d'une API à l'autre - pendant la période d'apprentissage. Toute politique doit être définie par l'équipe de sécurité une fois que les vulnérabilités potentielles de chaque API qu'elle prévoit d'exposer sont parfaitement comprises. Cependant, même sans le soutien de politiques externes, une technologie de point de décision et de point d'application adaptative et alimentée par l'IA finira par apprendre et empêcher certaines des attaques complexes que nous ne pouvons pas détecter avec des politiques.

Un autre avantage d'avoir deux composants distincts de point d'application de la sécurité et de point de décision est la possibilité de s'intégrer aux solutions de gestion d'API existantes. Une simple amélioration de l'interface utilisateur et une extension personnalisée pourraient intégrer le point d'application de la sécurité à l'éditeur et à la passerelle d'API. À partir de l'interface utilisateur, l'éditeur d'API pouvait choisir d'activer ou non la sécurité de l'IA pour l'API publiée, ainsi que les stratégies spéciales nécessaires. Le point d'application de sécurité étendu publierait les attributs de la demande sur le point de décision et limiterait l'accès à l'API en fonction de la réponse du point de décision.

Cependant, publier des événements sur le point de décision et restreindre l'accès en fonction de sa réponse prendra du temps et dépendra fortement du réseau. Par conséquent, il est préférable de l'implémenter de manière asynchrone à l'aide d'un mécanisme de mise en cache. Cela affectera un peu la précision, mais si l'on considère l'efficacité de la passerelle, l'ajout d'une couche de sécurité AI contribuera de manière minimale à la latence globale.

Défis de la couche de sécurité basés sur l'IA

Bien entendu, les avantages ne sont pas sans coûts. Bien qu'une couche de sécurité basée sur l'IA offre un niveau supplémentaire de protection des API, elle présente certains défis que les équipes de sécurité devront relever.

  • Frais généraux supplémentaires . La couche de sécurité AI supplémentaire ajoute une surcharge au flux de messages. Les solutions de médiation doivent donc être suffisamment intelligentes pour gérer la collecte et la publication d'informations en dehors du flux de médiation principal.
  • Faux positifs . Un volume élevé de faux positifs nécessitera un examen supplémentaire par des professionnels de la sécurité. Cependant, avec certains algorithmes d'IA avancés, nous pouvons réduire le nombre de faux positifs déclenchés.
  • Manque de confiance . Les gens se sentent mal à l'aise lorsqu'ils ne comprennent pas comment une décision a été prise. Les tableaux de bord et les alertes peuvent aider les utilisateurs à visualiser les facteurs derrière une décision. Par exemple, si une alerte indique clairement qu'un utilisateur a été bloqué pour accéder au système à un rythme anormal de plus de 1000 fois en une minute, les gens peuvent comprendre et faire confiance à la décision du système.
  • Vulnérabilité des données . La plupart des solutions d'IA et d'apprentissage automatique reposent sur des volumes massifs de données, souvent sensibles et personnelles. En conséquence, ces solutions pourraient devenir sujettes à des violations de données et au vol d'identité. Le respect du RGPD de l'Union européenne (règlement général sur la protection des données) permet d'atténuer ce risque mais ne l'élimine pas entièrement.
  • Limitations des données étiquetées . Les systèmes d'IA les plus puissants sont entraînés par un apprentissage supervisé, ce qui nécessite des données étiquetées qui sont organisées pour les rendre compréhensibles par les machines. Mais les données étiquetées ont des limites et la future création automatisée d'algorithmes de plus en plus difficiles ne fera qu'exacerber le problème.
  • Données erronées . L'efficacité d'un système d'IA dépend des données sur lesquelles il est formé. Trop souvent, de mauvaises données sont associées à des préjugés ethniques, communautaires, de genre ou raciaux, qui peuvent affecter des décisions cruciales concernant les utilisateurs individuels.

Compte tenu du rôle critique des API dans les entreprises d'aujourd'hui, elles deviennent de plus en plus la cible des pirates et des utilisateurs malveillants. Les mécanismes basés sur des stratégies, tels que l'authentification, l'autorisation, l'analyse de la charge utile, la validation de schéma, la limitation et la limitation de débit, sont des exigences de base pour mettre en œuvre une stratégie de sécurité d'API réussie. Cependant, ce n'est qu'en ajoutant des modèles d'IA pour inspecter en permanence et rendre compte de toutes les activités des API que les entreprises seront protégées contre les attaques de sécurité les plus sophistiquées émergentes aujourd'hui.

Sanjeewa Malalgoda est architecte logiciel et directeur associé de l'ingénierie chez WSO2, où il dirige le développement du gestionnaire d'API WSO2. Lakshitha Gunasekara est ingénieur logiciel au sein de l'équipe WSO2 API Manager. 

-

New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à  [email protected] .