Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
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:
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
Cloud Storage oder Blobstore
0.1.0.30/32
Nicht zutreffend
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
App Engine-Cron
0.1.0.1/32 oder 0.1.0.2/32 umgeht die Standard-Firewallregel, wenn sie auf „Ablehnen“ gesetzt ist.
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 von 0.1.0.1. Weitere Informationen zum Ermitteln von Anfragen vom App Engine-Cron-Dienst finden Sie unter Cron-Anfragen validieren.
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.
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 Cloud Armor-Sicherheitsrichtlinien, SSL-Zertifikate und privaten Schlüssel zu umgehen, die über den Load-Balancer weitergegeben werden.
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThe App Engine firewall controls incoming network traffic to your app, allowing or denying requests based on specified IP ranges and rules.\u003c/p\u003e\n"],["\u003cp\u003eBy default, the App Engine firewall allows any request that doesn't match a rule, but this can be changed to deny all unmatched requests.\u003c/p\u003e\n"],["\u003cp\u003eCertain internal traffic, such as warmup requests and requests from Cloud Scheduler or Cloud Tasks, can bypass the default firewall rule even if it's set to deny.\u003c/p\u003e\n"],["\u003cp\u003eServices like Cloud Storage, Cloud Scheduler, and URL Fetch have specific IP ranges for requests sent to App Engine environments, which can be used to create more specified firewall rules.\u003c/p\u003e\n"],["\u003cp\u003eWhen using Cloud Load Balancing with App Engine, it is recommended to use ingress controls and keep the default App Engine firewall rule as allow, instead of deny, while using Cloud Armor WAF rules.\u003c/p\u003e\n"]]],[],null,["# Understanding the App Engine firewall\n\nA **firewall** determines which network traffic is allowed to pass and which\ntraffic is rejected. Firewalls can apply to incoming traffic (ingress), outgoing\ntraffic (egress), or both. For App Engine, the App Engine firewall only\napplies to incoming traffic routed to your app or service.\n\nOverview\n--------\n\nThe App Engine firewall is checked for all types of\nrequests to your app, including:\n\n- Regular web traffic routed to the app's `appspot.com` address or custom domain.\n- Requests that arrive from [Cloud Load Balancing](/load-balancing).\n- Traffic from internal sources such as Compute Engine virtual machines (VMs) and Cloud Tasks.\n\nIn cases where your app is configured to use other networking services or\nproducts, you might need to create rules for controlling incoming traffic in\nboth the App Engine firewall and the firewall or security settings of other\nproducts. This guide covers the general behavior of the App Engine firewall,\nand details about those special use cases.\n\nApp Engine firewall rules\n-------------------------\n\nYou can [configure App Engine firewall rules](/appengine/docs/legacy/standard/java/creating-firewalls)\nusing the Google Cloud console, the Google Cloud CLI, or the Admin\nAPI by specifying rules that allow or block specified IP ranges.\n\nBy default, any request that does not match a rule is allowed access to your\napp. If you need to block all requests that do not match a specific rule\n(excluding requests from internal services allowed by default), change the\n`default` rule's action to `deny`.\n\n### Firewall feature\n\nIn the App Engine standard environment, the App Engine firewall can allow certain internal\ntraffic to bypass the firewall. This means that if you set the `default` rule to\n`deny`, requests from certain services destined for the App Engine standard environment do not\nget blocked. These are all types of traffic requested in the app's own\nconfiguration, or sent from the same app. Requests that bypass firewall rules in\nthis way include:\n\n- [Warmup requests](/appengine/docs/legacy/standard/java/configuring-warmup-requests)\n- Cloud Scheduler jobs using [App Engine HTTP](/scheduler/docs/creating#creating_jobs) (including [App Engine Cron](/appengine/docs/legacy/standard/java/config/cron)\n\n \u003cbr /\u003e\n\n - [App Engine tasks in Cloud Tasks](/tasks/docs/creating-appengine-tasks) (including App Engine Task Queues)\n\n For apps that use the App Engine standard environment and services bundled with the [first\n generation runtimes](/appengine/docs/standard/runtimes), notifications from the\n legacy Mail API also bypass the firewall.\n\n Allowing incoming requests from your services\n ---------------------------------------------\n\n The following table lists the IP ranges and App Engine firewall behavior for\n common services. The IP range you use depends on whether the incoming requests\n are delivered to a version that runs on the App Engine standard environment or\n flexible environment.\n\n Depending on your use case, these additional instructions might apply when\n configuring App Engine firewall rules:\n - Requests from newly created or updated App Engine Cron jobs sent to either the App Engine standard or flexible environment come from `0.1.0.2`. For Cron jobs created with older gcloud versions (earlier than 326.0.0), Cron requests will come from `0.1.0.1`. To learn more about how to identify requests from the App Engine Cron service, see [Validating cron requests](/appengine/docs/legacy/standard/java/scheduling-jobs-with-cron-yaml#validating_cron_requests).\n - If your app interacts with Cloud Load Balancing or is connected to a VPC network, see the [Interaction with other products or services](#interaction_with_other_products_or_services) section below.\n\n | **Caution:** Creating a rule for IP `0.0.0.0` will apply to **all** Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from `0.1.0.40` will allow **any** App Engine app to make URL Fetch requests to your app.\n\n ### App Engine standard example\n\n Your app running in the standard environment has two services: `frontend_service`\n and `backend_service`. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule allows Cloud Tasks requests even if configured to `deny`, you do not need to create\n a firewall rule for Cloud Tasks.\n\n However, if you wanted to restrict access to your app and explicitly block\n Cloud Tasks requests, you would create a `deny` firewall rule for IP range `0.1.0.2/32`.\n\n ### App Engine flexible example\n\n Your app running in the flexible environment has two services:\n `frontend_service` and `backend_service`, and has a firewall configured to deny\n traffic by default. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule denies Cloud Tasks requests, you would need to create an\n `allow` firewall rule for `0.1.0.2/32`.\n\n Interaction with other products or services\n -------------------------------------------\n\n ### Cloud Load Balancing\n\n If you use [Cloud Load Balancing and serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts), note the following:\n - The load balancer does not interfere or interact with App Engine firewall rules. The App Engine firewall rules are not evaluated until a serverless NEG directs traffic to App Engine.\n\n \u003c!-- --\u003e\n\n - We recommend that you [use ingress controls](/appengine/docs/standard/application-security#ingress_controls)\n so that your app only receives requests sent from the load balancer\n (and the VPC if you use it). Otherwise, users can use your app's\n App Engine URL to bypass the load balancer, Cloud Armor\n security policies, SSL certificates, and private keys that are passed through\n the load balancer.\n\n - If your [ingress controls](/appengine/docs/legacy/standard/java/application-security#ingress_controls) are set to receive `internal-and-cloud-load-balancing` traffic, leave the default App Engine firewall rule as is (`allow`), and use [Google Cloud Armor web application firewall (WAF) rules](/armor/docs/rule-tuning).\n\n Preventing access to cached content\n -----------------------------------\n\n The App Engine firewall sits behind mechanisms that cache content, for example\n web proxies and browsers. When content is cached, that content is served\n publicly from the specific URL until it expires and can be accessed even after\n creating new firewall rules.\n For information about changing the default expiration time for static content or preventing static content from being cached, see [Cache expiration](/appengine/docs/legacy/standard/java/how-requests-are-handled#static_cache_expiration).\n\n \u003cbr /\u003e\n\n To prevent dynamic content output from your app's code from being cached, use\n the `Cache-Control` and `Expires` HTTP response headers. For more information about\n these HTTP headers, including how to control caching, see\n [Avoiding caching](https://wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching).\n\n\n What's next\n -----------\n\n Follow the instructions in [Creating\n Firewalls](/appengine/docs/legacy/standard/java/creating-firewalls) to\n learn how to configure App Engine firewall rules."]]
