Sécuriser les API dans une API Gateway

Avant-propos

En juin 2021, près de 92 % des données des utilisateurs de LinkedIn ont été divulguées par des API publiques qui manquaient de contrôles de sécurité. Les données exposées, vendues au public sur le marché noir, contenaient 700 millions de noms d'utilisateurs, des données personnelles, des adresses e-mail, des numéros de téléphone et d'autres informations spécifiques. Bien que LinkedIn considère cet événement comme une collecte de données publiques plutôt qu'un accès illicite, il souligne néanmoins l'importance des mesures de sécurité des API.

En tant qu'interface externe permettant aux applications de fournir des services, les API sont constamment exposées au trafic externe, rencontrant des attaquants hostiles qui utilisent des attaques par déni de service, des injections et des vulnérabilités connues pour attaquer. Par exemple, en décembre 2020, des attaquants ont exploité les défauts de log4j 2 pour effectuer des attaques non configurées contre les API. Par conséquent, il est nécessaire de renforcer la capacité de l'API à repousser ces attaquants malveillants. Cependant, avant d'adopter des mesures pour sécuriser une API, comprenons d'abord ce qu'est une API.

Qu'est-ce qu'une API ?

Traditionnellement, l'API (Application Programming Interface) représente les bibliothèques de liens statiques ou dynamiques du logiciel pour invoquer ses fonctions. Les développeurs peuvent réutiliser les fonctions fournies par un logiciel existant en se basant sur des appels à ses API, comme TCP/IP, fourni par les systèmes d'exploitation.

Avec l'évolution des systèmes logiciels et des réseaux, le terme "API" désigne désormais les interfaces de système accessibles via un réseau. Les clients appellent ces interfaces en utilisant des protocoles comme HTTP pour exécuter des fonctions client, comme interroger l'API météo pour obtenir des informations météorologiques.

Dans son sens originel, l'API fait référence à un canal fourni par le système logiciel pour d'autres services, qui définit la spécification de l'interopération entre divers sous-systèmes. Le service d'authentification, par exemple, fournit des interfaces pour la connexion des utilisateurs, l'inscription et l'acquisition d'informations utilisateur. D'autres services peuvent utiliser ces interfaces d'appel pour accomplir la fonction d'authentification utilisateur. De même, via l'API, les sous-systèmes peuvent coopérer pour accomplir la tâche de l'application entière.

Qu'est-ce que la sécurité des API ?

Après cet aperçu des API, nous allons maintenant introduire la sécurité des API. La sécurité des API implique trois perspectives principales :

Sécurité de l'information (InfoSec) : Du point de vue de l'information, s'assurer que l'information est protégée tout au long de son cycle de vie, de sa génération à sa transmission, son stockage et sa destruction.

Sécurité réseau (NetSec) : Du point de vue du réseau, s'assurer que les données transmises sur le réseau ne sont pas écoutées ou modifiées et qu'aucun individu non autorisé n'accède au réseau.

Sécurité des applications (AppSec) : Du point de vue du système d'application, s'assurer que les applications développées peuvent empêcher les attaques malveillantes.

La sécurité des API est l'intersection de ces trois aspects, ce qui signifie que les trois aspects sont indispensables si vous voulez bien faire en matière de sécurité des API.

Attaques courantes sur la sécurité des API

OWASP, le projet ouvert de sécurité des applications web, a publié une liste de 10 problèmes de sécurité courants des API OWASP API Security Project | OWASP Foundation.

Elle contient les problèmes suivants :

Autorisation d'objet défaillante : Les utilisateurs accèdent à des objets de données auxquels ils n'ont pas accès.

Authentification utilisateur défaillante : Une erreur d'implémentation du service d'authentification permet aux utilisateurs de contourner le mécanisme d'authentification pour accéder illégalement à l'API.

Exposition excessive de données : Permettre aux utilisateurs d'obtenir des données sensibles excessives, qui devraient être interdites.

Manque de ressources et de limitation de débit : Manque de restrictions sur le nombre de ressources nécessaires pour répondre aux demandes des clients, ainsi que sur les volumes de requêtes réalistes.

Autorisation de fonction défaillante : Les utilisateurs accèdent à une API de fonctionnalité à laquelle ils n'ont pas accès. Affectation de masse : Les utilisateurs modifient involontairement les données qu'ils ne sont pas autorisés à éditer via une interface mal développée.

Mauvaise configuration de la sécurité : Mesures de sécurité mal configurées pour l'API.

Injection : Des données non fiables en entrée déclenchent des injections SQL, des exécutions de commandes imprévues ou des accès aux données.

Gestion inadéquate des actifs : Gestion inadéquate des ressources de l'API, comme la publication des API pour les environnements de test ou les versions incorrectes antérieures des API hors ligne.

Journalisation et surveillance insuffisantes : Il est difficile d'identifier les anomalies de sécurité en utilisant des méthodes d'audit en raison de l'absence d'outils de journalisation et de surveillance pour l'accès à l'API.

Après avoir remarqué les problèmes courants liés à la sécurité des API, que faut-il mettre en œuvre pour protéger l'API ?

Comment protéger votre API ?

En termes de protection des API, il est également possible de prendre des mesures sous trois perspectives :

InfoSec : Nous pouvons construire un système de confidentialité pour l'information conforme aux exigences légales et de sécurité pour éviter de divulguer des informations personnelles.

NetSec : Le chiffrement et la vérification de la transmission des données sont nécessaires.

AppSec : Nous devons renforcer la sécurité de l'application.

Voici quelques pratiques supplémentaires pour la sécurité des API.

Chiffrement constant : Nous pouvons empêcher les écoutes et les modifications de données causées par des réseaux non gérés grâce à une configuration TLS en flux complet. De plus, il est également nécessaire d'activer mTLS pour vérifier l'exactitude du côté client afin d'empêcher les accès non autorisés.

Utiliser les jetons avec prudence : Nous devons être prudents dans l'utilisation des JWTs car ils permettent au client de les décoder, ce qui pourrait exposer des informations confidentielles en cas d'utilisation incorrecte. De plus, nous aurons besoin d'aide pour révoquer une session de connexion spécifique car l'application d'une procédure de révocation est compliquée en raison de ses limitations.

Granularité des permissions réduite : Attribuer des permissions minimales pour l'accès aux API et aux données pour éviter les accès non autorisés.

Validation des entrées : Ne jamais faire confiance aux valeurs d'entrée du client. Vous devez valider les valeurs d'entrée du client pour vous assurer qu'elles répondent aux exigences de sécurité.

Limitation du débit : Limiter la vitesse d'accès à l'API. Cette mesure empêche les attaques par déni d'accès, qui se produisent lorsqu'un système est surchargé de requêtes qu'il ne peut pas gérer en même temps.

Journalisation et surveillance : Concevoir un mécanisme de journalisation et de surveillance approprié pour le système nous permet d'identifier rapidement les événements de sécurité et de prendre les mesures appropriées. Nous pouvons également revenir en arrière après un événement de sécurité de l'information pour identifier les systèmes et les données affectés et déterminer l'étendue des fuites de données potentielles.

Les mesures mentionnées ci-dessus nous obligent à apporter des modifications spécifiques au système d'application en traitant des composants individuels, ce qui est non seulement très coûteux mais aussi susceptible de provoquer d'autres problèmes.

Comment pouvons-nous mettre en place des mesures de sécurité sans compromettre les services d'application ?

Passerelles API

Les passerelles API offrent une nouvelle voie en dehors de la transformation du système, ce qui réduit considérablement le coût de la transformation et fournit une gestion centralisée et unifiée du trafic entrant. Les passerelles API offrent également des fonctionnalités de sécurité riches, qui nous permettent d'interdire et d'enregistrer les visites non autorisées.

En utilisant Apache APISIX comme exemple, la section suivante décrira plusieurs scénarios d'application de passerelle API pour sécuriser les API.

Chiffrement (TLS/mTLS)

Vous pouvez non seulement activer TLS pour l'API pour offrir un accès HTTPS, mais aussi activer mTLS pour vérifier l'identité du client. Naturellement, il est également possible pour vous d'activer TLS/mTLS pour les services en amont afin de garantir la sécurité du trafic pendant qu'il traverse le réseau interne. Vous pouvez consulter le manuel mTLS pour activer la fonctionnalité nécessaire.

Vérification d'identité

Toutes les connexions peuvent être chiffrées, mais cela ne garantit pas la sécurité de l'API. Par conséquent, dans des contextes commerciaux réels, nous devons inclure des composants liés à l'authentification. Pour résoudre ce problème, APISIX offre une variété de plugins connectés à l'authentification qui peuvent être facilement interfacés avec des services d'authentification externes ou directement via la passerelle. Ces plugins vont des plus simples comme LDAP, OpenID Connect et Open Policy Agent aux plus complexes comme Basic Auth, Key Auth, JWT Auth et Forward Auth.

Limitation du débit

Le manque de ressources et la limitation du débit sont deux attaques fréquentes. Pour ces situations, les passerelles incluent généralement des plugins liés à la limitation de débit ; Apache APISIX ne fait pas exception. Il offre trois plugins : limit-count, limit-req et limit-conn, qui fournissent des fonctionnalités de limitation de la vitesse des requêtes, de mesure des requêtes et de limitation des connexions. Ils peuvent aider à contrôler efficacement la pression d'accès à l'API et empêcher le système d'être surchargé par des quantités ingérables de requêtes.

Restrictions de sécurité

APISIX offre des plugins CORS et CSRF pour fournir une protection contre les requêtes inter-domaines et les falsifications de requêtes intersites pour l'API, renforçant ainsi sa capacité à protéger sa sécurité. De plus, ses plugins de restriction permettent de bloquer l'IP, l'UA, le Referer et l'URI, ce qui peut contrer la majorité des attaques sur les API.

Vérification des entrées

APISIX fournit le plugin request-validation, qui permet aux fournisseurs d'API de valider les entrées utilisateur via jsonschema. Les données structurées et le langage de description des règles de validation peuvent être bien utilisés pour la validation des données.

Observabilité

Les méthodes listées ci-dessus sont toutes des moyens de protéger l'API. Cependant, aucun système n'est complètement sécurisé. Une fois qu'un système est attaqué, nous devons agir rapidement pour déterminer la cause de l'attaque et empêcher d'autres dommages causés par l'attaque. Par conséquent, APISIX offre également une large gamme de plugins de journalisation, qui peuvent envoyer des logs à diverses destinations, y compris Kafka, Clickhouse et des solutions de journalisation en tant que service offertes par des fournisseurs de cloud comme Google Cloud, Splunk, etc.

De plus, APISIX offre une fonctionnalité de suivi des liens avec des connexions à Skywalking, OpenTelemetry et d'autres programmes de traçage.

En outre, APISIX fournit le plugin Prometheus, qui peut calculer et exporter des métriques liées aux requêtes API vers le service de surveillance Prometheus pour aider à identifier les problèmes de performance et éviter les interruptions de service systémiques.

Nous pouvons identifier les incidents de sécurité potentiels à temps en rendant le système suffisamment observable.

Capacités de programmation

Enfin et surtout, APISIX offre également un plugin serverless pour traiter les vulnérabilités 0-day, permettant aux utilisateurs d'utiliser du code Lua pour exécuter une logique lorsque la requête arrive. Nous pouvons profiter de cette fonctionnalité pour bloquer temporairement certaines vulnérabilités 0-day lorsqu'elles surviennent.

Conclusion

La sécurité des API est essentielle pour les fournisseurs de services, donc les développeurs doivent faire un effort pour la maintenir à jour. Afin de démontrer comment les passerelles API peuvent être utilisées dans différents contextes d'application, cet article utilise Apache APISIX comme exemple, qui est une nouvelle stratégie différente de la modification du système qui aide les développeurs à réduire le coût des problèmes de sécurité.