In andere Google-Produkte integrieren

Zum Schutz Ihrer Dienste und Anwendungen vor DoS-Angriffen (Denial of Service) und Webangriffen können Sie Google Cloud Armor in andere Google Cloud Produkte einbinden. In diesem Dokument wird erläutert, wie Cloud Armor mit VPC-Firewallregeln, Identity-Aware Proxy (IAP), Google Kubernetes Engine (GKE), Cloud CDN und Global Front End interagiert.

Cloud Armor und VPC-Firewallregeln

Cloud Armor-Sicherheitsrichtlinien und VPC-Firewall regeln haben unterschiedliche Funktionen:

Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie nur Traffic aus dem CIDR-Bereich 100.1.1.0/24 und dem CIDR-Bereich 100.1.2.0/24 für den Zugriff auf Ihren globalen externen Application Load Balancer oder klassischen Application Load Balancer zulassen möchten. Es muss verhindert werden, dass der Traffic die Backend-Instanzen mit Load-Balancing direkt erreicht. Mit anderen Worten: Nur externer Traffic, der über den globalen externen Application Load Balancer oder den klassischen Application Load Balancer mit einer zugehörigen Sicherheitsrichtlinie geleitet wird, kann die Instanzen erreichen.

Cloud Armor-Sicherheitsrichtlinien mit Firewalls für eingehenden Traffic verwenden, um den Zugriff einzuschränken
Cloud Armor-Sicherheitsrichtlinien mit Firewalls für eingehenden Traffic verwenden, um den Zugriff einzuschränken (zum Vergrößern klicken).

Das vorherige Diagramm zeigt die folgende Bereitstellungskonfiguration:

  1. Erstellen Sie zwei Instanzgruppen, eine in der Region us-west1 und eine andere in der Region europe-west1.
  2. Stellen Sie Back-End-Anwendungsinstanzen auf den VMs in den Instanzgruppen bereit.
  3. Erstellen Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer in der Premium-Stufe. Konfigurieren Sie eine URL-Zuordnung und einen einzelnen Back-End-Dienst, dessen Back-Ends die beiden Instanzgruppen sind, die Sie im vorherigen Schritt erstellt haben. Die Weiterleitungsregel des Load-Balancers muss die externe IP-Adresse 120.1.1.1 verwenden.
  4. Konfigurieren Sie eine Cloud Armor-Sicherheitsrichtlinie, die Traffic von 100.1.1.0/24 und 100.1.2.0/24 zulässt und den gesamten anderen Traffic ablehnt.
  5. Verknüpfen Sie diese Richtlinie mit dem Back-End-Dienst des Load-Balancers. Eine Anleitung finden Sie unter Cloud Armor-Sicherheitsrichtlinien konfigurieren. Externe HTTP(S)-Load-Balancer mit komplexeren URL-Zuordnungen können auf mehrere Back-End-Dienste verweisen. Sie können die Sicherheitsrichtlinie bei Bedarf mit einem oder mehreren der Back-End-Dienste verknüpfen.
  6. Konfigurieren Sie Firewallregeln zum Zulassen von eingehendem Traffic, um den Traffic vom globalen externen Application Load Balancer oder vom klassischen Application Load Balancer zuzulassen. Weitere Informationen finden Sie unter siehe Firewallregeln.

Cloud Armor mit externen Application Load Balancern und IAP

IAP überprüft die Identität eines Nutzers und bestimmt dann, ob dieser Nutzer auf eine Anwendung zugreifen kann. Um IAP für den globalen externen Application Load Balancer oder den klassischen Application Load Balancer zu aktivieren, verwenden Sie die Back-End-Dienste des Load-Balancers. In ähnlicher Weise werden Edge-Cloud Armor-Sicherheitsrichtlinien an die Back-End-Dienste eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers angehängt.

Wenn Cloud Armor-Sicherheitsrichtlinien und IAP für einen Back-End-Dienst aktiviert sind, hängt die Reihenfolge ihrer Auswertung vom Typ des Load-Balancers ab:

  • Bei einem Backend-Dienst eines globalen externen Application Load Balancers erfolgt die Cloud Armor-Auswertung zuerst. Wenn Cloud Armor eine Anfrage blockiert, wertet IAP die Anfrage nicht aus. Wenn Cloud Armor eine Anfrage zulässt, wertet IAP diese Anfrage aus. Die Anfrage wird blockiert, wenn IAP die Anfrage nicht authentifiziert.

  • Bei einem Backend-Dienst eines klassischen Application Load Balancers erfolgt die IAP-Auswertung zuerst. Wenn IAP eine Anfrage authentifiziert, wertet Cloud Armor die Anfrage aus. Wenn eine Anfrage die IAP-Authentifizierung nicht besteht, wertet Cloud Armor die Anfrage nicht aus.

Sperrlisten und Zulassungslisten für IP-Adressen mit IAP verwenden.
Sperrlisten und Zulassungslisten für IP-Adressen mit IAP verwenden (zum Vergrößern klicken).

Weitere Informationen zu IAP und zu den zugehörigen Konfigurationen finden Sie unter der Dokumentation zum Identity-Aware Proxy.

Cloud Armor mit Hybridbereitstellungen

Bei einer Hybridbereitstellung benötigt ein globaler externer Application Load Balancer oder ein klassischer Application Load Balancer Zugriff auf eine Anwendung oder Inhaltsquelle, die außerhalb ausgeführt wird Google Cloud– z. B. in der Infrastruktur eines anderen Cloud-Anbieters. Zum Schutz solcher Bereitstellungen können Sie Cloud Armor verwenden.

In der folgenden Abbildung verfügt der Load-Balancer über zwei Back-End-Dienste. Einer hat eine Instanzgruppe als Back-End. Der andere Back-End-Dienst hat eine Internet-NEG als Back-End. Die Internet-NEG ist einer Anwendung zugeordnet, die im Rechenzentrum eines Drittanbieters ausgeführt wird.

Cloud Armor für Hybridbereitstellungen
Cloud Armor für Hybridbereitstellungen (zum Vergrößern klicken).

Wenn Sie eine Cloud Armor-Sicherheitsrichtlinie an den Backend-Dienst anhängen, der eine Internet-NEG als Backend hat, überprüft Cloud Armor jede Layer 7-Anfrage, die beim globalen externen Application Load Balancer oder klassischen Application Load Balancer eingeht und für diesen Backend-Dienst bestimmt ist.

Der Cloud Armor-Schutz für Hybridbereitstellungen unterliegt denselben Einschränkungen wie Internet-NEGs.

Cloud Armor mit GKE

In den folgenden Abschnitten wird beschrieben, wie Cloud Armor mit GKE funktioniert.

GKE Ingress

Nachdem Sie eine Cloud Armor-Sicherheitsrichtlinie konfiguriert haben, können Sie sie mit Kubernetes Ingress und GKE aktivieren.

Sie können mit einer BackendConfig-Ressource auf die Sicherheitsrichtlinie verweisen, indem Sie den Namen Ihrer Sicherheitsrichtlinie zur BackendConfig hinzufügen. Das folgende BackendConfig-Manifest gibt eine Sicherheitsrichtlinie mit dem Namen example-security-policy an:

apiVersion: