Compreender a firewall do App Engine

Uma firewall determina que tráfego de rede tem autorização para passar e que tráfego é rejeitado. As firewalls podem aplicar-se ao tráfego de entrada (ingress), ao tráfego de saída (egress) ou a ambos. Para o App Engine, a firewall do App Engine aplica-se apenas ao tráfego de entrada encaminhado para a sua app ou serviço.

Vista geral

A firewall do App Engine é verificada para todos os tipos de pedidos à sua app, incluindo:

  • Tráfego Web normal encaminhado para o endereço appspot.com da app ou para o domínio personalizado.
  • Pedidos que chegam do Cloud Load Balancing.
  • Tráfego de origens internas, como máquinas virtuais (VMs) do Compute Engine e Cloud Tasks.

Nos casos em que a sua app está configurada para usar outros serviços de rede ou produtos, pode ter de criar regras para controlar o tráfego de entrada na firewall do App Engine e nas definições de firewall ou de segurança de outros produtos. Este guia aborda o comportamento geral da firewall do App Engine e detalhes sobre esses exemplos de utilização especiais.

Regras de firewall do App Engine

Pode configurar regras de firewall do App Engine através da Google Cloud consola, da CLI do Google Cloud ou da API Admin especificando regras que permitem ou bloqueiam intervalos de IP especificados.

Por predefinição, qualquer pedido que não corresponda a uma regra tem acesso permitido à sua app. Se precisar de bloquear todos os pedidos que não correspondam a uma regra específica (excluindo pedidos de serviços internos permitidos por predefinição), altere a ação da regra default para deny.

Funcionalidade de firewall

No ambiente padrão do App Engine, a firewall do App Engine pode permitir que determinado tráfego interno contorne a firewall. Isto significa que, se definir a regra default como deny, os pedidos de determinados serviços destinados ao ambiente padrão do App Engine não são bloqueados. Estes são todos os tipos de tráfego pedidos na própria configuração da app ou enviados a partir da mesma app. Os pedidos que ignoram as regras de firewall desta forma incluem:

Para apps que usam o ambiente padrão do App Engine e os serviços incluídos nos runtimes de primeira geração, as notificações da API Mail antiga também contornam a firewall.

Permitir pedidos recebidos dos seus serviços

A tabela seguinte indica os intervalos de IP e o comportamento da firewall do App Engine para serviços comuns. O intervalo de IPs que usa depende de as solicitações recebidas serem entregues a uma versão que é executada no ambiente padrão ou no ambiente flexível do App Engine.

Serviço Intervalo de IPs para pedidos enviados para o ambiente padrão do App Engine Intervalo de IPs para pedidos enviados para o ambiente flexível do App Engine
Cloud Storage ou Blobstore 0.1.0.30/32 Não aplicável
Trabalhos do Cloud Scheduler que usam HTTP do App Engine e tarefas do App Engine no Cloud Tasks (incluindo filas de tarefas do App Engine) 0.1.0.2/32, ignora a regra de firewall predefinida se estiver definida como 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 predefinida se estiver definida como recusar 0.1.0.1/32 ou 0.1.0.2/32
Obtenção de URL 0.1.0.40/32 0.1.0.40/32
Instâncias do Compute Engine com o acesso privado à Google ativado 0.0.0.0/32 0.0.0.0/32

Consoante o seu exemplo de utilização, estas instruções adicionais podem aplicar-se quando configurar regras de firewall do App Engine:

  • Os pedidos de tarefas cron do App Engine recém-criadas ou atualizadas enviados para o ambiente padrão ou flexível do App Engine são provenientes de 0.1.0.2. Para tarefas cron criadas com versões mais antigas do gcloud (anteriores à 326.0.0), os pedidos cron são provenientes de 0.1.0.1. Para saber como identificar pedidos do serviço App Engine Cron, consulte o artigo Validar pedidos cron.
  • Se a sua app interagir com o Cloud Load Balancing ou estiver ligada a uma rede VPC, consulte a secção Interação com outros produtos ou serviços abaixo.

Exemplo do App Engine Standard

A sua app 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 o backend_service. Uma vez que a regra de firewall permite pedidos do Cloud Tasks, mesmo que esteja configurada para deny, não precisa de criar uma regra de firewall para o Cloud Tasks.default

No entanto, se quiser restringir o acesso à sua app e bloquear explicitamente os pedidos do Cloud Tasks, cria uma denyregra de firewall para o intervalo de IPs 0.1.0.2/32.

Exemplo do App Engine Flexible

A sua app em execução no ambiente flexível tem dois serviços: frontend_service e backend_service, e tem uma firewall configurada para recusar o tráfego por predefinição. frontend_service usa o Cloud Tasks com o HTTP do App Engine para enviar mensagens para o backend_service. Uma vez que a regra de firewall default recusa pedidos do Cloud Tasks, tem de criar uma regra de firewall allow para 0.1.0.2/32.

Interação com outros produtos ou serviços

Cloud Load Balancing

Se usar o Cloud Load Balancing e NEGs sem servidor, tenha em atenção o seguinte:

  • O balanceador de carga não interfere nem interage com as regras da firewall do App Engine. As regras da firewall do App Engine não são avaliadas até que um NEG sem servidor direcione o tráfego para o App Engine.
  • Recomendamos que use controlos de entrada para que a sua app apenas receba pedidos enviados a partir do equilibrador de carga (e da VPC, se a usar). Caso contrário, os utilizadores podem usar o URL do App Engine da sua app para contornar o balanceador de carga, as políticas de segurança do Cloud Armor, os certificados SSL e as chaves privadas que são transmitidas através do balanceador de carga.

  • Se os seus controlos de entrada estiverem definidos para receber tráfego internal-and-cloud-load-balancing, deixe a regra de firewall do App Engine predefinida tal como está (allow) e use as regras da firewall de aplicações Web (WAF) do Google Cloud Armor.

Impedir o acesso a conteúdo em cache

A firewall do App Engine está atrás de mecanismos que colocam conteúdo em cache, por exemplo, proxies Web e navegadores. Quando o conteúdo é colocado em cache, esse conteúdo é publicado publicamente a partir do URL específico até expirar e pode ser acedido mesmo depois de criar novas regras de firewall.

Para obter informações sobre como alterar o tempo de expiração predefinido do conteúdo estático ou impedir que o conteúdo estático seja colocado em cache, consulte o artigo Expiração da cache.

Para impedir que o resultado do conteúdo dinâmico do código da sua app seja colocado em cache, use os cabeçalhos de resposta HTTP Cache-Control e Expires. Para mais informações acerca destes cabeçalhos HTTP, incluindo como controlar o armazenamento em cache, consulte o artigo Evitar o armazenamento em cache.

O que se segue?

Siga as instruções em Criar firewalls para saber como configurar as regras de firewall do App Engine.