Exemplos de utilização comuns para políticas de segurança

Esta página apresenta exemplos de utilização comuns para as políticas de segurança do Google Cloud Armor. As políticas de segurança do Cloud Armor podem proteger a sua aplicação com funcionalidades como listas de autorizações e listas de negações de endereços IP, e regras pré-configuradas para impedir ataques Web comuns.

Controle o acesso às suas aplicações e serviços Web

Esta secção apresenta várias formas de usar as políticas de segurança do Cloud Armor para controlar o acesso às suas aplicações ou serviços.

Ative o acesso para utilizadores em endereços IP específicos com listas de autorizações

Um exemplo de utilização típico para colocar endereços IP de utilizadores numa lista de autorizações é quando o seu Application Load Balancer externo global ou Application Load Balancer clássico só é acedido por um conjunto específico de utilizadores. No exemplo seguinte, apenas os utilizadores da sua organização têm autorização para aceder aos serviços que estão atrás do equilibrador de carga. Estes utilizadores têm endereços IP ou blocos de endereços atribuídos pela sua organização. Pode colocar estes endereços IP ou intervalos CIDR numa lista de autorizações para que apenas estes utilizadores tenham acesso ao equilibrador de carga.

Controla o acesso ao balanceador de carga de aplicações externo global ou ao balanceador de carga de aplicações clássico através da configuração de uma lista de autorizações com endereços IP de origem ou intervalos CIDR de origem a partir dos quais o acesso ao seu balanceador de carga é permitido. A secção seguinte descreve mais detalhadamente esta configuração.

Nesta configuração, só quer permitir que os utilizadores da sua organização com endereços IP de um intervalo de IP acedam ao Application Load Balancer externo global ou ao Application Load Balancer clássico. Quer que todo o outro tráfego seja recusado.

Para criar esta configuração, siga estes passos:

1. Crie uma política de segurança do Cloud Armor.
2. Na política de segurança, adicione uma regra que adicione o intervalo à lista de autorizações como a primeira regra. Esta regra tem a descrição allow [RANGE], onde [RANGE] é o intervalo de IP pretendido.
3. Modificar a regra predefinida na política de uma regra de permissão para uma regra de negação. A regra predefinida rege o tráfego que não corresponde a nenhuma das regras anteriores. É a última regra na política. Alterar a regra de allow para deny bloqueia todo o tráfego que não tenha origem no intervalo na lista de autorizações.
4. Associe esta política ao Application Load Balancer externo global ou ao serviço de back-end do Application Load Balancer clássico.

Se a sua organização usar um fornecedor de segurança de terceiros para limpar o tráfego, pode adicionar o endereço IP do fornecedor de segurança a uma lista de autorizações para garantir que apenas o tráfego limpo pode aceder ao Application Load Balancer externo global ou ao Application Load Balancer clássico e aos back-ends.

Na ilustração seguinte, o fornecedor terceiro é identificado pelo intervalo CIDR 192.0.2.0/24, e este intervalo está numa lista de autorizações.

Bloqueie o acesso de utilizadores em endereços IP específicos com listas de recusa

Use listas de negação para criar políticas de segurança do Cloud Armor que rejeitam tráfego de um endereço IP ou de um intervalo CIDR. Na ilustração seguinte, a política de segurança do Cloud Armor tem uma regra deny que bloqueia o tráfego do endereço IP 198.51.100.1, onde foi identificado um utilizador malicioso.

Regras personalizadas para filtrar com base nos parâmetros da camada 3 à camada 7

Use a linguagem de regras personalizadas do Cloud Armor para definir uma ou mais expressões na condição de correspondência de uma regra. Quando o Cloud Armor recebe um pedido, avalia-o em função destas expressões. Se existir uma correspondência, a ação da regra entra em vigor, recusando ou permitindo o tráfego recebido.

Os exemplos seguintes são expressões escritas na extensão do Cloud Armor do Idioma de expressão comum (IEC). Para mais informações, consulte a referência de linguagem das regras personalizadas.

Para definir expressões numa regra, use a flag --expression do gcloud ou a Google Cloud consola. Para mais informações, consulte o artigo Criar políticas, regras e expressões de segurança do Cloud Armor.

No exemplo seguinte, os pedidos de 2001:db8::/32 (como os seus testadores alfa) na região AU correspondem à seguinte expressão:

origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')

O exemplo seguinte corresponde a pedidos de 192.0.2.0/24 e a um agente do utilizador que contém a string WordPress:

inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')

Para ver exemplos adicionais, consulte as expressões de exemplo na referência da linguagem de regras personalizadas.

Proteja a sua implementação contra ataques na camada de aplicação e ajude a mitigar os riscos do OWASP Top 10

Pode usar o Cloud Armor para proteger um servidor de origem do Cloud CDN contra ataques da camada de aplicação (L7), como injeção SQL (SQLi) e cross-site scripting (XSS). O conteúdo numa cache é estático e, presumivelmente, não representa um risco de ataque direcionado a partir da Web. No entanto, o servidor de origem do conteúdo subjacente pode ser uma aplicação dinâmica com vulnerabilidades conhecidas ou potenciais de apps para a Web. Os seus requisitos de segurança ou conformidade podem exigir que mitigue estes riscos para impedir que as explorações de vulnerabilidades da Internet ataquem com êxito o servidor de origem.

Para mitigar os riscos, siga estes passos:

1. Crie ou identifique um serviço de back-end com a RFC ativada.
2. Crie uma política de segurança do Cloud Armor.
3. Crie uma ou mais regras na política de segurança para negar ataques da camada 7.
4. Configure um dos destinos da política de segurança para ser o serviço de back-end que criou ou identificou no passo 1.

Também pode usar regras pré-configuradas para detetar e bloquear ataques comuns da camada de aplicação. As regras pré-configuradas são conjuntos de expressões predefinidos que pode adicionar a uma política de segurança do Cloud Armor. Para adicionar estes conjuntos de expressões a uma regra, use a flag --expressiongcloud ou Google Cloud consola. Para mais informações, consulte o artigo Criar políticas, regras e expressões de segurança.

Uma regra pré-configurada inspeciona, por predefinição, até aos primeiros 8 kB de um corpo do pedido. No entanto, pode configurar este limite por política. Para mais informações sobre a configuração deste limite de inspeção para um corpo de pedido quando usar regras de WAF pré-configuradas, consulte o artigo Limitação da inspeção do corpo de POST e PATCH.

Para mais informações sobre as regras pré-configuradas, consulte o artigo Regras pré-configuradas na referência de linguagem das regras personalizadas.

O exemplo seguinte usa uma regra pré-configurada para mitigar ataques de cross-site scripting (XSS):

evaluatePreconfiguredWaf('xss-stable')

O exemplo seguinte usa uma regra pré-configurada para mitigar ataques de injeção de SQL (SQLi):

evaluatePreconfiguredWaf('sqli-stable')

Também pode combinar regras pré-configuradas com outras expressões. O exemplo seguinte usa uma regra pré-configurada para mitigar ataques SQLi do intervalo de endereços IP 192.0.2.1/24:

inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-stable')

Mitigação das 10 principais OWASP para cargas de trabalho híbridas

O Cloud Armor oferece mitigações para os seguintes ataques, quer sejam implementados Google Cloud, no local ou num fornecedor de terceiros:

• Injeção SQL (SQLi)
• Cross-site scripting (XSS)
• Inclusão de ficheiros locais (LFI)
• Inclusão de ficheiros remotos (RFI)
• Execução remota de código (RCE)

Pode usar estas capacidades para resolver alguns dos riscos de segurança de aplicações Web mais comuns, incluindo os riscos identificados na lista OWASP Top 10.

As regras de WAF pré-configuradas do Cloud Armor podem ser adicionadas a uma política de segurança para detetar e negar pedidos indesejáveis da camada 7 que contenham tentativas de SQLi ou XSS. O Cloud Armor deteta pedidos maliciosos e rejeita-os no limite da infraestrutura da Google. Os pedidos não são encaminhados para o serviço de back-end, independentemente de onde o serviço de back-end está implementado.

Para defender uma carga de trabalho não alojada na Google destes ataques na extremidade da rede da Google, siga estes passos:Google Cloud

1. Configure um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico com um serviço de back-end que tenha um NEG da Internet como back-end.
2. Crie uma política de segurança do Cloud Armor.
3. Adicione regras de SQLi e XSS pré-configuradas à política.
4. Anexe a política de segurança ao serviço de back-end que criou no passo 1.
5. Monitorize a atividade do Cloud Armor através do Cloud Logging, do Cloud Monitoring e das conclusões enviadas para o Security Command Center.

Defesa contra DDoS e monitorização da camada 7 do servidor de origem externo da RFC do Google Cloud

As implementações da RFC na nuvem com um servidor de origem externo podem ter a infraestrutura de limite da Google como o front-end para o proxy, o armazenamento em cache e a filtragem da camada 7 do Cloud Armor. Usando NEGs de Internet, o servidor de origem pode estar localizado no local ou com um fornecedor de infraestrutura de terceiros.

O Cloud Armor e o resto da infraestrutura de limite da Google mitigam e rejeitam ataques L3/L4, enviam alertas sobre atividade suspeita na camada 7 e estão prontos para negar pedidos indesejados na camada 7 com regras personalizadas. O registo e a telemetria do Cloud Armor no Cloud Logging, Cloud Monitoring e Security Command Center fornecem estatísticas acionáveis para aplicações protegidas, independentemente da respetiva implementação.

Para ativar a proteção do Cloud Armor para servidores de origens externas da RFC, siga estes passos:

1. Configure um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico com um serviço de back-end que tenha um NEG da Internet como back-end.
2. Ative o Cloud CDN para este serviço de back-end.
3. Crie uma política de segurança do Cloud Armor.
4. Anexe a política de segurança ao serviço de back-end que criou no passo 1.
5. Aceda a alertas, registos e telemetria do Cloud Armor no Security Command Center, Cloud Logging e Cloud Monitoring.

Além disso, pode usar políticas de segurança de limite para proteger o conteúdo armazenado na cache. Para mais informações sobre as políticas de segurança de limite, consulte a vista geral da política de segurança.

Controlos de acesso da camada 7 e ataques de eliminação da cache

Consoante a arquitetura da aplicação, pode configurar um serviço de back-end para publicar pedidos de vários URLs, incluindo conteúdo memorizável em cache e não memorizável em cache. Nestes cenários de implementação, crie políticas de segurança do Cloud Armor que neguem tráfego indesejável em determinados caminhos de pedidos, mas permitam que todos os clientes acedam a conteúdo estático num caminho de pedido diferente.

Noutras situações, embora o conteúdo esteja a ser servido de forma eficiente a partir da cache, um cliente malicioso ou com falhas pode gerar um elevado volume de pedidos que resultam numa falha de cache e exigem que o servidor de origem subjacente obtenha ou gere o conteúdo pedido. Isto pode sobrecarregar os recursos limitados e ter um impacto negativo na disponibilidade da aplicação para todos os utilizadores. Pode criar uma política de segurança do Cloud Armor para fazer corresponder a assinatura de todos os clientes que estão a causar o problema e negar os pedidos antes de chegarem ao servidor de origem e afetarem o desempenho.

Para o fazer, siga estes passos:

1. Crie uma política de segurança do Cloud Armor.

2. Configure uma regra; por exemplo, a seguinte regra nega o acesso a "/admin":

   request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')
   

3. Anexe a política de segurança do passo 1 ao serviço de back-end que tem o Cloud CDN ativado.

O que se segue?

• Configure políticas de segurança
• Saiba mais acerca da linguagem das regras personalizadas
• Ajuste as regras da WAF