Intégrer Cloud Armor à d'autres produits Google

Les sections suivantes expliquent comment Cloud Armor interagit avec d'autres fonctionnalités et produits Google Cloud .

Règles de pare-feu VPC et Cloud Armor

Les stratégies de sécurité Cloud Armor et les règles de pare-feu VPC ont différentes fonctions :

Les stratégies de sécurité Cloud Armor offrent une sécurité périphérique et agissent sur le trafic client vers les GFE (Google Front End).
Les règles de pare-feu VPC autorisent ou refusent le trafic vers et depuis vos backends. Vous devez créer des règles de pare-feu autorisant le trafic entrant, dont les cibles sont les VM de backend à équilibrage de charge et dont les sources sont des plages d'adresses IP utilisées par des équilibreurs de charge d'application externes mondiaux ou des équilibreurs de charge d'application classiques. Ces règles autorisent les GFE et les systèmes de vérification de l'état à communiquer avec vos VM de backend.

Par exemple, supposons que vous souhaitiez n'autoriser que le trafic provenant des plages CIDR 100.1.1.0/24 et 100.1.2.0/24 à accéder à votre équilibreur de charge d'application externe mondial ou à votre équilibreur de charge d'application classique. Votre objectif est d'empêcher le trafic d'atteindre directement les instances backend à équilibrage de charge. En d'autres termes, seul le trafic externe transmis par proxy via l'équilibreur de charge d'application externe mondial ou l'équilibreur de charge d'application classique associé à une stratégie de sécurité peut atteindre les instances.

Utiliser une stratégie de sécurité Cloud Armor avec des pare-feu d'entrée pour restreindre l'accès (cliquez pour agrandir)

Le schéma précédent illustre la configuration de déploiement suivante :

Créez deux groupes d'instances, un dans la région us-west1 et l'autre dans la région europe-west1.
Déployez des instances d'application backend sur les VM dans les groupes d'instances.
Créez un équilibreur de charge d'application externe mondial ou un équilibreur de charge d'application classique en Niveau Premium. Configurez un mappage d'URL et un service de backend unique dont les backends sont les deux groupes d'instances que vous avez créés à l'étape précédente. La règle de transfert de l'équilibreur de charge doit utiliser l'adresse IP externe 120.1.1.1.
Configurez une stratégie de sécurité Cloud Armor qui autorise le trafic provenant des plages CIDR 100.1.1.0/24 et 100.1.2.0/24 et refuse tout autre trafic.
Associez cette stratégie au service de backend de l'équilibreur de charge. Pour obtenir des instructions, consultez Configurer des stratégies de sécurité Cloud Armor. Les équilibreurs de charge HTTP(S) externes avec des mappages d'URL plus complexes peuvent référencer plusieurs services de backend. Vous pouvez associer la stratégie de sécurité à un ou plusieurs des services de backend, si nécessaire.
Configurez des règles de pare-feu autorisant le trafic entrant pour accepter le trafic provenant de l'équilibreur de charge d'application externe mondial ou de l'équilibreur de charge d'application classique. Pour plus d'informations, consultez la section Règles de pare-feu.

Cloud Armor avec des équilibreurs de charge d'application externes et IAP

Identity-Aware Proxy (IAP) vérifie l'identité d'un utilisateur, puis détermine si cet utilisateur peut accéder à une application. Pour activer IAP pour l'équilibreur de charge d'application externe mondial ou l'équilibreur de charge d'application classique, utilisez les services de backend de l'équilibreur de charge. De même, les stratégies de sécurité périphériques Cloud Armor sont associées aux services de backend d'un équilibreur de charge d'application externe mondial ou d'un équilibreur de charge d'application classique.

Si les stratégies de sécurité Cloud Armor et IAP sont toutes deux activées pour un service de backend, l'ordre de leur évaluation dépend du type d'équilibreur de charge :

Pour un service de backend d'un équilibreur de charge d'application externe mondial, l'évaluation Cloud Armor intervient en premier. Si Cloud Armor bloque une requête, IAP ne l'évalue pas. Si Cloud Armor autorise une requête, IAP l'évalue. La requête est bloquée si IAP ne l'authentifie pas.
Pour un service de backend d'un équilibreur de charge d'application classique, l'évaluation IAP intervient en premier. Si IAP authentifie une requête, Cloud Armor l'évalue. Si une requête échoue à l'authentification IAP, Cloud Armor ne l'évalue pas.

Utiliser les listes d'autorisation et de blocage d'adresses IP avec IAP (cliquez pour agrandir).

Pour plus d'informations sur IAP et les configurations associées, consultez la documentation Identity-Aware Proxy.

Cloud Armor avec des déploiements hybrides

Dans un déploiement hybride, un équilibreur de charge d'application externe mondial ou un équilibreur de charge d'application classique doit avoir accès à une application ou à une source de contenu qui s'exécute en dehors de Google Cloud, par exemple sur l'infrastructure d'un autre fournisseur de services cloud. Vous pouvez utiliser Cloud Armor pour protéger ce type de déploiements.

Dans le schéma suivant, l'équilibreur de charge comporte deux services de backend. L'un dispose d'un groupe d'instances comme backend. L'autre service de backend dispose d'un NEG Internet comme backend, lequel est associé à une application qui s'exécute dans le centre de données d'un fournisseur tiers.

Lorsque vous associez une stratégie de sécurité Cloud Armor au service de backend doté d'un NEG Internet comme backend, Cloud Armor inspecte chaque requête de couche 7 qui parvient à l'équilibreur de charge d'application externe mondial ou à l'équilibreur de charge d'application classique destiné à ce service de backend.

La protection Cloud Armor pour les déploiements hybrides est soumise aux mêmes limites que celles qui s'appliquent aux NEG Internet.

Cloud Armor avec Google Kubernetes Engine (GKE)

Les sections suivantes décrivent comment Cloud Armor fonctionne avec GKE.

GKE Ingress

Après avoir configuré une règle de sécurité Cloud Armor, vous pouvez utiliser l'objet Kubernetes Ingress pour l'activer avec GKE.

Vous pouvez référencer votre stratégie de sécurité avec une ressource BackendConfig en ajoutant son nom à BackendConfig. Le fichier manifeste BackendConfig suivant spécifie une stratégie de sécurité nommée example-security-policy :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Pour en savoir plus sur les fonctionnalités d'entrée, consultez la page Configuration d'entrée.

Passerelle GKE

Après avoir configuré une stratégie de sécurité Cloud Armor, vous pouvez utiliser l'API Gateway de Kubernetes pour l'activer avec GKE.

Vous pouvez référencer votre stratégie de sécurité en ajoutant son nom à une ressource de stratégie GCPBackendPolicy. Le fichier manifeste de ressource de stratégie GCPBackendPolicy suivant spécifie une règle de sécurité de backend nommée example-security-policy :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Pour en savoir plus sur la configuration des stratégies de sécurité de backend Cloud Armor, consultez Configurer une stratégie de sécurité de backend Cloud Armor pour sécuriser vos services de backend.

Cloud Armor avec Cloud CDN

Pour protéger les serveurs d'origine CDN, utilisez Cloud Armor avec Cloud CDN. Cloud Armor protège votre serveur d'origine CDN contre les attaques d'applications, limite les dix risques les plus importants selon OWASP, et applique une stratégie de filtrage de couche 7. Deux types de stratégies de sécurité affectent le fonctionnement de Cloud Armor avec Cloud CDN : les stratégies de sécurité de périphérie et les stratégies de sécurité de backend.

Stratégies de sécurité de périphérie

Vous pouvez utiliser des stratégies de sécurité de périphérie pour les services de backend sur lesquels Cloud CDN est activé et pour les buckets backend Cloud Storage derrière l'équilibreur de charge d'application externe mondial ou l'équilibreur de charge d'application classique. Utilisez des stratégies de sécurité de périphérie pour filtrer les requêtes avant que le contenu ne soit diffusé à partir du cache.

Stratégies de sécurité de backend

Lorsque les stratégies de sécurité de backend Cloud Armor sont appliquées aux services de backend avec Cloud CDN activé, elles ne s'appliquent qu'aux requêtes acheminées vers le service de backend. Ces requêtes incluent les requêtes de contenu dynamique et les défauts de cache (miss), c'est-à-dire les requêtes qui manquent ou contournent le cache Cloud CDN.

Lorsque les stratégies de sécurité de périphérie et les stratégies de sécurité de backend sont associées au même service de backend, les stratégies de sécurité de backend ne sont appliquées que pour les requêtes de défaut de cache qui ont été autorisées par les stratégies de sécurité de périphérie.

Le schéma suivant illustre exclusivement le fonctionnement des stratégies de sécurité de backend avec les origines Cloud CDN, une fois les requêtes autorisées par les stratégies de sécurité de périphérie.

Utiliser des stratégies de sécurité de backend Google Cloud Armor avec Cloud CDN. — Utiliser des stratégies de sécurité de backend Cloud Armor avec Cloud CDN (cliquez pour agrandir)

Pour plus d'informations sur Cloud CDN, consultez la documentation Cloud CDN.

Cloud Armor avec Cloud Run, App Engine ou Cloud Run Functions

Vous pouvez utiliser les stratégies de sécurité Cloud Armor avec un backend de NEG sans serveur qui pointe vers un service Cloud Run, App Engine ou Cloud Run Functions.

Toutefois, lorsque vous utilisez Cloud Armor avec des NEG sans serveur, Cloud Run ou Cloud Run Functions, tous les accès au point de terminaison sans serveur doivent être filtrés par une stratégie de sécurité Cloud Armor.

Les utilisateurs disposant de l'URL par défaut d'une application sans serveur peuvent contourner l'équilibreur de charge et accéder directement à l'URL du service. Cela permet de contourner les stratégies de sécurité Cloud Armor. Pour résoudre ce problème, désactivez l'URL par défaut que Google Cloud attribue automatiquement aux services Cloud Run ou aux fonctions Cloud Run Functions (2e génération). Pour protéger les applications App Engine, vous pouvez utiliser des contrôles d'entrée.

Si vous utilisez des contrôles d'entrée pour appliquer vos contrôles d'accès à l'ensemble du trafic entrant, vous pouvez utiliser le paramètre d'entrée internal-and-gclb lorsque vous configurez Cloud Run Functions ou Cloud Run. Le paramètre d'entrée internal-and-gclb n'autorise que le trafic interne et le trafic envoyé à une adresse IP externe exposée par l'équilibreur de charge d'application externe mondial ou l'équilibreur de charge d'application classique. Le trafic envoyé à ces URL par défaut depuis l'extérieur de votre réseau privé est bloqué. Cela empêche les utilisateurs de contourner les contrôles d'accès (tels que les stratégies de sécurité Cloud Armor) configurés via l'équilibreur de charge d'application externe mondial ou l'équilibreur de charge d'application classique.

Pour en savoir plus sur les NEG sans serveur, consultez les pages Présentation des groupes de points de terminaison du réseau sans serveur et Configurer des NEG sans serveur.

Cloud Armor avec Cloud Service Mesh

Vous pouvez configurer des stratégies de sécurité des services internes pour votre maillage de services afin d'appliquer une limitation de débit globale côté serveur par client. Cela vous permet de partager équitablement la capacité disponible de votre service et de réduire le risque de surcharge de vos services par des clients malveillants ou au comportement inapproprié. Vous associez une stratégie de sécurité à une stratégie de point de terminaison Cloud Service Mesh pour appliquer la limitation du débit au trafic entrant côté serveur. Toutefois, vous ne pouvez pas configurer de stratégie de sécurité Google Cloud Armor si vous utilisez le routage du trafic TCP. Pour en savoir plus sur l'utilisation de Cloud Armor avec Cloud Service Mesh, consultez Configurer la limitation du débit avec Cloud Armor.