Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Um firewall determina qual tráfego de rede tem permissão para passar e qual
é rejeitado. Os firewalls podem ser aplicados ao tráfego de entrada (entrada), o tráfego de saída (saída) ou ambos. No App Engine, o firewall do App Engine aplica-se apenas ao tráfego de entrada roteado para seu aplicativo ou serviço.
Visão geral
O firewall do App Engine é verificado para todos os tipos de solicitações do seu aplicativo, incluindo:
Tráfego da Web normal direcionado para o endereço appspot.com ou domínio personalizado do app.
Tráfego de fontes internas, como máquinas virtuais (VMs) do Compute Engine e Cloud Tasks.
Nos casos em que seu aplicativo estiver configurado para usar outros serviços ou produtos de rede, talvez seja necessário criar regras para controlar o tráfego de entrada no firewall do App Engine e nas configurações de firewall ou segurança de outros produtos. Neste guia, você verá o comportamento geral do firewall do App Engine e detalhes sobre esses casos de uso especiais.
Regras de firewall do App Engine
É possível configurar regras de firewall do App Engine
usando o console Google Cloud , a Google Cloud CLI ou a API
Admin especificando regras que permitem ou bloqueiam intervalos de IP especificados.
Por padrão, qualquer solicitação, que não corresponda a uma regra, permite o acesso ao seu aplicativo. Se você precisar bloquear todas as solicitações que não corresponderem a uma regra específica (excluindo solicitações de serviços internos permitidos por padrão), altere a ação da regra default para deny.
Recurso de firewall
No ambiente padrão do App Engine, o firewall pode permitir que determinado tráfego interno ignore o firewall. Isso significa que, se você definir a regra default como deny, as solicitações de determinados serviços destinados ao ambiente padrão do App Engine não serão bloqueadas. Esses são todos os tipos de tráfego solicitados na própria configuração do aplicativo ou enviados do mesmo aplicativo. As solicitações que ignoram as regras de firewall dessa forma incluem:
Para os aplicativos que usam o ambiente padrão do App Engine e serviços agrupados com os ambientes de execução de primeira geração, as notificações da API Mail legada também ignoram o firewall.
Como permitir solicitações recebidas dos serviços
A tabela a seguir lista os intervalos de IP e o comportamento do firewall do App Engine para serviços comuns. O intervalo de IPs que você usa depende de as solicitações recebidas serem entregues a uma versão executada no ambiente padrão ou flexível do App Engine.
Serviço
Intervalo de IP para solicitações enviadas ao ambiente padrão do App Engine
Intervalo de IP para solicitações enviadas ao ambiente flexível do App Engine
Cloud Storage ou Blobstore
0.1.0.30/32
Não relevante
Jobs do Cloud Scheduler usando tarefas HTTP do App Engine e do App Engine no Cloud Tasks (incluindo filas de tarefas do App Engine)
0.1.0.2/32, ignora a regra de firewall padrão, se configurada para negar
0.1.0.2/32
Cron do App Engine
0.1.0.1/32 ou 0.1.0.2/32, ignora a regra de firewall padrão se definido para negar
Dependendo do caso de uso, estas instruções adicionais podem ser aplicadas ao configurar regras de firewall do App Engine:
As solicitações de cron jobs recém-criados ou atualizados do App Engine enviados para o ambiente padrão ou flexível do App Engine vêm de 0.1.0.2. Para jobs do Cron criados com versões anteriores do gcloud (anteriores a 326.0.0), as solicitações do Cron virão de 0.1.0.1. Para saber mais sobre como identificar solicitações do serviço Cron do App Engine, consulte Como validar solicitações cron.
O aplicativo em execução no ambiente padrão tem dois serviços: frontend_service e backend_service. frontend_service usa o Cloud Tasks com o HTTP do App Engine para enviar mensagens para backend_service. Como a regra de firewall default permite solicitações do Cloud Tasks mesmo se configurado para deny, não é necessário criar uma regra de firewall para o Cloud Tasks.
No entanto, se você quiser restringir o acesso ao seu aplicativo e bloquear explicitamente as solicitações do Cloud Tasks, crie uma regra de firewall deny para o intervalo de IP 0.1.0.2/32.
Exemplo flexível do App Engine
Seu aplicativo em execução no ambiente flexível tem dois serviços: frontend_service e backend_service, além de ter um firewall configurado para negar tráfego por padrão. frontend_service usa o Cloud Tasks com o HTTP do App Engine para enviar mensagens para backend_service. Como a regra de firewall default
nega solicitações do Cloud Tasks, é necessário criar uma
regra de firewall allow para 0.1.0.2/32.
O balanceador de carga não interfere nem interage com as regras de firewall do
App Engine. As regras do App Engine não são avaliadas até que um
NEG sem servidor direcione o tráfego para o App Engine.
Recomendamos usar controles de entrada
para que o aplicativo receba apenas solicitações enviadas do balanceador de carga
(e da VPC, se você usá-la). Caso contrário, os usuários poderão usar o URL do App Engine
do aplicativo para ignorar o balanceador de carga, as políticas de segurança do Cloud Armor,
os certificados SSL e as chaves privadas transmitidas pelo
balanceador de carga.
O firewall do Google App Engine fica por trás de mecanismos que armazenam conteúdo em cache. Por exemplo, proxies da Web e navegadores. Quando o conteúdo é armazenado em cache, ele é disponibilizado publicamente a partir do URL específico até a expiração e pode ser acessado mesmo após a criação de novas regras de firewall.
Para informações sobre como alterar o prazo de validade padrão para o conteúdo estático
ou impedir que ele seja armazenado em cache, consulte
Expiração do cache.
Para evitar que a saída de conteúdo dinâmico do código do aplicativo seja armazenada em cache, use
os cabeçalhos de resposta HTTP Cache-Control e Expires. Para saber mais informações sobre
esses cabeçalhos HTTP, incluindo como controlar o armazenamento em cache, consulte
Como evitar o armazenamento em cache (em inglês).
A seguir
Siga as instruções em Como criar firewalls para saber como configurar regras de firewall do App Engine.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
