Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Regras de segurança

Esta página explica 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 de saída da Web. É possível usar 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 de URL, para garantir que apenas o tráfego HTTP/S aprovado saia da rede.

As regras de segurança do 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) ou conta de serviço específica.
- 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 do gateway oferecem controle granular. Essas regras permitem aplicar padrões de segurança diferentes em toda a organização usando definições claras e estruturadas.

Regras de correspondência de host

O Secure Web Proxy usa a correspondência de nome do host para verificar o domínio de destino. O processo de verificação varia dependendo de 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 contra o cabeçalho da conexão HTTP. Se você usar [atributos do Application Matcher](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) para inspeção TLS, o proxy vai verificar o nome do host primeiro no nível da conexão e depois no nível do aplicativo.
Modo de próximo salto	Para tráfego criptografado, o proxy verifica o nome do host de destino no 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 do host enviadas pelo cliente são extraídas corretamente e verificadas 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 no campo `host` no cabeçalho `CONNECT` padrão da solicitação HTTP.	No campo `sessionMatcher`, use `host() == "example.com"`.
HTTPS criptografado (sem inspeção Transport Layer Security (TLS) )	A correspondência de host não é possível no nível do aplicativo nem da sessão. Isso ocorre porque os detalhes da solicitação são criptografados e o `destination.ip` atributo não é compatível. É necessário usar controles de política mais amplos, como a correspondência de identidade de origem, ou ativar a inspeção 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 TLS.
HTTPS criptografado (com inspeção TLS)	Para inspecionar a solicitação completa, é necessário usar o Session Matcher e o Application Matcher.	1. Defina uma regra geral do Session Matcher 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 definidos. 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).

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 a o campo `host` no cabeçalho da solicitação HTTP padrão.	No campo `sessionMatcher`, use `host() == "example.com"`.
HTTPS criptografado (sem inspeção TLS)	O Secure Web Proxy verifica o nome do host no 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 TLS)	Para inspecionar a solicitação completa, é necessário usar o Session Matcher e o Application Matcher.	1. Defina uma regra geral do Session Matcher 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 (TCP) permitem controlar o tráfego que não é padrão da Web, 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 tráfego malicioso e gerenciar aplicativos não da Web que usam TCP.

Se a carga de trabalho (como aplicativos e serviços) usar o Secure Web Proxy como próximo salto, a aplicação de regras de proxy TCP será benéfica. O redirecionamento baseado em rota direciona o tráfego não HTTP(S) e não da Web para a instância do Secure Web Proxy. Ao fazer isso, é possível bloquear o tráfego de saída para 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 o aplicativo proteja o tráfego 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, é possível impedir o uso não autorizado de outras portas TCP para transferência de dados ou atividades maliciosas. Isso é útil principalmente quando suas cargas de trabalho usam o Secure Web Proxy como próximo salto para protocolos não da Web.

Para implementar regras de proxy TCP e criar uma regra de tráfego de permissão ou bloqueio para o aplicativo, especifique a porta de destino. Opcionalmente, é possível incluir 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 de upstream para a qual 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.iam.gserviceaccount.com')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	booleano	`True`, se `IP_ADDRESS` estiver contido em `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 uma Secure Web Proxy gatewaySecurityPolicyRule usando uma expressão CEL para permitir todo o tráfego TCP para a porta 22. É possível usar 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 configuradas precisam ter uma prioridade maior (número menor) do que as regras HTTP/S para garantir que sejam avaliadas e acionadas primeiro. Para mais informações, consulte Ordem de avaliação da regra.
Ao configurar regras de proxy TCP, o atributo host do Session Matcher 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 que você adicione outras condições usando operadores lógicos, o operador lógico AND (&&) e o operador lógico OR (||), e atributos compatíveis, como source.ip. Confira 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 oferece suporte à capacidade de configurar regras de proxy para aplicativos do protocolo de datagrama 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 do gateway, realize as seguintes ações:

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

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

Console

No Google Cloud console do, acesse a página Políticas do 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 correspondam à regra.
5. No campo Status, selecione uma das seguintes opções para a aplicação da regra:
  - Ativado: 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 correspondência da sessão, como host() == "www.wikipedia.org".
  
  Para mais informações sobre a sintaxe de SessionMatcher, consulte Referência da linguagem do CEL Matcher.
7. Na seção Correspondência de aplicativo, especifique os critérios para correspondência da solicitação.
  
  Para mais informações sobre a correspondência de 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 Referência da linguagem do CEL Matcher.
```
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 TLS ativada, crie o rule.yaml arquivo conforme mostrado aqui. Para mais informações, consulte Visão geral da inspeção TLS e Ativar a inspeção 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 a correspondência de tráfego TCP, consulte Configurar regras de proxy TCP.

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

Crie a regra de 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 do gateway e as regras de segurança do gateway associadas.
O Secure Web Proxy não oferece suporte à capacidade de configurar regras para aplicativos do protocolo de datagrama do usuário (UDP). O Secure Web Proxy bloqueia o tráfego de aplicativos baseados em UDP.