Zugriff mit Firewalls steuern

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:

Console

Auf der Seite "Firewallregeln" in der Cloud Console können Sie eine Firewallregel erstellen:

  1. Rufen Sie in Cloud Console die Seite "Firewallregel erstellen“ auf:

    Zur Seite "Firewallregel erstellen"

  2. Geben Sie die Details der Firewallregel an:

    1. 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 bis 2147483646. Die Regel mit der Priorität 1 wird als erste ausgewertet. Die Regel mit der Priorität 2147483647 wird als letzte ausgewertet. Dieser Prioritätswert ist für die Standardregel "default" reserviert.

    2. 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 Wert deny antworten auf Anfragen mit der Fehlermeldung 403 Forbidden.
    3. 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.
    4. Optional: Geben Sie unter Beschreibung eine Beschreibung für die Regel ein, die nicht mehr als 100 Zeichen enthalten darf.
  3. Klicken Sie auf Speichern, um die Regel zu erstellen.
  4. Testen Sie die Regel, um festzustellen, dass die Priorität und die Aktion zum gewünschten Verhalten führen:
    1. Klicken Sie auf IP-Adresse testen.
    2. 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.
gcloud

Mit den folgenden Befehlen vom Typ gcloud app firewall-rules können Sie eine Firewallregel erstellen:

  1. 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 bis 2147483646. Dieser Wert definiert die Wichtigkeit der Regel und legt die Reihenfolge der Regelauswertung fest. Die Regel mit der Priorität 1 wird als erste ausgewertet. Die Regel mit der Priorität 2147483647 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 und deny. Regeln mit dem Wert allow leiten die Anfrage an die Anwendung weiter. Regeln mit dem Wert deny antworten auf Anfragen mit der Fehlermeldung 403 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.
  2. 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.
  3. Führen Sie diesen Befehl aus, um eine Liste der bestehenden Regeln anzuzeigen:
    gcloud app firewall-rules list
  4. 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
API

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 auf deny 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 und 10.0.0.1
      • Anfragen von 0.1.0.40 oder 10.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.
    • 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 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.

    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 mit backend_flex.

    Sie müssen zwei Firewallregeln erstellen, um Anfragen zuzulassen, und in backend_flex den Header X-Appengine-Inbound-AppId prüfen, ob er der Anwendungs-ID von backend_std entspricht:

    • 0.1.0.40 – Eine Regel, die für backend_flex den Empfang von URL-Abrufanfragen von backend_std zulässt.
    • 10.0.0.1 – Eine Regel, die die Dienst-zu-Dienst-Kommunikation für die URL-Abrufanfragen in backend_flex zulässt.
    • Lassen Sie in backend_flex nur Anfragen zu, bei denen der Header X-Appengine-Inbound-AppId mit der ID von backend_std übereinstimmt.

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.