Eine Firewall legt fest, welcher Netzwerktraffic weitergeleitet werden muss und welcher Traffic abgelehnt wird. Firewalls können für eingehenden Traffic (ingress), ausgehenden Traffic (egress) oder für beides gelten. Bei App Engine gilt die App Engine-Firewall nur für eingehenden Traffic, der an Ihre Anwendung oder Ihren Dienst weitergeleitet wird.
Übersicht
Die App Engine-Firewall wird für alle Arten von Anfragen an Ihre Anwendung geprüft, einschließlich:
- Normaler Web-Traffic, der an die
appspot.com-Adresse oder die benutzerdefinierte Domain der Anwendung weitergeleitet wird. - Anfragen, die vom Cloud Load Balancing eingehen.
- Traffic aus internen Quellen wie Compute Engine-VMs (virtuellen Maschinen) und Cloud Tasks.
Wenn Ihre Anwendung für die Verwendung anderer Netzwerkdienste oder -produkte konfiguriert ist, müssen Sie möglicherweise Regeln zur Steuerung des eingehenden Traffics in der App Engine-Firewall und in den Firewall- oder Sicherheitseinstellungen anderer Produkte erstellen. Dieser Leitfaden behandelt das allgemeine Verhalten der App Engine-Firewall sowie Details zu diesen speziellen Anwendungsfällen.
App Engine-Firewallregeln
Sie können App Engine-Firewallregeln mit der Google Cloud Console, der Google Cloud CLI oder der Admin API konfigurieren. Geben Sie dazu Regeln an, die bestimmte IP-Bereiche zulassen oder blockieren.
Standardmäßig erhält jede Anfrage, die mit keiner Regel übereinstimmt, Zugriff auf Ihre Anwendung. Wenn Sie alle Anfragen blockieren müssen, die nicht mit einer bestimmten Regel übereinstimmen (mit Ausnahme der standardmäßig zulässigen Anfragen von internen Diensten), ändern Sie Aktion der default-Regel zu deny.
Unter bestimmten Umständen ist es in der flexiblen App Engine-Umgebung möglich, Firewallregeln auf der Ebene der Virtual Private Cloud (VPC) automatisch zu konfigurieren. Beachten Sie dabei, dass die VPC-Firewall nicht mit der App Engine-Firewall interagiert.
Eingehende Anfragen von Ihren Diensten zulassen
In der folgenden Tabelle sind die IP-Bereiche und das App Engine-Firewallverhalten für gängige Dienste aufgeführt. Der verwendete IP-Bereich hängt davon ab, ob die eingehenden Anfragen an eine Version gesendet werden, die in der App Engine-Standardumgebung oder der flexiblen Umgebung ausgeführt wird.
| Dienst | IP-Bereich für Anfragen, die an die App Engine-Standardumgebung gesendet werden | IP-Bereich für Anfragen, die an die flexible App Engine-Umgebung gesendet werden |
|---|---|---|
| App Engine-Cron | 0.1.0.1/32 oder 0.1.0.2/32 umgeht die Standard-Firewallregel, wenn sie auf „Ablehnen“ gesetzt ist. | 0.1.0.1/32 oder 0.1.0.2/32 |
| Compute Engine-Instanzen, die Cloud NAT für ausgehende Verbindungen verwenden | Konfigurierte Cloud NAT-IP-Adresse(n) | Konfigurierte Cloud NAT-IP-Adresse(n) |
| Compute Engine-Instanzen mit externen IP-Adressen | Externe IP-Adresse der Instanz | Externe IP-Adresse der Instanz |
| Compute Engine-Instanzen ohne externe IP-Adresse | 0.0.0.0/32 | 0.0.0.0/32 |
| Cloud Scheduler-Jobs, die App Engine-HTTP- und App Engine-Aufgaben in Cloud Tasks verwenden (einschließlich App Engine-Aufgabenwarteschlangen) | 0.1.0.2/32, umgeht die Standard-Firewallregel, wenn auf „deny” festgelegt | 0.1.0.2/32 |
| Cloud Storage oder Blobstore | 0.1.0.30/32 | Nicht zutreffend |
| URL-Abruf | 0.1.0.40/32 | 0.1.0.40/32 |
| Aufwärmanfragen | 0.1.0.3/32, umgeht die Standard-Firewallregel, wenn auf „deny” festgelegt | Nicht zutreffend |
Abhängig von Ihrem Anwendungsfall können diese zusätzlichen Anweisungen bei der Konfiguration der App Engine-Firewallregeln gelten:
- Anfragen von neu erstellten oder aktualisierten App Engine-Cronjobs, die entweder an die standardmäßige oder flexible Umgebung von App Engine gesendet werden, stammen von
0.1.0.2. Bei Cronjobs, die mit älteren gcloud-Versionen (vor Version 326.0.0) erstellt wurden, stammen Cron-Anfragen von0.1.0.1. Weitere Informationen zum Ermitteln von Anfragen vom App Engine-Cron-Dienst finden Sie unter Cron-Anfragen validieren. - Wenn Ihre Anwendung mit Cloud Load Balancing interagiert oder mit einem VPC-Netzwerk verbunden ist, lesen Sie den Abschnitt Interaktion mit anderen Produkten oder Diensten weiter unten.
Beispiel für eine App Engine-Standardumgebung
Ihre Anwendung, die in der Standardumgebung ausgeführt wird, hat zwei Dienste: frontend_service und backend_service. frontend_service verwendet Cloud Tasks mit App Engine HTTP, um Nachrichten an backend_service zu senden. Da die Firewallregel default Cloud Tasks-Anfragen zulässt, auch wenn deny konfiguriert ist, müssen Sie keine Firewallregel für Cloud Tasks erstellen.
Wenn Sie jedoch den Zugriff auf Ihre Anwendung einschränken und Cloud Tasks-Anfragen explizit blockieren möchten, erstellen Sie eine deny-Firewallregel für den IP-Bereich 0.1.0.2/32.
Beispiel für flexible App Engine-Umgebung
Ihre Anwendung, die in der flexiblen Umgebung ausgeführt wird, hat zwei Dienste: frontend_service und backend_service und eine Firewall, die standardmäßig den Traffic ablehnt. frontend_service verwendet Cloud Tasks mit App Engine HTTP, um Nachrichten an backend_service zu senden. Da die Firewallregel default Cloud Tasks-Anfragen ablehnt, müssen Sie eine allow-Firewallregel für 0.1.0.2/32 erstellen.
Interaktion mit anderen Produkten oder Diensten
Cloud Load Balancing
Wenn Sie Cloud Load Balancing und serverlose NEGs verwenden, beachten Sie Folgendes:
- Der Load-Balancer hat keine Auswirkungen auf App Engine-Firewallregeln und interagiert nicht mit diesen. Die App Engine-Regeln werden erst ausgewertet, wenn eine serverlose NEG den Traffic an App Engine weiterleitet.
Wir empfehlen die Verwendung von Steuerelementen für eingehenden Traffic, damit Ihre Anwendung nur Anfragen empfängt, die vom Load-Balancer (und ggf. von der VPC) gesendet werden. Andernfalls können Nutzer die App Engine-URL Ihrer Anwendung verwenden, um den Load-Balancer, die Google Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und private Schlüssel zu umgehen, die über den Load-Balancer weitergegeben werden.
Wenn Ihre Steuerelemente für eingehenden Traffic so eingestellt sind, dass sie
internal-and-cloud-load-balancing-Traffic empfangen, übernehmen Sie die standardmäßige App Engine-Firewallregel (allow) und verwenden Sie die Web Application Firewall (WAF) von Google Cloud Armor.
VPC-Firewallregeln
App Engine-Firewalls werden unabhängig von VPC-basierten Firewalls konfiguriert und erzwungen. VPC-Firewallregeln gelten für Ressourcen, die im VPC-Netzwerk ausgeführt werden, z. B. virtuelle Compute Engine-Maschinen, während App Engine-Firewallregeln für eingehende Anfragen an Ihre Anwendung oder Ihren Dienst gelten.
Wenn in Ihrer Netzwerkumgebung VPC-basierte Firewallregeln (wie VPC-Firewallregeln oder hierarchische Firewallrichtlinien) konfiguriert sind, muss von beiden, also von den Firewalls auf VPC-Ebene und von den App Engine-Firewalls, der IP-Bereich einer eingehenden Anfrage zugelassen werden, damit die App Engine-Anwendung sie empfangen kann.
Bei Firewalls auf VPC-Ebene werden hierarchische Firewallrichtlinien vor den VPC-Firewallregeln ausgewertet und durchlaufen während der VPC-Firewallauswertung eine Sequenz. Anfragen, die von der Firewall auf VPC-Ebene und der App Engine-Firewall zugelassen sind, werden von Ihrer App Engine-Anwendung oder ihrem App Engine-Dienst empfangen. Wenn die VPC-Firewall Anfragen aus demselben IP-Bereich ablehnt, der von der App Engine-Firewall zugelassen wird, wird Ihrer App Engine-Anwendung kein Zugriff gewährt.
Shared VPC
In der flexiblen App Engine-Umgebung können eine oder mehrere Firewalls erstellt werden, je nachdem, ob Ihre Anwendung für die Verwendung eines VPC-Netzwerks über freigegebene VPC konfiguriert ist.
Wenn Ihre flexible App Engine-Anwendung freigegebene VPC verwendet, werden von der flexiblen App Engine-Umgebung nicht automatisch Firewallregeln erstellt. Wenn Sie den Zugriff steuern und den Traffic im VPC-Netzwerk zulassen müssen, können Sie Firewallregeln im freigegebenen VPC-Netzwerk erstellen.
Außerdem müssen Sie in der VPC-Firewall und in der App Engine-Firewall denselben IP-Bereich zulassen, um Anfragen von einer Trafficquelle zuzulassen. Wenn der IP-Bereich nicht an beiden Orten (VPC-Firewall und App Engine-Firewall) angegeben ist, darf dieser IP-Bereich nicht auf Ihre App Engine-Anwendung oder Ihren App Engine-Dienst zugreifen.
Wenn Ihre Anwendung in der flexiblen App Engine-Umgebung nicht für die Verwendung von freigegebenen VPC konfiguriert ist, erstellt die flexible App Engine-Umgebung bis zu zwei verborgene VPC-Firewallregeln, je nachdem, ob Ihre Anwendung geteilte Systemdiagnosen (Standard) oder Legacy-Systemdiagnosen verwendet. Diese verborgenen Firewallregeln erlauben, dass Traffic und Systemdiagnose-Traffic in der flexiblen Umgebung weitergeleitet werden:
- Netzwerkname: Das in
app.yamlangegebene Netzwerk oder das Standardnetzwerk, wenn kein Netzwerk konfiguriert ist. - Ziel-Tag: Die in der Datei
app.yamlangegebeneninstance_tags. Wenn keine Ziel-Tags angegeben sind, generiert die flexible App Engine-Umgebung standardmäßig ein eindeutiges Tag im Formataef-INSTANCE_ID. Dieses Tag betrifft nur die Instanzen in dieser flexiblen Version und die Firewallregel wird auf dieses Tag ausgerichtet. - Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Quell-IP-Bereiche:
35.191.0.0/16und130.211.0.0/22 - Protokolle und Ports:
- TCP:
8443(für Legacy-Systemdiagnosen) oder10402(für geteilte Systemdiagnosen)
- TCP:
- Priorität:
1000
Zugriff auf Inhalte im Cache verhindern
Die App Engine-Firewall ist Mechanismen nachgeschaltet, die Inhalte im Cache speichern, z. B. Webproxys und Browser. Inhalte, die im Cache gespeichert sind, werden von der entsprechenden URL öffentlich bereitgestellt, bis sie ablaufen. Auf diese Inhalte kann selbst dann zugegriffen werden, wenn inzwischen neue Firewallregeln erstellt wurden.
Wenn Sie verhindern möchten, dass Inhalte im Cache gespeichert werden, können Sie die HTTP-Antwortheader Cache-Control und Expires verwenden. Weitere Informationen zu diesen HTTP-Headern und dazu, wie Sie das Caching steuern, finden Sie unter Caching vermeiden.
Nächste Schritte
Folgen Sie der Anleitung unter Firewalls erstellen, um zu lernen, wie Sie App Engine-Firewallregeln konfigurieren.