Tout ce que vous devez savoir sur la sécurité des API en 2021

La sécurité des API Web est l’application de toutes les bonnes pratiques de sécurité appliquées aux API Web, qui sont largement présentes dans les applications d’aujourd’hui. La sécurité des API Web comprend le contrôle des accès et la confidentialité des API ainsi que la détection et la résolution des attaques ciblant API via ‘reverse engineering’ et l’exploitation de leurs vulnérabilités, comme décrit dans OWASP API Security Top 10.

Qu’une application cible des consommateurs, des employés, des partenaires ou autre, le côté client d’une application (par exemple, une application mobile, une application Web) interagit avec le côté serveur d’une application via une API (Application Programming Interface). En termes simples, les API permettent à un développeur de créer facilement une application côté client. Les architectures de microservices sont également rendues possibles par les API.

Parce qu’elles sont souvent disponibles sur des réseaux publics (accessibles de n’importe où), les API sont généralement bien documentées ou leur ‘reverse engineering’ est aisé. Également très sensibles aux attaques de type par déni de service (DDOS), les API sont des cibles attractives pour des acteurs malveillants.

Une attaque peut inclure le contournement de l’application côté client pour tenter de perturber le fonctionnement d’une application pour d’autres utilisateurs ou la violation d’informations privées. La sécurité des API se concentre sur la sécurisation de cette couche applicative et sur ce qui peut arriver si un acteur malveillant interagissait directement avec une API.

Les API se sont multipliés de façon astronomique ces dernières années, alimenté par la transformation digitale et le rôle central que jouent les API dans les applications mobiles et l’Internet des Objets. Cette croissance fait de la sécurité des API une préoccupation majeure.

Dans son rapport How to Build an Effective API Security Strategy, Gartner 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 ». Pour vous protéger contre les attaques d’API, Gartner recommande d’adopter « une approche continue de la sécurité des API tout au long du cycle de développement et de livraison des API, en concevant la sécurité [directement] dans les API ».

Compte tenu du rôle essentiel qu’elles jouent dans la transformation numérique et de l’accès aux données et systèmes sensibles qu’elles fournissent, les API justifient une approche dédiée à la sécurité et à la conformité.

Étant donné que vous ne contrôlez que vos propres API, la sécurité des API se concentre sur la sécurisation des API que vous exposez directement ou indirectement. La sécurité des API est moins axée sur les API que vous utilisez et qui sont fournies par d’autres parties, bien que l’analyse du trafic des API sortant puisse également révéler des informations précieuses et doit être appliquée chaque fois que possible.

Il est également important de noter que la sécurité des API en tant que pratique chevauche plusieurs équipes et systèmes. La sécurité des API englobe des concepts de sécurité réseau tels que la limitation et la limitation de débit, ainsi que des concepts de sécurité des données, de sécurité basée sur l’identité et de surveillance/analyse.

Les API prennent de nombreuses formes et existent dans de nombreux styles. Parfois, le style d’une API affecte la façon dont la sécurité lui est appliquée. Par exemple, avant les API Web, le style standard utilisé était les services Web SOAP (WS). Au cours de l’ère de l’architecture orientée services WS de 2000 à 2010, XML était omniprésent et un riche ensemble de spécifications de sécurité formelles était largement reconnu sous WS-Security/WS-*.

Le style de sécurité SOAP est appliqué au niveau du message à l’aide de signatures numériques et de parties chiffrées dans le message XML même. Découplé de la couche transport, il a l’avantage d’être portable entre les protocoles réseau (par exemple, passer de HTTP à JMS). Mais ce type de sécurité au niveau des messages est tombé en disgrâce et n’est généralement rencontré qu’avec les services Web hérités qui ont survécu sans évoluer.

Le transfert d’état représentatif (REST) est devenu le style de sécurité des API le plus courant au cours de la dernière décennie. REST est souvent supposé par défaut lorsque le terme « API Web » est utilisé. Une convention fondamentale du style REST des API est que les ressources sont identifiées de manière unique par les URI HTTP. Cet aspect prévisible des API REST a inspiré une génération de méthodologies de contrôle d’accès dans lesquelles les règles sont associées à l’URI (ressource) en cours d’accès ou au moins au modèle de l’URI en cours d’accès.

Les règles de contrôle d’accès sont souvent basées sur une combinaison des modèles de verbe HTTP (GET/PUT/POST/DELETE) et d’URI HTTP (l’identifiant de la ressource). L’identification des données accessibles via l’URI signifie que les règles peuvent être appliquées sans visibilité et, surtout, sans capacité à comprendre la charge utile dans ces transactions avec les API. Cela a été pratique, en particulier, pour les solutions de sécurité des interlogiciels qui appliquent des règles de contrôle d’accès découplées des implémentations d’API Web mêmes, en s’installant devant elles (par exemple, des passerelles) ou en agissant en tant qu’agents (par exemple, des filtres de service).

Un autre style d’API est GraphQL, un projet standard d’API open source émergent. GraphQL est populaire auprès des développeurs front-end car il leur donne le contrôle. Ils ne sont plus limités à un ensemble fixe de méthodes d’API et de modèles d’URI, mais peuvent, à la place, personnaliser leurs requêtes de la manière qui convient le mieux à leurs applications et à leur contexte. En raison de ce contrôle accru et d’avantages supplémentaires tels que des mises à niveau de version ininterrompues et des optimisations de performances, GraphQL est en passe de devenir omniprésent parmi les API Web.

Bien que GraphQL ne remplace pas REST et que les deux styles d’API continueront de coexister, il devient un choix de plus en plus courant. En effet, sa popularité menace de perturber une décennie d’infrastructure de contrôle d’accès aux API Web. Cette perturbation est centrée sur une divergence majeure par rapport au modèle REST populaire : Les requêtes GraphQL n’identifient pas les données accessibles via l’URI HTTP. Au lieu de cela, GraphQL identifie les données demandées à l’aide de son propre langage de requête, généralement intégré dans un corps HTTP POST.

Dans une API GraphQL, toutes les ressources sont accessibles via un seul URI (par exemple, /graphql). Les systèmes et l’infrastructure existants de contrôle d’accès aux API Web ne sont souvent pas conçus pour ce type de trafic d’API. Les règles de contrôle d’accès pour GraphQL vont probablement nécessiter l’accès aux données structurées dans les charges utiles des API et devront être capables d’interpréter ces données structurées à des fins de contrôle des accès. Il suffit de dire que les fournisseurs d’API doivent considérer ce qui sera le mieux adapté à chaque nouvel ensemble d’exigences lors du choix de leur approche.

Les avancées technologiques telles que les services cloud, les passerelles API et les plateformes d’intégration permettent aux fournisseurs d’API de sécuriser les API de manière unique. La pile technologique que vous choisissez pour créer vos API affecte la façon dont vous les sécurisez. Par exemple, dans les grandes entreprises, différents départements peuvent développer leurs propres applications avec leurs propres API. De plus, à travers les fusions et acquisitions, les grandes entreprises se retrouvent avec plusieurs piles d’API ou silos d’API.

Lorsque toutes vos API se trouvent dans un seul silo, les exigences de sécurité des API peuvent être mappées directement à la technologie de ce silo. À des fins de portabilité, ces configurations de sécurité doivent être suffisamment portables pour être extraites et mappées vers une autre technologie à l’avenir.

Pour les environnements hétérogènes, cependant, la définition des règles de sécurité des API bénéficie généralement d’une infrastructure spécifique à la sécurité des API qui fonctionne à travers ces silos d’API. Cette connectivité entre les silos d’API et l’infrastructure de sécurité des API peut prendre la forme de side-cars, d’agents à bande latérale et, bien sûr, d’API intégrées entre les déploiements cloud et sur site.

Comme indiqué ci-dessus, la portée de la sécurité des API est étendue. De nombreuses couches, chacune se concentrant sur son propre périmètre de sécurité API, sont nécessaires pour atteindre un niveau de protection élevé.

Découverte des API

Vous ne pouvez pas sécuriser ce dont vous n’êtes pas au courant. Les obstacles qui empêchent les agents de sécurité d’avoir une visibilité complète sur toutes les API exposées par leur entreprise sont nombreux. Tout d’abord, vous avez des silos d’API comme décrit dans la section précédente. Les silos d’API affectent la visibilité des API en ayant des listes partielles d’API, sous une gouvernance déconnectée.

Un autre obstacle à la visibilité de l’API est l’API escroc ou fantôme. Une API est dite fantôme lorsqu’elle est développée dans le cadre d’une application, mais que l’API même est considérée comme un détail d’implémentation de l’application et n’est connue que par un groupe de développeurs très soudé. Les API fantômes ne sont pas sur le radar des agents de sécurité, car elles n’ont pas de visibilité sur les détails du déploiement.

À la fin, les API suivent leur propre cycle de vie. Une API évolue au fil du temps, de nouvelles versions d’une API apparaissent ou une API peut même être obsolète mais continuer à fonctionner pendant une période temporaire pour une question de compatibilité descendante. Elle peut ensuite être oubliée ou disparaître progressivement du radar en raison du peu de trafic reçu.

La découverte des PI est une course entre les fournisseurs d’API et les pirates informatiques qui exploiteront facilement les API une fois trouvées. Pour découvrir vos API avant les pirates, vous pouvez extraire les métadonnées de votre trafic d’API. Ces données sont extraites des passerelles API, des équilibreurs de charge ou directement en ligne du trafic réseau, puis transmises à un moteur spécialisé qui fournit une liste efficace d’API pouvant ensuite être comparée à des catalogues d’API disponibles via une couche de gestion d’API.

Afin de restreindre les ressources de l’API aux seuls utilisateurs qui devraient être autorisés à y accéder, l’utilisateur – et potentiellement l’application qui agit au nom de l’utilisateur – doit être identifié. Ceci est généralement réalisé en exigeant des applications côté client qu’elles incluent un jeton dans les appels d’API qu’elles effectuent vers le service, qui peut ensuite valider ce jeton et en obtenir les informations utilisateur. OAuth est la norme qui décrit comment une application côté client obtient un jeton d’accès en premier lieu. OAuth définit de nombreux types d’octroi différents pour s’adapter à divers flux et expériences utilisateur. Pour plus d’informations sur OAuth 2, ce guide du développeur décrit en détail ces différents flux OAuth.

Sur la base d’un jeton entrant, des règles de contrôle d’accès peuvent être appliquées. Par exemple, une règle peut être utilisée pour déterminer si l’application ou l’utilisateur doit être autorisé à effectuer cet appel d’API particulier.

La définition et la gestion des règles se font via des outils de définition de politique, et une couche d’application de politique doit pouvoir appliquer ces règles au moment de l’exécution. Ces règles prennent en considération des caractéristiques telles que :

• L’identité de l’utilisateur et ses attributs ou revendications associés

• Les étendues d’application et OAuth associées au jeton

• Les ressources en cours d’accès ou la requête en cours

• Les préférences de confidentialité de l’utilisateur

Dans un environnement hétérogène, contrôler l’accès de manière cohérente à travers les silos d’API nécessite des processus et une intégration.

Gouvernance des données des API et application de la confidentialité

Les fuites se produisent via les API car les données transitent par les API. Pour cette raison, la sécurité des API doit également inclure l’examen des données structurées entrant et sortant via vos API et l’application des règles au niveau de la couche de données.

Étant donné que les données sont structurées de manière prévisible dans votre trafic API, l’application de la sécurité des données en inspectant le trafic API est très bien adaptée à cette tâche. En plus des règles de type [oui/non], la gouvernance des données API vous permet de transformer les données structurées dans votre trafic API en temps réel à des fins de rédaction. Un exemple typique de ce modèle consiste à masquer des champs spécifiques pouvant contenir des informations qui, selon les paramètres de confidentialité d’un utilisateur, doivent rester cachées à l’application demandeuse. Comme indiqué précédemment, l’application du contrôle d’accès au niveau des données vous aide à prendre en charge GraphQL qui n’identifie pas les identifiants de ressources via les URI.

Le découplage de la gestion et de l’application des préférences de confidentialité d’une implémentation de service GraphQL offre un certain nombre d’avantages. Les logiciels développés en interne ont un coût de possession élevé et peuvent être lents à s’adapter. Le développeur Node.js et la personne responsable de l’application des règles de confidentialité se croisent rarement. Mais donner aux architectes de sécurité et aux business analysts leur propre outil pour mettre en œuvre ce niveau de contrôle d’accès accélère la transformation numérique. De plus, ce découplage pérennise l’investissement dans les services GraphQL et les API REST, en les rendant plus résilients aux changements en ce qui concerne la gouvernance des données à granularité fine.

La détection des menaces contre les API

La détection des menaces contre les l’API hérite des mesures générales de protection contre les menaces. Par exemple, les API se trouvent souvent derrière un pare-feu qui offre une protection de base. Les API se trouvent également parfois derrière un pare-feu d’application Web (WAF). Un WAF peut analyser le trafic de l’API pour la détection des menaces basée sur les signatures, à la recherche d’éléments tels que les injections SQL et d’autres attaques par injection. Les passerelles API jouent également un rôle dans la détection des menaces sous un angle spécifique à l’API. Une passerelle peut imposer un schéma strict à l’entrée et un nettoyage général des entrées. Elle recherchera des modèles d’imbrication profonds, des bombes XML et appliquera des limites de débit en plus d’agir comme un point d’application des politiques.

Comportement et analyse des API

À l’aide des métadonnées du trafic des API, un moteur d’IA peut créer des modèles pour le trafic des API normal et tirer parti de ce modèle pour rechercher un comportement anormal. Ces anomalies peuvent aider à identifier les attaques en cours, mais peuvent également indiquer des mauvais comportements du système et d’autres formes d’interruption non malveillante de votre service, telles qu’un tir ami, des failles d’API ou un partenaire qui utilise mal ou abuse d’une API. En analysant les métadonnées du trafic de l’API, une telle couche peut identifier la source de cette attaque ou de ce comportement inapproprié et ces informations peuvent ensuite être exploitées pour arrêter l’incident en cours, réparer l’API ou résoudre le problème avec le partenaire.

La sécurité basée sur des règles est aussi bonne que les règles elles-mêmes et la sécurité obtenue grâce aux systèmes basés sur des règles est limitée par les opérateurs de cette technologie. La raison pour laquelle tant de violations de la sécurité des API persistent malgré la disponibilité d’une technologie de sécurité sophistiquée est qu’il n’y a pas suffisamment d’experts disponibles pour définir ces règles en premier lieu. Les humains font également des erreurs et peuvent manquer des règles importantes qui devraient être définies dans ces systèmes.

En revanche, un moteur d’IA qui découvre vos API en analysant votre trafic d’API ne nécessite aucune règle, il calcule simplement les chiffres. En conséquence, cette couche supplémentaire est une protection puissante contre les failles de sécurité dans d’autres couches et des moyens intelligents que les pirates utilisent pour contourner ces règles de contrôle d’accès et ces couches de protection contre les menaces.

En associant des informations d’identité aux métadonnées du trafic API analysées au fil du temps, elles révèlent des modèles de consommation et d’identité des API. Par exemple :

• Quels utilisateurs consomment quelles API

• Quelle séquence d’appels d’API est courante, rare ou jamais vue

• Quels taux d’erreur un client API génère-t-il

La sécurité basée sur l’identité pour les API va au-delà du contrôle d’accès. En analysant les métadonnées du trafic API augmentées des informations d’identité, la capacité à identifier la source d’une attaque est améliorée.

Une compréhension commune des menaces spécifiques contre lesquelles les entreprises doivent se défendre est essentielle. Connu depuis longtemps et utilisé pour son Top 10 des vulnérabilités de sécurité Web OWASP original, OWASP a récemment lancé une liste spécifique aux API : le Top 10 des vulnérabilités de sécurité des API OWASP.

Top 10 de la sécurité des API OWASP

Dans ce Top 10, vous verrez que quatre des éléments (y compris les deux premiers) sont directement liés à un manque de règles de contrôle des accès et à un manque d'authentification forte. Cela reflète la source d’erreur la plus courante dans les incidents de sécurité impliquant des API. Le numéro trois dans ce classement est causé par un manque de gouvernance des données. Au fur et à mesure que vous parcourez chaque élément du Top 10, vous découvrez rapidement l’étendue de la sécurité des API et le nombre de couches de sécurité nécessaires pour faire face aux menaces.

TABLE GOES HERE

Tout fournisseur d’API serait sage de ne pas tenir pour acquis sa couverture contre les 10 menaces identifiées dans le classement OWASP. Il fournit un excellent point de départ pour évaluer la sécurité actuelle de vos API. Un retour à ce classement devrait également être intégré aux tests de sécurité en cours.

Menaces supplémentaires pour la sécurité des API

Au-delà du Top 10 de la sécurité des API OWASP, il existe des risques supplémentaires de sécurité des API à prendre en compte, notamment :

• Les pirates sont aussi des utilisateurs
  L’application de règles de contrôle des accès sophistiquées peut vous donner l’illusion que le pirate est un utilisateur valide. Le pirate peut être un initié ou s’être inscrit à l’application en utilisant une fausse adresse e-mail ou un compte de réseau social.

   

• Compte valide, identifiants valides
  Les attaquants ont de nombreuses façons d’accéder à des informations d’identification valides, du bourrage d’informations d’identification à leur achat sur le dark web. Parce qu’ils savent que les utilisateurs réutilisent les mots de passe, les pirates peuvent s’emparer de comptes légitimes, contournant ainsi la première couche de règles de contrôle des accès.

   

• Jetons volés
  Le jeton OAuth peut être divulgué via le hameçonnage, les annuaires publics sur GitHub et d’autres moyens. Étant donné que la grande majorité des confirmations de jetons sont des jetons au porteur légers, ce type de jeton divulgué peut être utilisé de n’importe où et par n’importe qui jusqu’à son expiration.

   

• Scénarios en dehors de l’application
  En contournant l’application côté client, les pirates informatiques fouillent pour trouver des vulnérabilités cachées dans vos API. Ces vulnérabilités sont également cachées au fournisseur d’API.

Il s’agit de risques persistants pour la sécurité des API. Bien qu’ils puissent être réduits en renforçant les procédures de sécurité, le risque ne disparaît jamais vraiment. La clé pour atténuer ces risques est de tirer parti de l’IA pour détecter les anomalies, comme décrit précédemment.

À la fin, la sécurité est l’affaire de tous. Les API touchent les services backend, les bases de données, l’IAM, et toute cette infrastructure, doit être correctement sécurisée. Cela commence au niveau du transport avec l’utilisation de SSL (HTTPS) et l’application de TLS 1.2 (les anciennes versions de TLS doivent être dépréciées). Vous devez également vous débarrasser d’éléments tels que l’authentification de base HTTP.

En ce qui concerne la couche API, il existe plusieurs bonnes pratiques que vous pouvez appliquer pour créer une API sécurisée.

Inventaire des API

Les initiatives de transformation numérique accélèrent le développement de nouvelles API, vous devez donc examiner les nouvelles API pour les mesures de sécurité appropriées. Mais vous ne pouvez pas sécuriser ce que vous ne connaissez pas.

En analysant les métadonnées du trafic des API, un moteur d’IA découvrira des API qui n’étaient peut-être pas sur le radar des praticiens de la sécurité. Ce niveau de découverte des API garantit que vous réduisez les angles morts des API malveillantes. Lorsque de nouvelles API sont découvertes de cette manière, la même liste de contrôle de sécurité des API peut leur être appliquée. La même analyse des métadonnées du trafic d’API qui permet cette découverte d’API peut également être utilisée pour la détection des menaces, comme décrit ci-dessous.

Contrôle des accès aux API

En utilisant des normes telles que OAuth et JWT pour authentifier le trafic API, vous pouvez définir des règles de contrôle d’accès qui déterminent quelles identités, appartenances à des groupes, attributs d’identité et rôles sont requis pour accéder à des ressources API spécifiques.

Si vos transactions API traversent plusieurs limites de réseau, vous pouvez appliquer les principes de Sécurité Zero Trust et propager l’identité pour permettre à chaque couche de prendre ses propres décisions. La sécurité des applications peut également tirer parti de ces identités propagées.

Les bonnes pratiques supplémentaires de contrôle des accès incluent :

• Le mappage entre les formats de jeton, le cas échéant lors du franchissement de frontières, comme un jeton opaque du côté public et un jeton signé du côté privé

• L’application des règles d’autorisation à chaque silo d’API

• L’activation des règles de contrôle des accès pour les applications tierces agissant pour le compte des utilisateurs et contrôle de la portée accordée pour chaque application

• La capacité de définition et d’application des préférences de confidentialité des utilisateurs et la gouvernance générale des données

La détection des menaces contre les API

Combinez de la détection des menaces en temps réel et hors bande. La détection des menaces en temps réel implique une passerelle API, un WAF ou un agent appliquant un ensemble de règles de validation. Chaque requête et réponse des API est soumise à cet ensemble de règles et n’est autorisée que si les règles sont respectées :

• Recherchez la détection des menaces basée sur les signatures, telles que les injections SQL

• Validez les messages entrants par rapport au contrat de définition des API à l’aide des schémas JSON et des chemins JSON. Plus ces règles sont strictes, plus il devient difficile pour les attaquants d’abuser de vos API.

• Appliquez des limites de débit pour protéger vos back-ends d’API

Il y a une limite aux couches de sécurité en temps réel qui peuvent être appliquées en mode séquentiel avant que la latence ne soit affectée négativement. L’analyse hors bande du trafic API doit être déchargée vers un moteur d’IA dédié découplé du chemin de trafic d’API. À partir de ce moteur d’IA, capturez les métadonnées du trafic d’API pour créer des modèles de ML pour chaque API et suivez les taux d’erreur, les séquences d’API, le regroupement d’API à travers le jeton, la clé d’API, l’adresse IP, le cookie, etc... Lorsqu’un moteur d’IA détecte une anomalie, instruisez la passerelle de l’API ou un équilibreur de charge pour commencer à bloquer le client d’API.

Tests de sécurité des API

Testez en permanence la sécurité et examinez-la à travers une lentille d’API. Concevez des cas de test qui ignorent l’application côté client comme le ferait un pirate informatique s’il attaquait votre API. Vos testeurs de sécurité doivent utiliser des outils tels que Postman et JavaScript. Essayez d’appeler l’API d’une manière que l’application ne fait pas et essayez de tromper l’API en renvoyant des données auxquelles le demandeur ne devrait pas avoir accès.

Surveillance et analyse à travers les silos d’API

Surveillez votre trafic d’API de l’intérieur. Introduisez les métadonnées du trafic API dans un moteur d’IA centralisé et corrélez l’identité du trafic API. Vous devriez être en mesure de répartir le trafic par utilisateur, par IP, par jeton et par API dans vos silos d’API. Intégrez la surveillance de vos API et la détection des menaces à vos systèmes existants de gestion des informations et des événements de sécurité (SIEM). Examinez les anomalies détectées à intervalles réguliers et ajustez les modèles au besoin. En ayant une visibilité sur le trafic de vos API à tout moment et ventilé sur n’importe quel facteur, vous obtenez une meilleure compréhension de ce qui se passe avec vos API, y compris si vous subissez une attaque ou un dysfonctionnement.

Analyse du trafic API décomposée pour une identité d’utilisateur

Audit et réponse aux incidents

La détection et l’arrêt d’une violation ne sont qu’une partie de la réponse à un incident de sécurité. En enregistrant des informations détaillées sur le trafic historique des API, vous pouvez générer des rapports d’investigation pour un jeton, une clé API, une identité d’utilisateur ou une adresse IP donnés. Réalisez des rapports d’investigation pour obtenir une image complète de l’activité qui s’est produite lors d’un incident. Cela facilite la conformité et les enquêtes et peut vous aider à réparer les dommages qui se sont produits avant la détection et le blocage automatiques d’une violation.

Exemple de rapport d’investigation pour un jeton spécifique

Depuis les premiers jours des API Web, les développeurs d’API et les praticiens de la sécurité ont tiré parti du leadership éclairé et des outils de Ping Identity. Ping contribue à la norme OAuth depuis près d’une décennie et a été l’un des premiers à mettre en œuvre le serveur d’autorisation OAuth. À ce jour, les membres de l’équipe Ping aident à définir les principales normes de sécurité des API telles que JWT, la révocation des jetons, l’introspection des jetons, l’enregistrement dynamique des clients, les API de qualité financière et une myriade d’autres spécifications pertinentes.

Les solutions d’identité intelligentes de Ping Identity comprennent un serveur OAuth de pointe, une authentification forte, une MFA, un contrôle d’accès des API, un consentement basé sur des API et une application de la confidentialité ainsi qu’une cybersécurité API basée sur l’IA.

PingFederate

L’émission et la gestion des jetons OAuth sont au cœur des préoccupations de la sécurité des API. La meilleure technologie de serveur d’autorisation OAuth pour la prise en charge des protocoles et la présence sur le marché, PingFederate permet l’émission de jetons à vos consommateurs d’API. Tirant parti d’un riche ensemble de flux standard et personnalisés, PingFederate vous aide à offrir une expérience exceptionnelle à vos utilisateurs finaux. Il est également utilisé par le serveur API pour valider les jetons et récupérer les attributs qui sont utilisés dans les décisions de contrôle d’accès API. En savoir plus sur PingFederate

PingAccess

Avec ses politiques OAuth prêtes à l’emploi pour la validation des jetons/de l’étendue et la définition des règles de contrôle des accès basées sur les attributs, PingAccess vous permet de définir et d’appliquer des règles de contrôle d’accès aux API. Pour une définition de règle avancée, vous pouvez alimenter des scripts dans ce moteur de règles. Déployé en side-car ou en ligne, PingAccess fonctionne sur vos silos d’API. En savoir plus sur PingAccess

PingAuthorize

Attaché à vos API en ligne ou via une passerelle API, PingAuthorize fournit des contrôles des accès précis et basés sur des politiques pour la protection et le filtrage des données attribut par attribut, idéal pour la conformité réglementaire et la gestion du consentement. Il dispose d’une interface utilisateur graphique pour les utilisateurs commerciaux afin de concevoir, tester et mettre en place de manière collaborative des règles de contrôle des données dans les annuaires d’utilisateurs et les API. Il fournit également une solution centralisée pour autoriser et filtrer les requêtes aux API en temps réel, ce qui constitue un réel avantage pour gérer et veiller à la confidentialité des données des clients. En savoir plus PingAuthorize

PingIntelligence for APIs

PingIntelligence for APIs analyse vos métadonnées de trafic d’API pour découvrir et protéger vos API. Il vous donne également des informations détaillées sur votre trafic d’API en associant des métadonnées de trafic d’API à des informations d’identité pour fournir un panneau d’indication unique à partir duquel vous pouvez surveiller vos activités API sur toutes les passerelles, centres de données et clouds. Cela vous permet de générer des rapports sur le trafic API à travers les silos, répartis entre les utilisateurs, les jetons, les adresses IP, les cookies, etc... PingIntelligence for APIs utilise l’apprentissage automatique pour créer des modèles sur votre trafic d’API et repérer les écarts qui indiquent des anomalies et des attaques sans règles à écrire et à entretenir. Ces modèles suivent un riche ensemble de métadonnées de trafic d’API, notamment les taux de transaction, les taux d’erreur, les séquences, l’identité de l’utilisateur, les ressources en cours d’accès, les actions entreprises, les volumes, les latences, l’emplacement du réseau, etc... Grâce à ses intégrations prêtes à l’emploi avec toutes les passerelles API et équilibreurs de charge courants, PingIntelligence for APIs peut identifier les défauts de conception des API et les bogues en cours de production, signaler les partenaires qui utilisent mal ou abusent de vos API et détecter et bloquer les pirates informatiques travaillant sur vos API pour violer votre entreprise. En savoir plus sur PingIntelligence for APIs

Alors qu’elles constituent déjà une cible attrayante pour les acteurs malveillants, les API pourraient bientôt devenir le plus grand vecteur d’attaques. Compte tenu du rôle fondamental qu’elles jouent dans la transformation numérique, et de l’accès qu’elles fournissent aux données sensibles et aux systèmes internes, les API vous garantissent une approche dédiée à la sécurité et à la conformité.

Pour mieux comprendre les menaces visant la sécurité des API ainsi que leurs vulnérabilités et comment construire une défense solide contre celles-ci, lisez le livre blanc.