O Python 2 não é mais compatível com a comunidade. Recomendamos que você migre aplicativos do Python 2 para o Python 3.

Como controlar o acesso com firewalls

Um firewall determina qual tráfego de rede tem permissão para passar e qual é rejeitado. No App Engine, é possível criar um firewall com até 1.000 regras individuais priorizadas que permitem ou restringem um intervalo de endereços IP e sub-redes. O app responderá apenas a solicitações permitidas pelo firewall.

Antes de começar

Antes de criar regras de firewall para o App Engine, é preciso ter um dos seguintes papéis do IAM do App Engine, com os privilégios necessários para criar ou modificar regras de firewall:

  • Administrador do App Engine
  • Editor
  • Proprietário

Como criar regras de firewall

Use um dos métodos a seguir para criar uma regra de firewall. Repita essas etapas para cada regra extra:

Console

Use a página "Regras de firewall" no Console do Cloud para criar uma regra de firewall:

  1. Acesse a página "Criar regra de firewall" no Console do Cloud:

    Acessar a página "Criar regra de firewall"

  2. Especifique os detalhes da regra de firewall:

    1. Em Prioridade, digite um número inteiro para especificar a importância relativa da regra e definir a ordem de avaliação dela.

      Os valores válidos são de 1 a 2147483646. A prioridade 1 determina que a regra será avaliada primeiro. A prioridade 2147483647 determina que a regra será avaliada por último, e está reservada para a regra "padrão".

    2. Em Ação se houver correspondência, especifique se o acesso às solicitações que corresponderem à regra será negado ou permitido. Regras definidas como allow encaminham a solicitação ao aplicativo. Regras definidas como deny respondem a solicitações com um erro 403 Forbidden.
    3. Em Intervalo de IP, defina o intervalo de endereços IP que se aplica à regra. O intervalo de endereços IP precisa ser definido na notação CIDR (em inglês). Ele pode incluir máscaras de sub-rede e aceita IPv4 e IPv6.
    4. Opcional: em Descrição, inclua uma descrição da regra de até 100 caracteres.
  3. Clique em Salvar para criar a regra.
  4. Teste a regra para garantir que a prioridade e a ação estão resultando no comportamento esperado:
    1. Clique em Testar endereço IP.
    2. Insira o endereço IP que você quer validar e clique em Testar para garantir que a regra correspondente seja avaliada corretamente.
gcloud

Execute os comandos gcloud app firewall-rules a seguir para criar uma regra de firewall:

  1. Execute o comando a seguir para criar uma regra de firewall: 

    gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION
    em que:
    • PRIORITY é um número inteiro entre 1 e 2147483646 que define a importância da regra e a ordem em que ela é avaliada. A prioridade 1 determina que a regra será avaliada primeiro. A prioridade 2147483647 determina que a regra será avaliada por último, e está reservada para a regra "padrão".
    • ALLOW_OR_DENY especifica se o firewall deve permitir ou negar o acesso às solicitações que corresponderem à regra. Os valores válidos são allow ou deny. Regras definidas como allow encaminham a solicitação ao aplicativo. Regras definidas como deny respondem a solicitações com um erro 403 Forbidden.
    • IP_RANGE define o intervalo de endereços IP que se aplica à regra. O intervalo de endereços IP precisa ser definido na notação CIDR (em inglês). Ele pode incluir máscaras de sub-rede e aceita IPv4 e IPv6.
    • DESCRIPTION é uma descrição opcional da regra e pode ter até 100 caracteres.
  2. Execute o comando a seguir para testar a regra e garantir que a prioridade e a ação estão resultando no comportamento esperado:
    gcloud app firewall-rules test-ip IP_ADDRESS
    em que IP_ADDRESS é o endereço IP que você quer testar no seu firewall.
  3. Execute o comando a seguir para ver a lista de regras atuais:
    gcloud app firewall-rules list
  4. Execute o comando a seguir para excluir uma regra:
    gcloud app firewall-rules delete PRIORITY
    em que PRIORITY é o valor de prioridade da regra que você quer excluir.
Exemplos:
Siga os exemplos abaixo para criar seu firewall:

  • Adicione uma regra que permita as solicitações de um endereço IPv6 e de uma máscara de sub-rede. Em seguida, teste essa regra para verificar se ela está sendo avaliada antes das demais:

    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

  • Adicione uma regra para negar as solicitações de um endereço IPv4 e de uma máscara de sub-rede. Em seguida, teste essa regra para verificar se ela está sendo avaliada adequadamente:

    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

  • Atualize e depois teste a regra padrão para garantir que ela está restringindo todos os endereços IP que não correspondem às demais regras:

    gcloud app firewall-rules update default --action deny
gcloud app firewall-rules test-ip 123.456.7.89
API

Para criar regras de firewall para seu aplicativo do App Engine de maneira programática, use os métodos apps.firewall.ingressRules na API Admin.

Para testar uma regra de firewall e garantir que a prioridade e a ação forneçam o comportamento esperado, é possível usar o método apps.firewall.ingressRules.list e especificar o endereço IP que você quer testar no parâmetro matchingAddress.

Noções básicas sobre regras de firewall do App Engine

Um firewall do App Engine consiste em uma lista ordenada de regras que podem permitir ou negar o acesso do endereço IP ou do intervalo especificado ao seu aplicativo. A regra se aplica a todos os recursos do aplicativo do App Engine.

As regras do firewall são ordenadas pela importância definida por você como valor numérico na prioridade de cada uma das regras. É preciso especificar um valor de prioridade exclusivo para cada regra, já que ela define a importância relativa às outras regras no firewall. Os valores da escala de prioridade de uma regra variam de 1, a mais importante, até 2147483647, a menos importante.

Cada firewall inclui uma regra default que é criada automaticamente com a prioridade 2147483647 e se aplica a todo o intervalo de IP do seu aplicativo. A regra default é sempre avaliada após todas as outras regras do firewall e aplicada a todas as solicitações em todos os endereços IP.

O firewall avalia primeiro a regra de prioridade mais alta. Todas as regras restantes no firewall são avaliadas sequencialmente até que uma regra corresponda ao intervalo de IP dessa solicitação. Quando uma regra correspondente é encontrada, a conexão é permitida ou negada e todas as regras restantes no firewall são ignoradas. Se nenhuma das regras definidas manualmente no firewall corresponder à solicitação, a regra default padrão será avaliada.

Por exemplo, ao criar uma regra com prioridade 1, ela é sempre avaliada em primeiro lugar. Se uma solicitação recebida corresponder à regra com prioridade 1, somente essa regra será avaliada e todas as demais serão ignoradas, incluindo a regra default padrão.

Veja no exemplo de firewall abaixo como a prioridade de uma regra altera o comportamento de firewall.

Firewalls do App Engine e Cloud Load Balancing

Se você usar o Cloud Load Balancing e os grupos de endpoints de rede (NEG, na sigla em inglês) sem servidor, observe os seguintes detalhes:

  • 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 Google Cloud Armor, os certificados SSL e as chaves privadas transmitidas pelo balanceador de carga.

Exemplo de firewall

Neste exemplo, uma empresa configurou um firewall para conceder acesso à equipe de engenharia e à rede corporativa interna ao aplicativo em desenvolvimento. As regras de firewall foram criadas com grandes lacunas entre cada prioridade para permitir o crescimento.

Prioridade Ação Intervalo de IP Descrição
1000 Negar 192.0.2.1 Nega o acesso a um ataque de DoS.
2000 Permitir 198.51.100.2 Permite o acesso a um engenheiro no escritório satélite.
3000 Negar 198.51.100.0/24 Nega o acesso a todas as divisões que não sejam de engenharia.
5000 Permitir 203.0.113.0/24 Permite acesso à rede do edifício principal.
2147483647 Negar * Ação padrão.

Após a criação do firewall, suponha que as solicitações a seguir tenham sido direcionadas para o aplicativo de amostra e anote a resposta do aplicativo:

  • A solicitação de 198.51.100.2 corresponde à regra com prioridade 2000 e é permitida.
  • A solicitação de 198.51.100.100 corresponde à regra com prioridade 3000 e é negada.
  • A solicitação de 203.0.113.54 corresponde à regra com prioridade 5000 e é permitida.
  • A solicitação de 45.123.35.242 corresponde à regra padrão e é negada.

Como resolver regras conflitantes

Por exemplo, suponha que duas das prioridades no firewall da empresa sejam trocadas. Se as regras para as prioridades 2000 e 3000 forem trocadas, observe que acontecerá um comportamento não desejado.

Prioridade Ação Intervalo de IP Descrição
1000 Negar 192.0.2.1 Nega o acesso a um ataque de DoS.
2000 Negar 198.51.100.0/24 Nega o acesso a todas as divisões que não sejam de engenharia.
3000 Permitir 198.51.100.2 Permite o acesso a um engenheiro no escritório satélite.
5000 Permitir 203.0.113.0/24 Permite acesso à rede do edifício principal.
2147483647 Negar * Ação padrão.

O engenheiro no escritório satélite não conseguirá acessar o aplicativo da empresa, já que a nova prioridade da regra indica que ela nunca será avaliada. O endereço IP 198.51.100.2 do engenheiro corresponde à regra que nega o acesso de todos os funcionários que não são engenheiros no intervalo 198.51.100.0/24 antes da regra que permite acesso ao endereço IP desse engenheiro.

Para corrigir isso, é preciso definir a prioridade da regra que permite o acesso a 198.51.100.2 como um valor maior do que a regra que nega o acesso ao intervalo de IP 198.51.100.0/24.

Como permitir solicitações dos serviços

Ao criar regras, considere os pontos a seguir:

  • Por padrão, qualquer solicitação que não corresponda a uma regra permite o acesso ao seu aplicativo. Se você quiser bloquear todas as solicitações que não correspondem a uma regra específica, será necessário definir a regra default como deny.
  • O tráfego do Task Queues será permitido pelo firewall, mesmo quando a regra default estiver definida como deny.

  • O tráfego do Cron será permitido no ambiente padrão. Para validar solicitações cron recebidas de aplicativos do App Engine, veja Como validar solicitações cron.

    No ambiente flexível, é necessário permitir explicitamente o tráfego do Cron. Saiba mais sobre como criar regras de firewall no ambiente flexível do App Engine em Como criar firewalls.

  • Para controlar o acesso de solicitações de outros aplicativos ou serviços do App Engine, pode ser preciso criar regras para acomodar os endereços IP que são usados para a comunicação de serviço a serviço. Se o aplicativo se comunica com outros aplicativos ou serviços no App Engine, é preciso pensar em formas de processar as solicitações provenientes dos endereços IP a seguir:

    • Solicitações do serviço de busca de URL: 0.1.0.40
      • Solicitações recebidas no ambiente padrão: 0.1.0.40
      • Solicitações recebidas no ambiente flexível: 0.1.0.40 e 10.0.0.1
      • Solicitações de 0.1.0.40 ou 10.0.0.1 podem vir de qualquer aplicativo do App Engine.
      • Use o cabeçalho X-Appengine-Inbound-AppId para determinar o ID do aplicativo de origem.
    • Solicitações do Blobstore ou do Cloud Storage: 0.1.0.30
    • Solicitações recebidas apenas no ambiente padrão:
      • Solicitações de implantação de aplicativos: 10.1.0.41
    • Solicitações de instâncias do Compute Engine com acesso privado do Google ativado: 0.0.0.0
      • As solicitações de 0.0.0.0 virão de qualquer instância do Compute Engine com o acesso privado do Google ativado.

    Exemplo

    Seu aplicativo tem um serviço de back-end em execução no ambiente padrão (backend_std). O serviço usa o serviço de busca de URL para se comunicar com backend_flex.

    É necessário criar duas regras de firewall para permitir solicitações. Em backend_flex, você precisa ler o cabeçalho X-Appengine-Inbound-AppId para garantir que ele corresponda ao ID do app de backend_std:

    • 0.1.0.40: uma regra para permitir que backend_flex receba solicitações de busca de URL de backend_std.
    • 10.0.0.1: uma regra para permitir a comunicação de serviço a serviço para as solicitações de Busca de URL em backend_flex.
    • Em backend_flex, permita apenas as solicitações em que o cabeçalho X-Appengine-Inbound-AppId é igual ao ID de backend_std.

Como impedir acesso ao conteúdo armazenado em cache

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

Para configurar o app e definir com segurança os níveis de acesso adequados, consulte Segurança para aplicativos e Controle de acesso.