Ordem de avaliação da regra

A avaliação de regras determina se uma solicitação da Web precisa ser permitida ou negada usando as regras definidas na sua política. Ele considera os seguintes atributos para tomar as decisões:

  • Prioridade de uma regra:os números inteiros mais baixos indicam prioridades mais altas.
  • SessionMatcher:corresponde aos seguintes atributos no nível da sessão:
    • Endereço IP da máquina de origem
    • Conta de serviço da máquina de origem
    • Tag segura da máquina de origem
    • Nome do host da máquina de destino
  • ApplicationMatcher:faz a correspondência com os seguintes atributos de solicitação HTTP:
    • URL
    • Caminho
    • Cabeçalhos de solicitação

Para uma lista de todos os atributos SessionMatcher e ApplicationMatcher, consulte Atributos disponíveis em SessionMatcher e ApplicationMatcher.

Como funciona a avaliação de regras

As regras são avaliadas na seguinte ordem:

  1. As regras de alta prioridade são avaliadas primeiro.
  2. A regra de prioridade mais alta que corresponde aos atributos SessionMatcher e ApplicationMatcher determina a ação a ser realizada no tráfego.
  3. Se a solicitação não corresponder aos atributos SessionMatcher e ApplicationMatcher dessa regra, a próxima regra com a prioridade mais alta será avaliada.
  4. Esse processo continua até que seja encontrada uma regra que corresponda à solicitação ou até que todas as regras sejam avaliadas. Se nenhuma correspondência for encontrada, a solicitação será negada.

Antes de configurar a inspeção TLS

Entenda os seguintes cenários de avaliação de regras antes de configurar a inspeção TLS:

  • Um cliente pode enviar uma solicitação HTTP para o servidor proxy. Em seguida, a solicitação é avaliada com o uso de todos os dados disponíveis, incluindo o nome do host, a identidade da origem, os cabeçalhos HTTP e o caminho.

    Se a solicitação for permitida, o tráfego HTTP será enviado para o destino. No entanto, se a solicitação for negada, o tráfego HTTP não terá permissão para passar.

  • Um cliente pode enviar ao proxy uma solicitação HTTP CONNECT para estabelecer um túnel TCP para o destino. Isso é feito quando o cliente quer enviar tráfego TCP arbitrário ou estabelecer uma conexão TLS de ponta a ponta com o destino por meio do proxy, como acontece com HTTPS.

  • Se uma regra tiver um atributo SessionMatcher correspondente e não contiver um atributo ApplicationMatcher, e a avaliação da regra resultar na permissão do tráfego, um túnel para o destino será estabelecido e o tráfego será encaminhado por proxy TCP. Isso se aplica ao tráfego HTTPS e TCP.

  • Se as regras de prioridade mais alta não conseguirem determinar a ação a ser tomada em uma solicitação, a avaliação da regra continuará. Se a avaliação avançar para uma regra com um atributo ApplicationMatcher, o tráfego encapsulado será interpretado como HTTP ou HTTPS.

    Se os dados subjacentes não forem HTTP ou HTTPS, a conexão vai falhar.

    Se os dados subjacentes forem HTTP, as solicitações serão avaliadas, incluindo o nome do host, a identidade da origem, os cabeçalhos HTTP e o caminho. Com base no resultado da avaliação, o tráfego é permitido ou negado.

  • Para o tráfego HTTPS, uma regra só será avaliada se tiver a sinalização de inspeção TLS ativada. Caso contrário, essa regra será ignorada.

  • Para o tráfego HTTPS, uma regra será inspecionada somente se as seguintes condições forem verdadeiras:

    • A sinalização de inspeção TLS está ativada.
    • O tráfego corresponde aos atributos SessionMatcher.

Recomendações para configurar regras de inspeção de TLS

  • Se você quiser permitir o tráfego TCP, a regra que permite o tráfego TCP precisa ter uma prioridade maior do que as regras que permitem tráfego HTTP.
  • As regras com o atributo ApplicationMatcher precisam ter um escopo rígido usando o atributo SessionMatcher para minimizar a interpretação de fluxos não relacionados como HTTP.
  • As regras que permitem o tráfego TLS (incluindo HTTPS), mas não fazem a inspeção TLS, podem ser interpretadas como regras de proxy TCP.
  • Para evitar uma inspeção de tráfego desnecessária, as regras de inspeção de TLS precisam ter menos prioridade do que as regras de inspeção que não são de TLS. Como alternativa, para falhar rapidamente para tráfego não correspondente, as regras de inspeção de TLS precisam ter um escopo rígido usando o atributo SessionMatcher.

Exemplos de configurações da regra de inspeção TLS

Considere as duas regras nos exemplos a seguir.

Example 1

Nesse exemplo, presumimos a presença de outras regras de menor prioridade. Considere as duas regras a seguir:

  • Regra 1

    description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

  • Regra 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

Neste exemplo, o Secure Web Proxy interpreta as duas regras da seguinte maneira:

  • Permitir o tráfego TCP, mas não permitir um tipo específico de solicitação HTTP é mutuamente exclusivo, porque o tráfego TCP pode conter uma solicitação POST.
  • O tráfego na regra 2 nunca é permitido. Ela é negada porque o tráfego da tag 12345 para example.com é interceptado e interpretado como HTTP para avaliar o método HTTP.

  • Para que a regra 2 entre em vigor, use uma das seguintes soluções:

    • Recomendado: aumente a prioridade da regra 2 para um nível mais alto (prioridade: 5).

    • Regra de escopo 1 para evitar a sobreposição do tráfego permitido com o atributo SessionMatcher:

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      Não recomendamos essa solução porque é difícil manter muitas regras sobrepostas.

Exemplo 2

Considere as duas regras a seguir:

  • Regra 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • Regra 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

Neste exemplo, o Secure Web Proxy interpreta as duas regras da seguinte maneira:

  • Todo o tráfego, incluindo o destinado a bankofamerica.com, é inspecionado para que o TLS corresponda ao request.url() da regra de alta prioridade 1.

  • Para evitar a inspeção TLS na regra 2, use uma das seguintes soluções:

    • Aumente a prioridade da regra 2 para um nível mais alto (prioridade: 5). Como resultado, a regra 2 é aplicada antes de avaliar a regra 1, e o tráfego de bankofamerica.com é permitido sem passar pela inspeção TLS.

    • Recomendado: restrinja o escopo da regra 1 para permitir a inspeção TLS especificamente para o domínio github.com. Para restringir o escopo, adicione um atributo sessionMatcher segmentado:

      sessionMatcher: host() == 'github.com'

Limitações

Considere estas limitações antes de configurar a inspeção TLS:

  • Os servidores só são verificados usando certificados raiz públicos. O conjunto de autoridade certificadora (CA, na sigla em inglês) raiz é baseado no Programa raiz do Mozilla. O comportamento da verificação de certificados está sujeito a mudanças e corresponde à forma como os navegadores da Web verificam os certificados.

    Como a verificação de back-end não é possível no momento, o tráfego para servidores com certificados particulares ou autoassinados não pode ser interceptado.

  • O Secure Web Proxy não executa verificações de lista de revogação de certificado (CRL).

  • Para que a inspeção TLS funcione, os clientes precisam enviar a indicação do nome do servidor (SNI, na sigla em inglês). A SNI é uma extensão de especificação TLS opcional, mas a maioria dos clientes a ativa por padrão.

  • A inspeção TLS não funcionará se o cliente exigir a Encrypted Client Hello (ECH) (anteriormente conhecida como SNI criptografada).

    ECH é um rascunho do padrão IETF que permite aos clientes criptografar o início do handshake de TLS usando uma chave de servidor pré-estabelecida. Como a inspeção TLS atua como um proxy de interceptação, ela não tem acesso a essa chave de servidor preestabelecida. Como resultado, o ECH não funciona.

  • Os clientes precisam ser configurados para confiar no seu certificado raiz particular.

  • Se você remover CAs do pool de CAs particulares, receberá certificados em cache assinados por essa CA por até 28 horas. Para impedir o uso dos certificados armazenados em cache, atualize sua política de inspeção de TLS para apontar para um novo pool de CAs. Como resultado, o Secure Web Proxy é forçado a gerar novos certificados.