PC & Mobile

Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir: Protection des API

Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir: Protection des API


par Joel D’sa et Michael Endler

L'année dernière, il était brièvement possible pour quiconque possédant des connaissances techniques rudimentaires de télécharger et d'héberger des fichiers - y compris des logiciels malveillants potentiellement potentiels - sur un site web .gov.

La vulnérabilité a entraîné des poteaux de protestation et des farces mais, heureusement, aucun dommage durable. Néanmoins, comme le reconnaissent probablement déjà les plus sournois ou les plus paranoïaques, cette vulnérabilité avait tous les ingrédients d'une campagne de phishing dangereuse et efficace. Étant donné qu'il est possible de légitimer des charges malveillantes, un mauvais acteur aurait facilement pu inciter des utilisateurs peu méfiants à compromettre leurs données.

Le coupable de cette vulnérabilité? Une API mal sécurisée.

Malheureusement, ce n’était pas un cas isolé. Ce genre d'incident se produit tout le temps - et parfois, les données personnelles de millions d'utilisateurs sont impliquées.

Une quantité considérable de données et de services est aujourd'hui partagée de manière sécurisée et sécurisée via des API: informations de paiement, informations bancaires, informations de santé, bases de données de toutes sortes. Les API permettent aux développeurs d’utiliser les données et les fonctionnalités pour créer de nouvelles applications et s’intégrer aux écosystèmes numériques. Elles sont essentielles pour offrir les expériences numériques modernes attendues par les clients et les partenaires.

Comme il est incontestable qu’il est impératif pour les entreprises d’exposer leurs services via des API afin de rester pertinentes et concurrentielles aujourd’hui, il est essentiel qu’elles le fassent en toute sécurité - en contrôlant qui accède aux API, en surveillant et en gérant le mode d’utilisation des API, en déployant des fonctionnalités permettant de détecter les comportements suspects sinon, rendre les données de surveillance exploitables, etc. Ces concepts reposent sur la visibilité du trafic API, mais dans de trop nombreux cas, les entreprises n’ont tout simplement pas une idée de ce qui a été exposé à qui, de ce qui se passe réellement avec les données et des contrôles en place dans l’organisation.

L'idée d'un périmètre réseau ne s'applique tout simplement plus dans un monde dans lequel les développeurs construisent de manière agile et modulaire des expériences numériques avec des API réparties dans plusieurs environnements. Si elles ne sont pas sécurisées, ces API représentent une autre surface d’attaque - mais si les entreprises ont une visibilité sur l’ensemble de leurs API et suivent les meilleures pratiques pour les sécuriser, les API peuvent non seulement permettre la productivité des développeurs, mais également constituer une couche de sécurité importante - après tout, pour contrôler et surveiller L'accès aux API consiste à établir un moyen important de contrôler et de surveiller l'accès aux systèmes, aux données et aux services de l'entreprise.

Les enjeux autour de la sécurité des API sont élevés. Voici certaines des principales manières dont les entreprises peuvent se protéger en sécurisant leurs API.

Établir la visibilité

Si une entreprise n’a pas une visibilité adéquate sur ce qui est exposé et sur la manière dont elle est exposée, elle tolère beaucoup de risques et de responsabilité potentielle. Tout se résume au simple fait qu’une personne ne peut pas obtenir ce qu’elle ne peut pas voir.

En effet, de nombreux autres aspects de la sécurité des API ne peuvent pas être activés si la visibilité n’est pas établie en tant que fondation via une couche de gestion d’API. Existe-t-il des anomalies de trafic et, dans l'affirmative, représentent-elles une augmentation de la demande pour le service alimenté par l'API - ou représentent-elles une attaque? À quelle fréquence les attaques se produisent? Quels sont les taux de latence et évoluent-ils dans le temps? Quelles adresses IP envoient les demandes et où sont-elles situées? Des questions telles que celles-ci, et les actions qui en découlent, ne peuvent tout simplement pas être traitées de manière exhaustive sans la visibilité complète fournie par les API gérées.

De plus, avoir la visibilité nécessaire pour répondre à ces questions n’est qu’une partie de la solution. le réal L’objectif est d’avoir une visibilité et des informations en temps quasi réel qui permettent au personnel informatique de prendre des mesures avant que l’activité ne soit affectée - de maintenir les services en ligne et de satisfaire les utilisateurs. Si une équipe sait qu’une API échoue mais ne peut pas discerner sur le moment s’il s’agit d’une attaque par déni de service ou d’un problème systémique, cette équipe risque de se retrouver dans une faille dangereuse dans ses opérations de sécurité.

Tout cela renforce le fait que les API ne sont pas simplement des middlewares - ce sont des produits que les développeurs utilisent pour alimenter des applications et des expériences numériques et, comme tous les produits, elles représentent les sociétés dont elles exposent les données et les fonctionnalités. Toutes les API doivent donc être gérées en tant que produits - et l'établissement de capacités de surveillance et d'analyse ainsi que la gestion de la visibilité et du contrôle sont des pierres angulaires importantes de ce processus.

Authentifiez les bons utilisateurs

Les API correctement sécurisées doivent fournir une authentification à la fois aux utilisateurs finaux et aux applications.

OAuth2 est le standard ouvert de facto pour la sécurité des API, permettant l'authentification et l'autorisation par jeton. Il permet aux utilisateurs finaux et aux applications d’obtenir un accès limité et limité dans le temps à une ressource protégée sans demander à l’utilisateur de révéler ses informations de connexion. Pour les API en particulier, OAuth2 permet à un client qui effectue un appel à l'API d'échanger des informations d'identification contre un jeton, et ce jeton lui permet d'accéder à l'API.

OAuth2 permet à un utilisateur de déléguer l'accès à ses données à un client, tel qu'une application Web, ayant besoin de cet accès. Le protocole peut être configuré de sorte qu'un utilisateur ne puisse déléguer l'accès à un client que pendant une durée limitée et uniquement à un nombre limité de données d'API.

OAuth2 fournit en outre un moyen de déléguer l'accès sans demander à l'utilisateur de divulguer ses informations d'identification au client. Au lieu de cela, le client reçoit un jeton qui permet d'accéder à cette quantité de données restreinte et uniquement pendant le temps requis par le client pour exécuter la tâche. Par exemple, si un utilisateur final autorise son compte de réseau social à se connecter à un abonnement à un journal, OAuth2 est probablement utilisé pour faciliter la transaction, en utilisant un jeton tout en conservant les mots de passe secrets.

Cette approche présente de nombreux avantages, mais le principal avantage est que si un client est compromis, il ne perdra pas les clés ou les mots de passe de l'utilisateur. En d'autres termes, si une attaque obtient un accès, elle ne le sera que pendant un temps limité. à un sous-ensemble des données de l'utilisateur.

En plus de l'authentification des utilisateurs, OAuth2 prend également en charge le concept des informations d'identification de l'application, qui permet à une API de vérifier l'application appelante avant de renvoyer un appel, facilitant ainsi les transactions de serveur à serveur. Cela ne fournit pas une protection absolue, car toute personne disposant d'informations d'identification d'application peut utiliser et éventuellement en abuser. C'est l'une des raisons pour lesquelles la surveillance des API et d'autres fonctionnalités de gestion sont également nécessaires pour assurer la sécurité des API. Même dans ce cas, les informations d'identification de l'application fournissent une couche de sécurité importante, renforçant ainsi le flux de confiance connectant l'utilisateur final, l'application, le serveur d'autorisation OAuth2 et l'actif protégé que l'application demande via une API.

OAuth2 est constitué d'une famille complexe de spécifications, et il existe de nombreuses façons de l'utiliser. De nombreuses entreprises s'appuient sur les plates-formes de gestion des API pour générer des jetons OAuth2, contrôler avec précision les tâches qu'un jeton est autorisé à faire et appliquer des concepts tels que le contrôle d'accès basé sur les rôles (RBAC), qui attribue différents niveaux d'accès et de privilèges à l'API en fonction de fonctions intégrées. types d'utilisateurs.

Le pouvoir de l’authentification n’est pas juste pour contrôler qui accède aux données d'entreprise précieuses. L'authentification peut également être sa propre source de visibilité et un vecteur important pour générer des informations utiles, telles que des métriques segmentant les utilisateurs légitimes des utilisateurs malveillants ou capturant les adresses IP de tous les participants à une attaque brutale.

Ne fermez pas les yeux pour obtenir de l'aide sérieuse

La visibilité découle non seulement des données de trafic des API, mais également des relations avec les développeurs utilisant les API. De nombreux problèmes de sécurité sont constatés par des utilisateurs bien intentionnés. Il est donc sage d’établir des canaux permettant aux parties concernées de prendre contact. Les entreprises doivent mettre en place un processus garantissant que le personnel informatique soit en mesure de trier les problèmes, de les résoudre, de les passer en production et de communiquer avec la personne qui a signalé le problème afin de vérifier que le problème a vraiment été résolu.

Valider la saisie

La validation des entrées permet à une application de vérifier avant d'envoyer toute donnée que l'entrée utilisateur correspond aux paramètres attendus. L’application de la validation des entrées aux API est l’un des meilleurs moyens de défense contre les injections SQL, les scripts intersites et les autres menaces courantes.

Des API bien conçues et gérées doivent exploiter une spécification OpenAPI ou Swagger pour définir clairement les entrées et les sorties et déployer des API avec des processus de validation des entrées uniformes. Le déploiement de bibliothèques partagées peut constituer un moyen efficace de parvenir à la cohérence. Certaines plates-formes de gestion d’API proposent des stratégies permettant d’appliquer facilement la validation des entrées.

A l’instar de l’authentification, la validation des entrées ne consiste pas uniquement à éloigner les charges utiles malveillantes des API, mais également à établir une visibilité sur les personnes qui tentent de s’y intégrer et sur la manière dont elles tentent de le faire. Tout utilisateur qui collecte des informations sur une API ou tente de s’y introduire va probablement renverser toutes les mesures de protection de la validation des entrées. Imaginez un voleur qui vérifie systématiquement toutes les serrures d’une maison et s’il en détecte la vulnérabilité. Les cybercriminels utilisent la même technique, explorant systématiquement les API pour rechercher les faiblesses. En mesurant le nombre de fois où les verrous protégeant une API sont vérifiés et par qui, une entreprise peut avoir un aperçu des éventuelles attaques avant leur démarrage.

Contrecarrer DDoS avec limitation du débit

Les attaques par déni de service sont faciles à créer pour les mauvais acteurs, mais la limitation de la vitesse peut aider une entreprise à garder le contrôle des attaquants.

Afin d'éviter que des activités inattendues n'affectent le back-end, les règles de limitation de débit fixent des seuils de déclenchement d'arrestations de pics. Une équipe d'API peut établir que personne ne doit appeler une API plus de 500 fois par seconde, par exemple, ou qu'une application ne peut être allouée qu'à un certain nombre d'appels d'API par jour.

Les limites de taux, ainsi que la visibilité sur les utilisateurs qui ne respectent pas les seuils, peuvent aider à maintenir les systèmes en ligne, même si les attaques continuent de se produire.

Tirez parti du libre-service pour plus de sécurité

Comme tout produit, les API ont besoin d'un magasin - une destination où les développeurs peuvent parcourir les API, en savoir plus sur eux et les essayer. Fournir un accès facile est à la fois la clé pour responsabiliser les développeurs d'applications internes et pour encourager l'adoption par des partenaires externes - et fournir cet accès de manière sécurisée et normalisée, fournissant un aperçu de la consommation d'API, est l'un des fondements de la sécurité de l'API.

De nombreuses entreprises répondent à ces exigences avec un portail de développeurs en libre-service qui permet aux utilisateurs de s'inscrire, de recevoir une clé d'API et de commencer à expérimenter des API - et qui offre à l'entreprise la visibilité et le contrôle nécessaires pour que les utilisateurs ne se trompent pas. niveau d'accès. En plus de renforcer la sécurité, les contrôles d'accès peuvent aider les entreprises à poursuivre leurs stratégies de monétisation via leurs portails. Les utilisateurs d'une API gratuite peuvent par exemple être autorisés à faire des appels périodiques, tandis que les utilisateurs d'une API payante peuvent avoir droit à des appels quasi continus.

Il est important de noter que les métriques dérivées de l'engagement du portail de développeur peuvent fournir des informations non seulement sur les utilisateurs légitimes, mais également sur les attaquants. Les mauvais acteurs se rendent sur les portails pour se renseigner sur les API, tout comme les développeurs bien intentionnés - mais plutôt que de rechercher des informations sur la façon d'utiliser l'API pour créer une meilleure application, ils recherchent des indices pour les aider à percer le sous-jacent. Les données. Si une entreprise sait qu'une adresse IP semble attaquer son portail de développeur et a également déclenché ses avertissements de validation des entrées, elle peut avoir la certitude qu'elle a un utilisateur légitime en difficulté - ou un utilisateur troublant sans résultat.

Utiliser les faiblesses des robots contre eux

Les attaques de robots malveillants, telles que les attaques par déni de service par force brute mentionnées ci-dessus, représentent à certains égards le coût de la réussite dans un écosystème numérique connecté. Plus les entreprises utilisent de logiciels pour automatiser les connexions, plus nombreux sont les mauvais acteurs qui essaieront de les utiliser eux-mêmes. Par exemple, un attaquant qui a compromis une clé API peut déployer des milliers de robots qui se présentent comme des "utilisateurs" essayant d'acheter des produits, de se connecter à des comptes de fidélité ou d'avoir une incidence sur les classements et les prix du marché.

Bien que les «robots malveillants» constituent une menace, de nombreux programmes automatisés sont de «bons robots» essentiels aux expériences connectées basées sur des API. Il est essentiel que les entreprises gèrent non seulement les clés d'API avec soin, mais qu'elles soient également en mesure de déterminer, à partir des modèles de trafic, si les appels d'API proviennent d'utilisateurs légitimes ou de criminels. La capacité d’analyser le trafic en temps quasi réel, ainsi que de détecter et de bloquer les comportements suspects peut être un élément crucial de la stratégie de sécurité d’une entreprise, réaffirmant ainsi le rôle fondamental de la visibilité sur le trafic.

Une autre défense contre les robots et les abus similaires consiste à imposer au client la preuve de son identité. En plus de l'authentification, ou pour les appels dans lesquels l'authentification n'est pas optimale, cet objectif peut être atteint en déployant un système tel que reCAPTCHA, qui (comme certains d'entre vous l'ont sûrement expérimenté) peut détecter un comportement inhabituel et présenter un défi pour l'utilisateur, telles que la sélection de toutes les images d’un groupe contenant des panneaux, des routes ou des vitrines. ReCAPTCHA constitue un inconvénient temporaire pour un utilisateur légitime dont le comportement a déclenché le système par inadvertance. Cependant, le défi est beaucoup plus grand pour les robots automatisés qui produisent du spam et des abus.

Conseil de départ: ne négligez pas le fait que votre organisation est unique

Comme indiqué dans cet article, la visibilité et les informations qu’elle peut fournir constituent en grande partie le fondement de la sécurité des API - mais il est important de reconnaître que chaque entreprise utilise une pile technologique unique qui non seulement soulève ses propres considérations de sécurité, mais évolue également constamment.

De nombreuses entreprises répondent aux préoccupations de sécurité en jetant tout leur ensemble d'outils sur un problème, mais cette approche brutale est à la fois inefficace et risque de bloquer les systèmes au point de négliger des opportunités commerciales vitales. Les entreprises doivent adapter leur approche afin de pouvoir réagir aux problèmes de manière plus agile. La visibilité dans le trafic d'API permet à une entreprise non seulement d'observer, de célébrer et de capitaliser sur le trafic généré par ses API parmi des utilisateurs légitimes, mais également d'observer, d'orienter et de décider de la façon d'agir contre les mauvais acteurs.

[VoussouhaitezensavoirplussurlafaçondefairedelasécuritédesAPIunepriorité?ConsultezlerapportdeGartner"[LookingtolearnmoreabouthowtomakeAPIsecurityapriority?CheckoutGartner’sreport“Comment construire une stratégie de sécurité API efficace. "]

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close