Regras de firewall da VPC

As regras de firewall da nuvem privada virtual (VPC) se aplicam a um determinado projeto e rede. Se você quiser aplicar regras de firewall a várias redes VPC em uma organização, consulte Políticas de firewall. O restante desta página abrange apenas as regras de firewall da VPC.

As regras de firewall da VPC permitem permitir ou negar conexões de/para instâncias de máquina virtual (VM) na sua rede VPC. As regras de firewall da VPC que estão ativadas sempre são aplicadas. Isso garante a proteção das instâncias independentemente da configuração e do sistema operacional, mesmo que elas não tenham sido inicializadas.

Toda rede VPC funciona como um firewall distribuído. Enquanto as regras de firewall são definidas no nível da rede, as conexões são permitidas ou negadas por instância. Pense nas regras de firewall da VPC como existentes não apenas entre suas instâncias e outras redes, mas também entre instâncias individuais dentro da mesma rede.

Para mais informações sobre firewalls, consulte Firewall.

Práticas recomendadas para regras de firewall

Ao criar e avaliar suas regras de firewall, lembre-se das seguintes práticas recomendadas:

  • Implemente os princípios de privilégio mínimo. Bloqueie todo o tráfego por padrão e permita apenas o tráfego específico de que você precisa. Isso inclui limitar a regra apenas aos protocolos e às portas de que você precisa.
  • Use as regras de política hierárquica de firewall para bloquear o tráfego que nunca deve ser permitido no nível da organização ou da pasta.
  • Para regras de permissão, restrinja-as a VMs específicas especificando a conta de serviço das VMs.
  • Se você precisar criar regras com base em endereços IP, tente minimizar o número de regras. É mais fácil rastrear uma regra que permite o tráfego para um intervalo de 16 VMs do que acompanhar 16 regras separadas.
  • Ative a Geração de registros de regras de firewall e use o Firewall Insights para verificar se as regras de firewall estão sendo usadas da maneira pretendida. A geração de registros de regras de firewall pode gerar custos, portanto, considere-a de maneira seletiva.

Regras de firewall no Google Cloud

Ao criar uma regra de firewall da VPC, você especifica uma rede VPC e um conjunto de componentes que definem as atribuições da regra. Com os componentes, é possível especificar determinados tipos de tráfego com base no protocolo, portas, origens e destinos. Para mais informações, consulte Componentes de regra de firewall.

Crie ou modifique regras de firewall da VPC usando o Console do Google Cloud, a Google Cloud CLI e a API REST. Quando você cria ou modifica uma regra de firewall, é possível especificar as instâncias às quais ela precisa ser aplicada usando o parâmetro de meta da regra. Para ver exemplos de regras de firewall, consulte Outros exemplos de configuração.

Além das regras de firewall criadas, o Google Cloud tem outras regras que podem afetar as conexões de entrada (saída) ou de saída (saída):

  • O Google Cloud bloqueia ou limita determinado tráfego. Para mais informações, consulte Tráfego bloqueado e limitado.

  • O Google Cloud sempre permite a comunicação entre uma instância de VM e o servidor de metadados correspondente em 169.254.169.254. Para mais informações, consulte a seção Tráfego sempre permitido.

  • Cada rede tem duas regras de firewall implícitas que permitem conexões de saída e bloqueiam conexões de entrada. As regras de firewall criadas por você podem modificar essas regras implícitas.

  • A rede padrão tem regras de firewall predefinidas que podem ser excluídas ou modificadas.

Especificações

As regras de firewall da VPC têm as seguintes características:

  • Cada regra de firewall se aplica à conexão de entrada (recebimento) ou de saída (envio), mas não a ambos. Para mais informações, consulte a direção da conexão.

  • As regras de firewall são compatíveis com conexões IPv4. As conexões IPv6 também são compatíveis com redes VPC que tenham o IPv6 ativado. Ao especificar uma origem ou um destino para uma regra de entrada ou saída por endereço, é possível especificar endereços ou blocos IPv4 ou IPv6 na notação CIDR.

  • Cada regra de firewall pode conter intervalos IPv4 ou IPv6, mas não ambos.

  • A ação de cada regra de firewall é allow ou deny. A regra é válida para conexões enquanto for aplicada. Por exemplo, é possível desativar uma regra para solucionar problemas.

  • Ao criar uma regra de firewall, é preciso selecionar uma rede VPC. Enquanto a regra é aplicada no nível da instância, a configuração é associada a uma rede VPC. Isso significa que não é possível compartilhar regras de firewall entre redes VPC, incluindo redes conectadas por peering de rede VPC ou usando túneis VPN do Cloud.

  • As regras de firewall da VPC são com estado.

    • Quando uma conexão for permitida por meio do firewall em qualquer direção, o tráfego de retorno correspondente a essa conexão também será permitido. Não é possível configurar uma regra de firewall para negar o tráfego de resposta associado.
    • O tráfego de retorno precisa corresponder a cinco tuplas (IP de origem, IP de destino, porta de origem, porta de destino, protocolo) do tráfego de solicitação aceito, mas com os endereços de origem e de destino e as portas invertidas.
    • O Google Cloud associa os pacotes de entrada aos pacotes de saída correspondentes usando uma tabela de rastreamento de conexão. As conexões IPv4 são compatíveis com os protocolos TCP, UDP, SCTP e ICMP. As conexões IPv6 são compatíveis com os protocolos TCP, UDP, SCTP e ICMPv6.
    • O Google Cloud implementa o rastreamento de conexão independentemente de o protocolo oferecer suporte a conexões. Se for permitida uma conexão entre uma origem e uma meta (para uma regra de entrada) ou entre uma meta e um destino (para uma regra de saída), todo o tráfego de resposta será permitido, desde que o estado de rastreamento de conexão do firewall esteja ativo. O estado de rastreamento de uma regra de firewall será considerado ativo se pelo menos um pacote for enviado a cada 10 minutos.
    • Quando uma conexão fragmentada é permitida por meio do firewall, o Google Cloud usa o rastreamento de conexão para permitir apenas o primeiro fragmento de tráfego de retorno. Para permitir fragmentos de retorno subsequentes, adicione uma regra de firewall.
    • O tráfego de resposta ICMP, como "ICMP TYPE 3, DESTINATION UNREACHABLE", gerado em resposta a uma conexão TCP/UDP permitida é permitido por meio do firewall. Esse comportamento é consistente com o RFC 792.
  • As regras de firewall da VPC não reagrupam pacotes TCP fragmentados. Por isso, uma regra de firewall aplicável ao protocolo TCP só pode ser aplicada ao primeiro fragmento, porque ele contém o cabeçalho TCP. As regras de firewall aplicáveis ao protocolo TCP não são aplicadas aos fragmentos TCP subsequentes.

  • O número máximo de conexões rastreadas na tabela de regras de firewall depende do número de conexões com estado compatíveis com o tipo de máquina da instância. Se o número máximo de conexões rastreadas for excedido, o rastreamento será interrompido para as conexões que tiverem o maior intervalo de inatividade para permitir que novas conexões sejam rastreadas.

    Tipo de máquina da instância Número máximo de conexões com estado
    Tipos de máquina com núcleo compartilhado 130.000
    Instâncias com 1 a 8 vCPUs 130.000 conexões por vCPU
    Instâncias com mais de 8 vCPUs 1.040.000 (130.000×8) conexões ao total

Regras implícitas

Toda rede VPC tem duas regras implícitas de firewall IPv4. Se o IPv6 estiver ativado em uma rede VPC, a rede também terá duas regras implícitas de firewall do IPv6. Essas regras não são mostradas no console do Google Cloud.

As regras de firewall implícitas estão presentes em todas as redes VPC, independentemente de como as redes são criadas e se elas são redes VPC de modo automático ou modo personalizado. A rede padrão tem as mesmas regras implícitas.

  • Regra de IPv4 implícita que permite a saída. Uma regra de saída que tem allow como ação, 0.0.0.0/0 como destino e a prioridade mais baixa possível (65535) permite que qualquer instância envie tráfego para qualquer destino, exceto tráfego bloqueado pelo Google Cloud. Uma regra de firewall de prioridade mais alta pode restringir o acesso de saída. O acesso à Internet será permitido se nenhuma outra regra de firewall negar o tráfego de saída e se a instância tiver um endereço IP externo ou usar uma instância do Cloud NAT. Para mais informações, consulte Requisitos de acesso à Internet.

  • Regra de entrada de negação IPv4 implícita. Uma regra de entrada em que a ação é deny, a origem é 0.0.0.0/0 e a prioridade é a mais baixa possível (65535) protege todas as instâncias bloqueando as conexões recebidas. Uma regra de prioridade mais alta pode permitir o acesso de entrada. A rede padrão inclui outras regras que substituem essa, permitindo certos tipos de conexões de entrada.

Se o IPv6 estiver ativado, a rede VPC também terá estas duas regras implícitas:

  • Regra de saída de IPv6 implícita. Uma regra de saída que tem allow como ação, ::/0 como destino e a prioridade mais baixa possível (65535) permite que qualquer instância envie tráfego para qualquer destino, exceto tráfego bloqueado pelo Google Cloud. Uma regra de firewall de prioridade mais alta pode restringir o acesso de saída. O acesso à Internet será permitido se nenhuma outra regra de firewall negar o tráfego de saída e se a instância tiver um endereço IP externo.

  • Regra de entrada de negação IPv6 implícita. Uma regra de entrada em que a ação é deny, a origem é ::/0 e a prioridade é a mais baixa possível (65535) protege todas as instâncias bloqueando as conexões recebidas. Uma regra de prioridade mais alta pode permitir o acesso de entrada.

As regras implícitas não podem ser removidas, mas têm as prioridades mais baixas possíveis. É possível criar regras que as substituam, desde que suas regras tenham prioridades mais altas (números de prioridade menores que 65535). Como as regras deny têm precedência sobre as regras allow com a mesma prioridade, uma regra de entrada allow com prioridade 65535 nunca terá efeito.

Regras predefinidas na rede padrão

A rede padrão tem regras de firewall predefinidas que permitem conexões de entrada nas instâncias. Essas regras podem ser excluídas ou modificadas conforme necessário:

Nome da regra Direção Prioridade Intervalos de origem Ação Protocolos e portas Descrição
default-allow-internal ingress 65534 10.128.0.0/9 allow tcp:0-65535
udp:0-65535
icmp
Permite conexões de entrada com instâncias de VM de outras instâncias na mesma rede VPC.
default-allow-ssh ingress 65534 0.0.0.0/0 allow tcp:22 Permite que você se conecte a instâncias com ferramentas como ssh, scp ou sftp.
default-allow-rdp ingress 65534 0.0.0.0/0 allow tcp:3389 Permite a conexão com instâncias usando o Microsoft Remote Desktop Protocol (RDP).
default-allow-icmp ingress 65534 0.0.0.0/0 allow icmp Permite usar ferramentas como ping.

É possível criar regras de firewall semelhantes para redes diferentes da rede padrão. Consulte Configurar regras de firewall para casos de uso comuns para mais informações.

Tráfego bloqueado e limitado

Separados das regras de firewall da VPC e das políticas hierárquicas de firewall, o Google Cloud bloqueia ou limita determinado tráfego, conforme descrito na tabela a seguir.

Tipo de tráfego Detalhes
Taxa de pacotes e largura de banda

Válido para:

  • Todos os pacotes de saída
  • Todos os pacotes de entrada
O Google Cloud é responsável pela largura de banda por instância de VM, para cada placa de rede (NIC, na sigla em inglês) ou endereço IP. O tipo de máquina de uma VM define a taxa máxima de saída possível. No entanto, só é possível alcançar essa taxa máxima de saída possível em situações específicas.

Para mais detalhes, consulte Largura de banda da rede na documentação do Compute Engine de dados.
Ofertas e confirmações do DHCP

Válido para:

  • Pacotes de entrada para a porta UDP 68 (DHCPv4)
  • Pacotes de entrada para a porta UDP 546 (DHCPv6)
O Google Cloud bloqueia ofertas e confirmações de DHCP de todas as origens, exceto pacotes de DHCP do servidor de metadados.
Protocolos compatíveis com endereços IP externos do Google Cloud

Válido para:

  • Pacotes de entrada para endereços IP externos

Os endereços IPv4 e IPv6 externos aceitam apenas pacotes TCP, UDP, ICMP, IPIP, AH, ESP, SCTP e GRE. Recursos que usam endereços IP externos impõem restrições de protocolo adicionais:

Tráfego SMTP (porta 25)

Válido para:

  • Pacotes de saída para endereços IP externos na porta TCP 25

Por padrão, o Google Cloud bloqueia pacotes de saída enviados para a porta de destino TCP 25 de um endereço IP externo (inclusive um endereço IP externo de outro recurso do Google Cloud). No entanto, esse tráfego não será bloqueado em projetos que pertençam a clientes selecionados do Google Cloud. No console do Google Cloud, a página de redes VPC e a página de políticas de firewall exibem uma mensagem que indica se a porta SMTP 25 está ou não na lista de permissões do projeto.

Este bloco não se aplica a pacotes de saída enviados para a porta de destino TCP 25 de um endereço IP interno, incluindo um endereço IP público de uso particular em uma rede VPC ou em uma rede local.

Se a saída SMTP externa na porta 25 for permitida no seu projeto e você quiser enviar esse tipo de tráfego, as seguintes condições extras precisarão ser atendidas:

  • As regras de firewall de saída na rede VPC e as políticas de firewall hierárquicas aplicáveis à rede VPC precisam permitir a saída para o endereço IP externo na porta TCP 25. As regras implícitas de permissão de saída atendem a esse requisito porque permitem a saída (e a resolução de respostas de entrada) a qualquer endereço IP.
  • A rota aplicável do destino precisa usar o próximo salto padrão do gateway da Internet. As rotas padrão geradas pelo sistema atendem a esse requisito.
  • A instância que envia pacotes para o endereço de IP externo precisa atender aos requisitos de acesso à Internet.

É possível evitar a saída do SMTP externo criando regras de firewall de negação de saída ou políticas hierárquicas de firewall.

Tráfego sempre permitido

Para instâncias de VM, as regras de firewall da VPC e as políticas hierárquicas de firewall não se aplicam ao seguinte:

  • Pacotes enviados e recebidos do servidor de metadados do Google Cloud
  • Pacotes enviados para um endereço IP atribuído a uma das próprias placas de rede (NICs) da instância em que os pacotes permanecem na própria VM. Os endereços IP atribuídos à NIC de uma instância incluem:

    • O endereço IPv4 interno principal da NIC
    • Qualquer endereço IPv4 interno de um intervalo de IP de alias da NIC
    • Se IPv6 estiver configurado na sub-rede, qualquer um dos endereços IPv6 atribuídos à NIC
    • Um endereço IPv4 interno ou externo associado a uma regra de encaminhamento, para balanceamento de carga ou encaminhamento de protocolo, se a instância for um back-end do balanceador de carga ou uma instância de destino para encaminhamento de protocolo
    • Endereços de loopback
    • Endereços configurados como parte do software de sobreposição de rede que você executa na própria instância

Servidor de metadados do Google Cloud

O Google Cloud executa um servidor de metadados local para cada instância em 169.254.169.254. Esse servidor é essencial para a operação da instância, de modo que a instância possa acessá-lo independentemente das regras de firewall que você configurar. O servidor de metadados fornece à instância os seguintes serviços básicos:

Interações com o produto

As seções a seguir descrevem como as regras de firewall e as políticas hierárquicas de firewall interagem com outros produtos do Google Cloud.

Regras de firewall e balanceadores de carga de passagem

As regras de firewall da VPC e as políticas hierárquicas de firewall controlam quais protocolos e portas compatíveis com a regra de encaminhamento podem acessar os back-ends do balanceador de carga de passagem. Veja mais detalhes em:

Regras de firewall e balanceadores de carga de proxy

Para balanceadores de carga de aplicativo externos, internos, de rede de proxy interno e de proxy externo, as regras de VPC e as políticas hierárquicas de firewall fazemnão controlar quais protocolos e portas são aceitos pelo endereço IP da regra de encaminhamento do balanceador de carga do proxy. Apenas a regra de encaminhamento determina quais protocolos e portas são aceitos pelo balanceador de carga do proxy.

As regras de firewall da VPC e as políticas hierárquicas de firewall controlam como esses balanceadores de carga do proxy se comunicam com os back-ends. Veja mais detalhes em:

Regras de firewall e VPN do Cloud

As regras de firewall e as políticas hierárquicas de firewall não controlam quais protocolos e portas são aceitos pelo gateway do Cloud VPN.

Os gateways do Cloud VPN aceitam apenas pacotes para os protocolos e portas descritos nas especificações do Cloud VPN.

Regras de firewall e GKE

O Google Kubernetes Engine cria e gerencia regras de firewall automaticamente quando você cria um cluster ou recursos no cluster, incluindo serviços e entradas. Para mais informações, consulte Regras de firewall criadas automaticamente na documentação do Google Kubernetes Engine.

Componentes da regra de firewall

Cada regra de firewall tem os seguintes componentes de configuração:

  • É uma direção da perspectiva da meta. A direção pode ser de entrada ou saída.

  • Uma prioridade numérica, que determina se a regra é aplicada. Somente a regra de prioridade mais alta (número de prioridade mais baixo) que tem outros componentes correspondentes ao tráfego é aplicada. Regras conflitantes com prioridades mais baixas são ignoradas.

  • Uma ação se houver correspondência, allow ou deny, que determina se a regra permite ou bloqueia as conexões.

  • O status de aplicação da regra de firewall: é possível ativar e desativar regras de firewall sem excluí-las.

  • Uma meta, que define as instâncias (incluindo clusters do GKE e instâncias do ambiente flexível do App Engine) às quais a regra se aplica.

  • Um filtro de origem ou destino para características do pacote.

  • O protocolo (como TCP, UDP ou ICMP) e a porta.

  • Uma opção de registros booleanos que registra conexões que correspondem à regra no Cloud Logging.

Resumo dos componentes

Regra de entrada (recebimento)
Prioridade Ação Aplicação Parâmetro de meta Filtros de origem e destino Protocolos e portas
Inteiro de 0 a 65535, incluindo esses dois valores.; 1000 padrão. allow ou deny enabled (padrão) ou disabled Especifica as instâncias que recebem pacotes.

Origens das regras de entrada

Destinos para regras de entrada

Especifique um protocolo ou um protocolo e uma porta de destino.

Caso contrário, a regra será aplicada a todos os protocolos e portas de destino. Para mais informações, consulte Protocolos e portas.

Regra de saída (envio)
Prioridade Ação Aplicação Parâmetro de meta Filtros de origem e destino Protocolos e portas
Inteiro de 0 a 65535, incluindo esses dois valores.; 1000 padrão. allow ou deny enabled (padrão) ou disabled Especifica as instâncias que enviam pacotes.

Origens para regras de saída

Destinos para regras de saída

Especifique um protocolo ou um protocolo e uma porta de destino.

Caso contrário, a regra será aplicada a todos os protocolos e portas de destino. Para mais informações, consulte Protocolos e portas.

Direção do tráfego

É possível criar regras de firewall que se apliquem ao tráfego de entrada ou saída. Uma única regra não pode ser aplicada ao tráfego de entrada e saída. No entanto, é possível criar várias regras para definir o tráfego de entrada e saída que você permite ou nega pelo firewall.

  • A entrada descreve os pacotes que entram na interface de rede de uma meta.

  • A saída descreve os pacotes que saem de uma interface de rede de uma meta.

  • Se não houver especificação da direção, o Google Cloud usará a entrada.

Prioridade

A prioridade da regra de firewall é um número inteiro de 0 a 65535, incluindo esses dois valores. Os números inteiros mais baixos indicam prioridades mais altas. Se nenhuma prioridade for especificada na criação da regra, será atribuída uma prioridade de 1000.

A prioridade relativa de uma regra de firewall determina se ela é aplicável quando avaliada em relação a outras. A lógica de avaliação funciona desta maneira:

  • A regra de prioridade mais alta aplicável a uma meta para um determinado tipo de tráfego tem precedência. A especificidade da meta não importa. Por exemplo, uma regra de entrada de prioridade mais alta para determinadas portas e protocolos de destino voltados a todas as metas substitui uma regra definida de maneira semelhante com menor prioridade para as mesmas portas e protocolos de destino voltados às metas específicas.

  • A regra de prioridade mais alta aplicável para um determinado protocolo e definição de porta tem precedência, mesmo quando o protocolo e a definição da porta são mais gerais. Por exemplo, uma regra de entrada de prioridade mais alta que permite o tráfego para todos os protocolos e portas voltados a determinadas metas substitui uma regra de entrada de prioridade mais baixa que nega o TCP 22 para as mesmas metas.

  • Uma regra com uma ação deny substitui outra com uma ação allow somente se as duas regras tiverem a mesma prioridade. Usando prioridades relativas, é possível criar regras allow que substituem regras deny e regras deny que substituem regras allow.

  • Regras com a mesma prioridade e ação têm o mesmo resultado. No entanto, não é possível determinar qual regra é usada durante a avaliação. Normalmente, não importa qual regra é usada, exceto quando você ativa a Geração de registros de regras de firewall. Se quiser que seus registros mostrem as regras de firewall que estão sendo avaliadas de maneira consistente e bem definida, atribua prioridades únicas a elas.

Considere o exemplo a seguir onde há duas regras de firewall:

  • Uma regra de entrada de origens 0.0.0.0/0 (qualquer endereço IPv4) aplicável a todas as metas, todos os protocolos e todas as portas, com uma ação deny e uma prioridade de 1000.

  • Uma regra de entrada de origens 0.0.0.0/0 (qualquer endereço IPv4) aplicável a destinos específicos com a tag de rede webserver, para tráfego no TCP 80, com uma ação allow.

A prioridade da segunda regra determina se o tráfego TCP na porta 80 é permitido para as metas de webserver:

  • Se a prioridade da segunda regra for definida como um número maior que 1000, ela terá uma prioridade inferior. Por isso, será aplicada a primeira regra, que nega todo o tráfego.

  • Se a prioridade da segunda regra for definida como 1000, as duas regras terão prioridades idênticas. Por isso, será aplicada a primeira regra, que nega todo o tráfego.

  • Se a prioridade da segunda regra estiver definida como um número inferior a 1000, ela terá uma prioridade mais alta, permitindo o tráfego em TCP 80 para as metas de webserver. Se não houver outras regras, a primeira regra ainda negaria outros tipos de tráfego para os destinos webserver e também negaria todo o tráfego (incluindo TCP 80) para as instâncias sem a tag de rede webserver.

O exemplo anterior demonstra como é possível usar as prioridades para criar regras allow seletivas e regras deny globais para implementar uma prática recomendada de segurança com o menor privilégio.

Ação se houver correspondência

O componente de ação de uma regra de firewall determina se ele permite ou bloqueia o tráfego, sujeito aos outros componentes da regra:

  • Uma ação allow permite conexões que correspondem a outros componentes especificados.

  • Uma ação deny bloqueia conexões que correspondem a outros componentes especificados.

Aplicação

É possível alterar a aplicação das regras de firewall definindo o estado como enabled ou disabled. Você define o estado de aplicação ao criar uma regra ou atualizar uma regra.

Se você não definir um estado de aplicação ao criar uma nova regra de firewall, ela será enabled automaticamente.

Casos de uso

A ativação e desativação são úteis para solucionar problemas e realizar manutenções. Altere a aplicação de uma regra de firewall nas seguintes situações:

  • Para solucionar problemas: em conjunto com a geração de registros de regras de firewall, é possível desativar temporariamente uma regra de firewall para determinar se ela é responsável por bloquear ou permitir tráfego. Isso é útil para situações em que várias regras de firewall se aplicam ao mesmo tráfego. Desativar e ativar regras é mais útil do que excluir e recriar regras porque nenhum dos outros componentes da regra é perdido.

  • Para manutenção: desativar regras de firewall pode simplificar a manutenção periódica. Por exemplo, é possível ativar uma regra de firewall de entrada que permita o acesso SSH apenas quando você precisar realizar manutenção usando SSH. Quando você não estiver realizando a manutenção, poderá desativar a regra.

Efeitos no tráfego existente

Quando você altera o estado de aplicação de uma regra de firewall ou cria uma nova regra enforced, a alteração se aplica apenas a novas conexões. As conexões existentes não são afetadas pela alteração.

Protocolos e portas

É possível restringir o escopo de uma regra de firewall especificando protocolos (ou protocolos e portas). Também é possível especificar um protocolo ou uma combinação de protocolos e as respectivas portas. Se você omitir os protocolos e as portas, a regra de firewall será aplicável a todo o tráfego em qualquer protocolo e em qualquer porta. Regras com base em portas de origem não são compatíveis.

Nem todos os protocolos são compatíveis com portas. Por exemplo, há portas para TCP e UDP, mas não para ICMP. O ICMP tem diferentes tipos de ICMP, mas eles não são portas e não podem ser especificados em uma regra de firewall.

Você pode usar os seguintes nomes de protocolo em regras de firewall: tcp, udp, icmp (para IPv4 ICMP), esp, ah, sctp e ipip. Para todos os outros protocolos, você precisa usar os números de protocolo IANA.

Muitos protocolos usam o mesmo nome e número no IPv4 e no IPv6, mas alguns protocolos, como o ICMP, não.

O protocolo IPv6 Hop-by-Hop não é compatível com regras de firewall.

A tabela a seguir é um resumo das combinações válidas de especificação de porta e protocolo para as regras de firewall do Google Cloud.

Especificação Exemplo Explicação
Nenhum protocolo e porta Se você não especificar um protocolo, a regra de firewall será aplicada a todos os protocolos e às respectivas portas aplicáveis.
Protocolo tcp Se você especificar um protocolo sem informações da porta, a regra de firewall será aplicada a esse protocolo e a todas as respectivas portas aplicáveis.
Protocolo e porta única tcp:80 Se você especificar um protocolo e uma única porta, a regra de firewall será aplicada a essa porta do protocolo.
Intervalo de protocolo e porta tcp:20-22 Se você especificar um protocolo e um intervalo de portas, a regra de firewall será aplicada a esse intervalo de portas para o protocolo.
Combinações icmp,tcp:80
tcp:443
udp:67-69
É possível especificar várias combinações de protocolos e portas às quais a regra de firewall se aplica. Para mais informações, consulte Criar regras de firewall.

Destino, origem, destino

As metas identificam as interfaces de rede das instâncias a que a regra de firewall se aplica.

É possível especificar os parâmetros de origem e de destino que se aplicam às origens ou aos destinos do pacote para as regras de firewall de entrada e saída. A direção da regra de firewall determina os valores possíveis para os parâmetros de origem e destino.

Parâmetro de meta

O parâmetro de meta identifica as interfaces de rede das instâncias do Compute Engine, incluindo nós do GKE e instâncias do ambiente flexível do App Engine.

É possível definir as seguintes metas para as regras de entrada ou saída. Os parâmetros de meta, origem e destino funcionam juntos, conforme descrito em Origem, destino e meta.

  • Meta padrão: todas as instâncias na rede VPC. Quando você omite uma especificação de meta, a regra de firewall se aplica a todas as instâncias na rede VPC.

  • Instâncias por tags de rede de destino. A regra de firewall se aplica apenas a instâncias na rede VPC com uma tag de rede correspondente. Para saber o número máximo de tags de rede de destino que podem ser aplicadas por regra de firewall, consulte Cotas de recursos de VPC.

  • Instâncias por contas de serviço de meta. A regra de firewall se aplica apenas a instâncias na rede VPC que usam uma conta de serviço específica. Para saber o número máximo de contas de serviço de meta que podem ser aplicadas por regra de firewall, consulte Cotas de recursos de VPC.

Para conferir informações sobre os benefícios e as limitações das tags de rede de destino e das contas de serviço de destino, consulte Filtragem por conta de serviço versus tag de rede.

Metas e endereços IP para regras de entrada

Os pacotes roteados para a interface de rede de uma VM de meta são processados com base nas seguintes condições:

  • Se a regra de firewall de entrada incluir um intervalo de endereços IP de destino, o destino do pacote precisará caber em um dos intervalos de endereços IP de destino explicitamente definidos.

  • Se a regra de firewall de entrada não incluir um intervalo de endereços IP de destino, o destino do pacote precisará corresponder a um dos seguintes endereços IP:

    • O endereço IPv4 interno principal atribuído à NIC da instância.

    • Qualquer intervalo de IP de alias configurado na NIC da instância.

    • O endereço IPv4 externo associado à NIC da instância.

    • Se IPv6 estiver configurado na sub-rede, qualquer um dos endereços IPv6 atribuídos à NIC.

    • Um endereço IP interno ou externo associado a uma regra de encaminhamento usada para balanceamento de carga de passagem, em que a instância é um back-end para um balanceador de carga de rede de passagem interna ou um balanceador de carga de rede de passagem externa.

    • Um endereço IP interno ou externo associado a uma regra de encaminhamento usada para encaminhamento de protocolos, em que a instância é referenciada por uma instância de meta.

    • Um endereço IP dentro do intervalo de destino de uma rota estática personalizada usando a instância como uma VM de próximo salto (next-hop-instance ou next-hop-address).

    • Um endereço IP no intervalo de destino de uma rota estática personalizada usando um próximo salto de balanceador de carga de rede interno (next-hop-ilb), se a VM for um back-end para esse balanceador de carga.

Metas e endereços IP para regras de saída

O processamento de pacotes emitidos da interface de rede de uma meta depende da configuração de encaminhamento de IP na VM de meta. O encaminhamento de IP é desativado por padrão.

  • Quando a VM de meta tem o encaminhamento de IP desativado, a VM pode emitir pacotes com as seguintes fontes:

    • O endereço IPv4 interno principal da NIC de uma instância.

    • Qualquer intervalo de IP de alias configurado na NIC de uma instância.

    • Se IPv6 estiver configurado na sub-rede, qualquer um dos endereços IPv6 atribuídos à NIC.

    • Um endereço IP interno ou externo associado a uma regra de encaminhamento, para balanceamento de carga de passagem ou encaminhamento de protocolo, se a instância for um back-end de um balanceador de carga de rede de passagem interna, um balanceador de carga de rede de passagem externa ou é referenciada por uma instância de destino.

    Se a regra de firewall de saída incluir intervalos de endereços IP de origem, as VMs de meta ainda estarão limitadas aos endereços IP de origem mencionados anteriormente, mas o parâmetro de origem poderá ser usado para refinar esse conjunto (recurso de visualização). O uso de um parâmetro de origem sem ativar o encaminhamento de IP não expande o conjunto de possíveis endereços de origem do pacote.

    Se a regra de firewall de saída não incluir um intervalo de endereços IP de origem, todos os endereços IP de origem mencionados anteriormente serão permitidos.

  • Quando a VM de meta tem o encaminhamento de IP ativado, a VM pode emitir pacotes com endereços de origem arbitrários. Você pode usar o parâmetro de origem para definir com mais precisão o conjunto de origens de pacotes permitidas.

Parâmetro de origem

Os valores dos parâmetros de origem dependem da direção da regra de firewall.

Origens das regras de entrada

Você pode usar as seguintes origens para regras de firewall de entrada:

  • Intervalo de origem padrão: quando você omite uma especificação de origem em uma regra de entrada, o Google Cloud usa o intervalo de endereço de origem IPv4 padrão 0.0.0.0/0 (qualquer endereço IPv4). O valor padrão não inclui origens IPv6.

  • Intervalos IPv4 de origem: lista de endereços IPv4 no formato CIDR.

  • Intervalos IPv6 de origem: uma lista de endereços IPv6 no formato CIDR.

  • Tags de rede de origem: uma ou mais tags de rede que identificam interfaces de rede de instâncias de VM na mesma rede VPC da regra de firewall. Para saber o número máximo de tags de rede de origem por regra de firewall, consulte Cotas de recursos de VPC. Para conferir detalhes sobre endereços de origem de pacotes ao usar essa especificação de origem implícita, consulte Como tags de rede de origem e contas de serviço de origem implicam origens de pacotes.

  • Contas de serviço de origem: uma ou mais contas de serviço que identificam interfaces de rede de instâncias de VM na mesma rede VPC que a regra de firewall. Para saber o número máximo de contas de serviço de origem por regra de firewall, consulte Cotas de recursos da VPC. Para conferir detalhes sobre endereços de origem de pacotes ao usar essa especificação de origem implícita, consulte Como tags de rede de origem e contas de serviço de origem implicam origens de pacotes.

  • Uma combinação de origem válida: para todas as combinações a seguir, o conjunto de origem efetivo é a união dos endereços IPv4 ou IPv6 especificados explicitamente e os intervalos de endereços IP implícitos pela tag de rede de origem ou pela conta de serviço de origem:

    • Uma combinação de intervalos IPv4 de origem e tags de rede de origem.
    • Uma combinação de intervalos IPv6 de origem e tags de rede de origem.
    • Uma combinação de intervalos IPv4 de origem e contas de serviço de origem.
    • Uma combinação de intervalos IPv6 de origem e contas de serviço de origem.

Como as tags da rede de origem e as contas de serviço de origem implicam origens de pacote

Quando uma regra de firewall de entrada usa uma tag de rede de origem, os pacotes precisam ser emitidos em uma interface de rede que atenda aos seguintes critérios:

  • A interface de rede usa a mesma rede VPC que a regra de firewall.
  • A interface de rede é associada a uma VM que tem uma tag de rede que corresponde à tag de rede de origem da regra de firewall.

Quando uma regra de firewall de entrada usa uma conta de serviço de origem, os pacotes precisam ser emitidos em uma interface de rede que atenda aos seguintes critérios:

  • A interface de rede usa a mesma rede VPC que a regra de firewall.
  • A interface de rede é associada a uma VM que tem uma conta de serviço correspondente à conta de serviço de origem da regra de firewall.

Além de especificar uma interface de rede, quando uma regra de firewall de entrada usa uma tag de rede de origem ou uma conta de serviço de origem, os pacotes emitidos pela interface de rede da VM precisam usar um dos seguintes endereços IP de origem válidos:

  • O endereço IPv4 interno principal da interface de rede.
  • Todos os endereços IPv6 atribuídos a essa interface de rede.

Se uma regra de firewall de entrada também contiver intervalos de endereços IP de destino, a interface de rede vinculada a uma tag de rede será resolvida para a mesma versão de IP que o intervalo de IP de destino.

Nenhum outro endereço IP de origem do pacote está implícito ao usar contas de serviço de origem ou tags de rede de origem. Por exemplo, os intervalos de IP de alias e o endereço IPv4 externo associados à interface de rede são excluídos. Se você precisar criar regras de firewall de entrada com origens que incluam intervalos de endereços IP de alias ou endereços IPv4 externos, use intervalos de endereços IPv4 de origem.

Origens para regras de saída

Você pode usar as seguintes origens para regras de firewall de saída:

  • Padrão: implícito pela meta. Se você omitir o parâmetro de origem de uma regra de saída, as origens de pacotes serão definidas implicitamente, conforme descrito em Metas e endereços IP para regras de saída.

  • Intervalos IPv4 de origem: uma lista de endereços IPv4 no formato CIDR.

  • Intervalos IPv6 de origem: uma lista de endereços IPv6 no formato CIDR.

Siga estas diretrizes para adicionar intervalos de endereços IP de origem às regras de saída:

  • Se uma interface de VM tiver endereços IPv4 internos e externos atribuídos, apenas o endereço IPv4 interno será usado durante a avaliação da regra.

  • Se você especificar os parâmetros de origem e de destino em uma regra de saída, use a mesma versão de IP para os dois parâmetros. É possível usar um intervalo de endereços IPv4 ou IPv6, mas não ambos. Para detalhes, consulte Destinos para regras de saída.

Parâmetro de destino

Os destinos podem ser especificados usando intervalos de endereços IP, que são compatíveis com as regras de entrada e saída. O comportamento de destino padrão depende da direção da regra.

Destinos para regras de entrada

Você pode usar os seguintes destinos para regras de firewall de entrada:

  • Padrão: implícito pela meta. Se você omitir o parâmetro de destino de uma regra de entrada, os destinos de pacote são definidos implicitamente, conforme descrito em Metas e endereços IP para regras de entrada.

  • Intervalos IPv4 de destino: uma lista de endereços IPv4 no formato CIDR.

  • Intervalos IPv6 de destino: uma lista de endereços IPv6 no formato CIDR.

Siga estas diretrizes para adicionar intervalos de endereços IP de destino às regras de entrada:

  • Se uma interface de VM tiver endereços IPv4 internos e externos atribuídos, apenas o endereço IPv4 interno será usado durante a avaliação da regra.

  • Se você especificar os parâmetros de origem e de destino em uma regra de entrada, eles serão resolvidos na mesma versão do IP que o intervalo de endereços IP de destino. Para saber mais sobre como definir origens para regras de entrada, consulte Fontes para regras de entrada.

Destinos para regras de saída

Você pode usar os seguintes destinos para regras de firewall de saída:

  • Intervalo de destino padrão. Quando você omite uma especificação de destino em uma regra de saída, o Google Cloud usa o intervalo de endereços de destino IPv4 padrão 0.0.0.0/0 (qualquer endereço IPv4). O valor padrão não inclui destinos IPv6.

  • Intervalos IPv4 de destino: uma lista de endereços IPv4 no formato CIDR.

  • Intervalos IPv6 de destino: uma lista de endereços IPv6 no formato CIDR.

Filtragem de origem e meta por conta de serviço

É possível usar contas de serviço para criar regras de firewall que são mais específicas por natureza:

  • Para regras de entrada e saída, é possível usar contas de serviço para especificar metas.

  • Para regras de entrada, é possível especificar a origem dos pacotes de entrada como o endereço IP interno primário de qualquer VM na rede em que ela usa uma conta de serviço específica.

A conta de serviço precisa ser criada no mesmo projeto que a regra de firewall antes de criar uma regra de firewall que dependa dela. O sistema não impede que você criar uma regra que use uma conta de serviço de um projeto diferente, mas a regra não será aplicada se a conta de serviço não existir no projeto da regra de firewall.

.

As regras de firewall que usam contas de serviço para identificar instâncias se aplicam a novas instâncias criadas e associadas à conta de serviço e a instâncias já existentes se você alterar as contas de serviço delas. É necessário parar e reiniciar a instância para alterar a conta de serviço associada a ela. É possível associar contas de serviço a instâncias individuais e a modelos de instâncias usados por grupos de instâncias gerenciadas.

Filtragem por conta de serviço versus tag de rede

Nesta seção, destacaremos os principais pontos a serem considerados ao decidir se você vai usar contas de serviço ou tags de rede para definir metas e origens (para regras de entrada).

Se você precisar de um controle rigoroso sobre como as regras de firewall são aplicadas às VMs, use contas de serviço de destino e contas de serviço de origem em vez de tags de rede de destino e tags de rede de origem:

  • Uma tag de rede é um atributo arbitrário. Uma ou mais tags de rede podem ser associadas a uma instância por qualquer principal do gerenciamento de identidade e acesso (IAM) que tenha permissão para editá-la. Os principais do IAM com o papel de administrador da instância do Compute Engine de um projeto têm essa permissão. Os principais do IAM que podem editar uma instância podem alterar as tags de rede, o que pode alterar o conjunto de regras de firewall aplicáveis para essa instância.

  • Uma conta de serviço representa uma identidade associada a uma instância. Apenas uma conta de serviço pode ser associada a uma instância. Você define o acesso à conta de serviço controlando a concessão do papel Usuário da conta de serviço a outros principais do IAM. Para que um principal do IAM inicie uma instância usando uma conta de serviço, esse principal precisa ter a função Usuário da conta de serviço pelo menos para essa conta e permissões adequadas para criar instâncias (por exemplo, ter a papel de administrador de instâncias do Compute Engine para o projeto).

Não é possível combinar contas de serviço e tags de rede em qualquer regra de firewall:

  • Não é possível usar contas de serviço de destino e tags de rede de destino juntas em qualquer regra de firewall (de entrada ou saída).

  • Se você especificar os destinos por tag de rede de destino ou por conta de serviço de destino, as origens a seguir serão inválidas para regras de firewall de entrada.

    Destinos Origens inválidas
    Tags de rede de destino Contas de serviço de origem

    Combinação de intervalos de IP de origem e contas de serviço de origem
    Conta de serviço de destino Tags de rede de origem

    Combinação de intervalos de IP de origem e tags de rede de origem

Veja a seguir considerações operacionais para contas de serviço e tags de rede.

  • É necessário parar e reiniciar a instância para alterar a conta de serviço associada a ela. A adição ou remoção de tags de rede pode ser feita enquanto a instância está em execução.

  • Há um número máximo de contas de serviço de meta, contas de serviço de origem, tags de rede de meta e tags de rede de origem que podem ser especificadas para regras de firewall. Para mais informações, consulte Cotas de recursos de VPC.

  • Se você identificar instâncias por tag de rede, a regra de firewall será aplicada ao endereço IP interno primário da instância.

  • As regras de firewall da conta de serviço se aplicam ao nó do GKE, não ao pod do GKE.

Papéis e permissões

A tabela a seguir descreve as permissões do Identity and Access Management (IAM) necessárias para trabalhar com regras de firewall da VPC.

Tarefa Permissão necessária Exemplo de papel
Criar uma regra de firewall compute.firewalls.create Administrador de segurança do Compute
(roles/compute.securityAdmin)
Excluir uma regra de firewall compute.firewalls.delete Administrador de segurança do Compute
(roles/compute.securityAdmin)
Fazer alterações nas regras de firewalls compute.firewalls.update Administrador de segurança do Compute
(roles/compute.securityAdmin)
Ver detalhes de uma regra de firewall compute.firewalls.get Leitor da Rede do Compute
(roles/compute.networkViewer
Ver uma lista de regras de firewall compute.firewalls.list Leitor da Rede do Compute
(roles/compute.networkViewer

Casos de uso

Os casos de uso a seguir demonstram como as regras de firewall funcionam. Nos exemplos, todas as regras de firewall estão ativadas.

Casos de entrada

As regras de firewall de entrada controlam as conexões recebidas de uma origem para as instâncias de meta na sua rede VPC. A origem de uma regra de entrada pode ser definida como uma das seguintes opções:

  • Intervalo de endereços IPv4 ou IPv6. o padrão é qualquer endereço IPv4 (0.0.0.0/0)
  • Outras instâncias na rede VPC identificadas por tags de rede
  • Outras instâncias na rede VPC identificadas pela conta de serviço
  • Outras instâncias na rede VPC identificadas pelo intervalo de endereços IPv4 ou IPv6 e pela tag de rede
  • Outras instâncias na rede VPC identificadas pelo intervalo de endereços IPv4 ou IPv6 e pela conta de serviço

A origem padrão é qualquer endereço IPv4 (0.0.0.0/0). Se você quiser controlar as conexões de entrada de origens fora da rede VPC, incluindo outras origens na Internet, use um intervalo de endereços IPv4 no formato CIDR.

Regras de entrada com uma ação allow permitem o tráfego de entrada com base nos outros componentes da regra. Além de especificar a origem e a meta da regra, é possível limitar a aplicação da regra a protocolos e portas específicos. Da mesma forma, as regras de entrada com uma ação deny podem ser usadas para proteger instâncias bloqueando o tráfego de entrada com base nos componentes da regra de firewall.

Exemplos de entrada

A Figura 1 ilustra alguns exemplos em que as regras de firewall podem controlar as conexões de entrada. Os exemplos usam o parâmetro meta nas atribuições de regras para aplicar regras a instâncias específicas.

Neste exemplo de rede VPC, as regras de permissão de firewall de entrada substituem a regra implícita de negação de entrada em algumas VMs.
Figura 1. Neste exemplo de rede VPC, as regras de firewall de permissão de entrada substituem a regra implícita de negação de entrada para algumas VMs (clique para ampliar).
  • Uma regra de entrada com prioridade 1000 é aplicável à VM 1. Essa regra permite o tráfego TCP de entrada de qualquer origem (0.0.0.0/0). O tráfego TCP de outras instâncias na rede VPC é permitido, sujeito às regras de saída aplicáveis para essas outras instâncias. A VM 4 pode se comunicar com a VM 1 por meio de TCP porque a VM 4 não tem uma regra de saída bloqueando essa comunicação (somente a regra implícita "permitir saída" é aplicável). Como a VM 1 tem um IP externo, essa regra também permite o tráfego TCP de entrada de hosts externos na Internet e da VM 2 por meio de endereços IP externos.

  • A VM 2 não tem uma regra de firewall de entrada especificada. Portanto, a regra implícita "negar entrada" bloqueia todo o tráfego de entrada. As conexões de outras instâncias da rede são bloqueadas, independentemente das regras de saída para as outras instâncias. Como a VM 2 tem um IP externo, há um caminho para ele a partir de hosts externos na Internet, mas a regra implícita "negar entrada" bloqueia também o tráfego de entrada externo.

  • Uma regra de entrada com prioridade 1000 é aplicável à VM 3. Essa regra permite o tráfego TCP de instâncias na rede com a tag de rede client, como VM 4. O tráfego TCP da VM 4 para a VM 3 é permitido porque a VM 4 não tem uma regra de saída bloqueando essa comunicação (somente a regra implícita "permitir saída" é aplicável). Como a VM 3 não tem um IP externo, não há nenhum caminho para ela de hosts externos na Internet.

Casos de saída

As regras de firewall de saída controlam as conexões de saída de instâncias de meta na rede VPC. As regras de saída com uma ação allow permitem o tráfego de instâncias com base nos outros componentes da regra. Por exemplo, é possível permitir o tráfego de saída para destinos específicos, como um intervalo de endereços IPv4, em protocolos e portas especificados por você. Da mesma forma, as regras de saída com uma ação deny bloqueiam o tráfego com base nos outros componentes da regra.

Cada regra de saída precisa de um destino. O destino padrão é qualquer endereço IPv4 (0.0.0.0/0), mas é possível criar um destino mais específico usando um intervalo de endereços IPv4 ou IPv6 no formato CIDR. Ao especificar um intervalo de endereços IPv4, você controla o tráfego para instâncias na rede e para destinos fora da rede, incluindo destinos na Internet.

Exemplos de saída

A Figura 2 ilustra alguns exemplos em que as regras de firewall podem controlar as conexões de saída. Os exemplos usam o parâmetro meta nas atribuições de regras para aplicar regras a instâncias específicas.

Neste exemplo de rede VPC, as regras de negação de firewall de saída substituem a regra implícita de permissão de saída para algumas VMs.
Figura 2. Neste exemplo de rede VPC, as regras de firewall de negação de saída substituem a regra implícita de permissão de saída para algumas VMs (clique para ampliar).
  • A VM 1 não tem uma regra de firewall de saída especificada. Portanto, a regra implícita "permitir saída" permite que ela envie tráfego para qualquer destino. As conexões com outras instâncias da rede VPC são permitidas, sujeitas às regras de entrada aplicáveis para essas outras instâncias. A VM 1 pode enviar tráfego para a VM 4 porque a VM 4 tem uma regra de entrada que permite o tráfego recebido de qualquer intervalo de endereços IP. Como a VM 1 tem um endereço IP externo, ela pode enviar tráfego para hosts externos na Internet. As respostas de entrada ao tráfego enviado pela VM 1 são permitidas porque as regras de firewall funcionam com estado.

  • Uma regra de saída com prioridade 1000 é aplicável à VM 2. Essa regra nega todo o tráfego de saída para todos os destinos (0.0.0.0/0). O tráfego de saída para outras instâncias na rede VPC é bloqueado, independentemente das regras de entrada aplicadas às outras instâncias. Ainda que a VM 2 tenha um endereço IP externo, esta regra de firewall bloqueia o tráfego de saída para hosts externos na Internet.

  • Uma regra de saída com prioridade 1000 é aplicável à VM 3. Essa regra bloqueia o tráfego TCP de saída para qualquer destino no intervalo de IP 192.168.1.0/24. Mesmo que as regras de entrada para VM 4 permitam todo o tráfego recebido, a VM 3 não pode enviar o tráfego TCP para a VM 4. No entanto, a VM 3 é livre para enviar o tráfego UDP para a VM 4 porque a regra de saída se aplica apenas ao protocolo TCP.

    Além disso, a VM 3 pode enviar qualquer tráfego para outras instâncias na rede VPC fora do intervalo de IP 192.168.1.0/24, desde que essas outras instâncias tenham regras de entrada para permitir esse tráfego. Por não ter um endereço IP externo, ela não tem um caminho para enviar tráfego para fora da rede VPC.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho do Cloud NGFW em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Teste o Cloud NGFW gratuitamente