Pourquoi vous devriez réévaluer la force de votre sécurité API


Les API sont les principaux éléments constitutifs des entreprises numériques: assembler des données, des événements et des services au sein de l’organisation, à travers les écosystèmes et les appareils. Maintenant que les organisations déplacent davantage leurs activités en ligne dans le sillage de COVID-19, ces API sont de plus en plus exposées à des groupes externes, que ce soit à d’autres départements, clients ou entreprises de leur réseau de partenaires. Cette exposition augmente non seulement les enjeux de protection des utilisateurs et des données, mais rend également les API plus vulnérables aux attaques de sécurité.

À la lumière de ces changements, il est important que les architectes et développeurs de logiciels examinent les mécanismes de sécurité des API qu’ils ont mis en place avec leurs implémentations de gestion des API et évaluent s’il est temps de mettre en place des protections plus robustes. Examinons les quatre principales approches d’authentification pour sécuriser les API dans le cadre d’une implémentation de la gestion des API, ainsi que les options pour augmenter ces approches lors de la conception ou de l’exécution d’une API.

Authentification de base

L’authentification de base est la méthode la plus simple et la plus simple. L’expéditeur place un nom d’utilisateur et un mot de passe dans l’en-tête de la demande, et le nom d’utilisateur et le mot de passe sont codés avec Base64. Cette méthode d’authentification ne nécessite pas de cookies, d’ID de session, de pages de connexion ou d’autres solutions spéciales de ce type, car elle utilise l’en-tête HTTP ou HTTPS lui-même. Il n’a également pas besoin de faire de poignée de main ou de suivre des systèmes de réponse complexes.

La simplicité de l’authentification de base signifie qu’elle peut être une méthode appropriée pour sécuriser les API lorsque vous avez une communication système à système qui se produit dans un réseau interne, par exemple avec une solution Internet des objets (IoT).

Cependant, l’authentification de base comporte certaines mises en garde. Tout d’abord, les informations d’identification sont codées et non cryptées. Par conséquent, il est facile de récupérer le nom d’utilisateur et le mot de passe. Pour cette raison, les développeurs doivent uniquement utiliser l’authentification de base sur HTTPS, pas le HTTP simple. En outre, avec cette méthode, il n’y a pas de stratégie d’actualisation des informations d’identification de l’utilisateur. Ainsi, si les informations d’identification de l’utilisateur sont modifiées, les applications clientes doivent également être modifiées.

OAuth 2.0

Open Authorization (OAuth) 2.0 est une norme ouverte pour la délégation d’accès qui est utilisée pour l’authentification et l’autorisation basées sur des jetons. Avec cette approche, l’utilisateur se connecte à un système et ce système demande une authentification, généralement sous la forme d’un jeton. L’utilisateur transmettra ensuite cette demande à un serveur d’authentification, qui rejettera ou autorisera l’authentification.

À partir de là, le jeton est fourni à l’utilisateur, puis au demandeur. Par la suite, sans l’utilisateur, ce jeton peut être utilisé ou peut être validé dans le temps jusqu’à son expiration. Ce jeton a une portée définissant la limite de son utilisation, de sorte que le même jeton ne peut pas être utilisé pour toutes les ressources des API s’il est lié à une ressource particulière. Une fois la durée de vie du jeton d’accès expirée, le demandeur doit actualiser le jeton pour en obtenir un nouveau. Il existe donc un mécanisme d’actualisation des jetons par rapport à l’authentification de base.

Fondamentalement, OAuth 2.0 est un système beaucoup plus sûr et puissant en raison de sa portée et de sa période de validité. Cette norme est utilisée par de nombreux fournisseurs de technologies, tels que Google, Facebook et Twitter.

Il existe plusieurs types d’autorisations qu’une application cliente peut utiliser pour acquérir un jeton d’accès, notamment les informations d’identification du client, le code d’autorisation, l’octroi de mot de passe, le gestionnaire de nouvelles technologies LAN (NTLM), le langage de balisage d’assertion de sécurité (SAML), l’octroi et l’actualisation de l’octroi. L’octroi de mot de passe est similaire à l’authentification de base où un utilisateur doit utiliser ses informations d’identification pour obtenir un jeton d’accès. Pendant ce temps, le code d’autorisation est le type de subvention le plus puissant.

Un jeton d’accès OAuth 2.0 peut résider sous deux formes: un jeton opaque ou un jeton Web JSON (JWT). JWT est un jeton d’accès autonome qui contient toutes les informations requises pour valider un jeton d’accès. Lorsque vous fournissez un jeton d’accès opaque, la passerelle doit appeler le gestionnaire de clés pour valider le jeton d’accès.

En revanche, avec un jeton d’accès JWT, la passerelle elle-même peut valider le jeton d’accès sans passer par le gestionnaire de clés. Ceci est très important dans un environnement verrouillé où la passerelle n’est pas connectée à d’autres composants. L’inconvénient de cette option OAuth 2.0 est que les applications clientes doivent implémenter la récupération, l’actualisation, etc. du jeton d’accès, ce qui la rend quelque peu complexe pour l’application cliente.

Clés API

Les clés API sont une option populaire car elles nécessitent moins d’efforts que le développement d’un flux OAuth 2.0. Dans cette méthode, une valeur générée unique est attribuée à chaque premier utilisateur, ce qui signifie que l’utilisateur est connu. Chaque fois qu’un utilisateur essaie de rentrer dans le système, sa clé unique est utilisée pour vérifier qu’il s’agit du même utilisateur qu’auparavant. En fonction de l’implémentation de la clé API de différents fournisseurs de gestion d’API, la clé peut être modifiée. Il peut s’agir d’un jeton d’accès JWT, d’un jeton opaque ou d’une clé client d’une application OAuth 2.0.

Une clé API peut être envoyée en tant qu’en-tête ainsi qu’un paramètre de requête dans le cadre de l’URL. Cependant, son utilisation en tant que valeur d’en-tête est plus sûre, car l’envoi de la clé API en tant que paramètre de requête facilite la découverte par les attaquants.

L’approche de clé API est largement utilisée dans l’industrie et est devenue quelque peu une norme en raison de sa simplicité. Et, bien que les clés API soient recommandées pour une utilisation avec les communications de système à système, elles présentent trop de risques de sécurité lorsqu’elles sont utilisées pour authentifier les utilisateurs.

SSL mutuel

Dans l’authentification SSL (Secure Sockets Layer) mutuelle, un client vérifie l’identité du serveur et le serveur valide l’identité du client afin que les deux parties se fassent mutuellement confiance. En utilisant cette approche, la passerelle API et les clients qui s’y connectent sont bien connus. Par conséquent, il est recommandé de l’utiliser dans des scénarios nécessitant une sécurité stricte et / ou des communications de serveur à serveur.

La détermination de la meilleure option d’authentification pour sécuriser les API dépendra du cas d’utilisation spécifique. Les questions clés à considérer sont:
1. Une sécurité renforcée du système est-elle nécessaire?
2. Les communications de système à système ou de serveur à serveur sont-elles impliquées?
3. Une délégation d’accès est-elle requise?
4. La communication entre la passerelle API et les clients se produit-elle dans un réseau interne?

Au-delà de l’authentification

L’authentification est au cœur de la sécurisation des API. Mais, selon le degré d’utilisation d’une API, il convient d’envisager d’autres mesures de sécurité de l’API pour mesurer la sécurité d’une API ou signaler s’il existe une attaque potentielle de l’API.

Une approche consiste à auditer la définition Swagger d’une API avant de la publier. Avec une technologie comme l’API Security Audit de 42Crunch, un développeur d’API peut obtenir un rapport sur la sécurité de l’API basée sur les exigences de format OpenAPI, la sécurité et la validation des données. À l’aide du rapport, le développeur peut éliminer toutes les failles de sécurité existantes dans une API en suivant exactement où se trouve un problème et en prenant des mesures correctives.

Une autre approche consiste à utiliser une analyse de sécurité basée sur l’intelligence artificielle (IA) lors de l’exécution pour détecter toute tentative d’attaque. Ici, la passerelle API interceptera les demandes d’API et appliquera les politiques comme d’habitude, mais elle enverra également des métadonnées de demande d’API à un outil d’analyse de sécurité d’API, tel que PingIntelligence pour les API. L’outil piloté par l’IA vérifiera la validité de la demande, recherchera tout modèle d’accès anormal et confirmera si la demande est OK ou si elle est suspecte et doit donc être bloquée par la passerelle API.

Des exemples d’attaques d’API pouvant être signalées et bloquées à l’aide de cette approche incluent les attaques de bourrage d’informations d’identification sur les systèmes de connexion, les données de grattage des botnets, les attaques par déni de service distribué (DDoS) de couche 7, les cookies volés, les jetons ou les clés d’API; et des initiés voyous exfiltrant des données en petites quantités au fil du temps.

Conclusion

Les premières enquêtes commerciales et nos propres discussions avec les clients dans un large éventail d’industries suggèrent que leur expansion de la collaboration et des communications à distance, de l’automatisation et des offres de produits et de services numériques deviendra la nouvelle norme. Les API étant à l’origine de bon nombre de ces utilisations, le moment est venu pour les architectes et les développeurs de réévaluer et de mettre à jour leurs stratégies de sécurité des API.

Auteur de l’article : manuboss