Eine Firewall bestimmt, welcher Netzwerktraffic weitergeleitet werden muss und welcher Traffic abgelehnt wird. In App Engine können Sie eine Firewall mit bis zu 1.000 priorisierten einzelnen Regeln erstellen, die entweder einen Bereich von IP-Adressen und Subnetzen zulassen oder einschränken. Ihre Anwendung antwortet nur auf Anfragen, die von der Firewall zugelassen werden.
Hinweis
Zur Erstellung von App Engine-Firewallregeln für Ihre Anwendung benötigen Sie eine der folgenden App Engine-IAM-Rollen mit den erforderlichen Berechtigungen zum Erstellen oder Ändern von Firewallregeln:
- App Engine Admin
- Bearbeiter
- Inhaber
Firewallregeln erstellen
Verwenden Sie eine der folgenden Methoden, um eine Firewallregel zu erstellen. Wiederholen Sie diese Schritte für jede weitere Regel:
Auf der Seite "Firewallregeln" in der Cloud Console können Sie eine Firewallregel erstellen:
-
Rufen Sie in Cloud Console die Seite "Firewallregel erstellen“ auf:
-
Geben Sie die Details der Firewallregel an:
- Unter Priorität geben Sie eine Ganzzahl ein, um die relative Wichtigkeit der Regel anzugeben und die Reihenfolge festzulegen, in der die Regel ausgewertet wird.
Gültige Werte sind
1
bis2147483646
. Die Regel mit der Priorität1
wird als erste ausgewertet. Die Regel mit der Priorität2147483647
wird als letzte ausgewertet. Dieser Prioritätswert ist für die Standardregel "default" reserviert. -
Geben Sie unter Aktion bei Übereinstimmung an, ob der Zugriff für Anfragen, die der Regel entsprechen, zugelassen oder abgelehnt wird. Regeln mit dem Wert
allow
leiten die Anfrage an die Anwendung weiter. Regeln mit dem Wertdeny
antworten auf Anfragen mit der Fehlermeldung403 Forbidden
. - Definieren Sie unter IP-Bereich den Bereich der IP-Adressen, für die die Regel gelten soll. Der IP-Adressbereich muss in CIDR-Notation definiert sein, darf Subnetzmasken enthalten und unterstützt sowohl IPv4 als auch IPv6.
- Optional: Geben Sie unter Beschreibung eine Beschreibung für die Regel ein, die nicht mehr als 100 Zeichen enthalten darf.
- Unter Priorität geben Sie eine Ganzzahl ein, um die relative Wichtigkeit der Regel anzugeben und die Reihenfolge festzulegen, in der die Regel ausgewertet wird.
- Klicken Sie auf Speichern, um die Regel zu erstellen.
- Testen Sie die Regel, um festzustellen, dass die Priorität und die Aktion zum gewünschten Verhalten führen:
- Klicken Sie auf IP-Adresse testen.
- Geben Sie die IP-Adresse ein, die Sie prüfen möchten, und klicken Sie dann auf Testen, um festzustellen, ob die entsprechende Regel korrekt ausgewertet wird.
Mit den folgenden Befehlen vom Typ gcloud
app firewall-rules
können Sie eine Firewallregel erstellen:
-
Mit diesem Befehl können Sie eine Firewallregel erstellen:
gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
Dabei gilt:-
PRIORITY ist eine Ganzzahl im Bereich von
1
bis2147483646
. Dieser Wert definiert die Wichtigkeit der Regel und legt die Reihenfolge der Regelauswertung fest. Die Regel mit der Priorität1
wird als erste ausgewertet. Die Regel mit der Priorität2147483647
wird als letzte ausgewertet. Dieser Prioritätswert ist für die Standardregel "default" reserviert. -
ALLOW_OR_DENY gibt an, ob der Zugriff für Anfragen, die der Regel entsprechen, zugelassen oder verweigert wird. Gültige Werte sind
allow
unddeny
. Regeln mit dem Wertallow
leiten die Anfrage an die Anwendung weiter. Regeln mit dem Wertdeny
antworten auf Anfragen mit der Fehlermeldung403 Forbidden
. - IP_RANGE definiert den Bereich der IP-Adressen, für die die Regel gelten soll. Der IP-Adressbereich muss in CIDR-Notation definiert sein, darf Subnetzmasken enthalten und unterstützt sowohl IPv4 als auch IPv6.
- DESCRIPTION ist eine optionale Beschreibung der Regel und darf nicht mehr als 100 Zeichen enthalten.
-
PRIORITY ist eine Ganzzahl im Bereich von
- Führen Sie diesen Befehl aus, um die Regel zu testen und zu prüfen, ob die Priorität und die Aktion zum gewünschten Verhalten führen:
gcloud app firewall-rules test-ip IP_ADDRESS
IP_ADDRESS ist dabei die IP-Adresse, mit der Sie die Firewall testen möchten. - Führen Sie diesen Befehl aus, um eine Liste der bestehenden Regeln anzuzeigen:
gcloud app firewall-rules list
- Führen Sie diesen Befehl aus, um eine bestehende Regel zu löschen:
gcloud app firewall-rules delete PRIORITY
PRIORITY ist dabei der Prioritätswert der Regel, die Sie löschen möchten.
- Beispiele:
- Diese Beispiele helfen Ihnen beim Erstellen der Firewall:
-
Fügen Sie eine Regel hinzu, die einer IPv6-Adresse und einer Subnetzmaske den Zugriff erlaubt, und testen Sie diese Regel, um sicherzustellen, dass sie vor den anderen Regeln ausgewertet wird:
gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778
-
Fügen Sie eine Regel hinzu, die den Zugriff über eine IPv4-Adresse und eine Subnetzmaske verweigert, und testen Sie diese Regel, um zu prüfen, ob sie korrekt ausgewertet wird.
gcloud app firewall-rules create 123456 --source-range "74.125.0.0/16" --action deny gcloud app firewall-rules test-ip 74.125.0.8
-
Aktualisieren Sie die Standardregel und testen Sie sie, um sicherzustellen, dass der Zugriff über alle IP-Adressen verweigert wird, die nicht mit anderen Regeln übereinstimmen.
gcloud app firewall-rules update default --action deny gcloud app firewall-rules test-ip 123.456.7.89
-
Mit den Methoden apps.firewall.ingressRules
in der Admin API können Sie Firewallregeln für Ihre App Engine-Anwendung programmgesteuert erstellen.
Mit der Methode apps.firewall.ingressRules.list
können Sie eine Firewallregel testen und prüfen, ob die Priorität und die Aktion zum gewünschten Verhalten führen. Dabei geben Sie im Parameter matchingAddress
die IP-Adresse an, die getestet werden soll.
Informationen zu App Engine-Firewallregeln
Eine App Engine-Firewall besteht aus einer sortierten Liste von Regeln, die den Zugriff von der angegebenen IP-Adresse oder dem angegebenen IP-Bereich auf Ihre App zulassen oder verweigern können. Die Regel gilt für alle Ressourcen der App Engine-Anwendung.
Die Firewallregeln sind nach Wichtigkeit sortiert. Sie definieren für jede Regel die Priorität als numerischen Wert. Sie müssen für jede Regel einen eindeutigen Prioritätswert festlegen, da dieser die Wichtigkeit im Verhältnis zu den anderen Regeln in der Firewall definiert. Die Werte für die Priorität einer Regel beginnen mit 1
für die wichtigste Regel und werden immer höher bis zum Wert 2147483647
für die am wenigsten wichtige Regel.
Jede Firewall enthält eine Regel default
, die automatisch mit der Priorität 2147483647
erstellt wird und für den gesamten IP-Bereich Ihrer Anwendung gilt. Die Regel default
wird immer nach allen anderen Regeln in der Firewall ausgewertet und auf alle Anfragen von allen IP-Adressen angewendet.
Die Regel mit der höchsten Priorität wird von der Firewall zuerst ausgewertet.
Alle übrigen Regeln in der Firewall werden der Reihe nach ausgewertet, bis eine Regel dem IP-Bereich dieser Anfrage entspricht. Wird eine übereinstimmende Regel gefunden, wird die Verbindung entweder zugelassen oder abgelehnt. Die restlichen Regeln in der Firewall werden dann übersprungen. Wenn keine der manuell definierten Regeln in der Firewall der Anfrage entspricht, wird die Regel default
ausgewertet.
Wenn Sie beispielsweise eine Regel mit der Priorität 1
erstellen, wird diese immer zuerst ausgewertet. Wenn eine eingehende Anfrage der Regel mit der Priorität 1
entspricht, wird nur diese Regel ausgewertet und alle anderen Regeln in der Firewall werden übersprungen, einschließlich der Regel default
.
Die folgende Beispielfirewall zeigt, wie die Priorität einer Regel das Verhalten der Firewall ändern kann.
App Engine-Firewalls und Cloud Load Balancing
Wenn Sie Cloud Load Balancing und serverlose NEGs verwenden, beachten Sie Folgendes:
- Der Load-Balancer wirkt sich nicht auf App Engine-Firewallregeln aus 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, Google Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und private Schlüssel zu umgehen, die über den Load-Balancer weitergegeben werden.
Beispielfirewall
In diesem Beispiel hat ein Unternehmen eine Firewall eingerichtet, um dem Entwicklerteam und dem internen Unternehmensnetzwerk Zugriff auf die gerade entwickelte Anwendung zu gewähren. Bei den Firewallregeln wurden große Lücken zwischen den einzelnen Prioritäten gelassen, damit spätere Ergänzungen möglich sind.
Priorität | Aktion | IP-Bereich | Beschreibung |
---|---|---|---|
1.000 | Ablehnen | 192.0.2.1 | Verweigert einem DoS-Angreifer den Zugriff |
2.000 | Zulassen | 198.51.100.2 | Ermöglicht einem Entwickler in einer Außenstelle den Zugriff |
3.000 | Ablehnen | 198.51.100.0/24 | Verweigert den Zugriff aus allen Nicht-Entwicklungsgebäuden |
5.000 | Zulassen | 203.0.113.0/24 | Ermöglicht den Zugriff aus dem Netzwerk des Hauptgebäudes |
2147483647 | Ablehnen | * | Standardaktion |
Nach dem Erstellen der Firewall werden die folgenden Anfragen an die Beispielanwendung gerichtet. Beachten Sie die Antwort der Anwendung:
- Eine Anfrage von 198.51.100.2 entspricht der Regel mit der Priorität 2.000 und wird zugelassen.
- Eine Anfrage von 198.51.100.100 entspricht der Regel mit der Priorität 3.000 und wird abgelehnt.
- Eine Anfrage von 203.0.113.54 entspricht der Regel mit der Priorität 5.000 und wird zugelassen.
- Eine Anfrage von 45.123.35.242 entspricht der Standardregel und wird abgelehnt.
Regelkonflikte auflösen
Angenommen, zwei der Prioritäten in der Firewall des Unternehmens werden vertauscht. Wenn die Regeln für die Prioritäten 2.000 und 3.000 vertauscht werden, tritt ein unerwünschtes Verhalten auf.
Priorität | Aktion | IP-Bereich | Beschreibung |
---|---|---|---|
1.000 | Ablehnen | 192.0.2.1 | Verweigert einem DoS-Angreifer den Zugriff |
2.000 | Ablehnen | 198.51.100.0/24 | Verweigert den Zugriff aus allen Gebäuden außer denen der Entwicklungsabteilung. |
3.000 | Zulassen | 198.51.100.2 | Ermöglicht einem Entwickler in einer Außenstelle den Zugriff |
5.000 | Zulassen | 203.0.113.0/24 | Ermöglicht den Zugriff aus dem Netzwerk des Hauptgebäudes |
2147483647 | Ablehnen | * | Standardaktion |
Der Entwickler in der Außenstelle kann nicht auf die Anwendung des Unternehmens zugreifen, da die neue Priorität der Regel dazu führt, dass sie nie ausgewertet wird. Für die IP-Adresse 198.51.100.2
des Entwicklers gilt die Regel, durch die allen Nicht-Entwicklern im Bereich 198.51.100.0/24
der Zugriff verweigert wird. Die Regel, die den Zugriff durch die IP-Adresse des Entwicklers erlaubt, hat eine niedrigere Priorität.
Wenn Sie dieses Problem beheben möchten, müssen Sie die Priorität der Regel, die den Zugriff von 198.51.100.2
aus erlaubt, höher einstellen als die Priorität der Regel, die den Zugriff vom IP-Bereich 198.51.100.0/24
aus verhindert.
Anfragen von Diensten zulassen
Beim Erstellen von Regeln sollten Sie diese Punkte beachten:
- Standardmäßig erhält jede Anfrage, die mit keiner Regel übereinstimmt, Zugriff auf Ihre Anwendung. Wenn Sie alle Anfragen blockieren möchten, die keiner bestimmten Regel entsprechen, müssen Sie für die Regel
default
deny
festlegen. - Traffic der Aufgabenwarteschlangen wird von der Firewall zugelassen, selbst wenn die Regel
default
aufdeny
gesetzt ist. Cron-Traffic ist in der Standardumgebung zulässig. Informationen zum Prüfen eingehender Cronanfragen, die von App Engine-Anwendungen stammen, finden Sie unter Cronanfragen prüfen.
In der flexiblen Umgebung müssen Sie Cron-Traffic ausdrücklich zulassen. Weitere Informationen zum Erstellen von Firewallregeln in der flexiblen App Engine-Umgebung finden Sie unter Firewalls erstellen.
Wenn Sie den Zugriff von Anfragen anderer App Engine-Anwendungen oder -Dienste steuern möchten, müssen Sie möglicherweise Regeln zum Einbeziehen der für die Dienst-zu-Dienst-Kommunikation verwendeten IP-Adressen erstellen. Wenn die Anwendung mit anderen Anwendungen oder Diensten in App Engine kommuniziert, müssen Sie festlegen, wie Anfragen von folgenden IP-Adressen verarbeitet werden sollen:
- Anfragen vom URL-Abrufdienst:
0.1.0.40
- In der Standardumgebung empfangene Anfragen:
0.1.0.40
- In der flexiblen Umgebung empfangene Anfragen:
0.1.0.40
und10.0.0.1
- Anfragen von
0.1.0.40
oder10.0.0.1
können von jeder App Engine-Anwendung stammen. - Mit dem Header
X-Appengine-Inbound-AppId
können Sie die ID der ursprünglichen Anwendung ermitteln.
- In der Standardumgebung empfangene Anfragen:
- Anfragen aus dem Blobstore oder aus Cloud Storage:
0.1.0.30
- Nur in der Standardumgebung empfangene Anfragen:
- Anfragen der Anwendungsbereitstellung:
10.1.0.41
- Anfragen der Anwendungsbereitstellung:
- Anfragen von Compute Engine-Instanzen mit aktiviertem privatem Google-Zugriff:
0.0.0.0
- Anfragen von
0.0.0.0
stammen von Compute Engine-Instanzen mit aktiviertem privatem Google-Zugriff.
- Anfragen von
Beispiel
Ihre Anwendung hat einen Back-End-Dienst, der in der Standardumgebung ausgeführt wird (
backend_std
). Der Dienst verwendet den URL-Abrufdienst für die Kommunikation mitbackend_flex
.Sie müssen zwei Firewallregeln erstellen, um Anfragen zuzulassen, und in
backend_flex
den HeaderX-Appengine-Inbound-AppId
prüfen, ob er der Anwendungs-ID vonbackend_std
entspricht:0.1.0.40
– Eine Regel, die fürbackend_flex
den Empfang von URL-Abrufanfragen vonbackend_std
zulässt.10.0.0.1
– Eine Regel, die die Dienst-zu-Dienst-Kommunikation für die URL-Abrufanfragen inbackend_flex
zulässt.- Lassen Sie in
backend_flex
nur Anfragen zu, bei denen der HeaderX-Appengine-Inbound-AppId
mit der ID vonbackend_std
übereinstimmt.
- Anfragen vom URL-Abrufdienst:
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 oder zum Verhindern, dass statische Inhalte zwischengespeichert werden, finden Sie unter Cache-Ablaufzeit.Wenn Sie verhindern möchten, dass dynamische Inhalte aus dem Code Ihrer Anwendung 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
Informationen zur sicheren Konfiguration einer Anwendung und zur Festlegung der erforderlichen Zugriffsebenen finden Sie in den Abschnitten zur Anwendungssicherheit und Zugriffssteuerung.