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 política. Ele considera os seguintes atributos para tomar decisões:

  • Prioridade de uma regra:números inteiros mais baixos indicam prioridades mais altas.
  • SessionMatcher:corresponde aos seguintes atributos de nível de 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:corresponde aos seguintes atributos de solicitação HTTP:
    • URL
    • Caminho
    • Cabeçalhos de solicitação

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

Como a avaliação de regras funciona

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 tomada no tráfego.
  3. Se a solicitação não corresponder aos atributos SessionMatcher e ApplicationMatcher da regra, a próxima regra com a prioridade mais alta será avaliada.
  4. Esse processo continua até que uma regra correspondente à solicitação seja encontrada ou todas as regras sejam avaliadas. Se nenhuma correspondência for encontrada, a solicitação será negada.

Antes de configurar a inspeção de TLS

É necessário entender os seguintes cenários de avaliação de regras antes de configurar a inspeção de TLS:

  • Um cliente pode enviar uma solicitação HTTP para o servidor proxy. A solicitação é avaliada usando 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 ao destino. No entanto, se a solicitação for negada, o tráfego HTTP não poderá ser transmitido.

  • Um cliente pode enviar ao proxy uma solicitação CONNECT HTTP 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 pelo proxy, como no 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á encapsulado por TCP. Isso se aplica ao tráfego HTTPS e TCP.

  • Se as regras de prioridade mais alta não puderem determinar a ação a ser tomada em uma solicitação, a avaliação da regra continuará. Se a avaliação prosseguir para uma regra com um atributo ApplicationMatcher, o tráfego de túnel 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.

  • No caso do tráfego HTTPS, uma regra só é avaliada se tiver a flag de inspeção TLS ativada. Caso contrário, ela é ignorada.

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

    • A flag de inspeção de 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 o tráfego HTTP.
  • As regras com o atributo ApplicationMatcher precisam ter um escopo restrito 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 realizam a inspeção TLS, podem ser interpretadas como regras de proxy TCP.
  • Para evitar a inspeção TLS desnecessária do tráfego, as regras de inspeção TLS precisam ter prioridade menor do que as regras de inspeção que não são TLS. Como alternativa, para falha rápida em tráfego não correspondente, as regras de inspeção TLS precisam ter um escopo restrito usando o atributo SessionMatcher.

Exemplos de configurações de regras de inspeção de TLS

Considere as duas regras nos exemplos a seguir.

Exemplo 1

Neste exemplo, pressupomos a presença de outras regras de prioridade mais baixa. 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. A negação ocorre 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 destas 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 fica 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 a 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 da avaliação da regra 1, e o tráfego de bankofamerica.com é permitido sem ser inspecionado pelo 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 de TLS:

  • Os servidores são verificados apenas usando certificados raiz públicos. O conjunto de autoridades certificadoras raiz (ACs) é 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 certificados.

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

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

  • Para que a inspeção TLS funcione, os clientes precisam enviar a indicação de nome do servidor (SNI). O SNI é uma extensão opcional da especificação TLS, mas a maioria dos clientes a ativa por padrão.

  • A inspeção TLS não funciona se o cliente exigir ClientHello criptografado (ECH) (anteriormente conhecido como SNI criptografado).

    O ECH é um rascunho de padrão IETF que permite que os clientes criptografem o início do handshake de TLS usando uma chave de servidor preestabelecida. Como a inspeção TLS está agindo como um proxy de interceptação, ela não tem acesso à chave de servidor preestabelecida. Como resultado, o ECH não funciona.

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

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