Utiliser Google Cloud Armor, l'équilibrage de charge et Cloud CDN pour déployer des interfaces globales programmables

Last reviewed 2024-04-04 UTC

Ce document fournit une architecture de référence pour une application Web hébergée sur Google Cloud. L'architecture utilise une interface mondiale qui intègre les bonnes pratiques de Google Cloud pour vous aider à faire évoluer, sécuriser et accélérer la diffusion de vos applications Web. L'architecture comprend la compatibilité avec Cloud Build, ainsi que des outils tiers d'intégration continue (CI) et de livraison continue (CD) tels que Jenkins et GitLab. Cette architecture est destinée aux développeurs et aux propriétaires d'applications qui souhaitent faire évoluer leur application avec un équilibreur de charge et les protéger contre les attaques par déni de service distribué (DDoS) et les attaques sur le Web à l'aide d'un pare-feu d'application Web (WAF).

Architecture

Le schéma suivant illustre l'architecture décrite dans ce document.

Architecture de l'application Web.

Dans cette architecture, la charge de l'application est équilibrée avec des équilibreurs de charge d'application externes globaux, qui répartissent le trafic HTTP et HTTPS sur plusieurs instances backend dans différentes régions. Cloud CDN accélère les applications Web en utilisant les points de présence périphériques (PoP) de Google et fonctionne avec l'équilibreur de charge d'application externe global pour fournir du contenu aux utilisateurs. Les backends sont protégés par des stratégies de sécurité Google Cloud Armor qui assurent un filtrage de couche 7 en nettoyant les requêtes entrantes pour les attaques Web courantes ou d'autres attributs de couche 7, ce qui permet de bloquer le trafic avant qu'il n'atteigne les services de backend à équilibrage de charge. La protection contre les attaques DDoS volumétriques est activée par défaut.

Lorsqu'un utilisateur demande du contenu à votre service, cette requête est envoyée aux applications Web frontales mondiales, fournies par le Cross-Cloud Network. La requête est évaluée par les stratégies de sécurité Google Cloud Armor, en commençant par les stratégies de sécurité périphériques Google Cloud Armor. Si la requête est autorisée et peut être traitée par Cloud CDN, le contenu est extrait du cache Google Cloud Armor et renvoyé à l'utilisateur. Si la requête génère un défaut de cache (miss), il est évalué par les stratégies de backend, puis, conformément aux règles de la stratégie, elle est refusée ou traitée par votre serveur backend.

Composants d'architecture

Le schéma précédent comprend les composants suivants :

  • Équilibreur de charge d'application externe global: cet équilibreur de charge d'application est un équilibreur de charge de couche 7 basé sur un proxy qui vous permet d'exécuter et de faire évoluer vos services. L'équilibreur de charge d'application répartit le trafic HTTP et HTTPS entre les backends hébergés sur diverses plates-formes Google Cloud. L'équilibreur de charge d'application présente les fonctionnalités suivantes:

    • Backend configurable : cette architecture utilise deux groupes d'instances gérés (MIG) dans différentes régions, mais vous pouvez configurer n'importe quel backend compatible avec l'équilibreur de charge d'application externe global. Vous pouvez utiliser le même équilibreur de charge pour les applications GKE, Cloud Run, Cloud Functions et App Engine, ainsi que celles hébergées sur site et sur d'autres clouds avec une configuration de backend différente. Pour en savoir plus, consultez la présentation de l'équilibreur de charge d'application.
    • Répartition du trafic : vous pouvez utiliser l'équilibreur de charge d'application pour la gestion du trafic, y compris la gestion des versions logicielles en envoyant différents utilisateurs à différents serveurs de backend. Dans l'architecture décrite dans ce document, il existe une répartition du trafic simple de 60/40. Toutefois, vous pouvez modifier cette répartition pour créer des schémas de gestion du trafic plus complexes. Pour en savoir plus sur les autres options de configuration, consultez les délais avant expiration et les nouvelles tentatives configurables et déterminez le mode d'équilibrage souhaité.

  • Cloud CDN : la plate-forme Cloud CDN agit comme un cache. Il est déployé avec le serveur d'origine pour fournir la suite complète des fonctionnalités de Cloud CDN, y compris QUIC et HTTP/2, ainsi que les contrôles du routage et du cache. Cette approche permet à votre application d'évoluer à l'échelle mondiale sans compromettre les performances, et de réduire les coûts liés à la bande passante et aux calculs frontaux. La configuration par défaut utilisée par l'interface mondiale est basée sur les bonnes pratiques concernant la diffusion de contenu de Cloud CDN et sur les bonnes pratiques concernant la sécurité Web.

  • Google Cloud Armor : ce composant inclut la protection DDoS et les règles WAF. L'architecture présente la configuration Google Cloud Armor de base suivante, qui permet d'atténuer les risques liés aux vecteurs de menaces courants :

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

Considérations de conception

Cette section fournit des conseils pour vous aider à utiliser ce document comme point de départ pour développer une architecture répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, d'efficacité opérationnelle, de coût et de performances.

Sécurité, confidentialité et conformité

Cette section décrit des facteurs supplémentaires à prendre en compte lorsque vous utilisez cette architecture de référence pour déployer l'application Web.

Établir une référence de sécurité

Pour renforcer votre sécurité, l'architecture décrite dans ce document est également compatible avec le plan de base de l'entreprise. Le plan aide les organisations qui utilisent Google Cloud à établir une référence sécurisée pour toutes les charges de travail futures, y compris la configuration d'Identity and Access Management (IAM), de Cloud Key Management Service et de Security Command Center.

Protéger les données utilisateur avec Cloud CDN

Dans cette architecture, nous vous recommandons de ne pas mettre en cache du contenu spécifique à l'utilisateur. Pour mettre en cache les types de contenu HTML (text/html) et JSON (application/json), définissez des en-têtes explicites de contrôle du cache dans la réponse Cloud CDN. Assurez-vous de ne pas mettre en cache les données d'un utilisateur et de les diffuser pour tous les utilisateurs.

Contrôler l'accès à votre application avec IAP

L'architecture est également compatible avec Identity-Aware Proxy (IAP). IAP vérifie l'identité d'un utilisateur, puis détermine si cet utilisateur doit être autorisé à accéder à une application. Pour activer IAP pour l'équilibreur de charge d'application pour le mode externe global ou pour le mode classique, activez-le sur les services de backend de l'équilibreur de charge. Les requêtes HTTP/HTTPS entrantes sont évaluées par Google Cloud Armor avant d'être envoyées pour l'équilibrage de charge par l'équilibreur de charge d'application. Si Google Cloud Armor bloque une requête, IAP ne l'évalue pas. Si Google Cloud Armor autorise une requête, IAP l'évalue. La requête est bloquée si IAP ne l'authentifie pas. Pour en savoir plus, consultez la section Intégrer Google Cloud Armor à d'autres produits Google.

Optimisation des coûts

En règle générale, l'utilisation de Cloud CDN avec Google Cloud Armor peut aider à minimiser l'effet des frais de transfert de données.

Cloud CDN

Les objets statiques diffusés au client à partir du cache ne passent pas par l'équilibreur de charge. Une stratégie de mise en cache efficace peut réduire la quantité de données sortantes traitées par l'équilibreur de charge et réduire vos coûts.

Google Cloud Armor

Google Cloud Armor vous aide à réduire les coûts en évitant que votre compte ne soit facturé pour du trafic indésirable. Les requêtes bloquées par Google Cloud Armor ne génèrent pas de réponse de votre application, ce qui réduit efficacement la quantité de données sortantes traitées par l'équilibreur de charge. L'effet sur vos coûts dépend du pourcentage de trafic indésirable bloqué par les stratégies de sécurité Google Cloud Armor que vous mettez en œuvre.

Les coûts finaux peuvent également varier en fonction du nombre de services ou d'applications que vous souhaitez protéger, du nombre de stratégies et de règles Google Cloud Armor dont vous disposez, du remplissage et de la sortie du cache, ainsi que du volume de données. Pour en savoir plus, consultez les ressources suivantes :

Déploiement

Pour déployer cette architecture de référence, utilisez l'exemple Terraform. Pour en savoir plus, consultez le fichier README. Le dossier web_app_protection_example inclut le fichier (main.tf). Le code de ce fichier crée l'architecture décrite dans ce document et fournit une assistance supplémentaire pour le déploiement automatique.

La structure du dossier Terraform se présente comme suit :

Lorsque vous procédez au commit d'une modification dans une branche sur laquelle est basé votre pipeline, ces modifications déclenchent l'exécution du pipeline et les modifications sont intégrées dans une nouvelle version une fois l'opération terminée. Lorsque vous extrayez le toolkit pour la première fois, la solution est chargée dans le projet Google Cloud de votre choix.

Étapes suivantes

Découvrez les bonnes pratiques concernant les produits Google Cloud utilisés dans cette architecture de référence :

Contributeurs

Auteurs :

Autres contributeurs :