Convergência de vários tipos de proxies para SASE

Por que proxies no SASE?

Já se foi o tempo em que a segurança em nível de pacote era considerada suficiente.
Devido à sofisticação dos ataques, está se tornando imperativo fazer uma inspeção profunda do conteúdo para vários tipos de proteção.
O acesso com reconhecimento de identidade é um requisito fundamental devido à força de trabalho distribuída e aos aplicativos distribuídos.
Esta postagem do blog analisa detalhadamente os requisitos relacionados ao acesso com reconhecimento de identidade.
A inspeção profunda de conteúdo e o acesso com reconhecimento de identidade no nível da API/recurso de aplicativo exigem o encerramento das conexões do cliente, a inspeção de conteúdo para detecção de ameaças e controle de acesso e a originação de conexões por meio de proxies.
Por isso, muitas soluções SASE implementam a segurança por meio de proxies.

Tipos de proxy

O senhor já deve ter ouvido falar de vários tipos de proxies: Forward, Reverse e Transparent.
A principal funcionalidade de todos os tipos de proxies é a mesma.
A funcionalidade de alto nível está listada aqui.

• Obter tráfego
• Encerrar conexões de clientes.
• Autenticar clientes.
• Obter a identidade do usuário.
• Originar conexões para servidores.
• Decodificação e criptografia de TLS
• Verifique a reputação do IP e do domínio.
• Realizar controles de acesso baseados em identidade.
• Executar as funções do CASB.
• Verifique se há perda de dados e evite a perda.
• Executar a função de detecção/prevenção de intrusão.
• Executar a função de firewall de aplicativo da Web.
• Procure por malware e indicadores de exploração no tráfego e aja.

A diferença entre eles se baseia nos seguintes fatores:

• Obtenção de tráfego para inspeção de ameaças e controle de acesso
• Autenticação de usuários e identificação dos usuários

Tipo de proxy transparente

Nesse tipo, clientes e servidores não sabem da presença de proxies.
Esses proxies capturam o tráfego dos roteadores de rede pelos quais o tráfego está passando.
É responsabilidade dos administradores de rede garantir que o tráfego dos usuários do escritório e o tráfego dos usuários de WFH sejam direcionados por meio de entidades de roteamento corporativo.
Para garantir que o tráfego dos usuários de WFH passe pelos roteadores da empresa, é prática comum usar clientes VPN para se conectar às redes da empresa.
No caso da SD-WAN, os túneis de VPN terminam em concentradores de VPN no local mais próximo do PoP.
A autenticação do usuário e a identificação do usuário correspondente ocorrem por meio de

• Portal Explícito
• Portal On Demand
• Estabelecimento do túnel VPN
• Certificado de cliente TLS

No caso do “Explicit Portal”, os usuários fazem login no portal de forma proativa.
O serviço de portal autentica o usuário com a ajuda dos sistemas de autenticação da empresa.
Após a validação bem-sucedida das credenciais do usuário, ele anota o endereço IP do usuário (do IP de origem da conexão) e informa aos proxies as informações de mapeamento do ID do usuário e do endereço IP.
Quando o proxy conhece esses mapeamentos, ele identifica o usuário a partir do endereço IP do tráfego e executa a aplicação de políticas com reconhecimento de identidade.
Se o usuário iniciar a sessão sem se autenticar proativamente no portal, o proxy poderá redirecionar o usuário para o portal.
Como o acesso ao portal é sob demanda, esse método de autenticação também é chamado de autenticação de portal sob demanda.
Um aspecto a ser observado é que o redirecionamento do usuário para o portal só é possível se a conexão for baseada em HTTP/HTTPS.
No caso de HTTPS, o redirecionamento só é possível após a descriptografia TLS.
No caso de acesso a serviços/sites que não sejam da empresa, é necessário imitar o certificado do servidor com o certificado CA da empresa.
Além disso, se o usuário não for um usuário humano usando o navegador, o redirecionamento não ajudará.
Mesmo com essas ressalvas, ainda é uma forma eficiente de o proxy conseguir autenticar e identificar o usuário.
Conforme discutido brevemente, para fazer parte das redes corporativas, os usuários WFH (Work From Home) precisam se conectar às redes corporativas por meio de um túnel VPN.
O estabelecimento do túnel VPN já realiza a autenticação do usuário.
Os concentradores de VPN atribuem o endereço IP privado exclusivo a cada cliente.
Os clientes podem ser configurados para usar o túnel VPN e, portanto, esse endereço IP como origem para a maioria das conexões (incluindo o túnel dividido desativado).
Os concentradores de VPN podem anunciar o endereço IP atribuído ao cliente e o mapeamento da ID do usuário (ID do iniciador) para partes externas.
Os proxies usam esse mapeamento para identificar as sessões para um usuário posteriormente, quando os clientes iniciam as sessões.
Se a sessão TLS estabelecida pelos programas clientes tiver um certificado de cliente TLS, ele poderá ser usado para autenticar e identificar o usuário.
Atualmente, isso é usado muito raramente no SASE, mas é uma das opções disponíveis.
Um dos principais benefícios do tipo de proxy transparente é que ele pode capturar todo o tráfego de protocolo, não apenas HTTP/HTTPS.
Outra grande vantagem é que não há nenhuma configuração especial nos computadores clientes ou servidores da empresa.
Há poucas desvantagens nesse tipo de proxy.
Como ele identifica o usuário com base no endereço IP observado no tráfego, todos os aplicativos nesse computador de usuário recebem o mesmo tratamento de segurança.
Se for um computador multiusuário, todos os usuários desse computador receberão o mesmo tratamento/privilégio de segurança.
Se esse endereço IP estiver fazendo NAT de várias máquinas, todas as máquinas por trás desse endereço IP NAT receberão o mesmo acesso e tratamento de segurança.
Pense em um caso em que o laptop do usuário está infectado com malware.
O malware obtém o mesmo acesso definido para esse usuário, pois o malware faz parte da mesma máquina em que o usuário faz login no portal.
Por esse motivo, os tipos de proxy transparente devem ser usados com cuidado, pelo menos para sessões HTTP/HTTPS. Outra desvantagem é que esse tipo de proxy exige que o cliente VPN esteja presente nos dispositivos.
Embora isso não seja um problema para os dispositivos gerenciados, pode ser um desafio convencer os funcionários a instalar o cliente VPN nos dispositivos de propriedade deles.

Tipo de proxy de encaminhamento

Os proxies de encaminhamento são destinados a dispositivos clientes que se comunicam com serviços/sites externos.
Os aplicativos clientes são configurados para passar pelo proxy de encaminhamento para se comunicar com serviços externos.
Os aplicativos clientes são configurados com o FQDN/IP do proxy e a porta na qual os proxies estão escutando.
No caso do proxy transparente, o endereço IP de origem e destino da sessão nunca tem o endereço IP do proxy.
No caso de proxy encaminhado, as conexões do cliente são para o endereço IP do proxy e a conexão com o servidor seria feita a partir do endereço IP do proxy.
Os arquivos PAC são usados para configurar os aplicativos clientes, como navegadores, com definições de proxy.
O arquivo PAC permite selecionar o roteamento do tráfego para vários proxies com base nos domínios de serviço de destino.
Os arquivos PAC são distribuídos aos navegadores clientes por meio de soluções de gerenciamento do sistema ou pelo serviço WPAD (Web Proxy Auto Discovery).
Os aplicativos clientes com as configurações de proxy sempre se comunicam com o proxy.
É assim que os proxies avançados capturam o tráfego.
No caso de conexões TLS, como HTTPS, toda conexão TCP começa com a transação “HTTP CONNECT”.
Essa transação é somente entre o cliente e o proxy.
Depois dessa transação HTTP CONNECT, os dados entre o cliente e o servidor são mediados pelo proxy.
A transação “HTTP CONNECT” tem um campo de cabeçalho de host cujo valor é usado pelo proxy para determinar o FQDN e a porta do destino final.
No caso do HTTP2.0, toda conexão de fluxo começa com a transação “HTTP CONNECT”.
Como o senhor deve ter observado, não há necessidade de o tráfego ser enviado aos roteadores da empresa para que o proxy capture o tráfego.
Ou seja, o tráfego vai diretamente para o proxy.
Dessa forma, ele é agnóstico em relação à rede.
Os proxies de encaminhamento também podem autenticar e identificar os usuários por meio dos cabeçalhos proxy-authenticate e proxy-authorization.
No caso de conexões TLS, esses cabeçalhos são enviados na resposta e na solicitação, respectivamente, em transações HTTP CONNECT.
Um ponto a ser observado é que não há necessidade de descriptografar as conexões TLS para fins de autenticação e identificação do usuário.
Não é necessária nenhuma autenticação de portal.
Há uma vantagem adicional: muitos navegadores e aplicativos clientes suportam o Kerberos como parte da autenticação de proxy.
Com isso, qualquer usuário que fizer login no dispositivo pode se autenticar automaticamente com o proxy sem pop-ups de login adicionais (também conhecido como SSO).
Há várias vantagens em usar o tipo de proxy avançado para clientes que se comunicam com serviços externos.
Algumas delas estão listadas abaixo.

• A autenticação e a identificação do usuário são determinísticas.
  No caso do tipo de proxy transparente, se o usuário se esquecer de se autenticar proativamente no portal, o redirecionamento do portal sob demanda ou do portal cativo para autenticação do usuário só será possível após a descriptografia do TLS.
  Algumas empresas não permitem a descriptografia TLS para sites que coletam PII.
  Se os sites adotam a fixação de certificados, não se espera que os proxies transparentes imitem o certificado e, portanto, a descriptografia TLS não é possível.
  Nesses casos, o usuário não pode ser determinado para fornecer aplicação de política com reconhecimento de identidade.
  No tipo de proxy avançado, como a fase de autenticação do proxy ocorre antes de qualquer troca de TLS, a autenticação e a identificação do usuário são determinísticas.
• Conforme discutido anteriormente, o proxy avançado é independente de rede e pode funcionar em qualquer rede, desde que os aplicativos clientes estejam configurados com definições de proxy.
  Não há necessidade de o cliente VPN estar presente nos dispositivos, mesmo que os usuários estejam trabalhando em casa.
• Como muitos aplicativos clientes suportam o Kerberos, o usuário obtém a experiência de SSO.
• O Encrypted Client Hello (ECH) no TLS 1.3+ está ganhando força no setor.
  Quando o ECH é adotado, o SNI não fica visível e, portanto, o tipo de proxy transparente não poderá fazer nem mesmo a filtragem básica de URL e o controle de acesso.
  No tipo forward proxy, devido à transação HTTP CONNECT, o proxy conhece o FQDN de destino mesmo que o ECH seja adotado.
  Ou seja, o tipo de proxy avançado é seguro para ECH.
• Não há lista de permissões de IP.
  Cada aplicativo cliente precisa se autenticar separadamente com o proxy e, portanto, é muito seguro.

Há também algumas desvantagens.
Ele só funciona para tráfego HTTP/HTTPS.
Embora a maioria dos aplicativos clientes seja compatível com as configurações de proxy, alguns não são.

Tipo de proxy reverso

Os proxies reversos são usados para aplicativos de servidor front-end.
Os proxies reversos são usados para proteger os serviços contra ameaças, para fornecer RBAC, para encerrar sessões TLS e também para equilibrar a carga das sessões de tráfego entre várias instâncias de serviços.
O proxy reverso captura o tráfego por meio de métodos de DNS.
O FQDN de cada serviço corporativo exposto a funcionários ou usuários públicos é configurado nos servidores DNS da empresa para apontar para os endereços IP das instâncias de proxy reverso.
Por isso, toda vez que um usuário tenta se conectar aos serviços corporativos, o tráfego correspondente chega aos proxies reversos.
Os proxies reversos também encerram as sessões HTTPS/HTTP.
Como parte desse processo, eles também autenticam os usuários e, em seguida, identificam os usuários das sessões por meio dos métodos OIDC, SAMLv2 e SPENGO/Kerberos.
No caso da comunicação entre aplicativos, os usuários também são identificados a partir de certificados TLS.

SASE Proxy

Para obter uma cartilha sobre a SASE, leia a postagem do blog Decifrando a SASE.
Como o senhor deve ter observado, espera-se que as soluções SASE ofereçam segurança abrangente: proteção de clientes, proteção de dados SaaS e proteção de aplicativos corporativos.
Conforme descrito na postagem do blog Identity-aware-SASE, os controles de acesso baseados em identidade são o principal recurso da SASE.
Embora muitas empresas possam viver apenas com o acesso HTTP/HTTPS, algumas também podem exigir controles de acesso em outros protocolos.
Devido a essas necessidades, acreditamos que o proxy SASE deve atuar como transparente para o tráfego não HTTP e para aplicativos clientes que não suportam configurações de proxy.
O proxy SASE deve atuar como proxy de encaminhamento para aplicativos clientes que acessam a Internet e os serviços SaaS para fornecer controle de acesso baseado em identidade determinística e também para garantir o futuro quando o ECH for adotado.
O proxy SASE também deve atuar como proxy reverso para proteger os aplicativos corporativos.
Essa convergência de vários tipos de proxy é necessária para que a solução SASE seja bem-sucedida.

• Blog CTO Insights

  A série de blogs Aryaka CTO Insights oferece liderança de pensamento para tópicos de rede, segurança e SASE.
  Para obter as especificações dos produtos Aryaka, consulte as fichas técnicas da Aryaka.