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.
Firewall-Feature
In der App Engine-Standardumgebung kann die App Engine-Firewall bestimmten internen Traffic zulassen, um die Firewall zu umgehen. Wenn Sie also die Regel default auf deny setzen, werden Anfragen von bestimmten Diensten für die App Engine-Standardumgebung nicht blockiert. Dies sind alle Arten von Traffic, die in der eigenen Konfiguration der Anwendung angefordert oder von derselben Anwendung gesendet werden. Beispiele für Anfragen, bei denen Firewallregeln auf diese Weise umgangen werden:
- Aufwärmanfragen
- Cloud Scheduler-Jobs, die App Engine HTTP verwenden (einschließlich App Engine Cron)
- App Engine-Aufgaben in Cloud Tasks (einschließlich App Engine-Aufgabenwarteschlangen)
Bei Anwendungen, die die App Engine-Standardumgebung und Dienste nutzen, die im Laufzeit der ersten Generation enthalten sind, umgehen Benachrichtigungen der Legacy Mail API auch die Firewall.
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 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 |
| Compute Engine-Instanzen ohne externe IP-Adresse, die Cloud NAT für ausgehende Verbindungen verwenden | 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.
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.
Informationen zum Ändern der Standardablaufzeit für statische Inhalte und dazu, wie verhindert werden kann, dass statische Inhalte zwischengespeichert werden, finden Sie unter Cache-Ablaufzeit.Wenn Sie verhindern möchten, dass aus dem Code Ihrer Anwendung ausgegebene dynamische Inhalte im Cache gespeichert werden, verwenden Sie die HTTP-Antwortheader Cache-Control und Expires. 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.