Ce document décrit les bonnes pratiques qui peuvent vous aider à sécuriser vos applications et vos API à l'aide de Apigee API Management et des produits Google Cloud suivants :
Ce document est destiné aux architectes d'API, aux architectes de sécurité et aux ingénieurs qui gèrent l'infrastructure d'une application et qui souhaitent exposer des API sécurisées, évolutives et performantes.
Ce document s'appuie sur une série d'exemples d'architectures pour illustrer les bonnes pratiques relatives à la gestion de l'API Apigee. Ce document traite également des bonnes pratiques pour utiliser la protection des applications Web et des API (WAAP), une solution de sécurité complète que vous pouvez utiliser pour sécuriser vos applications et vos API.
Dans ce document, nous partons du principe que vous connaissez la mise en réseau, les API et Google Cloud.
Gestion des API Apigee
Apigee est une plate-forme de développement et de gestion des API. En ajoutant une couche de proxy à vos services, Apigee fournit une abstraction ou une façade qui vous aide à sécuriser les API de votre service de backend.
Les utilisateurs peuvent interagir avec les applications à l'aide du protocole OAuth 2.0 et des plages d'adresses IP figurant sur la liste d'autorisation. Comme le montre l'image suivante, les utilisateurs peuvent interagir avec une application et les données et services sont exposés dans un flux bidirectionnel.
Les points de sécurité sont les suivants :
- Utilisateurs :
- OAuth 2.0
- Contrôle des accès aux adresses IP
- Applications
- Clés API
- OAuth 2.0
- TLS
- Développeurs et partenaires
- SSO
- RBAC
- API
- OAuth 2.0
- OpenID Connect
- Quotas
- Arrêt des pics
- Protection contre les menaces
- Équipe API
- IAM RBAC
- Logique fédérée
- Masquage des données
- Journaux d'audit
- Backend
- Mise en réseau privée
- TLS mutuel
- Contrôle des accès aux adresses IP
Comme l'illustre l'image précédente, vous pouvez utiliser différents mécanismes de sécurité dans une application, tels que la clé API ou OAuth 2.0 avec TLS (Transport Layer Security). Vous pouvez également ajouter une limitation du débit et des règles de protection contre les menaces, et configurer une authentification TLS mutuelle sur le backend de votre couche API.
Pour vous aider à gérer l'accès pour une équipe API au sein de la plate-forme Apigee, Apigee offre un contrôle des accès basé sur les rôles (RBAC) et une connexion fédérée.
Nous vous recommandons d'utiliser les stratégies par défaut d'Apigee pour sécuriser vos API. Les stratégies sont les suivantes :
- Gestion du trafic. Vous aide à configurer la mise en cache, à contrôler les quotas, à limiter les effets des pics et à contrôler le trafic des API.
- Protection au niveau du message. Vous permet d'inspecter et de valider les charges utiles de requêtes pour protéger votre backend contre les pirates malveillants.
- Sécurité. Permet de contrôler l'accès à vos API.
Vous pouvez associer une ou plusieurs de ces stratégies à votre couche de proxy. Le tableau suivant répertorie les cas d'utilisation de la sécurité pour chaque règle, classés par type.
| Type de règles | Nom de la règle | Cas d'utilisation de la sécurité |
|---|---|---|
| Gestion du trafic | Règle SpikeArrest | Applique la limitation du débit au nombre de requêtes envoyées au backend. |
| Gestion du trafic | Règles relatives aux quotas | Aide votre organisation à appliquer des quotas (nombre d'appels d'API effectués) pour chaque consommateur. |
| Gestion du trafic | Règle ResponseCache | Met en cache les réponses, réduisant ainsi le nombre de requêtes adressées au backend. |
| Protection au niveau du message | Règle OASValidation | Valide les requêtes entrantes ou les messages de réponse par rapport à une spécification OpenAPI 3.0 (JSON ou YAML). |
| Protection au niveau du message | Règle SOAPMessageValidation | Valide les messages XML par rapport au schéma de votre choix. Valide les messages SOAP par rapport à un WSDL et détermine si les messages JSON et XML sont correctement formés. |
| Protection au niveau du message | Règle JSONThreatProtection | Permet de réduire le risque d'attaques au niveau du contenu en vous permettant de spécifier des limites sur les structures JSON, comme les tableaux et les chaînes. |
| Protection au niveau du message | Règle XMLThreatProtection | Vous aide à traiter les failles XML et à limiter le risque d'attaque en évaluant le contenu des messages et en détectant les messages corrompus ou incorrects avant de les analyser. |
| Protection au niveau du message | Règle RegularExpressionProtection | Évalue le contenu par rapport aux expressions régulières prédéfinies et le rejette si l'expression est vraie. |
| Sécurité | Règle BasicAuthentication | Encode et décode les identifiants utilisateur en base64. |
| Sécurité | Règle de vérification des clés API | Applique la vérification et la validation des clés API au moment de l'exécution. N'autorise que les applications disposant de clés API approuvées associées à vos produits d'API à accéder à vos API. |
| Sécurité | Règle OAuthV2 | Effectue des opérations de type d'octroi OAuth 2.0 pour générer et valider des jetons d'accès. |
| Sécurité | Règles JWS et JWT | Génère, vérifie et décode les jetons Web JSON (JWT) et les signatures Web JSON (JWS). |
| Sécurité | Règle HMAC | Calcule et vérifie le code HMAC (hash-based message authentication code) pour les vérifications d'authentification et d'intégrité au niveau de l'application. |
| Sécurité | Règle SAMLAssertion |
|
| Sécurité | Règle CORS | Vous permet de définir des en-têtes Cross-Origin Resource Sharing (CORS) pour les API utilisées par les applications Web. |
Nous vous recommandons d'utiliser Google Cloud Armor pour le contrôle d'accès basé sur l'adresse IP et la géolocalisation. Toutefois, lorsque ce n'est pas possible, vous pouvez utiliser la règle AccessControl. Pour vous aider à sécuriser les connexions d'Apigee à votre backend, Apigee fournit également une fonctionnalité de gestion de keystore qui vous permet de configurer le keystore et le truststore pour les handshakes TLS.
Apigee vous permet de créer des produits d'API capables de regrouper vos opérations d'API et de les mettre à la disposition des développeurs d'applications. Un produit d'API regroupe une ou plusieurs opérations. Une opération spécifie un proxy d'API et des chemins de ressources accessibles par ce proxy. Une opération peut également limiter l'accès sur la base des méthodes HTTP utilisées ou de quoats.
Vous utilisez des produits d'API pour contrôler l'accès à vos API. En définissant un ou plusieurs produits d'API dans une application de développeur, vous pouvez limiter l'accès aux proxys disposant d'une clé API. Par exemple, les applications mobiles utilisées par les clients ne peuvent effectuer qu'une opération POST sur le point de terminaison /v1/payments, dans ce cas, https://$DOMAIN/v1/payments. Autre exemple : les applications des centres d'appels utilisées par les équipes de ces centres peuvent effectuer des opérations telles que PUT ou DELETE sur le point de terminaison /payments (https://$DOMAIN/v1/payments/1234 par exemple), afin d'annuler ou d'inverser les paiements.
Architecture initiale
Cette section décrit un exemple d'architecture de microservices avec des services déployés dans un centre de données et auprès d'un fournisseur cloud. Les bonnes pratiques relatives à l'architecture ci-dessous vous montrent comment créer plusieurs itérations et améliorer l'architecture initiale.
L'architecture initiale est la suivante :
- Les services de paiement et de comptes sont hébergés dans le centre de données, tandis que le service de transfert d'argent est hébergé dans Google Cloud.
- L'équilibreur de charge d'application externe contrôle et configure l'entrée vers les services.
- L'équilibreur de charge d'application externe transfère la requête au backend ou au service tiers approprié et gère le handshake TLS.
Dans son état initial, l'exemple d'architecture présente les contraintes suivantes :
- Il est peu probable qu'il évolue.
- Il est peu probable qu'il protège un système contre les attaques malveillantes.
- Il ne reflète pas les bonnes pratiques en termes de sécurité et de journalisation, car ces services sont développés et gérés par différentes équipes au sein de l'organisation.
Bonnes pratiques d'architecture
Apigee peut apporter de la valeur et simplifier l'exposition de vos services aux clients en mettant en œuvre un ensemble standard de règles de sécurité dans toutes les API. Cette section présente les bonnes pratiques d'utilisation d'Apigee pour sécuriser vos API.
Utiliser Apigee en tant que couche proxy
Le schéma suivant illustre l'architecture initiale avec l'ajout d'Apigee en tant que couche proxy (façade) :
Apigee est provisionné dans un projet Google Cloud, et l'environnement d'exécution est provisionné et appairé dans un projet locataire à l'aide de l'appairage de réseaux VPC. Pour sécuriser votre système, au lieu d'envoyer des données via Internet, vous pouvez utiliser Apigee en tant que couche proxy pour établir une connexion directe (privée) à votre centre de données à l'aide de Cloud Interconnect.
Le flux de requêtes s'effectue comme suit :
- Le client envoie la requête à l'équilibreur de charge d'application externe avec les identifiants de l'application (par exemple, une clé, un jeton ou un certificat).
- L'équilibreur de charge achemine la requête vers Apigee.
- Apigee traite la requête, exécute les règles de sécurité comme décrit dans la section Gestion des API Apigee, et autorise ou refuse la requête. Apigee peut également servir à acheminer la requête vers différents backends en fonction du client, de la requête ou des deux.
- Apigee transfère la requête aux backends GKE directement via des adresses IP internes. La communication entre Apigee et le service de transfert d'argent peut avoir lieu sur une adresse RFC 1918 (adresse IP interne), car elles appartiennent au réseau appairé.
- Apigee envoie la requête aux backends de centre de données privés via Cloud Interconnect.
- Apigee envoie la requête à des services tiers via le provisionnement des adresses IP NAT Apigee.
Utiliser Google Cloud Armor comme couche WAF avec Apigee
Vous pouvez ajouter Google Cloud Armor à l'architecture pour augmenter votre périmètre de sécurité. Google Cloud Armor fait partie de l'infrastructure globale d'équilibrage de charge de Google Cloud. Il fournit des fonctionnalités de pare-feu d'application Web (WAF) et permet d'éviter les attaques par déni de service distribué (DDoS). Il peut également vous aider à réduire la menace aux applications posée par les risques répertoriés dans le Top 10 de la fondation OWASP.
Vous pouvez configurer des règles et des stratégies dans Google Cloud Armor afin d'évaluer chaque appel effectué par le client qui atteint l'équilibreur de charge d'application externe. Vous pouvez également automatiser la configuration des stratégies Google Cloud Armor. Pour en savoir plus sur la configuration des règles dans Google Cloud Armor, consultez les guides d'utilisation de Google Cloud Armor.
Le schéma suivant montre l'architecture d'exemple avec Apigee et Google Cloud Armor :
Le flux d'événements dans cette architecture ressemble à ceux décrits dans la section Utiliser Apigee en tant que couche proxy plus haut dans ce document. Le flux de requêtes s'effectue comme suit :
- Le client envoie la requête à l'équilibreur de charge d'application externe avec les identifiants de l'application (par exemple, une clé, un jeton ou un certificat).
- Étant donné qu'il est activé pour l'équilibreur de charge d'application externe, Google Cloud Armor filtre la requête. Il applique et évalue toutes les règles et stratégies configurées. Si une règle n'est pas respectée, Google Cloud Armor rejette la requête et vous renvoie un message d'erreur ainsi qu'un code d'état.
- Si les règles Google Cloud Armor ne sont pas enfreintes, l'équilibreur de charge d'application externe achemine la requête vers Apigee.
- Apigee traite la requête, exécute les règles de sécurité, et autorise ou refuse la requête. Il peut également servir à acheminer la requête vers différents backends en fonction du client, de la requête ou des deux critères.
- Apigee transfère la requête aux backends GKE directement via des adresses IP internes. La communication entre Apigee et le service de transfert d'argent peut avoir lieu sur une adresse RFC 1918 (adresse IP interne), car elles appartiennent au réseau appairé.
- Apigee envoie la requête aux backends de centre de données privés via Cloud Interconnect.
- Apigee envoie la requête à des services tiers via le provisionnement des adresses IP NAT Apigee.
Utiliser WAAP
Pour améliorer votre profil de sécurité, vous pouvez également utiliser WAAP, qui regroupe Google Cloud Armor, reCAPTCHA et Apigee pour protéger votre système contre les attaques DDoS et les robots. Il fournit également des fonctionnalités de WAF et de protection des API.
Nous recommandons l'utilisation de WAAP pour les cas d'utilisation en entreprise où les appels d'API sont effectués à partir d'un site Web et d'applications mobiles. Vous pouvez configurer les applications pour qu'elles chargent les bibliothèques reCAPTCHA de manière à générer un jeton reCAPTCHA et à l'inclure lors de l'envoi d'une requête.
Le schéma suivant illustre le workflow :
Le flux de requête du schéma précédent s'effectue comme suit :
- (1) Toutes les requêtes HTTP(S) des clients et des utilisateurs d'API sont envoyées à l'équilibreur de charge d'application externe.
- (2) Le premier point de contact de la solution WAAP est Google Cloud Armor.
- (2a) Si aucune de ces règles n'est déclenchée par les stratégies Google Cloud Armor, une requête est envoyée à l'API reCAPTCHA pour évaluer si le trafic entrant est une requête légitime ou non.
- (3a) S'il s'agit d'une requête légitime, la requête est transmise au backend.
- (2b) Si la requête n'est pas légitime, Google Cloud Armor peut la refuser et renvoyer un code de réponse 403 à l'utilisateur.
- (3b) Pour les requêtes d'API, une fois les règles OWASP et les protections DDoS de Google Cloud Armor évaluées, la requête est ensuite transmise à Apigee pour vérifier la validité de la requête API.
- (4) Apigee détermine si les clés API ou les jetons d'accès utilisés dans la requête sont valides. Si Apigee détermine que la requête n'est pas légitime, un code de réponse 403 peut être envoyé.
- (5) Si la requête est légitime, Apigee la transfère au backend.
Le schéma suivant illustre l'architecture de WAAP avec Google Cloud Armor, reCAPTCHA et Apigee pour les requêtes API.
Le flux de requête du schéma précédent s'effectue comme suit :
- Le client envoie la requête à l'équilibreur de charge d'application externe avec les identifiants de l'application (par exemple, une clé, un jeton ou un certificat).
- Étant donné qu'il est activé pour l'équilibreur de charge d'application externe, Google Cloud Armor sélectionne la requête. Il applique et évalue ensuite toutes les règles et stratégies configurées. Si une règle est enfreinte, Google Cloud Armor rejette la requête avec un message d'erreur et un code d'état.
- Pour les appels de site Web tels que l'envoi de formulaires pour une page de connexion, Google Cloud Armor est intégré à reCAPTCHA. reCAPTCHA évalue le trafic entrant et ajoute des scores de risque au trafic légitime. Pour le trafic qui n'est pas légitime, Google Cloud Armor peut refuser la requête.
- Si les règles Google Cloud Armor ne sont pas enfreintes, l'équilibreur de charge d'application externe achemine la requête API vers Apigee.
- Apigee traite la requête, exécute les règles de sécurité, et autorise ou refuse la requête. Apigee peut également servir à acheminer la requête vers différents backends en fonction du client, de la requête ou des deux.
- Apigee transfère la requête aux backends GKE directement via des adresses IP internes. La communication entre Apigee et le service de transfert d'argent peut avoir lieu sur l'adresse RFC 1918, qui est une adresse IP interne, car elles appartiennent toutes les deux au réseau appairé.
- Apigee envoie la requête aux backends de centre de données privés via Cloud Interconnect.
- Apigee envoie la requête à des services tiers via le provisionnement des adresses IP NAT Apigee.
Utiliser Cloud CDN pour la mise en cache
Cloud CDN exploite le réseau mondial de Google pour diffuser le contenu au plus près des utilisateurs, ce qui accélère les temps de réponse pour vos sites Web et applications. Cloud CDN offre également des fonctionnalités de mise en cache qui vous aident à sécuriser le backend en renvoyant la réponse directement depuis son cache. En mettant en cache les données fréquemment consultées sur un Google Front End (GFE), qui est situé à la périphérie du réseau Google, il conserve les données aussi proches que possible des utilisateurs et permet l'accès le plus rapide possible.
Cloud CDN aide également les entreprises à gérer de manière transparente les pics de trafic saisonniers comme les pics de trafic pendant les fêtes ou la rentrée. Cette approche de la mise en cache permet d'améliorer la fiabilité et l'expérience utilisateur dans un écosystème. Elle permet également de minimiser la charge du serveur Web, la charge de calcul et l'utilisation du réseau. Pour mettre en œuvre cette architecture, vous devez activer Cloud CDN sur l'équilibreur de charge qui diffuse le trafic pour Apigee.
Cloud CDN peut être utilisé avec n'importe laquelle des options décrites dans ce document. Le schéma suivant illustre l'exemple initial d'architecture de WAAP avec l'ajout de Cloud CDN.
Le flux de requête illustré dans le schéma précédent s'effectue comme suit :
- Le client utilise les bibliothèques reCAPTCHA pour obtenir un jeton et envoie la requête à l'équilibreur de charge d'application externe avec les identifiants de l'application (par exemple, une clé, un jeton ou un certificat).
- Cloud CDN vérifie le cache avec la clé de cache et renvoie la réponse si la correspondance (hit) trouvée dans le cache est "true".
- Si la correspondance trouvée dans le cache est définie sur "false", Google Cloud Armor filtre la requête car il est activé pour l'équilibreur de charge d'application externe. Google Cloud Armor applique et évalue toutes les règles et stratégies configurées. Si une règle est enfreinte, la requête est rejetée avec un message d'erreur et un code d'état.
- Google Cloud Armor est intégré à reCAPTCHA, qui évalue le trafic entrant légitime avec des scores de risque. Pour le trafic qui n'est pas légitime, Google Cloud Armor peut refuser la requête.
- Si les règles Google Cloud Armor ne sont pas enfreintes, l'équilibreur de charge d'application externe achemine la requête vers Apigee.
- Apigee traite la requête, exécute les règles de sécurité comme décrit dans la section Gestion des API Apigee, et autorise ou refuse la requête. Il peut également servir à acheminer la requête vers différents backends en fonction du client, de la requête ou des deux.
- Apigee transfère la requête aux backends GKE directement via des adresses IP internes. La communication entre Apigee et le service de transfert d'argent peut avoir lieu sur l'adresse RFC 1918, qui est une adresse IP interne, car elles appartiennent au réseau appairé.
- Apigee envoie la requête aux backends de centre de données privés via Cloud Interconnect.
- Apigee envoie la requête à des services tiers via le provisionnement des adresses IP NAT Apigee.
- Lorsqu'une réponse est renvoyée au client, Cloud CDN la met en cache afin de pouvoir renvoyer la réponse du cache lors de futurs appels.
Étape suivante
- Apprenez-en plus sur les options de provisionnement Apigee.
- Découvrez la sécurité multicouche des API avec Apigee et Google Cloud Armor.
- Découvrez comment fournir des API globales très performantes avec Apigee X et Cloud CDN.
- Lisez et posez des questions dans la communauté Apigee.
- Explorez le dépôt Apigee sur GitHub.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.