Casos de uso comuns de políticas de segurança

Nesta página, você verá casos de uso comuns das políticas de segurança do Google Cloud Armor. As políticas de segurança do Google Cloud Armor podem proteger seu aplicativo com recursos como listas de permissões e negações de endereços IP e regras pré-configuradas para impedir ataques comuns da Web.

Como controlar o acesso aos aplicativos e serviços da Web

Nesta seção, apresentamos várias maneiras de usar as políticas de segurança do Google 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

Um caso de uso típico para colocar endereços IP de usuários em uma lista de permissões é quando seu balanceador de carga de aplicativo externo global ou o balanceador de carga de aplicativo clássico é acessado apenas por um conjunto específico de usuários. No exemplo a seguir, somente usuários da sua organização têm acesso permitido a serviços que estão atrás do balanceador de carga. Esses usuários têm endereços IP ou blocos de endereços atribuídos pela organização. É possível colocar esses endereços IP ou intervalos CIDR em uma lista de permissões, para que apenas esses usuários tenham acesso ao balanceador de carga.

Para controlar o acesso ao balanceador de carga de aplicativo externo global ou ao balanceador de carga de aplicativo clássico, configure uma lista de permissões com endereços IP de origem ou intervalos CIDR de origem a partir dos quais o acesso ao balanceador de carga é permitido. A seção a seguir explica melhor essa configuração.

Nesta configuração, você quer permitir que os usuários da organização com endereços IP de um intervalo de IPs acessem 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 Google Cloud Armor.
2. Na política de segurança, adicione uma regra com o intervalo à lista de permissões como a primeira regra. Essa regra tem a descrição allow [RANGE], em que [RANGE] é o intervalo de IP desejado.
3. Modifique a regra padrão na política de uma regra de permissão para uma regra de negação. A regra padrão controla o tráfego que não corresponde a nenhuma das regras anteriores. É a última regra da política. Alterar a regra de allow para deny bloqueia todo o tráfego que não é originado no intervalo na 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.

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

Use as listas de negação para criar políticas de segurança do Google Cloud Armor que rejeitam o tráfego de um endereço IP ou intervalo CIDR. Na ilustração a seguir, a política de segurança do Google Cloud Armor tem uma regra deny que bloqueia o tráfego do endereço IP 198.51.100.1, no qual um usuário mal-intencionado foi identificado.

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

Use a linguagem de regras personalizadas do Google Cloud Armor para definir uma ou mais expressões na condição de correspondência de uma regra. Quando o Google Cloud Armor recebe uma solicitação, ele a avalia com base nessas expressões. Se houver uma correspondência, a ação da regra entrará em vigor, negando ou permitindo o tráfego de entrada.

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

Para definir expressões em uma regra, use a sinalização --expression do gcloud ou o Console do Google Cloud. Para mais informações, consulte Como criar políticas, regras e expressões de segurança do Google Cloud Armor.

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')

Para mais exemplos, consulte Expressões de exemplo na referência da linguagem de regras personalizadas.

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

Use o Google Cloud Armor para proteger um servidor de origem do Cloud CDN de ataques de camada de aplicativo (L7), como a injeção de SQL (SQLi, na sigla em inglês) e o scripting em vários locais (XSS). O conteúdo armazenado em cache é estático e supostamente não representa um risco de um ataque direcionado da Web. No entanto, o servidor de origem do conteúdo subjacente pode ser um aplicativo dinâmico com vulnerabilidades de apps da Web potenciais ou conhecidas. Seus requisitos de segurança ou conformidade podem exigir a redução desses riscos para impedir que explorações de vulnerabilidades da Internet consigam atacar 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 Google 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.

Também é possível usar 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 adicionadas a uma política de segurança do Google Cloud Armor. Para adicionar esses conjuntos de expressões a uma regra, use a sinalização --expression do gcloud ou o console do Google Cloud. Para mais informações, consulte Como criar políticas, regras e expressões de segurança.

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):

evaluatePreconfiguredExpr('xss-stable')

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

evaluatePreconfiguredExpr('sqli-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') && evaluatePreconfiguredExpr('sqli-stable')

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

O Google 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 lidar com alguns dos problemas riscos de segurança de aplicativos, incluindo os identificados 10 principais do OWASP lista.

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

Para proteger uma carga de trabalho não hospedada pelo Google Cloud desses 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 Google Cloud Armor.
3. Adicione regras pré-configuradas de SQLi e XSS à política.
4. Atrele a política de segurança ao serviço de back-end criado na etapa 1.
5. Monitore a atividade do Google 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 Google Cloud Armor. Usando NEGs da Internet, o servidor de origem pode estar no local ou com um provedor de infraestrutura terceirizado.

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

Para ativar a proteção do Google 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 Google Cloud Armor.
4. Atrele 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 Google 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 Google 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 veiculado de maneira eficiente a partir do cache, um cliente mal-intencionado ou com falha pode gerar um alto volume de solicitações que resultam na ausência do cache e exige que o servidor de origem subjacente seja buscado ou {101 }gerem o conteúdo solicitado. Isso pode sobrecarregar recursos limitados e ter um impacto negativo na disponibilidade do aplicativo para todos os usuários. Crie uma política de segurança do Google Cloud Armor para corresponder à assinatura de qualquer cliente que esteja causando o problema e negar as solicitações antes que elas cheguem ao servidor de origem e afetem o desempenho.

Para fazer isso, siga estas etapas:

1. Crie uma política de segurança do Google 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.

A seguir

• Como configurar políticas de segurança
• Saiba mais sobre a linguagem das regras personalizadas
• Ajustar regras do WAF