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) und Cloud CDN interagiert.
Cloud Armor und VPC-Firewallregeln
Cloud Armor-Sicherheitsrichtlinien und VPC-Firewall regeln haben unterschiedliche Funktionen:
- Cloud Armor-Sicherheitsrichtlinien bieten Edge-Sicherheit und reagieren auf Clienttraffic zu Google Front Ends (GFEs).
- VPC-Firewallregeln lassen Traffic zu und von Ihren Back-Ends zu oder lehnen ihn ab. Sie müssen Firewallregeln zum Zulassen von eingehendem Traffic erstellen, deren Ziele die Backend-VMs mit Load-Balancing sind und deren Quellen IP-Bereiche sind, die von globalen externen Application Load Balancern oder klassischen Application Load Balancern verwendet werden. Diese Regeln ermöglichen es GFEs und den Systemdiagnosesystemen, mit Ihren Back-End-VMs zu kommunizieren.
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.
Das vorherige Diagramm zeigt die folgende Bereitstellungskonfiguration:
- Erstellen Sie zwei Instanzgruppen, eine in der Region
us-west1und eine andere in der Regioneurope-west1. - Stellen Sie Back-End-Anwendungsinstanzen auf den VMs in den Instanzgruppen bereit.
- 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.1verwenden. - 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.
- 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.
- 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. Wenn Sie IAP für den globalen externen Application Load Balancer oder den klassischen Application Load Balancer aktivieren möchten, 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 Back-End-Dienst eines globalen externen Application Load Balancers erfolgt zuerst die Cloud Armor-Auswertung. 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 zuerst die IAP-Auswertung. 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.
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. Sie können Cloud Armor verwenden, um solche Bereitstellungen zu schützen.
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.
Wenn Sie eine Cloud Armor-Sicherheitsrichtlinie an den Back-End-Dienst anhängen, der eine Internet-NEG als Back-End 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 Back-End-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: cloud.google.com/v1
kind: BackendConfig
metadata:
namespace: cloud-armor-how-to
name: my-backendconfig
spec:
securityPolicy:
name: "example-security-policy"
Weitere Informationen zu Ingress-Features finden Sie unter Ingress-Konfiguration.
GKE-Gateway
Nachdem Sie eine Cloud Armor-Sicherheitsrichtlinie konfiguriert haben, können Sie sie mit der Kubernetes Gateway API und GKE aktivieren.
Sie können auf die Sicherheitsrichtlinie verweisen, indem Sie den Namen der Sicherheitsrichtlinie zu einer GCPBackendPolicy-Richtlinienressource hinzufügen. Das folgende GCPBackendPolicy-Richtlinienressourcenmanifest gibt eine Back-End-Sicherheitsrichtlinie mit dem Namen example-security-policy an:
Dienst
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
Multi-Cluster-Dienst
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
Weitere Informationen zum Konfigurieren von Cloud Armor-Back-End-Sicherheitsrichtlinien finden Sie unter Cloud Armor-Back-End-Sicherheitsrichtlinie konfigurieren, um Ihre Back-End-Dienste zu schützen.
Cloud Armor mit Cloud CDN
Zum Schutz der CDN-Ursprungsserver können Sie Cloud Armor mit Cloud CDN verwenden. Cloud Armor schützt Ihren CDN-Ursprungsserver vor Anwendungsangriffen, verringert die OWASP-Top-10-Risiken und erzwingt Filterrichtlinien für Ebene 7. Es gibt zwei Arten von Sicherheitsrichtlinien, die sich auf die Funktionsweise von Cloud Armor mit Cloud CDN auswirken: Edge-Sicherheitsrichtlinien und Back-End-Sicherheitsrichtlinien.
Edge-Sicherheitsrichtlinien
Sie können Edge-Sicherheitsrichtlinien für Cloud CDN-fähige Back-End-Dienste und Cloud Storage-Back-End-Buckets hinter dem globalen externen Application Load Balancer oder dem klassischen Application Load Balancer verwenden. Verwenden Sie Edge-Sicherheitsrichtlinien, um Anfragen zu filtern, bevor Inhalte aus dem Cache bereitgestellt werden.
Back-End-Sicherheitsrichtlinien
Wenn die Back-End-Sicherheitsrichtlinien von Cloud Armor auf Back-End-Dienste mit aktiviertem Cloud CDN angewendet werden, gelten sie nur für Anfragen, die an den Back-End-Dienst weitergeleitet werden. Diese Anfragen umfassen Anfragen für dynamische Inhalte und Cache-Fehler, also Anfragen, die den Cloud CDN-Cache übersehen oder umgehen.
Wenn Edge-Sicherheitsrichtlinien und Back-End-Sicherheitsrichtlinien an denselben Back-End-Dienst angehängt sind, werden Back-End-Sicherheitsrichtlinien nur für Cache-Fehleranfragen erzwungen, die Edge-Sicherheitsrichtlinien bestanden haben.
Das folgende Diagramm zeigt ausschließlich, wie Back-End-Sicherheitsrichtlinien mit Cloud CDN-Ursprüngen funktionieren, nachdem die Anfragen von den Edge-Sicherheitsrichtlinien zugelassen wurden.
Weitere Informationen zu Cloud CDN finden Sie in der Cloud CDN-Dokumentation.
Cloud Armor mit Cloud Run, App Engine oder Cloud Run Functions
Sie können Cloud Armor-Sicherheitsrichtlinien mit einem serverlosen NEG-Back-End verwenden, das auf einen Cloud Run, App Engine oder Cloud Run Functions Dienst verweist.
Wenn Sie Cloud Armor jedoch mit serverlosen NEGs, Cloud Run oder Cloud Run Functions verwenden, muss der gesamte Zugriff auf den serverlosen Endpunkt über eine Cloud Armor-Sicherheitsrichtlinie gefiltert werden.
Nutzer mit der Standard-URL für eine serverlose Anwendung können den Load-Balancer umgehen und direkt die Dienst-URL aufrufen. Dadurch werden die Cloud Armor-Sicherheitsrichtlinien umgangen. Deaktivieren Sie die Standard-URL, die automatisch Cloud Run-Diensten oder Cloud Run Functions (2. Generation) zugewiesen wird, um dieses Problem zu beheben. Google Cloud Zum Schutz von App Engine Anwendungen können Sie Ingress-Steuerungen verwenden.
Wenn Sie Ingress-Steuerungen verwenden, um Ihre Zugriffssteuerungen auf den gesamten eingehenden
Traffic anzuwenden, können Sie die internal-and-gclb Ingress-Einstellung verwenden, wenn Sie
Cloud Run Functions
oder Cloud Run konfigurieren.
Die Ingress-Einstellung internal-and-gclb lässt nur internen Traffic und Traffic zu, der an eine externe IP-Adresse gesendet wird, die vom globalen externen Application Load Balancer oder vom klassischen Application Load Balancer bereitgestellt wird. Traffic, der an diese Standard-URLs von außerhalb Ihres privaten Netzwerks gesendet wird, wird blockiert.
Dadurch wird verhindert, dass Nutzer Zugriffssteuerungen (z. B. Cloud Armor-Sicherheitsrichtlinien) umgehen, die über den globalen externen Application Load Balancer oder den klassischen Application Load Balancer eingerichtet wurden.
Weitere Informationen zu serverlosen NEGs finden Sie unter Übersicht über serverlose Netzwerk-Endpunktgruppen und Serverlose NEGs einrichten.
Cloud Armor mit Cloud Service Mesh
Sie können Sicherheitsrichtlinien für interne Dienste für Ihr Service Mesh konfigurieren, um die globale serverseitige Ratenbegrenzung pro Client zu erzwingen. So können Sie die verfügbare Kapazität Ihres Dienstes fair aufteilen und das Risiko verringern, dass böswillige oder fehlerhafte Clients Ihre Dienste überlasten. Sie hängen eine Sicherheitsrichtlinie an eine Cloud Service Mesh-Endpunktrichtlinie an, um die Ratenbegrenzung für eingehenden Traffic serverseitig zu erzwingen. Wenn Sie TCP-Traffic-Routing verwenden, können Sie jedoch keine Cloud Armor-Sicherheitsrichtlinie konfigurieren. Weitere Informationen zur Verwendung von Cloud Armor mit Cloud Service Mesh finden Sie unter Ratenbegrenzung mit Cloud Armor konfigurieren.
Nächste Schritte
- Sicherheitsrichtlinien, Regeln und Ausdrücke konfigurieren
- Informationen zu den Funktionen in den Google Cloud Armor Enterprise-Stufen
- Fehlerbehebung