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:
Use a página "Regras de firewall" no Console do Cloud para criar uma regra de firewall:
-
Acesse a página "Criar regra de firewall" no Console do Cloud:
-
Especifique os detalhes da regra de firewall:
-
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
a2147483646
. A prioridade1
determina que a regra será avaliada primeiro. A prioridade2147483647
determina que a regra será avaliada por último, e está reservada para a regra "padrão". -
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 comodeny
respondem a solicitações com um erro403 Forbidden
. - 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.
- Opcional: em Descrição, inclua uma descrição da regra de até 100 caracteres.
-
Em Prioridade, digite um número inteiro para especificar a importância relativa da regra e definir a ordem de avaliação dela.
- Clique em Salvar para criar a regra.
-
Teste a regra para garantir que a prioridade e a ação estão resultando no comportamento esperado:
- Clique em Testar endereço IP.
- Insira o endereço IP que você quer validar e clique em Testar para garantir que a regra correspondente seja avaliada corretamente.
Execute os comandos gcloud
app firewall-rules
a seguir para criar uma regra de firewall:
-
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
e2147483646
que define a importância da regra e a ordem em que ela é avaliada. A prioridade1
determina que a regra será avaliada primeiro. A prioridade2147483647
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
oudeny
. Regras definidas comoallow
encaminham a solicitação ao aplicativo. Regras definidas comodeny
respondem a solicitações com um erro403 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.
-
PRIORITY é um número inteiro entre
- 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. - Execute o comando a seguir para ver a lista de regras atuais:
gcloud app firewall-rules list
- 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
-
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
comodeny
. - O tráfego do Task Queues será permitido pelo firewall, mesmo
quando a regra
default
estiver definida comodeny
. O tráfego 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 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
e10.0.0.1
- Solicitações de
0.1.0.40
ou10.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 recebidas no ambiente padrão:
- 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 implantação de aplicativos:
- 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.
- As solicitações de
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 combackend_flex
.É necessário criar duas regras de firewall para permitir solicitações. Em
backend_flex
, você precisa ler o cabeçalhoX-Appengine-Inbound-AppId
para garantir que ele corresponda ao ID do app debackend_std
:0.1.0.40
: uma regra para permitir quebackend_flex
receba solicitações de busca de URL debackend_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 embackend_flex
.- Em
backend_flex
, permita apenas as solicitações em que o cabeçalhoX-Appengine-Inbound-AppId
é igual ao ID debackend_std
.
- Solicitações do serviço de busca de URL:
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.