O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Regras de segurança

Nesta página, explicamos as regras de segurança do gateway e como criá-las.

O Secure Web Proxy permite definir vários tipos de regras de segurança nas políticas de segurança do gateway para proteger o tráfego da Web de saída. Use essas regras para controlar com precisão a segurança do tráfego usando detalhes específicos da solicitação, como cabeçalhos e padrões do URL, para garantir que apenas o tráfego HTTP/S aprovado saia da rede.

As regras de segurança de gateway têm os seguintes recursos:

Cada regra é uma instrução if-then que verifica uma solicitação da Web em relação aos seguintes parâmetros:
- Identidade de origem: quem está fazendo a solicitação, como uma máquina virtual (VM) específica ou uma conta de serviço.
- Destino: para onde a solicitação está indo, como um URL de destino ou domínio como trusted-partner.com.
- Ação: a decisão de permitir ou negar o tráfego.
As regras de segurança de gateway oferecem controle granular. Com essas regras, é possível aplicar diferentes padrões de segurança na sua organização usando definições claras e estruturadas.

Regras de correspondência de host

O Secure Web Proxy usa a correspondência de nome de host para verificar o domínio de destino. O processo de verificação varia de acordo com a forma como o proxy é implantado, conforme mostrado na tabela a seguir.

Modo de implantação	Processo de verificação do host
Modo de proxy explícito	Para tráfego não criptografado, o proxy verifica o nome do host em relação ao cabeçalho de conexão HTTP. Se você usar atributos do Application Matcher para inspeção de TLS, o proxy vai verificar o nome do host primeiro no nível da conexão e depois no nível do aplicativo.
Modo do próximo salto	Para tráfego criptografado, o proxy verifica o nome do host de destino em relação ao campo de indicação de nome do servidor (SNI, na sigla em inglês) na solicitação de saída. Esse campo fica visível mesmo em conexões seguras.

Configurar regras de correspondência de host para o modo de proxy explícito

Ao implantar o Secure Web Proxy como um proxy explícito, configure regras de correspondência de host para verificar se as informações de host enviadas pelo cliente são extraídas e verificadas corretamente em relação às regras de segurança definidas. No modo de proxy explícito, os clientes são configurados ativamente para enviar o tráfego diretamente para a instância do Secure Web Proxy.

A correspondência de host no modo de proxy explícito funciona para diferentes tipos de tráfego da Web da seguinte maneira:

Tipo de tráfego	Mecanismo de correspondência	Configuração da regra
HTTP não criptografado	O Secure Web Proxy verifica o nome do host de destino em relação ao campo `host` no cabeçalho `CONNECT` padrão da solicitação HTTP.	No campo `sessionMatcher`, use `host() == "example.com"`.
HTTPS criptografado (sem inspeção de Transport Layer Security (TLS))	A correspondência de host não é possível no nível do aplicativo ou da sessão. Isso ocorre porque os detalhes da solicitação são criptografados e o atributo `destination.ip` não é compatível. É necessário usar controles de política mais amplos, como correspondência de identidade de origem, ou ativar a inspeção de TLS para filtragem baseada em host.	Para usar o Application Matcher, use a correspondência de identidade de origem, como contas de serviço, ou ative a inspeção de TLS.
HTTPS criptografado (com inspeção de TLS)	Para inspecionar a solicitação completa, use o correspondente de sessão e o correspondente de aplicativo.	1. Defina uma regra geral de correspondência de sessão que retorne `true` ou corresponda ao host de destino, como `host() == "example.com"`. 2. No campo `applicationMatcher`, adicione uma regra de host específica, como `request.host() == "example.com"`.

Configurar regras de correspondência de host para o modo de próximo salto

Ao implantar o Secure Web Proxy como próximo salto, é necessário configurar regras de correspondência de host. O tráfego é redirecionado para o proxy por uma rota de nuvem privada virtual (VPC) com base nos intervalos de endereços IP que você definir. As regras de correspondência de host garantem que o proxy identifique corretamente o host de destino verificando vários campos do tráfego, como o cabeçalho de indicação de nome do servidor (SNI, na sigla em inglês).

A correspondência de host no modo de próximo salto funciona para diferentes tipos de tráfego da Web da seguinte maneira:

Tipo de tráfego	Mecanismo de correspondência	Configuração da regra
HTTP não criptografado	O Secure Web Proxy verifica o nome do host de destino em relação ao campo `host` no cabeçalho da solicitação HTTP padrão.	No campo `sessionMatcher`, use `host() == "example.com"`.
HTTPS criptografado (sem inspeção de TLS)	O Secure Web Proxy verifica o nome do host em relação ao cabeçalho SNI na solicitação de saída, que fica visível mesmo que o restante do tráfego esteja criptografado.	No campo `sessionMatcher`, use `host() == "example.com"`.
HTTPS criptografado (com inspeção de TLS)	Para inspecionar a solicitação completa, use o correspondente de sessão e o correspondente de aplicativo.	1. Defina uma regra geral de correspondência de sessão que retorne `true` ou corresponda ao host de destino, como `host() == "example.com"`. 2. No campo `applicationMatcher`, adicione uma regra de host específica, como `request.host() == "example.com"`.

Regras de proxy TCP

As regras de proxy do protocolo TCP permitem controlar o tráfego que não é o tráfego da Web padrão, como HTTP (porta 80) ou HTTPS (porta 443). Ao configurar regras de proxy TCP, é possível permitir ou bloquear o tráfego em qualquer outra porta TCP. Essas regras ajudam a bloquear o tráfego malicioso e gerenciar aplicativos que não são da Web e usam TCP.

Se a carga de trabalho (como aplicativos e serviços) usar o Secure Web Proxy como próximo salto, aplicar regras de proxy TCP será benéfico. O redirecionamento baseado em rota direciona o tráfego não HTTP(S) e não da Web para sua instância do Secure Web Proxy. Dessa forma, é possível impedir que o tráfego de saída alcance sites externos maliciosos e gerenciar os serviços externos aos quais as cargas de trabalho de rede podem se conectar.

Configurar regras de proxy TCP

É possível configurar regras de proxy TCP para que seu aplicativo proteja o tráfego que não é da Web e aplique políticas de segurança para aplicativos que não usam HTTP/S padrão, como para as portas 80 e 443.

Ao aplicar essas regras, você pode impedir o uso não autorizado de outras portas TCP para transferência de dados ou atividades mal-intencionadas. Isso é útil principalmente quando as cargas de trabalho usam o Secure Web Proxy como próximo salto para protocolos que não são da Web.

Para implementar regras de proxy TCP e criar uma regra de permissão ou bloqueio de tráfego para seu aplicativo, especifique a porta de destino. Se quiser, inclua qualquer um dos seguintes atributos do Session Matcher para refinar os critérios da regra de permissão ou bloqueio.

A tabela a seguir fornece mais informações sobre os vários atributos que podem ser usados em uma regra de proxy TCP:

Atributo	Tipo de atributo	Descrição
`source.ip`	string	Endereço IP do cliente que enviou a solicitação.
`source.port`	string	Porta do cliente que enviou a solicitação.
`destination.port`	string	Porta upstream para onde a instância do Secure Web Proxy envia o tráfego.
`source.matchTag(SECURE_TAG)`	booleano	`True`, se a origem estiver associada a `SECURE_TAG`. O argumento é o ID permanente da tag segura, como `source.matchTag('tagValues/123456')`.
`source.matchServiceAccount(SERVICE_ACCOUNT)`	booleano	`True`, se a origem estiver associada a `SERVICE_ACCOUNT`, como `source.matchServiceAccount('x@my-project.')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	booleano	`True`, se `IP_ADDRESS` estiver contido no `IP_RANGE`, como `inIpRange(source.ip, '1.2.3.0/24')`. As máscaras de sub-rede para endereços IPv6 não podem ser maiores que `/64`.

Exemplo de regra de proxy TCP

Este exemplo mostra como definir um Secure Web Proxy gatewaySecurityPolicyRule usando uma expressão CEL para permitir todo o tráfego TCP para a porta 22. Use essa configuração ao aplicar os recursos de proxy TCP do Secure Web Proxy.

O exemplo de código a seguir mostra como definir uma regra de proxy TCP:

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

Substitua:

PROJECT_ID: ID do projeto
REGION: região da política
POLICY_NAME: nome da política
RULE_NAME: nome da regra de proxy TCP. Neste exemplo, podemos considerar o valor como allow-ssh-tcp-proxy.

Considerações importantes

Todas as regras de proxy TCP que você configurar precisam ter uma prioridade mais alta (número menor) do que as regras HTTP/S para garantir que sejam avaliadas e executadas primeiro. Para mais informações, consulte Ordem de avaliação da regra.
Ao configurar regras de proxy TCP, o atributo de correspondência de sessão host não é compatível porque as informações do host não estão disponíveis na camada TCP.
As regras de proxy TCP filtram o tráfego da Web com base apenas na porta de destino. Para melhorar a segurança da rede, recomendamos adicionar outras condições usando operadores lógicos, como o operador lógico AND (&&) e o operador lógico OR (||), além de atributos de suporte, como source.ip. Veja um exemplo de como definir uma regra de proxy TCP mais específica:
```
  // Allow port 22 from only a specific source IP range
  sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
```
O Secure Web Proxy não permite configurar regras de proxy para aplicativos do protocolo de datagramas do usuário (UDP). Como resultado, o Secure Web Proxy bloqueia o tráfego de aplicativos baseados em UDP.

Criar uma regra de segurança

Antes de criar uma regra de segurança de gateway, realize as seguintes ações:

Conclua todas as etapas de configuração inicial.
Criar uma política

Depois de criar uma regra e associá-la a uma política, use-a ao implantar o Secure Web Proxy.

Console

No console do Google Cloud , acesse a página Políticas de SWP.

Acessar as políticas do SWP
Clique no nome da política, como policy1.
Clique em Adicionar regra.
Para cada regra, faça o seguinte:
1. Em Prioridade, insira uma ordem de avaliação numérica para a regra. As regras são avaliadas da prioridade mais alta para a mais baixa, em que 0 é a mais alta.
2. No campo Nome, insira um nome para a regra.
3. No campo Descrição, insira uma descrição para a regra.
4. Em Ação, selecione uma das seguintes opções:
  - Permitir: para permitir solicitações de conexão que correspondam à regra.
  - Negar: para negar solicitações de conexão que correspondem à regra.
5. No campo Status, selecione uma das seguintes opções para a aplicação da regra:
  - Ativada: para aplicar a regra na instância do Secure Web Proxy.
  - Desativado: para não aplicar a regra na instância do Secure Web Proxy.
6. Na seção Correspondência de sessão, especifique os critérios para corresponder à sessão, como host() == "www.wikipedia.org".
  
  Para mais informações sobre a sintaxe de SessionMatcher, consulte a referência da linguagem de correspondência da CEL.
7. Na seção Correspondência de aplicativo, especifique os critérios para corresponder à solicitação.
  
  Para mais informações sobre como corresponder o tráfego TCP, consulte Configurar regras de proxy TCP.
8. Clique em Adicionar regra.

Cloud Shell

Use o editor de texto de sua preferência para criar um arquivo rule.yaml. Para mais informações sobre a sintaxe de sessionMatcher, consulte a referência da linguagem de correspondência da CEL.
```
name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
description: Allow wikipedia.org
enabled: true
priority: 1
basicProfile: ALLOW
sessionMatcher: host() == 'www.wikipedia.org'
```
Substitua:
- PROJECT_ID: ID do projeto
- REGION: região da política
- RULE_NAME: nome da regra. Neste exemplo, podemos considerar o valor como allow-wikipedia-org.
Opcional: como alternativa, se você quiser criar uma regra com a inspeção de TLS ativada, crie o arquivo rule.yaml como mostrado aqui. Para mais informações, consulte Visão geral da inspeção de TLS e Ativar a inspeção de TLS.
```
  name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
  description: Allow wikipedia.org
  enabled: true
  priority: 1
  basicProfile: ALLOW
  sessionMatcher: host() == 'www.wikipedia.org'
  applicationMatcher: request.path.contains('index.html')
  tlsInspectionEnabled: true
```
Para mais informações sobre como corresponder o tráfego TCP, consulte Configurar regras de proxy TCP.

Importante: para ativar a inspeção TLS em todas as regras criadas, defina o atributo tlsInspectionEnabled como true para cada regra que usa applicationMatcher para corresponder ao tráfego HTTPS. A inspeção de TLS da regra é limitada ao tráfego que corresponde ao atributo sessionMatcher da regra. Para mais informações, consulte Avaliação de regras de inspeção de TLS.

Crie a regra da política de segurança.

gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
    --source=rule.yaml \
    --location=REGION \
    --gateway-security-policy=policy1

Limitações

Se você criar uma política de autorização na instância do Secure Web Proxy, o proxy vai ignorar todas as políticas de segurança de gateway atuais e as regras de segurança de gateway associadas.
O Secure Web Proxy não é compatível com a configuração de regras para aplicativos do protocolo de datagramas do usuário (UDP). O Secure Web Proxy bloqueia o tráfego de aplicativos baseados em UDP.