Ordem de avaliação das regras

A avaliação de regras determina se um pedido Web deve ser permitido ou recusado através das regras que define na sua política. Considera os seguintes atributos para tomar as suas decisões:

  • Prioridade de uma regra: os números inteiros mais baixos indicam prioridades mais elevadas.
  • SessionMatcher: corresponde aos seguintes atributos ao nível da sessão:
    • Endereço IP da máquina de origem
    • Conta de serviço da máquina de origem
    • Etiqueta segura da máquina de origem
    • Nome do anfitrião da máquina de destino
  • ApplicationMatcher: corresponde aos seguintes atributos do pedido HTTP:
    • URL
    • Caminho
    • Cabeçalhos do pedido

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

Como funciona a avaliação de regras

As regras são avaliadas pela seguinte ordem:

  1. As regras de prioridade elevada são avaliadas primeiro.
  2. A regra de prioridade mais elevada que corresponda aos atributos SessionMatcher e ApplicationMatcher determina a ação a tomar no tráfego.
  3. Se o pedido não corresponder aos atributos SessionMatcher e ApplicationMatcher dessa regra, é avaliada a regra seguinte com a prioridade mais alta.
  4. Este processo continua até ser encontrada uma regra que corresponda ao pedido ou todas as regras terem sido avaliadas. Se não for encontrada nenhuma correspondência, o pedido é recusado.

Antes de configurar a inspeção de TLS

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

  • Um cliente pode enviar um pedido HTTP para o servidor proxy. O pedido é, em seguida, avaliado através de todos os dados disponíveis, incluindo o nome do anfitrião, a identidade de origem, os cabeçalhos HTTP e o caminho.

    Se o pedido for permitido, o tráfego HTTP é enviado para o destino. No entanto, se o pedido for recusado, o tráfego HTTP não pode passar.

  • Um cliente pode enviar ao proxy um pedido HTTP CONNECT para estabelecer um túnel TCP para o destino. Isto é feito quando o cliente quer enviar tráfego TCP arbitrário ou estabelecer uma ligação TLS ponto a ponto com o destino através do proxy, tal 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 resultar na permissão do tráfego, é estabelecido um túnel para o destino e o tráfego é encaminhado por proxy TCP. Isto aplica-se ao tráfego HTTPS e TCP.

  • Se as regras de prioridade mais elevada não conseguirem determinar a ação a tomar num pedido, a avaliação das regras continua. Se a avaliação avançar para uma regra com um atributo ApplicationMatcher, o tráfego em túnel é interpretado como HTTP ou HTTPS.

    Se os dados subjacentes não forem HTTP ou HTTPS, a ligação falha.

    Se os dados subjacentes forem HTTP, os pedidos são avaliados, incluindo o nome de anfitrião, a identidade de origem, os cabeçalhos HTTP e o caminho. Com base no resultado da avaliação, o tráfego é permitido ou recusado.

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

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

    • O sinalizador de inspeção TLS está ativado.
    • O tráfego corresponde aos atributos SessionMatcher.

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

  • Se quiser permitir tráfego TCP, a regra que permite tráfego TCP tem de ter uma prioridade mais alta do que as regras que permitem tráfego HTTP.
  • As regras com o atributo ApplicationMatcher devem ter um âmbito restrito através do 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 uma inspeção TLS desnecessária do tráfego, as regras de inspeção TLS devem ter uma prioridade inferior à das regras de inspeção não TLS. Em alternativa, para falhar rapidamente no caso de tráfego sem correspondência, as regras de inspeção TLS devem ter um âmbito restrito através do atributo SessionMatcher.

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

Considere as duas regras nos exemplos seguintes.

Exemplo 1

Neste exemplo, assumimos a presença de outras regras de baixa prioridade. Considere as duas regras seguintes:

  • Regra 1

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

  • Rule 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 forma:

  • Permitir tráfego TCP, mas não permitir um tipo específico de pedido HTTP é mutuamente exclusivo porque o tráfego TCP pode conter um pedido POST.
  • O tráfego na regra 2 nunca é permitido. É recusado porque o tráfego da etiqueta 12345 para example.com é intercetado e interpretado como HTTP para avaliar o método HTTP.

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

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

    • Restrinja a regra 1 para evitar a sobreposição do tráfego permitido com o respetivo SessionMatcher atributo:

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

      Não recomendamos esta solução porque torna-se difícil manter muitas regras sobrepostas.

Exemplo 2

Considere as duas regras seguintes:

  • 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')

  • Rule 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 forma:

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

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

    • Aumente a prioridade da regra 2 para um nível superior (prioridade: 5). Como resultado, a regra 2 é aplicada antes de avaliar a regra 1 e o tráfego de bankofamerica.com é permitido sem ser inspecionado pelo TLS.

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

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

Limitações

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

  • Os servidores só são validados através de certificados de raiz públicos. O conjunto de autoridades de certificação (AC) de raiz baseia-se no Mozilla Root Program. O comportamento da validação de certificados está sujeito a alterações e corresponde à forma como os navegadores de Internet validam os certificados.

    Uma vez que a validação de back-end não é possível neste momento, não é possível intercetar o tráfego para servidores com certificados privados ou autoassinados.

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

  • Para que a inspeção TLS funcione, os clientes têm de enviar atualmente a Indicação do nome do servidor (SNI). O SNI é uma extensão da especificação TLS opcional, mas a maioria dos clientes ativa-o por predefinição.

  • A inspeção TLS não funciona se o cliente exigir o Encrypted Client Hello (ECH) (anteriormente conhecido como SNI encriptado).

    O ECH é uma norma IETF de rascunho que permite que os clientes encriptem o início do handshake TLS através de uma chave de servidor pré-estabelecida. Uma vez que a inspeção TLS está a atuar como um proxy de interceção, não tem acesso a essa chave do servidor pré-estabelecida. Como resultado, o ECH não funciona.

  • Os clientes têm de ser configurados para confiar no seu certificado de raiz privado.

  • Se remover ACs do seu conjunto de ACs privadas, são-lhe apresentados certificados em cache assinados por essa AC durante um máximo de 28 horas. Para evitar a utilização dos certificados em cache, pode atualizar a política de inspeção TLS para apontar para um novo conjunto de ACs. Como resultado, o Secure Web Proxy é forçado a gerar novos certificados.