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:os 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 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 SessionMatcher e Os atributos ApplicationMatcher determinam a ação a ser realizada. o 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 TLS

Você precisa entender os seguintes cenários de avaliação de regras antes você configura a inspeção TLS:

  • Um cliente pode enviar uma solicitação HTTP para o servidor proxy. A solicitação é avaliado usando todos os dados disponíveis, incluindo nome do host, identidade de origem, cabeçalhos HTTP e 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 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 destino por meio do proxy, como acontece com o HTTPS.

  • Se uma regra tiver um atributo SessionMatcher correspondente e não contiver um atributo ApplicationMatcher, e a avaliação da regra resulta para permitir o tráfego, um túnel para o destino é estabelecido e o tráfego é encaminhado por proxy 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 seguir para uma regra com um atributo ApplicationMatcher, então a o tráfego encapsulado é interpretado como HTTP ou HTTPS.

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

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

  • Para o tráfego HTTPS, uma regra só é avaliada quando tem a inspeção TLS flag 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

  • Para permitir o tráfego TCP, a regra que permite o tráfego TCP precisam ter uma prioridade mais alta 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 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 falhar rapidamente no tráfego não correspondente, as regras de inspeção TLS precisam ser com 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: aumentar 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 ao respectivo SessionMatcher atributo:

      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:

    • Aumentar 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: restringir 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. A raiz da autoridade certificadora (CA) tem como base Mozilla Root Program: 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 o nome do servidor indicação (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 Encrypted Client Hello (ECH) (anteriormente conhecida como SNI criptografada).

    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 os certificados armazenados em cache, atualize a política de inspeção TLS para para um novo pool de ACs. Como resultado, o Secure Web Proxy é forçado a e gerar novos certificados.