Casos de uso para políticas de segurança

Este documento descreve casos de uso comuns das políticas de segurança do Google Cloud Armor. As políticas de segurança do Cloud Armor ajudam a proteger seu aplicativo com listas de permissões e negações de endereços IP e regras pré-configuradas que impedem ataques comuns da Web.

Disponibilidade do recurso

A tabela a seguir resume a disponibilidade dos recursos do Cloud Armor com base no nível de assinatura e no tipo de balanceador de carga ou endpoint que você está protegendo.

Recurso Cloud Armor Standard Cloud Armor Enterprise Pontos de extremidade compatíveis
Proteção volumétrica contra DDoS Incluído Incluído Todos os balanceadores de carga externos, Cloud CDN e Media CDN
Regras de permissão/negação de IP Incluído Incluído Balanceador de carga de aplicativo externo, balanceador de carga de rede de proxy externo
Regras de WAF pré-configuradas Incluído Incluído Balanceador de carga de aplicativo externo, balanceador de carga de rede de proxy externo
Regras CEL personalizadas Incluído Incluído Balanceador de carga de aplicativo externo, balanceador de carga de rede de proxy externo
Proteção Adaptativa Somente geração de alertas Proteção total Balanceador de carga de aplicativo externo
Gerenciamento de bots Indisponível Incluído Balanceador de carga de aplicativo externo
Proteção avançada contra DDoS de rede Indisponível Incluído Balanceador de carga de rede de passagem externa, encaminhamento de protocolo, VM com IP público
Políticas de segurança de borda de rede Indisponível Incluído Balanceador de carga de rede de passagem externa, encaminhamento de protocolo, VM com IP público
Inteligência contra ameaças Indisponível Incluído Balanceador de carga de aplicativo externo, balanceador de carga de rede de proxy externo

Exemplos de políticas de segurança

Esta seção descreve como usar as políticas de segurança do Cloud Armor para controlar o acesso aos seus aplicativos ou serviços.

Usar listas de permissão para ativar o acesso de usuários com endereços IP específicos

Use uma lista de permissões de endereços IP para limitar solicitações a endereços IP ou intervalos CIDR específicos, como os IPs públicos das suas filiais. É possível permitir apenas o tráfego originado desses intervalos especificados.

Como restringir o acesso ao balanceador de carga de aplicativo externo usando uma lista de permissões.
Como restringir o acesso ao balanceador de carga de aplicativo externo usando uma lista de permissões (clique para ampliar).

Controle o acesso ao balanceador de carga de aplicativo externo global ou ao balanceador de carga de aplicativo clássico configurando uma lista de permissões com endereços IP ou intervalos CIDR de clientes. A seção a seguir descreve essa configuração.

Nesta configuração, você permite apenas solicitações de endereços IP de clientes em um intervalo específico para acessar o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico. Qualquer outro tráfego será negado.

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 inclua o intervalo na lista de permissões. Essa regra tem a descrição allow [RANGE], em que [RANGE] é o intervalo de IP desejado.
  3. Mude a regra padrão na política de uma regra de permissão para uma regra de negação. A regra padrão é a última da política e controla o tráfego que não corresponde a nenhuma regra anterior. Mudar essa regra para deny bloqueia todo o tráfego que não está no intervalo da lista de permissões.
  4. Associe esta política ao balanceador de carga de aplicativo externo global ou ao serviço de back-end do balanceador de carga de aplicativo clássico.

Se sua organização usa um provedor de segurança de terceiros para remover o tráfego, é possível adicionar o endereço IP do provedor de segurança a uma lista de permissões para garantir que apenas o tráfego acessado possa acessar o balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico e back-ends.

Na ilustração a seguir, o provedor terceirizado é identificado pelo intervalo CIDR 192.0.2.0/24, e esse intervalo está em uma lista de permissões.

Como restringir o acesso ao balanceador de carga de aplicativo externo usando uma lista de permissões para restringir
  o tráfego de um provedor de segurança de terceiros.
Como restringir o acesso ao balanceador de carga de aplicativo externo usando uma lista de permissões para restringir o tráfego de um provedor de segurança de terceiros (clique para ampliar).

Usar listas de bloqueio para proibir o acesso de usuários com endereços IP específicos

Use listas de negação para rejeitar o tráfego de endereços IP ou intervalos CIDR específicos. Na ilustração a seguir, 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, em que um usuário malicioso foi identificado.

Como restringir o acesso ao balanceador de carga de rede de passagem externa usando uma lista de bloqueio.
Como restringir o acesso ao balanceador de carga de rede de passagem externa usando uma lista de bloqueio (clique para ampliar).

Personalizar regras de filtragem com base nos parâmetros da camada 3 à camada 7

Defina expressões na condição de correspondência de uma regra usando a linguagem de regras personalizadas do Cloud Armor. O Cloud Armor avalia as solicitações recebidas com base nessas expressões. Se uma solicitação corresponder, a ação da regra será aplicada, negando ou permitindo o tráfego.

Os exemplos a seguir são expressões escritas na extensão do Cloud Armor do Common Expression Language (CEL). Para mais informações, consulte a referência da linguagem de regras personalizadas.

Defina expressões usando a flag --expression da Google Cloud CLI ou o consoleGoogle Cloud . Para mais informações, consulte Criar políticas, regras e expressões de segurança.

No exemplo a seguir, solicitações de 2001:db8::/32 (como seus testadores alfa) na região AU correspondem à seguinte expressão:

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

O exemplo a seguir corresponde às solicitações de 192.0.2.0/24 e a um user agent 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')

Veja mais exemplos em Exemplos de expressões na referência de linguagem de regras personalizadas.

Proteja a implantação contra ataques na camada de aplicativos e ajude a reduzir os 10 principais riscos do OWASP

O Cloud Armor ajuda a proteger os servidores de origem do Cloud CDN contra ataques de camada de aplicativo (L7), como injeção de SQL (SQLi) e scripting em vários locais (XSS). O conteúdo de um cache é estático e geralmente não representa um risco de um ataque direcionado. No entanto, o servidor de origem pode ser um aplicativo dinâmico com vulnerabilidades. Seus requisitos de segurança podem exigir a redução desses riscos para impedir que explorações ataquem o servidor de origem.

Para atenuar os riscos, siga estas etapas:

  1. Crie ou identifique um serviço de back-end com o CDN ativado.
  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 de L7.
  4. Configure um dos destinos da política de segurança para ser o serviço de back-end que você criou ou identificou na etapa 1.

Use regras pré-configuradas para detectar e bloquear ataques comuns da camada de aplicativo. Regras pré-configuradas são conjuntos de expressões predefinidos que podem ser adicionados a uma política de segurança. Para adicionar esses conjuntos de expressões a uma regra, use a flag --expression da CLI gcloud ou o console do Google Cloud . Para mais informações, consulte Como criar políticas, regras e expressões de segurança.

Por padrão, uma regra pré-configurada inspeciona até os primeiros 8 KB do corpo de uma solicitação. No entanto, é possível configurar esse limite por política. Para mais informações sobre como configurar esse limite de inspeção para um corpo de solicitação ao usar regras de WAF pré-configuradas, consulte Limitação de inspeção do corpo da solicitação.

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

O exemplo a seguir usa uma regra pré-configurada para mitigar ataques de scripting em vários locais (XSS):

evaluatePreconfiguredWaf('xss-v422-stable')

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

evaluatePreconfiguredWaf('sqli-v422-stable')

Também é possível combinar regras pré-configuradas com outras expressões. O exemplo a seguir 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-v422-stable')

Top 10 mitigações do OWASP para cargas de trabalho híbridas

O Cloud Armor oferece mitigações para os seguintes ataques, sejam eles implantados no Google Cloud, no local ou em um provedor terceirizado:

  • Injeção de SQL (SQLi)
  • Scripting em vários locais (XSS)
  • Inclusão de arquivos locais (LFI, na sigla em inglês)
  • Inclusão de arquivo remoto (RFI, na sigla em inglês)
  • Execução de código remoto (RCE, na sigla em inglês)

Use esses recursos para solucionar alguns dos riscos de segurança mais comuns em aplicativos da Web, incluindo os identificados na lista OWASP Top 10.

Adicione regras de WAF pré-configuradas a uma política de segurança para detectar e negar solicitações indesejadas da camada 7, como tentativas de SQLi ou XSS. O Cloud Armor detecta e bloqueia solicitações maliciosas na borda da infraestrutura do Google. As solicitações não são encaminhadas para o serviço de back-end, independentemente de onde ele está implantado.

Para proteger uma carga de trabalho não hospedada peloGoogle Clouddesses ataques na borda da rede do Google, siga estas etapas:

  1. Configure um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo 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 criado na etapa 1.
  5. Monitore a atividade do Cloud Armor usando o Cloud Logging, o Cloud Monitoring e as descobertas enviadas para o Security Command Center.

Defesa do servidor de origem externo do Cloud CDN contra DDoS e monitoramento da camada 7

As implantações do Cloud CDN com um servidor de origem externo podem ter a infraestrutura de borda do Google como front-end para proxy, cache e filtragem da camada 7 do Cloud Armor. Usando NEGs da Internet, o servidor de origem pode estar no local ou com um provedor de infraestrutura terceirizado.

O Cloud Armor e a infraestrutura de borda do Google mitigam ataques de L3 e L4, alertam sobre atividades suspeitas da camada 7 e negam solicitações indesejadas da camada 7 com regras personalizadas. A geração de registros e a telemetria do Cloud Armor no Cloud Logging, no Cloud Monitoring e no Security Command Center oferecem insights acionáveis para aplicativos protegidos, independentemente de onde eles são implantados.

Para ativar a proteção do Cloud Armor para servidores de origens externas da CDN, siga estas etapas:

  1. Configure um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo 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 criado na etapa 1.
  5. Acesse alertas, geração de registros e telemetria do Cloud Armor no Security Command Center, Cloud Logging e Cloud Monitoring.

Além disso, é possível usar políticas de segurança de borda para proteger o conteúdo armazenado em cache. Para mais informações sobre políticas de segurança de borda, consulte a Visão geral da política de segurança.

Controles de acesso da camada 7 e ataques de impedimento de cache

Dependendo da arquitetura do aplicativo, é possível configurar um serviço de back-end para disponibilizar solicitações para vários URLs, incluindo conteúdo armazenável em cache e não armazenável em cache. Nesses cenários de implantação, crie políticas de segurança do Cloud Armor que neguem tráfego indesejado em determinados caminhos de solicitação, mas permitam que todos os clientes acessem conteúdo estático em um caminho de solicitação diferente.

Em outras situações, mesmo que o conteúdo seja exibido no cache, um cliente malicioso pode gerar muitas solicitações que resultam em uma ausência no cache. Uma ausência no cache exige que o servidor de origem busque ou gere o conteúdo, o que pode sobrecarregar os recursos e afetar a disponibilidade. Crie uma política de segurança para corresponder às assinaturas de clientes que estão causando o problema e negar as solicitações antes que elas cheguem ao servidor de origem.

Para fazer isso, siga estas etapas:

  1. Crie uma política de segurança do Cloud Armor.
  2. Configurar uma regra; por exemplo, a regra a seguir nega o acesso a "/admin":

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')
    
  3. Atrele a política de segurança da etapa 1 ao serviço de back-end que tem o Cloud CDN ativado.

Proteção do balanceador de carga de rede de passagem externa

Se você tiver uma assinatura do Cloud Armor Enterprise, use a proteção avançada contra DDoS de rede para proteger seus balanceadores de carga de rede de passagem externa, encaminhamento de protocolo e VMs com endereços IP públicos. Esse recurso oferece mitigação inline e sempre ativa de ataques DDoS de camadas 3 e 4.

Para mais informações, consulte Visão geral da proteção avançada contra DDoS de rede.

A seguir