Cette page a été traduite par l'API Cloud Translation.

Intégrer Google Cloud Armor à d'autres produits Google

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

Règles de pare-feu VPC et Google Cloud Armor

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

Les stratégies de sécurité Google 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 des VM de backend à équilibrage de charge, et dont les sources sont Plages d'adresses IP utilisées par les équilibreurs de charge d'application externes globaux ou classiques. Ces règles autorisent les GFE et les systèmes de vérification de l'état à communiquer avec vos VM de backend.

Prenons l'exemple d'un scénario dans lequel vous souhaitez autoriser uniquement le trafic provenant plage CIDR 100.1.1.0/24 et plage CIDR 100.1.2.0/24 pour accéder à vos un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique. Votre objectif est de vous assurer que le trafic ne peut pas atteindre directement les instances backend à équilibrage de charge. Dans d'autres uniquement le trafic externe transmis par proxy via l'équilibreur de charge d'application externe global un équilibreur de charge d'application classique avec une stratégie de sécurité associée doit atteindre Compute Engine.

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

Dans l'illustration précédente, vous atteignez vos objectifs de sécurité en configurant votre déploiement Google Cloud comme suit :

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éer un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique dans Premium à un niveau. Configurez un mappage d'URL simple 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. Assurez-vous que la règle de transfert de l'équilibreur de charge utilise l'adresse IP externe 120.1.1.1.
Configurez une stratégie de sécurité Google 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 la page Configurer des stratégies de sécurité. 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 un équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique. Pour plus d'informations, consultez la section Règles de pare-feu.

Google 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 doit être autorisé à accéder à une application. À activer IAP pour l'équilibreur de charge d'application externe global d'un équilibreur de charge d'application classique, vous l'activez services de backend de l'équilibreur de charge. De même, Google Cloud Armor de périphérie des stratégies de sécurité sont associées aux services de backend un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique.

Si les stratégies de sécurité Google Cloud Armor et IAP activée pour un service de backend, l'ordre de leur évaluation dépend de l'équilibreur de charge:

Pour un service de backend d'un équilibreur de charge d'application externe global, Google Cloud Armor l'évaluation se fait en premier. Si Google Cloud Armor bloque une requête, IAP n'évalue pas la requête. Si Google Cloud Armor autorise une requête, IAP évalue ensuite la requête. La requête est bloquée si IAP le fait ne pas authentifier la requête.
Pour le service de backend d'un équilibreur de charge d'application classique, L'évaluation IAP a lieu en premier. Si IAP authentifie une requête, puis Google Cloud Armor évalue la requête. Si une requête échoue à l'authentification IAP, Google Cloud Armor n'évalue pas la requête.

Utiliser les listes d'autorisation et de blocage d'adresses IP avec IAP. — Utiliser des listes de blocage et des listes d'autorisation 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.

Google Cloud Armor avec des déploiements hybrides

Dans un déploiement hybride, un équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique a besoin d'accéder à une application source de contenu s'exécutant en dehors de Google Cloud, par exemple dans une autre l'infrastructure du fournisseur de services cloud. Vous pouvez utiliser Google 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é Google Cloud Armor au backend disposant d'un NEG Internet comme backend, Google Cloud Armor inspecte chaque requête L7 arrivant sur l'équilibreur de charge d'application externe global ; un équilibreur de charge d'application classique destiné à ce service de backend.

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

Google Cloud Armor avec l'objet Entrée de Google Kubernetes Engine (GKE)

Après avoir configuré une stratégie de sécurité Google Cloud Armor, vous pouvez utiliser 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 règle 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 section Configurer les fonctionnalités d'entrée.

Google Cloud Armor avec Cloud CDN

Pour protéger les serveurs d'origine CDN, vous pouvez utiliser Google Cloud Armor avec Cloud CDN. Google 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 règles de sécurité affectent le fonctionnement de Google Cloud Armor avec Cloud CDN : les règles de sécurité périphérique et les règles de sécurité de backend.

Stratégies de sécurité Edge

Vous pouvez utiliser des stratégies de sécurité périphérique pour les services de backend compatibles avec Cloud CDN et aux buckets backend Cloud Storage situés derrière l'équilibreur de charge d'application externe global ou un équilibreur de charge d'application classique. Utilisez des règles de sécurité périphérique pour filtrer les requêtes avant que le contenu ne soit diffusé à partir du cache.

Règles de sécurité de backend

Lorsque les règles de sécurité de backend Google 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 dynamiques et les défauts de cache (miss), c'est-à-dire les requêtes qui manquent ou contournent le cache Cloud CDN.

Lorsque des stratégies de sécurité de périphérie et de sécurité de backend sont associées au même service de backend, les règles de sécurité du backend ne s'appliquent qu'en cas de défaut de cache (miss) Requêtes ayant transmis des stratégies de sécurité périphériques

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 règles de sécurité périphérique.

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

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

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

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

Toutefois, lorsque vous utilisez Google Cloud Armor avec des NEG sans serveur, Cloud Run, ou Cloud Functions, vous devez prendre des pour s'assurer que tous les accès au point de terminaison sans serveur sont filtrés à l'aide d'un Stratégie de sécurité Google Cloud Armor.

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

Si vous utilisez des contrôles d'entrée pour vous assurer que vos contrôles d'accès sont appliqués à l'ensemble du trafic entrant, vous pouvez utilisez internal-and-gclb lorsque vous configurez Cloud Functions ou Cloud Run ; Cela permet uniquement le trafic interne et le trafic envoyé à une adresse IP externe exposée par un équilibreur de charge d'application externe global ou l'équilibreur de charge d'application classique. Trafic généré par les messages envoyés à ces URL par défaut en dehors de votre réseau privé sont bloqués. Cela empêche les utilisateurs de contourner des contrôles d'accès (tels que les stratégies de sécurité Google Cloud Armor) configurés via l'équilibreur de charge d'application externe global ou 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.