O artigo genérico sobre SSL forward proxy descreve a interceptação de TLS de saída realizada por um proxy na borda da rede. O Netskope faz o mesmo trabalho, mas realoca o proxy: em vez de um appliance no data center, a interceptação acontece na nuvem do Netskope, a rede global NewEdge de data planes, e o tráfego é direcionado até lá de onde quer que o usuário esteja. Essa única mudança arquitetural é o que o torna um produto de Secure Service Edge (SSE) em vez de uma caixa, e ela muda como as peças do modelo genérico são arranjadas sem mudar a mecânica da interceptação em si.

Onde o proxy vive: direcionamento para a nuvem

Como o proxy não está na rede local, o primeiro problema é levar o tráfego até ele. O Netskope chama isso de steering (direcionamento), e sua arquitetura de referência oferece vários métodos para o caso de forward proxy (saída): o Netskope One Client em endpoints gerenciados (um agente leve que tunela tráfego de nuvem e web para a plataforma, com todo o proxy e a segurança feitos na nuvem); túneis GRE ou IPsec de um dispositivo de saída on-premises (com pelo menos dois túneis para data planes NewEdge diferentes recomendados para resiliência); e o Cloud Explicit Proxy, direcionado por um arquivo PAC, para dispositivos que não podem rodar o cliente. Quando o tráfego de proxy explícito é carregado dentro de um túnel, o Netskope chama o método de Explicit Proxy over Tunnel (EPoT). O fio comum é que todos esses entregam o tráfego web e de nuvem do usuário a uma data plane NewEdge, que é onde o forward proxy de fato fica.

Interceptação, inalterada no meio

Assim que o tráfego alcança a NewEdge, a interceptação é exatamente o modelo genérico. O Next Gen Secure Web Gateway termina o TLS do usuário, abre sua própria sessão até o destino, descriptografa, inspeciona, aplica política (filtragem web, proteção contra ameaças, DLP, controles CASB inline), e recriptografa. E depende da mesma âncora de confiança de que toda interceptação depende: a root CA do Netskope precisa ser confiável nos endpoints, ou os clientes rejeitarão os certificados reassinados. A própria documentação do Netskope é explícita em que a autenticação SAML do usuário e a inspeção SSL só são possíveis se o pacote de certificados root e intermediário do Netskope puder ser instalado nos endpoints. Para usuários remotos no Cloud Explicit Proxy, o certificado root é baixado e instalado por dispositivo. Essa é a versão hospedada na nuvem do requisito "instale a CA do proxy nos dispositivos gerenciados" do artigo genérico.

Identificando o usuário: SAML no caminho de forward proxy

Um forward proxy precisa saber quem é o usuário para aplicar política por usuário, e aqui o Netskope se apoia no SAML, e é por isso que este tópico toca o artigo sobre SAML proxy. No caminho de proxy explícito, a identidade do usuário pode ser estabelecida com um IdP SAML 2.0, configurado em Settings > Security Cloud Platform > Forward Proxy > SAML; o navegador do usuário é definido para usar a porta 8081 para isso, e a identidade autenticada então conduz a política. O Cloud Explicit Proxy simples, uma vez que um usuário é identificado, apoia-se em cookie surrogates para continuar associando as requisições subsequentes àquele usuário. Usuários remotos de localizações desconhecidas precisam autenticar no IdP antes de navegar. Esse é o uso de forward proxy do SAML (autenticar o usuário de uma sessão de saída); ele é distinto do SAML reverse proxy do Netskope, que se insere no próprio fluxo de SSO de uma aplicação SaaS para controlar o acesso de entrada a apps sancionados de forma clientless, o lado de reverse proxy que a discussão de federação do artigo sobre SAML proxy descreve.

O problema do pinning, e o Bypass + Tunnel

Sendo um forward proxy, o Netskope encontra a mesma parede que o artigo genérico descreve: aplicações com certificate pinning rejeitam o certificado reassinado e quebram. O tratamento do Netskope tem uma reviravolta útil para um proxy em nuvem. Um Bypass simples envia o tráfego direto ao seu destino, pulando o Netskope inteiramente. Mas aplicações com pinning também têm a opção de Bypass Netskope Proxy + Tunnel: o tráfego ainda é tunelado ao Netskope e sai pela sua data plane (então ainda é direcionado e ainda visível no nível de conexão), mas a descriptografia SSL e a aplicação de política são puladas para ele. Isso preserva o controle de saída e alguma visibilidade para apps com pinning que não toleram interceptação, e o Netskope recomenda o Bypass + Tunnel em vez de um bypass simples exatamente por essa razão. É a expressão de proxy em nuvem da regra do artigo genérico de que uma implantação de interceptação real é inspecionar-por-padrão mais um conjunto mantido de exceções para tráfego com pinning e de outra forma não interceptável.