Les 10 principales menaces API de l'OWASP

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Ce document décrit différentes approches que vous pouvez utiliser dans Apigee pour corriger les failles de sécurité identifiées par l'OWASP. Pour découvrir d'autres approches documentées pour Apigee, consultez la section Top 10 des options d'atténuation de l'OWASP de 2021 sur Google Cloud.

Introduction

OWASP est une communauté ouverte qui aide les organisations à développer, acheter et gérer des applications et des API fiables. Via le projet OWASP sur la sécurité des API, l'OWASP publie les risques de sécurité les plus critiques pour les applications Web et les API REST, et fournit des recommandations pour y remédier.

Ce document présente des approches permettant de se protéger contre les attaques courantes basées sur les API, telles qu'elles sont identifiées dans le top 10 des menaces de sécurité des API de 2019 de l'OWASP. Un thème commun aux principales menaces mises en évidence par la dernière liste est causé par le placement incorrect des contrôles d'authentification et d'autorisation, comme le recours au filtrage des données renvoyées par une requête d'API dans les applications clientes, en utilisant l'anti-modèle consistant à s'appuyer sur l'application cliente consommatrice pour appliquer le contrôle des accès.

La croissance de l'écosystème d'API se poursuit à un rythme rapide. Malheureusement, les utilisations abusives et les utilisations abusives des API qui entraînent l'exfiltration de données par des pirates informatiques deviennent 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 d'implémenter correctement les fonctionnalités de sécurité d'Apigee pour réduire la probabilité de réussite des attaques sur vos API.

Les applications grand public doivent être considérées comme non fiables ou "publiques", car vous ne contrôlez pas la plate-forme sur laquelle elles s'exécutent. Supposons qu'une application publique puisse être compromise et qu'elle le sera. Par conséquent, vous ne pouvez pas lui faire confiance pour appliquer le contrôle des accès (API1, API5), filtrer les données de réponse (API6) ni stocker de manière sécurisée des secrets client (API2), tels que des clés API ou des jetons d'accès. Voici quelques recommandations qui ressortent de l'examen du top 10 de l'OWASP 2019:

  • Déterminez le type d'applications clientes qui utiliseront vos API (SPA, mobiles ou basées sur le navigateur), puis concevez les modèles d'authentification, d'autorisation et de sécurité appropriés.
  • Utilisez toujours les flux OAuth ou OpenID Connect "client public" (l'utilisation de PKCE est vivement recommandée).
  • Réfléchissez à 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 vous appuyez jamais sur la logique de code d'application en aval pour effectuer cette opération.
  • Filtrez toutes les requêtes de données contenant des informations personnelles spécifiques à l'utilisateur pour n'autoriser que les données de votre backend appartenant à l'utilisateur à l'origine de la requête.

API1:2019 Autorisation au niveau de l'objet non valide

Description de la menace

Une validation d'autorisation insuffisante d'une requête 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 règles ValidApiKey, OAuth et des jetons Web JSON (JWT), qui contribuent à la protection contre cette faille. Il est toutefois essentiel que ces règles soient correctement configurées pour éviter cette menace.

Pour éviter cette menace, il est important que les équipes de développement d'applications et de sécurité collaborent étroitement. L'autorisation est par nature un sujet complexe, et une autorisation précise efficace nécessite une compréhension approfondie de la logique métier de l'application.

Deux aspects principaux sont à prendre en compte du point de vue de l'implémentation d'Apigee:

  • Intégrité des jetons 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 requête n'a pas été falsifié, en utilisant le flux OAuth ou OpenID Connect approprié, ainsi que le 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 vérification des jetons d'accès Apigee incluent les suivantes:

Application du contrôle des accès

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

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

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

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 d'API.

Utilisez les variables de flux disponibles pour les règles OAuth ou JWT pour évaluer les requêtes 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 utilisées directement pour autoriser une requête d'API à un objet backend, ou pour des types de flux OAuth plus complexes qui nécessitent un appel distinct à un serveur d'autorisation pour obtenir un jeton d'accès.

À l'aide de la règle service callout, vous pouvez demander une décision de règle d'autorisation à un service tiers ou obtenir des informations de revendication supplémentaires sur l'agent à l'origine de la demande afin de prendre une décision de contrôle des accès à l'aide d'un flux conditionnel.

API2:2019 Authentification des utilisateurs défaillante

Description de la menace

Une mauvaise implémentation des règles d'authentification des utilisateurs permet aux pirates informatiques d'usurper l'identité d'utilisateurs légitimes en profitant des failles d'implémentation des authentifications. Voici quelques principes d'authentification à garder à l'esprit lors de l'implémentation d'approches d'authentification:

  • Authentifiez toujours à la fois l'user-agent (l'application) et l'utilisateur à l'origine de la requête.
  • Utilisez des 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 une date d'expiration définie.
  • Prévenez les attaques par force brute en définissant des quotas et en utilisant Apigee Sense pour détecter et répondre aux attaques par force brute générées par des bots.

Dans un paradigme extérieur-intérieur, la conception de l'API est basée sur les cas d'utilisation des données par les consommateurs plutôt que 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 implémentations d'authentification suffisamment solides pour être exposés à des réseaux publics. C'est là qu'Apigee, associé à une solution de gestion de l'identité et des accès, peut offrir des solutions efficaces pour se protéger contre cette menace.

Il existe quelques éléments importants à prendre en compte ici, qui seront abordés dans les sections suivantes:

  • Conception de la sécurité: exploitez pleinement les fonctionnalités d'Apigee pour implémenter des modèles d'authentification.
  • Gouvernance: s'assurer que les modèles d'authentification conçus sont utilisés 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, ainsi que les tentatives de contourner ou de forcer par cassage des proxys d'API authentifiés

Conception de la sécurité

L'objectif de la conception de la sécurité est d'implémenter correctement les flux d'authentification et l'intégration avec des outils d'identité tiers. La conception de la sécurité est une phase critique qui commence par identifier le bon type de flux d'authentification délégué à utiliser en fonction du type d'application qui utilisera 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 à implémenter avec votre solution d'identité.

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éfaillante soit l'une des principales menaces OWASP pour les API. Il n'entre pas dans le cadre de ce document de fournir une présentation complète sur la mise en œuvre correcte des normes d'identité. Toutefois, Apigee propose de nombreuses ressources supplémentaires pour mieux comprendre les flux OAuth, comme cet e-book et ce webcast, ainsi qu'un exemple d'implémentation.

Règles d'authentification

Voici quelques-unes des règles Apigee qui aident à résoudre les problèmes d'identité et d'authentification:

  • Vérifier ou générer des jetons d'accès, des jetons d'actualisation ou des jetons de flux de réponse lorsque vous utilisez le 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 les clés API
  • Validation du code d'authentification de message par hachage avec clé (HMAC)

Gestion du trafic

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

  • La règle Spike Arrest, qui permet de définir une limite de débit moyenne glissante globale sur un proxy d'API
  • Règles de quota, pour définir des limites de débit précises sur les proxys d'API en fonction des quotas définis par les clés d'application, les développeurs ou les quotas de produits d'API
  • Règles de mise en cache pour mettre en cache les jetons d'accès stockés en fonction de leur date d'expiration définie, ainsi que la possibilité d'invalidate les identifiants mis en cache (par exemple, en cas de compromission d'un jeton d'accès valide)

Gouvernance

La sécurité est un processus continu, et non un projet "configurer et oublier". L'une des principales causes des brèches de sécurité est la mauvaise configuration. Une fois les flux d'authentification, les modèles d'intégration d'identité et les règles de gestion du trafic liées à l'authentification définis, il est absolument essentiel qu'ils soient implémentés correctement et de manière cohérente.

Apigee fournit un certain nombre de fonctionnalités et d'outils pour garantir l'intégrité de l'implémentation et éviter les erreurs de configuration.

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

Que vous soyez une grande entreprise ou une petite start-up, la première étape pour éviter les erreurs de configuration consiste à vous assurer que seules les personnes et les équipes appropriées peuvent accéder aux configurations de proxy API et les modifier. Les programmes d'API sont pris en charge par des équipes pluridisciplinaires de votre organisation. Il est absolument essentiel que chaque équipe ne reçoive que les autorisations nécessaires pour accomplir ses tâches dans le cadre de votre parcours avec les API.

Apigee vous permet de gérer l'accès basé 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 d'API. Il est essentiel de définir et de gérer correctement l'attribution des rôles pour pouvoir faire évoluer votre programme d'API de manière sécurisée. Vous pouvez également utiliser la fédération pour vous intégrer à votre répertoire d'entreprise existant et réduire le besoin de 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 implémenté dans les proxys d'API. Par exemple, vous pouvez avoir conçu en collaboration avec vos équipes de sécurité plusieurs modèles de conception d'authentification en fonction du type d'application qui utilise une API. Un développeur d'API n'a pas besoin d'être un expert en identité pour réutiliser cela. Il doit simplement connaître le flux partagé approprié à ajouter à sa configuration de proxy d'API existante à l'aide de la règle Invite de flux.

Illustration: Les flux partagés sont des ensembles réutilisables de règles et de logique conditionnelle qui vous permettent de gérer un modèle composite.

Rapports de sécurité

Une fois que vous vous êtes assuré que seules les bonnes personnes de 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 d'authentification 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 d'exploitation et de sécurité de consulter facilement les 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 sont un élément clé de la sécurité des API, qui sera abordé plus en détail dans la section API10: journalisation insuffisante. Toutefois, du point de vue de la prévention des risques d'authentification défaillante, il est extrêmement utile de s'assurer du respect des normes d'authentification définies et implémentées en tant que flux partagés.

Sécurité opérationnelle

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

Apigee Sense

Apigee Sense protège vos API contre le trafic de requêtes indésirables, y compris les attaques de clients malveillants. Apigee Sense analyse le trafic des requêtes d'API, en identifiant les modèles qui pourraient représenter des requêtes indésirables. Grâce à cette analyse, vous pouvez identifier les clients qui envoient des requêtes indésirables, puis prendre des mesures pour les autoriser, les bloquer ou les signaler. Les futures fonctionnalités de Sense incluront la possibilité d'activer automatiquement la validation reCAPTCHA sur le trafic suspect.

Avec Apigee Sense, vous pouvez protéger vos API contre les modèles de requêtes, y compris les suivants:

  • Comportement automatisé qui s'intègre au comportement humain
  • Tentatives persistantes depuis la même adresse IP
  • Taux d'erreur inhabituels
  • Requêtes client suspectes
  • Exploration des données
  • Récupération de clés et attaques par force brute d'authentification
  • Épisodes d'activité
  • Modèles géographiques

Advanced API Ops

Alors que Sense a été conçu spécifiquement pour détecter et répondre aux menaces de type bot, Advanced API Ops inclut à la fois la détection d'anomalies et la définition d'alertes avancées.

Les détections d'anomalies fonctionnent en appliquant des modèles d'intelligence artificielle (IA) et de machine learning (ML) à vos données d'historique d'API. La détection d'anomalies peut ensuite déclencher des alertes en temps réel pour les scénarios auxquels vous n'avez même pas pensés afin d'améliorer votre productivité et réduire le délai moyen de résolution (MTTR) des problèmes d'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 de trafic total. Déclenche une alerte lors d'une modification du trafic, en fonction d'un pourcentage spécifié sur une période donnée. Par exemple, vous pouvez générer une alerte lorsque le trafic augmente de 5 % ou plus pendant une heure, ou lorsqu'il diminue de 10% ou plus pendant une semaine.
  • Alertes d'anomalie. Edge détecte les problèmes de trafic et de performances au lieu d'avoir à les prédéterminer vous-même. Vous pouvez ensuite déclencher une alerte pour ces anomalies.
  • Alertes d'expiration TLS. Génère 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 s'appuyant sur 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 "de l'extérieur vers l'intérieur" d'Apigee pour la conception d'API est la parcimonie des données. Collaborez avec vos concepteurs UX et développeurs pour n'exposer que les données via les API nécessaires dans l'UI de votre application. Les systèmes backend n'ont pas été conçus pour des modèles d'utilisation publics. Par conséquent, l'une des premières tâches de la conception axée sur les API avec Apigee consiste à réduire les données exposées au minimum nécessaire pour fournir un excellent produit d'API à vos clients et développeurs.

La réutilisation est un autre principe de conception d'Apigee. Mis à part les problèmes de sécurité, le fait de s'appuyer sur une application pour filtrer les données fournies par une API nécessite de porter cette logique de filtrage sur toutes les plates-formes pour lesquelles vous développez une application.

D'un point de vue de sécurité, cette menace résulte de la délégation de l'application de l'autorisation à une application, souvent sur une plate-forme ou un OS sur lesquels vous n'avez aucun contrôle. Nous avons déjà examiné dans les sections 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 backend pour minimiser l'exposition des données
  • Implémentez la gestion des erreurs pour éviter que des messages d'erreur détaillés n'exposent des informations sensibles sur l'environnement de vos services backend aux pirates informatiques.

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 sur des applications publiques ni sur des réseaux publics non approuvés. Apigee Edge a été conçu pour vous permettre de déployer des produits d'API publics en protégeant vos backends contre une exposition excessive des données.

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

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

Règle d'attribution des messages

La règle AssignMessage modifie ou crée des messages de requête et de réponse pendant le flux du proxy d'API. La règle vous permet d'effectuer les actions suivantes sur ces messages :

  • Ajouter de nouveaux paramètres de formulaire, d'en-têtes ou de requête à un message
  • Copier des 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'un message
  • Définir la valeur des propriétés existantes dans un message

Avec le paramètre "Attribuer un message", généralement, vous ajoutez, modifiez ou supprimez les propriétés de la requête ou de la réponse. Toutefois, vous pouvez également utiliser la règle d'attribution de messages 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 une gestion de données et des règles de réécriture complexes dont la complexité dépasse la capacité de la règle Assign message (Attribuer un message), 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 compatibilité avec le code procédural est conçue pour faciliter la mise en œuvre de traitements complexes de variables de flux, de pannes et de corps de requêtes et de réponses.

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 d'appel Java et la règle de script Python.

Gestion des erreurs

Apigee vous permet d'effectuer un traitement personnalisé des exceptions à l'aide d'une règle de type Raise Fault. La règle Raise Fault, qui est une variante de la règle Assign 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 standardisation des messages d'erreur. Par exemple, les mêmes stratégies 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 n'implémentant pas de règles de limitation de débit, les pirates informatiques peuvent submerger le backend avec des attaques par déni de service.

Cette menace peut être facilement gérée à l'aide des fonctionnalités Apigee suivantes:

  • Quotas et règles Spike Arrest en tant que mesures préventives pour appliquer des limites de trafic aux requêtes API entrantes
  • Apigee Sense pour détecter et répondre de manière dynamique aux attaques par robot
  • Surveillance et alerte avancées des API en tant que contrôles de détection pour être alerté des attaques DDoS en cours

Limiter le débit avec des règles de quotas et d'arrêts des pics

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

  • Spike Arrest fournit une règle générale, définie au niveau du proxy d'API, pour limiter le nombre total de requêtes entrantes vers un backend.
  • Les quotas fournissent un outil de règles précis pour appliquer des règles de quota, que ce soit au niveau d'un proxy d'API ou d'un produit d'API.

Arrêt des pics

La règle SpikeArrest protège contre les surcharges 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 protège contre les délais de latence et les temps d'arrêt, à l'aide d'une valeur moyenne glissante définissable 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, telle qu'une minute, une heure, un jour, une semaine ou un mois. Vous pouvez définir le même quota pour toutes les applications qui accèdent au proxy d'API, ou définir le quota en fonction des éléments suivants:

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

Cette règle est plus précise que la stratégie Spike Arrest et doit généralement être utilisée en même temps qu'elle.

Détection des bots avec Apigee Sense

Avec Apigee Sense, vous pouvez prendre des mesures pour autoriser, bloquer ou signaler explicitement les requêtes provenant de clients, de plages d'adresses IP ou d'organisations de systèmes autonomes spécifiques, en fonction de ces clients ou de ces emplacements présentant 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 "devinage par force" peut être détecté, puis bloqué ou signalé.

Détection des menaces avec Advanced API Ops Monitoring

Utilisez une alerte de trafic pour envoyer 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 dynamiquement une alerte lorsque le trafic s'écarte considérablement du débit attendu, comme ce serait le cas lors d'une attaque DDoS. Ces alertes peuvent facilement être envoyées à une solution de journalisation et de surveillance tierce.

API5:2019 Autorisation au niveau de la fonction non valide

Description de la menace

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

Ce type de menace met en évidence l'intérêt d'utiliser Apigee comme 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 seul point de terminaison pour exécuter 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 se répartissent généralement comme suit:

  • Qu'est-ce qui est protégé ? Réfléchissez à votre stratégie de produit d'API et implémentez 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 à vos ressources API ? Définissez les personas de haut niveau et implémentez les droits d'accès par défaut de "privilège minimal" à l'aide de certaines des fonctionnalités d'authentification et d'autorisation d'Apigee, comme indiqué dans 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 diagramme montre comment l'autorisation au niveau de la fonction est appliquée dans Apigee, à l'aide des portées fournies dans un jeton d'accès en tant que droits d'accès.

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

Apigee fournit un kit d'outils hautement flexible pour permettre la segmentation logique des ressources d'API. Les proxys d'API peuvent ainsi être regroupés dans un nombre illimité de produits d'API, qui sont à leur tour consommés par vos développeurs d'applications, qui peuvent enregistrer des applications qui utilisent vos produits d'API. Les stratégies d'accès peuvent être définies à l'un de ces niveaux.

Toutefois, pour mettre en œuvre une autorisation et une 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, en examinant vos ressources d'API du point de vue de vos clients et développeurs, puis en définissant précisément les types de requêtes autorisés au niveau d'une ressource de chemin et d'un 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 combiner et utiliser des ressources pour créer des niveaux de consommation et des limites d'autorisation.

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

Bien que les approches d'autorisation envisagées ci-dessus pour API1:2019 Broken object authorization traitent du contrôle d'accès précis au niveau des objets, il est tout aussi important de traiter le contrôle d'accès grossier au niveau des fonctions. L'utilisateur à l'origine de la requête est-il autorisé à demander ce chemin d'URL ? Ce type de stratégie est souvent défini par persona utilisateur (client, employé, administrateur, développeur interne ou tiers).

Pour réduire le risque de mauvaise configuration, nous vous recommandons de travailler avec votre équipe de sécurité pour vous assurer que les assertions sur l'utilisateur à l'origine de la requête sont incluses dans le jeton d'accès, soit à l'aide d'étendues OAuth, soit à l'aide de revendications JWT.

Valider les requêtes avec des flux conditionnels

À un niveau fondamental, un appel d'API REST se compose des éléments suivants:

  • Un point de terminaison
  • Une ressource
  • Un verbe d'action
  • Un nombre illimité 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 un 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 qui vous permet de filtrer les requêtes en fonction des jetons d'accès ou des revendications, Apigee permet d'implémenter une logique de filtrage basée sur la requête elle-même.

Une fois que vous avez bien 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 à limiter les requêtes qui ne rentrent pas dans ce cadre à l'aide des fonctionnalités suivantes du produit Apigee:

  • Logique conditionnelle et règles RaiseFault pour restreindre les chemins de ressources ou les verbes à n'importe quelle étape de la configuration d'un flux de proxy
  • Règles de protection contre les menaces JSON et XML pour vous protéger contre les attaques basées sur le contenu à l'aide de charges utiles de requête JSON ou XML incorrectes

Attribution groupée API6:2019

Description de la menace

Les données non filtrées fournies via des API aux applications clientes permettent aux pirates informatiques de deviner les propriétés des objets via des requêtes ou d'utiliser des conventions d'attribution de noms de point de terminaison pour obtenir des indices sur l'emplacement où effectuer une modification ou un accès non autorisé aux propriétés des objets de données stockés dans le backend.

Cette menace se produit lorsqu'un client reçoit des données non filtrées (généralement au format JSON ou XML), ce qui permet à un pirate informatique de deviner les détails d'implémentation sous-jacents de vos systèmes backend, ainsi que les noms de propriété des éléments de données confidentiels. Ce type d'attaque peut potentiellement permettre à un pirate informatique de lire ou de manipuler des données inappropriées, ou dans le pire des cas, d'exploiter des failles d'exécution de code à distance.

Ce type de menace est généralement permis par deux aspects:

  • Vue de la conception de l'API. Ne vous appuyez jamais sur la logique de l'application pour effectuer le filtrage des données côté client, car les applications peuvent être exploitées par des pirates informatiques et être considérées comme fiables. Concevez toujours votre schéma de données d'API de manière à n'exposer que les données minimales nécessaires pour activer un service d'API.
  • Vue d'implémentation de l'API. Implémentez le filtrage des données et la validation du schéma pour éviter l'exposition involontaire de données confidentielles à une application cliente.

Du point de vue du produit Apigee, nous proposons plusieurs fonctionnalités utiles pour garantir une implémentation robuste du filtrage des données de vos API.

Règle de filtrage de la spécification OpenAPI

La règle OASValidation (validation de spécification OpenAPI) vous permet de valider une requête ou un message de réponse entrants par rapport à une spécification OpenAPI 3.0 (JSON ou YAML). Cette règle vous permet d'effectuer les actions suivantes:

  1. Concevoir votre API en créant une spécification OpenAPI (OAS)
  2. Implémentez 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 à partir de votre backend avec Apigee.
  3. Validez les requêtes entrantes par rapport au schéma de données défini dans votre spécification OAS, y compris le chemin de base, le verbe, la règle de message de requête et les paramètres.

Règle de validation de message SOAP

La règle de validation des messages SOAP vous permet de valider les requêtes basées sur XML, en validant un message XML par rapport à un schéma XSD ou un message SOAP par rapport à une définition WSDL. Vous pouvez également utiliser la règle de validation de message pour confirmer qu'une charge utile de message JSON ou XML est correctement formée, ce qui inclut de vérifier les é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

En général, les problèmes de sécurité sont dus à des configurations par défaut non sécurisées, incomplètes ou ponctuelles, à un stockage cloud ouvert, à des erreurs de configuration d'en-têtes HTTP, ainsi qu'à des messages d'erreur détaillés qui dévoilent des informations sensibles. Les pirates informatiques tentent souvent de trouver des failles non corrigées, des points de terminaison courants, ou des fichiers et des répertoires non protégés pour obtenir un accès non autorisé ou des informations sur le système qu'ils souhaitent attaquer. Les mauvaises configurations de sécurité peuvent non seulement exposer des données utilisateur sensibles, mais aussi des informations système pouvant entraîner la compromission complète du serveur. En outre, voici d'autres cas d'utilisation des failles liées aux mauvaises configurations de sécurité:

  • TLS mal configuré
  • Messages d'erreur avec des traces de la pile
  • Systèmes non corrigés
  • Panneaux de gestion du stockage ou du 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 la sécurité, y compris les suivantes:

  1. Établir et normaliser les processus de renforcement et de correction
  2. Développer un système de gouvernance autour de l'écosystème d'API
  3. Limiter l'accès administrateur, et activer l'audit et les alertes

Flux partagés et hooks de flux

Apigee est compatible avec le concept de flux partagé, qui permet aux développeurs d'API de combiner des règles et des ressources dans un groupe réutilisable. En capturant les fonctionnalités réutilisables au même endroit, un flux partagé vous permet d'assurer la cohérence, de raccourcir le temps de développement et de 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 une logique de flux partagé pour chaque proxy d'API déployé dans le même environnement qu'un flux partagé.

API Security Reporting

Alors que les organisations s'efforcent de développer un framework de gouvernance, Apigee fournit des fonctionnalités de création de rapports sur la sécurité des API, qui aident les équipes d'exploitation à obtenir la visibilité dont elles ont besoin sur les attributs de sécurité des API pour:

  • Assurer 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
  • Identifier, diagnostiquer et résoudre de manière proactive les incidents de sécurité

Les rapports de sécurité Apigee fournissent des insights détaillés aux équipes d'exploitation pour s'assurer du respect des règles et des exigences de configuration, protéger les API contre les utilisations abusives internes et externes, et identifier et 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 susceptibles d'avoir un impact sur la sécurité des proxys. Grâce à ces informations, vous pouvez ajuster la configuration pour vous assurer d'avoir le niveau de sécurité approprié pour chaque proxy.

Surveillance des API

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

Figure: API Monitoring d'Apigee fournit une large gamme d'outils pour surveiller, examiner et résoudre les problèmes. Il exploite les fonctionnalités d'intelligence de pointe de Google Cloud Platform.

Apigee Sense

Apigee Sense aide à protéger les API contre le trafic de requêtes indésirable, y compris les attaques de clients malveillants. Apigee Sense analyse le trafic des requêtes d'API, identifiant les modèles pouvant représenter des requêtes indésirables.

Grâce à cette analyse, les organisations peuvent identifier les clients qui envoient des requêtes indésirables, puis prendre des mesures pour les autoriser, les bloquer ou les signaler. Avec Apigee Sense, vous pouvez protéger les API contre les modèles de requêtes, y compris les suivants:

  • Comportement automatisé qui s'intègre au comportement humain
  • Tentatives persistantes depuis la même adresse IP
  • Taux d'erreur inhabituels
  • Requêtes client suspectes
  • Exploration des données
  • Récupération de clés
  • Épisodes d'activité
  • Modèles géographiques

Injection API8:2019

Description de la menace

L'injection non approuvée de données, telles que SQL, NoSQL, les analyseurs XML, ORM, LDAP, les commandes de l'OS et JavaScript, dans les requêtes d'API peut entraîner l'exécution de commandes inattendues 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, tels que les entrées directes, les paramètres, les services intégrés, etc., en s'attendant à ce qu'elles soient envoyées à un interprète. Les pirates informatiques peuvent facilement découvrir ces failles lorsqu'ils examinent le code source à l'aide d'outils d'analyse des failles et de fuzzing. Une injection réussie peut entraîner la divulgation d'informations affectant la confidentialité et la perte de données, ou dans certains cas, elle peut également entraîner une attaque DoS.

Les bonnes pratiques pour atténuer les erreurs/attaques par injection consistent à définir strictement les données d'entrée telles que les schémas, les types, les modèles de chaîne, à effectuer une validation des entrées, à effectuer des vérifications de limite et à les appliquer 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 des valeurs valides pour chaque paramètre d'entrée.

Apigee Edge, agissant 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 de limite. Vous pouvez configurer un proxy d'API pour 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écurisées.

Règle de protection contre les expressions régulières

La règle RegularExpressionProtection extrait les 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 le contenu par rapport à des expressions régulières prédéfinies. Si l'une des expressions régulières spécifiées renvoie la valeur "true", le message est considéré comme une menace et est rejeté. Une expression régulière (ou "expression régulière") est un ensemble de chaînes spécifiant 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 est l'évaluation des charges utiles JSON et XML afin de détecter du contenu malveillant.

Aucune expression régulière ne peut éliminer toutes les attaques basées sur le contenu. Plusieurs mécanismes doivent être combinés pour permettre une défense en profondeur. Cette section décrit des schémas recommandés pour empêcher l'accès à du contenu.

La plate-forme Apigee propose plusieurs autres approches pour valider les entrées:

Valider les types de contenus

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 d'une logique conditionnelle, comme expliqué ci-dessous.

API Security Reporting

Alors que les organisations s'efforcent de développer un framework de gouvernance, Apigee fournit des fonctionnalités de création de rapports sur la sécurité des API, qui aident les équipes d'exploitation et leur donnent la visibilité dont elles ont besoin pour sécuriser les API en leur fournissant les attributs de sécurité des API nécessaires pour:

  • Assurez-vous que les règles de sécurité et les exigences de configuration sont respectées.
  • Protéger les données sensibles contre toute utilisation abusive interne et externe
  • Identifiez, diagnostiquez et corrigez de manière proactive les incidents de sécurité.

API9:2019 Mauvaise gestion des composants

Description de la menace

Une gestion et une ségrégation insuffisantes des environnements permettent aux pirates informatiques d'accéder aux points de terminaison d'API sous-sécurisés. L'absence de mesures de gouvernance entraîne également une exposition inutile des ressources obsolètes.

Pour y remédier, vous pouvez exploiter les fonctionnalités avancées d'Apigee pour gérer l'ensemble du cycle de vie des API. Vous pourrez ainsi créer un modèle de gouvernance complet qui favorise la collaboration entre les équipes, tout en appliquant une séparation des responsabilités entre les personnes concernées par la sécurité et les développeurs d'API. Vous pouvez configurer et gérer les limites et les commandes à 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 les rôles: seules les personnes nécessaires de vos équipes API auront les autorisations nécessaires pour gérer les modifications de configuration et le processus de promotion.

Gestion des audiences pour la documentation de l'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 en tant que 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é ont une visibilité de bout en bout sur les API publiées et leur configuration associée. Le respect des règles de sécurité mondiales peut être audité et évalué en fonction du profil de risque de chaque point de terminaison d'API publié.

Organisations et environnements

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

Organisations : une organisation est le locataire de niveau supérieur dans Apigee. Il vous permet de ségréger complètement le trafic, la configuration et les utilisateurs. En tant que bonne pratique de gouvernance, vous devriez envisager de créer des organisations distinctes pour la production et les environnements hors production. Cette pratique évite efficacement de mélanger les données de production, les utilisateurs et le trafic avec les environnements de niveau inférieur.

Environnements : les API d'Apigee peuvent être promues via plusieurs états de déploiement. Chaque état est associé à un contexte d'exécution. Le contexte de l'environnement n'est pas transmis lors du processus de promotion, ce qui évite d'exposer une configuration sensible à des utilisateurs non autorisés.

Révisions : les révisions permettent de promouvoir facilement les API et les fonctionnalités individuelles dans les environnements.

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

Pour atténuer le risque API9, il est impératif de définir clairement les responsabilités et de les répartir entre les personnes concernées par la sécurité et les développeurs d'API. Comme indiqué précédemment dans ce document, Apigee dispose de fonctionnalités flexibles de contrôle des accès basé sur les rôles qui vous permettent d'attribuer des autorisations à des rôles personnalisés. Pour cette menace spécifique, les rôles peuvent être limités par organisation, environnements ou autorisations de configuration plus précises. Nous vous recommandons de limiter les droits d'accès pour modifier l'état de déploiement des API via des environnements, et de vous assurer que les développeurs ne peuvent pas accéder ni modifier les bibliothèques de sécurité globales (hooks de flux). Ces rôles limités empêchent les modifications non sollicitées des règles de sécurité globales qui couvrent un large éventail de points de terminaison publiés anciens et actuels.

Gestion des audiences pour la documentation des API

Un portail des développeurs est un élément essentiel pour 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 produits d'API. Les produits d'API sont définis par des lots de ressources et d'opérations qui relèvent du même contexte métier et de sécurité (par exemple, plan de service, domaine d'activité, catégorie, hiérarchie de l'entreprise, etc.).

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

Hooks de flux

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

Apigee vous permet de renforcer les 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 en tant que garde-fous privilégiés qui ne peuvent pas être modifiés par les développeurs d'API. Cela garantit la séparation des responsabilités et favorise l'agilité en appliquant une sécurité par défaut et, par extension, en assurant la conformité de sécurité pour toutes les API déployées dans un environnement d'exécution donné.

Figure: Les 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 gérer 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 agile.

Rapports de sécurité

Les audits de sécurité visent à évaluer et à tester les règles de sécurité destinées à protéger les données et les objectifs métier 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, en même temps, auditable.

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

Trafic d'exécution : vue unique des insights sur le trafic des API concernant les serveurs cibles, les hôtes virtuels, la configuration TLS, les modifications de trafic par environnement, etc.

Configuration : fonctionnalité d'audit de 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 aux niveaux d'organisation ou de proxy.

Activité des utilisateurs: suivez les opérations sensibles effectuées par les utilisateurs de la plate-forme. Analysez l'activité suspecte en effectuant une analyse détaillée.

API10:2019 Journalisation et surveillance insuffisantes

Description de la menace

Un manque de journalisation, de surveillance et d'alertes permet aux attaques en cours de ne pas être détectées. Par conséquent, une stratégie doit être mise en place 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 journalisation des 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 verbosity, les niveaux de journalisation, l'intégrité des journaux, le dépôt centralisé, etc.
  • Règle de gestion des événements: garantit que chaque événement doit être traçable jusqu'à sa source. Les événements doivent également pouvoir être classés en fonction de leur criticité et de leur impact sur l'activité.
  • Rapports et audits: les personnes concernées par la sécurité et les opérations doivent pouvoir accéder aux journaux et aux événements en temps réel, et y réagir. En outre, les personnes concernées peuvent effectuer 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 de gestion complète des événements et des journaux. Ces outils sont les suivants :

Règle de journalisation des messages: créez des flux de journaux en fonction des données de trafic ou des métadonnées de votre trafic d'API. Vous pouvez choisir le niveau de verbosity du flux en utilisant la logique conditionnelle et des modèles de message.

Suite Google Cloud Operations: exploitez l'intégration prête à l'emploi dans les outils de surveillance et de journalisation hautement évolutifs de Google.

Règle ServiceCallout: permet d'utiliser des flux de journaux qui nécessitent des points de terminaison HTTP pour envoyer des événements.

Données analytiques : accédez aux métadonnées de l'historique du trafic et analysez-les à l'aide de rapports prêts à l'emploi et/ou personnalisés. Créez et gérez des alertes en fonction des tendances, et comprenez les anomalies de 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 être analysés plus en détail et utilisés à des fins de traitement.