Como controlar o acesso com firewalls

Python 2.7/3 |Java 8/11 |PHP 5/7 |Ruby |Go 1.11 / 1.12+ |Node.js

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".

      Importante: não é possível editar o valor de prioridade após a criação da regra. Para alterar o valor de prioridade de uma regra, é necessário excluí-la e, em seguida, recriá-la.
   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 è válido para a 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".
     Importante: não é possível editar o valor de prioridade após a criação da regra. Para alterar o valor de prioridade de uma regra, é necessário excluí-la e, em seguida, recriá-la.
   • 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 app. 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ê usa Cloud Load Balancing e NEGs 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.

• Não é possível desativar os URLs que o Google Cloud atribui automaticamente aos serviços do App Engine. Os usuários que já têm o URL padrão do serviço do App Engine podem ignorar o balanceador de carga e acessar diretamente o URL do serviço. Isso significa que, mesmo que você configure políticas de segurança do Google Cloud Armor, certificados SSL e chaves privadas por meio do balanceador de carga, os usuários com o URL padrão podem burlar essas políticas.

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.

  Crie 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 aplicativo 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.

Cuidado: a criação de uma regra para o IP 0.0.0.0 será aplicada a todas as instâncias do Compute Engine com o acesso privado do Google ativado, e não apenas às que pertencem a você. Da mesma forma, permitir solicitações de 0.1.0.40 ou 10.0.0.1 autorizará qualquer app do App Engine a fazer solicitações de busca de URL ao seu aplicativo.

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 armazenado em cache, o conteúdo é exibido publicamente do URL específico até expirar, podendo 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 o conteúdo estático seja armazenado em cache, consulte Expiração do cache.

Para evitar que a saída de conteúdo dinâmico do código do seu app seja armazenada em cache, use os cabeçalhos de resposta HTTP Cache-Control e Expires. Para mais informações sobre esses cabeçalhos HTTP, incluindo como controlar o armazenamento em cache, consulte Como evitar o armazenamento em cache.

A seguir

Para verificar se você configurou o app com segurança e definiu os níveis de acesso adequados, consulte Segurança para aplicativos e Controle de acesso.