Les 10 principales menaces API de l'OWASP

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Ce document décrit diverses approches que vous pouvez utiliser dans Apigee pour corriger les failles de sécurité identifiées par l'OWASP. Pour connaître les approches supplémentaires documentées pour Apigee, consultez la page OWASP Top 10 2021 options on Google Cloud.

Introduction

OWASP est une communauté ouverte dont l'objectif est d'aider les entreprises à développer, acheter et gérer des applications et des API fiables. Dans le cadre de son projet de sécurité des API OWASP, l'OWASP publie les risques de sécurité les plus critiques sur les applications Web et les API REST, et fournit des recommandations pour faire face à ces risques.

Ce document présente les approches de protection contre les attaques courantes basées sur les API, identifiées par le top 10 des menaces de sécurité pour les API de l'OWASP en 2019. Un thème courant dans les principales menaces mises en avant dans la liste la plus récente est dû au mauvais positionnement des contrôles d'authentification et d'autorisation, tel que la dépendance au filtrage des données renvoyées par une requête API dans les applications clientes, par l'utilisation de l'anti-modèle consistant à dépendre de l'application cliente consommateur pour appliquer le contrôle des accès.

L'écosystème d'API se développe rapidement, et les utilisations abusives et utilisations abusives des API qui entraînent l'exfiltration de données par des pirates informatiques deviennent malheureusement l'un des vecteurs d'attaque les plus courants aujourd'hui. La sécurité reste une priorité clé pour Apigee, avec un certain nombre de nouvelles fonctionnalités telles que Advanced API Ops, qui inclut des fonctionnalités de création de rapports de sécurité et de détection d'anomalies. Toutefois, il est essentiel de concevoir et de mettre en œuvre correctement les fonctionnalités de sécurité d'Apigee pour réduire les risques d'attaques réussies contre vos API.

Les applications grand public doivent être considérées comme non approuvées ou "publiques", car vous ne contrôlez pas la plate-forme sur laquelle elles s'exécutent. Partez du principe qu'une application publique peut et sera compromise, et qu'elle ne peut donc pas être approuvée pour appliquer le contrôle des accès (API1, API5), filtrer les données de réponse (API6) ou stocker de manière sécurisée les codes secrets des clients (API2) tels que les clés API ou les jetons d'accès. Certaines recommandations sont basées sur l'examen du top 10 de l'OWASP de 2019:

  • Déterminez le type d'applications clientes qui consommeront vos API (SPA, mobile ou basée sur un navigateur), et concevez les modèles d'authentification, d'autorisation et de sécurité appropriés.
  • Utilisez toujours les flux OAuth ou OpenID Connect de type "client public" (l'utilisation de PKCE est vivement recommandée).
  • Pensez à la logique métier de votre application, définissez d'abord votre spécification OpenAPI, puis concevez vos proxys d'API pour filtrer toutes les données de réponse du backend dans Apigee. Ne comptez jamais sur la logique du code de l'application en aval pour effectuer cette opération.
  • Filtrez toutes les requêtes de données contenant des informations permettant d'identifier personnellement l'utilisateur pour n'autoriser que les données de votre backend qui appartiennent à l'utilisateur à l'origine de la demande.

API1:2019 Autorisation au niveau de l'objet défectueuse

Description de la menace

Une validation d'autorisation insuffisante d'une demande d'accès à un objet permet à un pirate informatique d'effectuer une action non autorisée en réutilisant un jeton d'accès. Cette menace est causée par une configuration incorrecte des validations d'autorisation. Apigee fournit des stratégies VerifyApiKey, OAuth et JSON Web Token (JWT), qui permettent de se protéger contre cette faille. Toutefois, il est essentiel que ces stratégies soient correctement configurées pour prévenir cette menace.

Pour prévenir cette menace, il est important que les équipes chargées du développement des applications et de la sécurité collaborent étroitement. L'autorisation est un sujet complexe par nature. Un contrôle précis et efficace de l'autorisation nécessite une compréhension approfondie de la logique métier de l'application.

Du point de vue de l'implémentation d'Apigee, deux aspects principaux sont à prendre en compte:

  • Intégrité du jeton d'accès
  • Application du contrôle des accès

Intégrité du jeton d'accès

Il est essentiel de vérifier que le jeton fourni par le client à l'origine de la demande n'a pas été falsifié, à l'aide du flux OAuth ou OpenID Connect approprié et du mécanisme de validation ou de signature des identifiants approprié. Apigee est compatible avec tous les flux OAuth couramment utilisés.

Les règles de validation des jetons d'accès Apigee incluent les éléments suivants:

Application du contrôle des accès

Une fois la validité du jeton d'accès vérifiée, il est essentiel de mettre en œuvre des règles d'application du contrôle des accès afin d'évaluer chaque requête API entrante par rapport aux droits d'accès du jeton d'autorisation.

Apigee fournit deux mécanismes principaux pour vérifier et appliquer les règles d'autorisation:

  • Interne: utilisation de flux conditionnels pour évaluer les requêtes d'accès basées sur les revendications extraites en tant que variables de flux d'un jeton d'autorisation
  • Délégué: utiliser un appel de service à une solution tierce de gestion des accès

L'approche interne (illustrée dans la figure ci-dessus) est recommandée lorsque le modèle de contrôle des accès est relativement simple. Par exemple, si les revendications extraites d'un jeton d'accès peuvent être utilisées pour évaluer et autoriser directement une requête d'objet API.

Utilisez les variables de flux disponibles pour les stratégies OAuth ou JWT pour évaluer les demandes d'accès à l'aide d'instructions de flux conditionnelles.

L'approche déléguée (illustrée dans la figure ci-dessus) est recommandée lorsque les revendications extraites d'un jeton d'accès ne peuvent pas être directement utilisées pour autoriser une requête API à destination d'un objet backend, ou pour les types de flux OAuth plus complexes qui nécessitent un appel distinct à un serveur d'autorisation pour obtenir un jeton d'accès.

La règle d'appel de service permet de demander une décision liée aux règles d'autorisation à un service tiers ou d'obtenir des informations de revendication supplémentaires sur l'agent à l'origine de la demande afin de prendre ensuite une décision de contrôle des accès à l'aide d'un flux conditionnel

API2:2019 Authentification de l'utilisateur non fonctionnelle

Description de la menace

Des règles d'authentification des utilisateurs mal implémentées permettent aux pirates informatiques d'usurper l'identité d'utilisateurs légitimes en tirant parti des failles d'implémentation dans les mises en œuvre de l'authentification. Voici quelques principes d'authentification à prendre en compte lors de la mise en œuvre des approches d'authentification:

  • Authentifiez toujours l'user-agent (l'application) et l'utilisateur à l'origine de la demande
  • Utilisez les modèles d'authentification et d'autorisation délégués, et évitez de transmettre des mots de passe directement dans une requête API.
  • Validez toujours la signature des identifiants d'accès et assurez-vous que tous les identifiants d'accès utilisés ont un délai d'expiration défini
  • Prévenez les attaques par force brute en définissant des quotas et en utilisant Apigee Sense pour détecter les attaques par force brute lancées par des bots et y répondre

Dans un paradigme de type outside-in, la conception des API repose sur les cas d'utilisation des données des consommateurs, et non sur la structure des données existantes dans vos systèmes backend. La sécurité est un élément essentiel lors de la conception d'API pour les consommateurs externes. Les systèmes backend ne sont généralement pas conçus avec des mises en œuvre d'authentification suffisamment robustes pour l'exposition aux réseaux publics. C'est là qu'Apigee, associé à une solution de gestion de l'authentification et des accès, peut offrir des solutions efficaces de protection contre cette menace.

Les principaux éléments à prendre en compte ici sont abordés dans les sections suivantes:

  • Conception de la sécurité: exploiter pleinement les fonctionnalités d'Apigee pour mettre en œuvre des modèles d'authentification
  • Gouvernance: s'assurer que l'utilisation correcte des modèles d'authentification conçus est utilisée de manière cohérente dans tous les produits d'API publiés
  • Sécurité opérationnelle: capacité à détecter les comportements suspects ou anormaux, et les tentatives de contournement ou les proxys d'API authentifiés par force brute

Conception de la sécurité

L'objectif de la conception de la sécurité est de mettre en œuvre correctement les flux d'authentification et l'intégration aux outils d'identité tiers. La conception de la sécurité est une phase essentielle. Elle commence par la compréhension du type de flux d'authentification déléguée à utiliser en fonction du type d'application qui consommera vos points de terminaison d'API. L'étape suivante consiste à définir, avec votre équipe chargée de l'identité, les modèles d'intégration à mettre en œuvre avec votre solution de gestion des identités.

Les RFC OpenID Connect et OAuth fournissent un grand nombre de flux d'authentification et d'autorisation délégués, ainsi que les acteurs impliqués dans ces flux. Il s'agit d'un sujet complexe, et il n'est pas surprenant que l'authentification défectueuse soit l'une des principales menaces pour les API OWASP. Ce document ne vise pas à fournir des informations complètes sur la mise en œuvre correcte des normes d'identité. Cependant, Apigee dispose de nombreuses ressources supplémentaires pour mieux comprendre les flux OAuth, telles que cet e-book, ce webcast et un exemple de mise en œuvre.

Règles d'authentification

Les règles Apigee qui permettent de résoudre les problèmes liés à l'identité et à l'authentification sont les suivantes:

  • Vérifier ou générer des jetons d'accès, des jetons d'actualisation ou des jetons de flux de réponse lors de l'utilisation du framework OAuth 2.0. Remarque: Techniquement, OAuth est un framework d'autorisation déléguée, mais il est largement utilisé dans les modèles d'authentification déléguée ou fédérée.
  • Vérifier, décoder et générer des jetons Web JSON et des signatures Web JSON OpenID Connect 1.0
  • Générer et valider des assertions SAML
  • Valider des clés API
  • Validation des codes d'authentification des messages hachés à clé (HMAC)

Gestion du trafic

Les fonctionnalités de gestion du trafic Apigee suivantes aident à se protéger contre les attaques par force brute:

  • La règle Spike Arrest (Arrêt des pics), permettant de définir une limite de taux de moyenne glissante globale sur un proxy d'API
  • Les règles de quotas, pour définir des limites de débit précises pour les proxys d'API en fonction de quotas définis par des clés d'application, des développeurs ou des quotas de produits d'API
  • Règles de mise en cache, pour la mise en cache des jetons d'accès stockés en fonction des délais d'expiration définis, et possibilité d'invalidate les identifiants mis en cache (par exemple, dans le cas où un jeton d'accès valide est compromis)

Gouvernance

La sécurité est un processus continu, et non un projet défini et négligé. L'une des principales causes de brèches de sécurité est une mauvaise configuration. Une fois les flux d'authentification, les modèles d'intégration des identités et les règles de gestion du trafic liés à l'authentification définis, il est absolument essentiel qu'ils soient mis en œuvre correctement et de manière cohérente.

Apigee fournit un certain nombre de fonctionnalités et d'outils permettant de garantir l'intégrité de la mise en œuvre et d'éviter les erreurs de configuration.

Contrôle des accès basé sur les rôles (RBAC)

Que vous gériez une grande entreprise ou une petite start-up, vous devez commencer par vous assurer que seules les personnes et les équipes appropriées peuvent accéder aux configurations de proxy d'API et les modifier. Les programmes d'API sont soutenus par les équipes pluridisciplinaires de votre organisation. Il est absolument essentiel que chaque équipe ne dispose que des autorisations nécessaires pour effectuer ses tâches dans le cadre de votre utilisation de l'API.

Apigee fournit des fonctionnalités pour gérer les accès basés sur les rôles en vous permettant d'attribuer des utilisateurs à des rôles prédéfinis ou de créer des rôles personnalisés adaptés à vos équipes API. Une définition et une gestion correctes de l'attribution des rôles sont essentielles pour vous permettre de faire évoluer votre programme d'API de manière sécurisée. Vous pouvez également utiliser la fédération pour intégrer votre annuaire d'entreprise existant et éviter de devoir gérer un deuxième ensemble d'identifiants d'administrateur dans Apigee.

Flux partagés

Les flux partagés vous permettent de définir des règles et des ressources dans un objet réutilisable pouvant être mis en œuvre sur des proxys d'API. Par exemple, vous avez peut-être conçu, en collaboration avec vos équipes de sécurité, plusieurs modèles de conception d'authentification en fonction du type d'application consommant une API. Un développeur d'API n'a pas besoin d'être un expert en identité pour réutiliser cette fonctionnalité. Il lui suffit de connaître le flux partagé approprié à ajouter à sa configuration de proxy d'API existante à l'aide de la règle Appel de flux.

Figure: Les flux partagés sont des groupes de règles et de logique conditionnelle réutilisables qui vous permettent de maintenir un modèle composite.

Rapports de sécurité

Une fois que vous vous êtes assuré que seules les personnes appropriées dans votre organisation peuvent modifier vos modèles d'authentification et que vous avez défini vos flux d'authentification partagés, vous devez vous assurer que les proxys d'API développés par vos équipes d'API utilisent ces modèles de manière cohérente.

La nouvelle fonctionnalité Advanced API Ops d'Apigee inclut des rapports de sécurité avancés, qui permettent aux équipes chargées des opérations et de la sécurité de consulter facilement des rapports sur tous les proxys d'API. Elle se concentre sur le respect des règles de sécurité telles que l'utilisation de flux partagés. La création de rapports, la journalisation et les alertes constituent un élément clé de la sécurité des API. Nous les examinerons plus en détail dans la section API10: journalisation insuffisante. Toutefois, du point de vue de la prévention des risques d'authentification, ils sont extrêmement utiles pour assurer le respect des normes d'authentification définies et mises en œuvre sous forme de flux partagés.

Sécurité opérationnelle

Une fois que vos API sont en production, en utilisant les bons modèles d'authentification avec une gestion de référence du trafic en place, votre équipe SecOps doit également être en mesure de surveiller et de réagir aux activités suspectes, qui commencent souvent par des tentatives de compromission des identifiants d'authentification.

Apigee Sense

Apigee Sense protège vos API du trafic de requêtes indésirables, y compris des attaques de clients malveillants. Apigee Sense analyse le trafic des requêtes d'API en identifiant les modèles susceptibles de représenter des requêtes indésirables. Cette analyse vous permet d'identifier les clients qui effectuent des requêtes indésirables, puis de prendre les mesures nécessaires pour autoriser, bloquer ou signaler ces requêtes. Les futures fonctionnalités de Sense comprendront la possibilité d'activer automatiquement la validation ReCAPTCHA sur le trafic suspect.

Avec Apigee Sense, vous pouvez protéger vos API des modèles de requêtes qui incluent les éléments suivants:

  • Comportement automatisé qui se marie avec le comportement humain
  • Tentatives persistantes depuis la même adresse IP
  • Taux d'erreur inhabituels
  • Requêtes client suspectes
  • Exploration des données
  • Collecte de clés et authentification par force brute
  • Utilisation intensive
  • Schémas géographiques

Advanced API Ops

Bien que Sense a été spécialement conçue pour détecter les menaces de type bot et y répondre, le service Advanced API Ops inclut à la fois la détection d'anomalies et la définition des alertes avancées.

La détection d'anomalies repose sur l'application de modèles d'intelligence artificielle (IA) et de machine learning (ML) à l'historique des données de vos API. La détection d'anomalies peut ensuite générer des alertes en temps réel pour des scénarios auxquels vous n'aviez même pas pensé, afin d'améliorer votre productivité et de réduire les délais moyens de résolution des problèmes liés à vos API.

Advanced API Ops s'appuie sur le mécanisme d'alerte de surveillance des API existant pour ajouter les types d'alertes avancés suivants:

  • Alertes sur le trafic total. Déclenche une alerte lorsque le trafic change d'un pourcentage spécifié sur une période donnée. Par exemple, vous pouvez déclencher une alerte lorsque le trafic augmente de 5 % ou plus pendant une heure, ou réduit de 10% ou plus pendant une semaine.
  • Alertes d'anomalie. Edge détecte les problèmes de trafic et de performances, ce qui vous évite de les prédéterminer vous-même. Vous pouvez alors envoyer une alerte pour ces anomalies.
  • Alertes d'expiration du protocole TLS Déclenche une notification lorsqu'un certificat TLS est sur le point d'expirer

API3:2019 Exposition excessive des données

Description de la menace

Une API publiée peut exposer plus de données que nécessaire, en fonction de l'application cliente pour effectuer le filtrage nécessaire. Si un pirate informatique interroge directement l'API sous-jacente, il peut accéder à des données sensibles.

L'un des principes de conception "outside-in" d'Apigee pour la conception d'API est la parcsimonie des données. Collaborez avec les concepteurs et les développeurs UX pour n'exposer les données que via les API nécessaires dans l'interface utilisateur de votre application. Les systèmes backend n'ont pas été conçus pour les modèles d'utilisation publique. L'une des premières tâches de la conception d'API avec Apigee consiste donc à réduire les données exposées au minimum nécessaire afin de fournir un excellent produit d'API à vos clients et développeurs.

La réutilisation est un autre des principes de conception d'Apigee. Mis à part les problèmes de sécurité, le fait de dépendre d'une application pour filtrer les données fournies par une API nécessite de transférer cette logique de filtrage sur chaque plate-forme pour laquelle vous développez une application.

Du point de vue de la sécurité, cette menace résulte de la délégation de l'application des autorisations à une application, mais souvent sur une plate-forme ou un système d'exploitation sur lesquels vous n'avez aucun contrôle. Nous avons déjà vu dans les API API1 et API2 l'importance d'implémenter correctement l'authentification et l'autorisation pour éviter tout accès non autorisé aux données.

Les sections suivantes expliquent comment:

  • Réécrire les requêtes et les réponses aux services de backend pour minimiser l'exposition des données
  • Mettez en œuvre la gestion des pannes pour empêcher les messages d'erreur détaillés d'exposer aux pirates informatiques des informations sensibles sur vos services de backend.

Réécrire les réponses et les requêtes

Les systèmes backend ne sont généralement pas conçus pour être utilisés dans des applications publiques ou sur des réseaux publics non approuvés. Apigee Edge a été conçu pour vous permettre de déployer des produits d'API publiques en protégeant vos backends d'une exposition excessive des données.

Pour ce faire, Apigee utilise trois règles clés:

  • Attribuer un message
  • Accroches de code
  • Gestion des pannes

Règle d'attribution des messages

La règle Assign Message (Attribuer un message) modifie ou crée des messages de requête et de réponse pendant le flux de proxy d'API. La règle vous permet d'effectuer les actions suivantes sur ces messages :

  • Ajouter des paramètres de formulaire, des en-têtes ou des paramètres de requête à un message
  • Copier les propriétés existantes d'un message à un autre
  • Supprimer des en-têtes, des paramètres de requête, des paramètres de formulaire et/ou des charges utiles de message
  • Définir la valeur des propriétés existantes dans un message

Avec l'option "Attribuer un message", vous pouvez généralement ajouter, modifier ou supprimer les propriétés de la requête ou de la réponse. Toutefois, vous pouvez également utiliser l'option "Attribuer un message" pour créer un message de requête ou de réponse personnalisé et le transmettre à une autre cible, comme décrit dans la section Créer des messages de requête personnalisés.

Réécriture complexe avec du code personnalisé

Pour les règles complexes de traitement et de réécriture de données dont la complexité dépasse les capacités de la stratégie d'attribution de messages, vous pouvez utiliser des langages procéduraux tels que JavaScript, Java ou Python. Vous pouvez ajouter du code personnalisé à un proxy d'API, puis l'appeler à partir de règles ajoutées au flux de proxy. La prise en charge du code procédural est conçue pour vous permettre de mettre en œuvre plus facilement une gestion complexe des variables de flux, des erreurs et des corps de requête et de réponse.

Avec le code procédural, vous pouvez effectuer les actions suivantes :

  • Créer ou manipuler des valeurs de corps complexes, telles que des valeurs de requête et de réponse
  • Réécrire les URL, par exemple pour masquer l'URL d'un point de terminaison cible

Apigee Edge inclut une règle distincte pour les langages compatibles: la règle JavaScript, la règle Java Callout et la règle de script Python.

Gestion des erreurs

Apigee vous permet d'effectuer un traitement personnalisé des exceptions à l'aide d'une stratégie de type Generate Fault. La stratégie Accéder à une erreur, qui est une variante de la stratégie Attribuer un message, vous permet de générer une réponse d'erreur personnalisée en réponse à une condition d'erreur.

Flux partagés

Les flux partagés peuvent être utilisés pour appliquer la normalisation des messages d'erreur. Par exemple, les mêmes règles configurées qui détectent un code d'erreur HTTP spécifique à partir du backend peuvent être utilisées pour réécrire la réponse d'erreur afin de renvoyer un message d'erreur générique.

API4:2019 Manque de ressources et limitation du débit

Description de la menace

En l'absence de règles de limitation du débit, les pirates informatiques peuvent submerger le backend d'attaques par déni de service.

Il est facile de s'attaquer à cette menace à l'aide des fonctionnalités Apigee suivantes:

  • Les règles d'arrêt des quotas et d'arrêt des pics sont des contrôles préventifs permettant de limiter le trafic sur les requêtes API entrantes
  • Apigee Sense pour détecter et contrer de manière dynamique les attaques basées sur des bots
  • Surveillance et alertes avancées des API en tant que contrôles de détection pour être alerté des attaques DDoS en cours

Limitation du débit avec les règles de quotas et d'arrêt des pics

Apigee propose deux règles pour la limitation du débit:

  • L'arrêt des pics fournit une règle générale, définie au niveau du proxy d'API, permettant de limiter le débit du nombre total de requêtes entrantes vers un backend.
  • Les quotas fournissent un outil de règle précis pour appliquer des règles de quotas, au niveau d'un proxy d'API ou au niveau d'un produit d'API.

Arrêt des pics

La règle Arrêt des pics protège contre les pics de trafic. Cette règle limite le nombre de requêtes traitées par un proxy d'API et envoyées à un backend, ce qui vous protège contre les délais de performance et les temps d'arrêt, à l'aide d'une valeur de moyenne glissante définie dans la règle.

Quotas

La règle Quota permet de configurer le nombre de messages de requête autorisés par un proxy d'API sur une période donnée, par exemple une minute, une heure, un jour, une semaine ou un mois. Vous pouvez définir le même quota pour toutes les applications accédant au proxy d'API ou en fonction des éléments suivants:

  • Produit contenant le proxy d'API
  • L'application qui demande l'API
  • Le développeur de l'application
  • De nombreux autres critères

Cette règle est plus précise que l'arrêt de Spike et doit généralement être utilisée en parallèle.

Détection des bots avec Apigee Sense

Avec Apigee Sense, vous pouvez prendre des mesures pour autoriser, bloquer ou signaler explicitement des requêtes provenant de clients, de plages d'adresses IP ou d'organisations de systèmes autonomes spécifiques, en fonction des clients ou des emplacements qui présentent un comportement malveillant ou suspect. Apigee Edge applique ces actions aux requêtes avant que vos proxys d'API ne les traitent. Par exemple, une plage d'adresses IP ou un client spécifique présentant un comportement de "prédiction brutal" peut être détecté, puis bloqué ou signalé.

Détection des menaces avec une surveillance avancée des opérations d'API

Utilisez une alerte de trafic pour générer une notification lorsque le trafic d'un environnement, d'un proxy ou d'une région change d'un pourcentage spécifié sur une période donnée. Cette fonctionnalité peut déclencher une alerte de manière dynamique lorsque le trafic s'écarte de manière significative de votre débit attendu, comme lors d'une attaque DDoS. Ces alertes peuvent facilement être envoyées à une solution de journalisation et de surveillance tierce.

API5:2019 Interruption de l'autorisation au niveau de la fonction

Description de la menace

Cette menace est une variante de l'API1 et une faille d'autorisation. Grâce à cette menace, un pirate informatique peut effectuer des actions en envoyant des requêtes à des fonctions auxquelles il n'a pas accès. Par exemple, un pirate informatique peut être en mesure de modifier ou de supprimer des données qu'il n'est autorisé à lire que si un point de terminaison de l'API ne valide pas le verbe de requête HTTP, en remplaçant un élément GET par PUT ou DELETE. Ou bien, en ne mettant pas en œuvre un contrôle des accès suffisamment restrictif sur le chemin d'URI d'une ressource d'API, un point de terminaison de l'API peut permettre à un pirate informatique de visualiser les données d'un autre utilisateur simplement en modifiant le chemin dans une requête.

Ce type de menace souligne l'intérêt d'utiliser Apigee en tant que couche de médiation et d'abstraction, car de nombreux systèmes backend, qui ne sont pas conçus pour un accès public, peuvent fournir par défaut un point de terminaison unique pour l'exécution de plusieurs fonctions de logique métier, y compris des fonctionnalités administratives à haut risque.

Les éléments conceptuels permettant de réduire la probabilité de cette menace sont généralement répartis comme suit:

  • Qu'est-ce qui est protégé ? Réfléchissez à votre stratégie de produits d'API, et mettez en œuvre une segmentation logique des fonctionnalités lorsque vous utilisez les bonnes pratiques RESTful pour concevoir les chemins et les ressources exposés par les proxys d'API, les produits et les fonctionnalités des applications Apigee.
  • Qui accède aux ressources de vos API ? Définissez les personas de haut niveau et mettez en œuvre les droits d'accès par défaut du "moindre privilège" à l'aide de certaines des fonctionnalités d'authentification et d'autorisation d'Apigee, décrites dans les API1 et API2.
  • Comment vos règles d'accès sont-elles appliquées ? Utilisez des flux et des erreurs conditionnels pour valider le chemin d'URL et le verbe de toutes les requêtes API.

Figure: Ce schéma montre comment l'autorisation au niveau de la fonction serait appliquée dans Apigee en utilisant les niveaux d'accès fournis dans un jeton d'accès en tant que droits d'accès.

Segmentation logique avec des proxys d'API, des produits et des applications

Apigee fournit un kit d'outils hautement flexible pour permettre la segmentation logique des ressources d'API. Vous pouvez ainsi regrouper des proxys d'API dans un nombre illimité de produits d'API, lesquels sont eux-mêmes utilisés par vos développeurs d'applications, qui peuvent enregistrer des applications qui utilisent vos produits d'API. Des stratégies d'accès peuvent être définies à n'importe lequel de ces niveaux.

Pourtant, pour mettre en œuvre l'autorisation et la segmentation fonctionnelles efficaces, il est essentiel de définir une stratégie de produit d'API. Une partie de ce processus essentiel et continu consiste à définir le "qui" et le "quoi" de vos produits d'API. Pour ce faire, examinez les ressources d'API du point de vue du client et du développeur, puis définissez précisément les types de requêtes autorisés (avec une ressource de chemin d'accès et un niveau de verbe HTTP).

Figure: Les ressources d'API regroupées dans un produit d'API peuvent provenir d'une ou de plusieurs API. Vous pouvez donc les combiner pour créer des niveaux de consommation et des limites d'autorisation.

Contrôle des accès au niveau de la fonction avec des champs d'application OAuth et des revendications JWT

Bien que les approches d'autorisation envisagées ci-dessus pour l'API 1:2019 Autorisation d'objets non fonctionnels couvrent le contrôle des accès précis au niveau des objets, il est tout aussi important d'effectuer le contrôle des accès sommaire au niveau d'une fonction. L'utilisateur à l'origine de la demande est-il même autorisé à demander ce chemin d'URL ? Ce type de règle est souvent défini par persona utilisateur (client, employé, administrateur, développeur interne ou tiers).

Pour réduire le risque d'erreur de configuration, nous vous recommandons de collaborer avec votre équipe de sécurité afin de vous assurer que les assertions concernant le demandeur sont contenues dans le jeton d'accès, soit à l'aide de champs d'application OAuth, soit de revendications JWT.

Validation des requêtes avec des flux conditionnels

À un niveau de base, un appel d'API REST comprend les éléments suivants:

  • Un point de terminaison
  • Une ressource
  • Verbe d'action
  • N'importe quel nombre d'attributs de requête supplémentaires, tels que des paramètres de requête

Le type d'attaque décrit dans cette menace est généralement causé par le filtrage insuffisant d'une requête API, ce qui permet à un pirate informatique d'effectuer des actions non autorisées ou d'accéder à une ressource protégée. En plus de la logique conditionnelle vous permettant de filtrer les requêtes en fonction de jetons d'accès ou de revendications, Apigee permet d'implémenter une logique de filtrage en fonction de la requête elle-même.

Une fois que vous avez clairement compris et défini la logique métier d'un produit d'API, ainsi que les fonctions autorisées par vos API, l'étape suivante consiste à restreindre les requêtes qui en découlent grâce aux fonctionnalités suivantes du produit Apigee:

  • Logique conditionnelle et stratégies de génération de pannes pour restreindre les chemins d'accès ou les verbes de ressources à n'importe quelle étape de la configuration d'un flux proxy
  • Règles de protection contre les menaces JSON et XML permettant de se protéger contre les attaques basées sur le contenu à l'aide de charges utiles de requête JSON ou XML non valides

API6:2019 Attribution de masse

Description de la menace

Les données non filtrées fournies aux applications clientes via des API permettent aux pirates informatiques de deviner les propriétés d'objets via des requêtes, ou d'utiliser des conventions de dénomination des points de terminaison pour savoir où effectuer des modifications non autorisées ou accéder aux propriétés d'objets de données stockés dans le backend.

Cette menace survient lorsque des données non filtrées (généralement au format JSON ou XML) sont envoyées à un client, ce qui permet à un pirate informatique de deviner les détails de la mise en œuvre sous-jacente de vos systèmes backend, ainsi que les noms de propriété des éléments de données confidentiels. Le résultat de ce type d'attaque peut permettre à un pirate informatique de lire ou de manipuler des données inappropriées. Dans les pires scénarios, il peut également entraîner des failles d'exécution de code à distance.

Ce type de menace implique généralement deux aspects:

  • Le point de vue de la conception de l'API. Ne comptez jamais sur la logique d'application pour filtrer les données côté client, car les applications peuvent être exploitées par des pirates informatiques et considérées comme fiables. Concevez toujours votre schéma de données d'API de façon à n'exposer que les données minimales nécessaires pour activer un service d'API.
  • Le point de vue de l'implémentation de l'API. Mettez en œuvre le filtrage des données et la validation du schéma pour éviter l'exposition par inadvertance de données confidentielles à une application cliente.

Du point de vue du produit Apigee, nous fournissons plusieurs fonctionnalités utiles pour garantir une mise en œuvre robuste du filtrage des données de vos API.

Règle de filtrage de la spécification OpenAPI

La stratégie OASValidation (OpenAPI Specification Validation) vous permet de valider un message de requête ou de réponse entrant par rapport à une spécification OpenAPI 3.0 (JSON ou YAML). Cette règle vous permet:

  1. Concevoir votre API en créant une spécification OpenAPI (OAS)
  2. Mettez en œuvre la logique de médiation, de sécurité et de mise en cache nécessaire pour exposer de manière sécurisée un produit d'API depuis votre backend avec Apigee.
  3. Validez les requêtes entrantes par rapport au schéma de données défini dans la spécification OAS, y compris le chemin de base, le verbe, la stratégie de message de requête et les paramètres.

Stratégie de validation de message SOAP

La stratégie de validation des messagesSOAP vous permet de valider les requêtes XML en validant un message XML par rapport à un schéma XSD ou en validant un message via une définition WSDL. De plus, vous pouvez utiliser la stratégie de validation de message pour confirmer qu'une charge utile de message JSON ou XML est bien formatée, ce qui inclut la vérification des éléments suivants dans un message XML ou JSON:

  • Il existe un seul élément racine.
  • Il n'y a pas de caractères non autorisés dans le contenu.
  • Les objets et les tags sont correctement imbriqués.
  • Les tags de début et de fin correspondent.

API7:2019 Mauvaise configuration de la sécurité

Description de la menace

Les erreurs de configuration liées à la sécurité sont souvent le résultat de configurations par défaut non sécurisées, incomplètes ou ad hoc, d'un stockage cloud ouvert, d'en-têtes HTTP mal configurés, de méthodes HTTP inutiles, de partages de ressources inter-origines (CORS, Cross-Origin Resource Sharing) permissifs, et de messages d'erreur détaillés contenant des informations sensibles. Les pirates informatiques tentent souvent de trouver des failles non corrigées, des points de terminaison courants ou des fichiers et répertoires non protégés pour obtenir un accès non autorisé ou une connaissance du système qu'ils souhaitent attaquer. Les erreurs de configuration liées à la sécurité peuvent non seulement exposer des données utilisateur sensibles, mais également des détails du système, ce qui peut compromettre la sécurité du serveur. Voici d'autres cas d'utilisation des failles liées à des erreurs de configuration de sécurité:

  • Protocole TLS mal configuré
  • Messages d'erreur avec les traces de la pile
  • Systèmes non corrigés
  • Panneaux de stockage ou de gestion de serveur exposés

Les organisations peuvent prendre différentes mesures pour résoudre et atténuer les problèmes liés aux erreurs de configuration de sécurité. Par exemple:

  1. Établir et standardiser les processus de renforcement et de correctifs
  2. Développer une gouvernance autour de l'écosystème des API
  3. Restreindre l'accès administrateur, et activer l'audit et les alertes

Flux partagés et hooks de flux

Apigee prend en charge le concept de flux partagé qui permet aux développeurs d'API de combiner des règles et des ressources au sein d'un groupe réutilisable. En capturant les fonctionnalités réutilisables en un seul endroit, un flux partagé vous aide à garantir la cohérence, à raccourcir le temps de développement et à gérer plus facilement le code. Vous pouvez inclure un flux partagé dans des proxys d'API individuels ou aller plus loin et placer des flux partagés dans des hooks de flux pour exécuter automatiquement la logique de flux partagé pour chaque proxy d'API déployé dans le même environnement qu'un flux partagé.

Rapports de sécurité des API

Alors que les entreprises s'efforcent de développer un framework de gouvernance, Apigee offre des fonctionnalités de reporting sur la sécurité des API qui aident les équipes opérationnelles à obtenir la visibilité dont elles ont besoin pour les attributs de sécurité des API:

  • Garantir le respect des règles de sécurité et des exigences de configuration
  • Protéger les données sensibles contre les utilisations abusives internes et externes
  • Identifiez, diagnostiquez et résolvez les incidents de sécurité de manière proactive.

Les rapports de sécurité Apigee fournissent des informations détaillées aux équipes chargées des opérations, afin de garantir le respect des règles et des exigences de configuration, de protéger les API contre les utilisations abusives internes et externes, ainsi que d'identifier et de résoudre rapidement les incidents de sécurité.

Grâce aux rapports de sécurité, les administrateurs de sécurité peuvent rapidement comprendre comment vos proxys d'API sont configurés pour la sécurité, ainsi que les conditions d'exécution qui peuvent avoir une incidence sur la sécurité des proxys. Ces informations vous permettent d'ajuster la configuration afin de garantir le niveau de sécurité approprié pour chaque proxy.

Surveillance des API

Apigee fournit une plate-forme complète de surveillance des API qui complète les fonctionnalités de création de rapports de sécurité. La surveillance des API permet aux entreprises de détecter de manière proactive les problèmes de trafic et de performances des API. Apigee API Monitoring fonctionne avec Apigee Edge pour le cloud public afin de fournir des informations contextuelles en temps réel sur les performances des API, de diagnostiquer rapidement les problèmes et de faciliter les actions correctives pour assurer la continuité des activités.

Figure: La surveillance de l'API Apigee offre un large éventail d'outils permettant de surveiller, d'analyser et de résoudre les problèmes. Elle s'appuie sur les fonctionnalités d'intelligence de Google Cloud Platform les plus performantes.

Apigee Sense

Apigee Sense permet de protéger les API du trafic de requêtes indésirables, y compris des attaques de clients malveillants. Apigee Sense analyse le trafic des requêtes d'API en identifiant les modèles susceptibles de représenter des requêtes indésirables.

Cette analyse permet aux entreprises d'identifier les clients qui effectuent des requêtes indésirables, puis de prendre des mesures pour autoriser, bloquer ou signaler ces requêtes. Avec Apigee Sense, il est possible de protéger les API contre les modèles de requête tels que les suivants:

  • Comportement automatisé qui se marie avec le comportement humain
  • Tentatives persistantes depuis la même adresse IP
  • Taux d'erreur inhabituels
  • Requêtes client suspectes
  • Exploration des données
  • Collecte de clés
  • Utilisation intensive
  • Schémas géographiques

API8:2019 Injection

Description de la menace

L'injection non approuvée de données dans des requêtes API (SQL, NoSQL, XML Parsers, ORM, LDAP, commandes OS et JavaScript, par exemple) peut entraîner l'exécution de commandes non souhaitées ou un accès non autorisé aux données. Les pirates informatiques alimentent l'API avec des données malveillantes via tous les vecteurs d'injection disponibles (entrée directe, paramètres, services intégrés, etc.), en s'attendant à ce qu'elles soient envoyées à un interpréteur. Les pirates informatiques peuvent facilement détecter ces failles lorsqu'ils examinent le code source à l'aide d'analyseurs de failles et de fuzzers. Une injection réussie peut entraîner la divulgation d'informations, ce qui peut avoir une incidence sur la confidentialité et la perte de données. Dans certains cas, elle peut également entraîner des attaques DoS.

Pour limiter les erreurs/attaques d'injection, les bonnes pratiques incluent la définition stricte des données d'entrée telles que les schémas, les types et les modèles de chaîne, la validation des entrées, les vérifications des limites et leur application au moment de l'exécution. La plate-forme Apigee permet de valider les données entrantes à l'aide de filtres pour n'autoriser que les valeurs valides pour chaque paramètre d'entrée.

Apigee Edge, qui agit en tant que serveur pour les requêtes API entrantes, vérifie que la structure de la charge utile se situe dans une plage acceptable, également appelée vérification des limites. Vous pouvez configurer un proxy d'API afin que la routine de validation des entrées transforme l'entrée afin de supprimer les séquences de caractères à risque et de les remplacer par des valeurs sûres.

Règlement sur la protection des expressions régulières

La règle RegularExpressionProtection extrait des informations d'un message (par exemple, chemin d'URI, paramètre de requête, en-tête, paramètre de formulaire, variable, charge utile XML ou charge utile JSON) et évalue ce contenu par rapport à des expressions régulières prédéfinies. Si des expressions régulières spécifiées renvoient la valeur "true", le message est considéré comme une menace et est rejeté. Une expression régulière est un ensemble de chaînes qui spécifient un modèle dans une chaîne. Les expressions régulières permettent d'évaluer le contenu de manière automatisée pour identifier des schémas. Les expressions régulières peuvent être utilisées, par exemple, pour évaluer une adresse e-mail afin de vous assurer qu'elle est correctement structurée.

L'utilisation la plus courante de RegularExpressionProtection consiste à évaluer les charges utiles JSON et XML pour détecter le contenu malveillant.

Aucune expression régulière ne peut éliminer toutes les attaques basées sur le contenu, et plusieurs mécanismes doivent être combinés pour permettre une défense en profondeur. Cette section décrit certains modèles recommandés pour empêcher l'accès au contenu.

Il existe plusieurs autres approches pour valider les entrées disponibles avec la plate-forme Apigee:

Valider les types de contenu

Le type de contenu fait référence au contenu d'un fichier transféré via HTTP et classé selon une structure en deux parties. Apigee recommande de valider les types de contenu pour la requête et la réponse à l'aide de la logique conditionnelle, comme expliqué ci-dessous.

Rapports de sécurité des API

Alors que les entreprises s'efforcent de développer un framework de gouvernance, Apigee offre des fonctionnalités liées aux rapports de sécurité des API. Ces fonctionnalités aident les équipes opérationnelles et leur offrent la visibilité dont elles ont besoin pour sécuriser les API en leur fournissant la visibilité dont elles ont besoin pour:

  • Assurez-vous du respect des règles de sécurité et des exigences de configuration.
  • Protéger les données sensibles contre les utilisations abusives internes et externes
  • Identifier, diagnostiquer et résoudre les incidents de sécurité de manière proactive.

API9:2019 Gestion inappropriée des éléments

Description de la menace

Une gestion de l'environnement insuffisante et une séparation entre environnement permettent aux pirates informatiques d'accéder à des points de terminaison d'API non sécurisés. L'absence de protections de gouvernance entraîne également une exposition inutile des ressources obsolètes.

Cette menace peut être traitée en exploitant les fonctionnalités avancées d'Apigee pour gérer le cycle de vie complet des API, ce qui vous permet de créer un modèle de gouvernance complet qui permet la collaboration entre les équipes, tout en séparant les responsabilités entre les acteurs de la sécurité et les développeurs d'API. Les limites et les contrôles peuvent être configurés et maintenus à l'aide des éléments suivants:

Organisations, environnements et révisions: garde-fous virtuels et physiques qui garantissent l'isolation et un processus de promotion sécurisé via des contextes d'exécution.

Contrôle des accès basé sur le rôle: seules les personnes nécessaires dans vos équipes API seront autorisées à gérer les modifications de configuration et le processus de promotion.

Gestion des audiences pour la documentation des API: une fois qu'une API a été publiée dans le portail des développeurs, vous pouvez limiter la visibilité de la documentation en gérant les audiences cibles.

Hooks de flux: vous pouvez appliquer des règles et des modèles globaux qui peuvent être gérés comme des garde-fous privilégiés qui ne peuvent pas être modifiés par les développeurs d'API.

Rapports de sécurité: les personnes concernées par la sécurité bénéficient d'une visibilité de bout en bout sur les API publiées et leur configuration associée. Le respect des règles de sécurité globales peut être audité et évalué en fonction du profil de risque pour chaque point de terminaison de l'API publié.

Organisations et environnements

Les artefacts de configuration, les utilisateurs et les fonctionnalités d'Apigee peuvent s'appliquer à des organisations et/ou des environnements spécifiques. Cela signifie que la plate-forme dispose de garde-fous prédéfinis qui peuvent être placés autour des API et de leur configuration compatible.

Organisations : une organisation est le locataire de premier niveau dans Apigee. Cela vous permet de séparer complètement le trafic, la configuration et les utilisateurs. Selon les bonnes pratiques de gouvernance, il est recommandé de disposer d'organisations de production et de hors production distinctes. Cette pratique évite efficacement de mélanger les données de production, les utilisateurs et le trafic avec des environnements inférieurs.

Environnements : les API dans Apigee peuvent être promues via plusieurs états de déploiement, chaque état étant lié à un contexte d'exécution. Le contexte de l'environnement n'est pas conservé pendant le processus de promotion, ce qui évite d'exposer une configuration sensible aux utilisateurs non privilégiés.

Révisions : les révisions permettent une promotion fluide des API et des fonctionnalités individuelles dans les environnements.

Contrôle des accès basé sur les rôles

Afin d'atténuer les effets d'API9, il est impératif de définir clairement les tâches des personnes concernées par la sécurité et des développeurs d'API, et de les séparer clairement. Comme indiqué précédemment dans ce document, Apigee offre des fonctionnalités flexibles de contrôle des accès basé sur les rôles, qui vous permettent d'attribuer des autorisations aux rôles personnalisés. Concernant cette menace spécifique, les rôles peuvent être limités pour disposer de droits limités par organisation et par environnement, ou d'autorisations de configuration plus précises. Il est recommandé de limiter les droits permettant de modifier l'état de déploiement des API via des environnements, et de vous assurer que les développeurs ne peuvent pas accéder aux bibliothèques de sécurité globales (Hooks de flux) ni les modifier. Ces rôles limités empêchent les modifications non sollicitées des règles de sécurité globales qui couvrent une large couverture des points de terminaison publiés (anciens et actuels).

Documentation sur la gestion des audiences pour l'API

Le portail des développeurs est un composant essentiel à la réussite de votre stratégie d'API. Il vous permet de conserver un inventaire complet de toute la documentation liée à vos API, y compris les hôtes/points de terminaison, les ressources, les opérations, les schémas de charge utile, etc. Dans Apigee, vous pouvez regrouper vos API à l'aide de constructions de produit d'API. Les produits d'API sont définis par des ensembles de ressources et d'opérations qui appartiennent au même contexte commercial et de sécurité (par exemple, forfait, domaine d'activité, catégorie, hiérarchie d'entreprise, etc.).

Avec le portail intégré des développeurs d'Apigee, vous pouvez publier des produits d'API et restreindre la visibilité du contenu publié en gérant les audiences cibles. Cette fonctionnalité est conforme à une stratégie de segmentation de contenu conforme aux exigences commerciales et de sécurité.

Crochets de flux

Les processus de promotion et de publication des API doivent toujours inclure des processus de conformité et de certification en termes de sécurité. Pour être efficaces, les équipes API qui utilisent les outils appropriés doivent être en mesure de créer des garde-fous qui garantissent la séparation des responsabilités et tout en maintenant des cycles de publication agiles.

Apigee vous permet de renforcer vos tâches de gouvernance de la sécurité en appliquant des règles globales via des hooks de flux. Ces règles globales peuvent être gérées comme des garde-fous privilégiés qui ne peuvent pas être modifiés par les développeurs d'API. Elles assurent ainsi la séparation des responsabilités et favorisent l'agilité en appliquant la sécurité par défaut et, par extension, en assurant la conformité de toutes les API déployées dans un environnement d'exécution donné.

Figure: Des garde-fous privilégiés peuvent être configurés dans Apigee via des hooks de flux et des flux partagés. Les personnes concernées par la sécurité sont chargées de maintenir les règles globales liées à la sécurité. Ces fonctionnalités garantissent la séparation des responsabilités et favorisent les cycles de vie de développement agiles.

Rapports de sécurité

Les audits de sécurité servent à évaluer et à tester les règles de sécurité visant à protéger les données et les objectifs commerciaux de votre organisation. Les API sont des interfaces publiques ou privées standardisées qui doivent être protégées par un modèle de gouvernance de la sécurité complet et vérifiable.

Dans Apigee, vous avez accès à des rapports de sécurité spécialisés qui vous aident à respecter les règles définies et permettent à vos équipes de sécurité d'agir en s'appuyant sur des insights complets sur les éléments suivants:

Trafic d'exécution: une vue centralisée pour obtenir des insights sur le trafic des API: serveurs cibles, hôtes virtuels, configuration TLS, modifications du trafic par environnement, etc.

Configuration : fonctionnalité d'audit pour la configuration des proxys d'API qui offre une visibilité de bout en bout sur toutes les règles appliquées au niveau du proxy d'API, ainsi que sur le spectre d'application des flux partagés associés au niveau de l'organisation ou du proxy.

Activité des utilisateurs: suivez les opérations sensibles effectuées par les utilisateurs de la plate-forme. Analysez les activités suspectes en affichant le détail des activités suspectes.

API10:2019 Journalisation et surveillance insuffisantes

Description de la menace

Une journalisation, une surveillance et des alertes insuffisantes permettent de ne pas détecter les attaques en cours. Vous devez donc mettre en place une stratégie pour obtenir des insights sur les événements critiques qui ont un impact sur votre activité.

Les stratégies de gestion des événements et de la journalisation pour les API doivent tenir compte des bonnes pratiques suivantes:

  • Règle de gestion des journaux: documentez et appliquez des règles pour standardiser et contrôler la verbosité des journaux, leurs niveaux, leur intégrité, leur dépôt centralisé, etc.
  • Règle de gestion des événements: garantissez que chaque événement doit être traçable jusqu'à sa source. En outre, les événements doivent pouvoir être classés par niveau de gravité et impact commercial.
  • Rapports et audits: les acteurs de la sécurité et des opérations doivent pouvoir accéder aux journaux et aux événements, et y réagir en temps réel. De plus, les partenaires peuvent appliquer des cycles de renforcement pour ajuster les modèles de détection en fonction des données historiques

Apigee fournit les outils nécessaires pour créer une stratégie complète de gestion des événements et des journaux. Ces outils sont les suivants :

Règle de journalisation des messages: créez des flux de journaux basés sur les données ou les métadonnées du trafic de votre API. Le niveau de verbosité du flux vous permet de contrôler le niveau de verbosité du flux à l'aide d'une logique conditionnelle et de modèles de message.

La suite Google Cloud Operations: exploitez l'intégration clé en main des outils Google hautement évolutifs de surveillance et de journalisation.

Règle d'appel de service: permet d'ajouter la compatibilité avec les flux de journaux qui nécessitent des points de terminaison HTTP pour envoyer des événements.

Analytics : consultez et analysez l'historique des métadonnées du trafic via des rapports prêts à l'emploi et/ou personnalisés. Créez et gérez des alertes en fonction des tendances, et analysez les anomalies liées au trafic.

Surveillance des API: comme décrit précédemment, cet outil fournit des fonctionnalités d'alerte pouvant être déclenchées en fonction d'événements critiques. Les journaux de trafic peuvent faire l'objet d'analyses et d'actions plus poussées.