Realização de SASE com reconhecimento de identidade com políticas baseadas em identidade

Por que a conscientização da identidade na SASE?

Realização de SASE com reconhecimento de identidade Meu blog anterior sobre Decifrando a SASE falou sobre o reconhecimento de identidade em vários componentes de segurança da SASE.
Esta postagem descreve os vários métodos para realizar a SASE com reconhecimento de identidade.
Os controles de acesso na segurança tradicional centrada no perímetro são definidos usando endereços IP e serviços.
Os clientes são representados como endereços IP nas políticas de acesso, e os serviços são definidos com nomes de domínio e endereços IP, juntamente com portas TCP/UDP, como a porta 80 para HTTP e 443 para HTTPS, etc.
Como há diferentes tipos de clientes – usuários humanos que acessam serviços por meio de PCs/Laptops/Móveis, aplicativos de clientes, dispositivos de IoT e várias categorias de usuários humanos, foi inventada uma abordagem de segmentação com cada segmento representando vários tipos de clientes.
Cada segmento recebe sua própria sub-rede ou intervalo de endereços IP.
Isso possibilita a definição de controles de acesso para diferentes tipos de clientes.
Embora tenha resolvido alguns desafios na definição dos controles de acesso para vários clientes, introduziu outro conjunto de complexidades: o gerenciamento de segmentos.
Rapidamente, muitas organizações começaram a ver a explosão de segmentos.
As organizações começaram a perceber a necessidade de criar vários segmentos para definir QoS diferenciada, seleção de links de WAN e vários tipos de controles de acesso de segurança.
Outro grande desafio da segmentação está relacionado ao “trabalho de qualquer lugar“.
Ou seja, o endereço IP do usuário muda constantemente de acordo com o local de onde o usuário está trabalhando.
Nesse caso, a associação do usuário a um segmento torna-se rapidamente um grande desafio.
Os usuários que trabalham em escritórios designados, em casa, em cafeterias, em outro escritório ou em escritórios parceiros devem ser tratados da mesma forma, independentemente de onde o usuário esteja trabalhando.
O SASE com reconhecimento de identidade simplifica o gerenciamento de segmentos, eliminando a necessidade de criar segmentos para diferenciar clientes, pelo menos para usuários humanos.
No entanto, o senhor pode não se livrar completamente dos segmentos para clientes como dispositivos de IoT.
O SASE com reconhecimento de identidade também é necessário para a “perícia digital”. Quando há uma violação de dados, é importante saber o que aconteceu durante o ataque para entender a abordagem usada pelos invasores, os pontos fracos explorados e identificar o impacto geral.
De acordo com o “2022 Verizon Data Breach Report“, 82% das violações de dados envolveram o elemento humano.
Portanto, a identidade de cada conexão/sessão torna-se muito importante para entender os padrões de acesso, os sites visitados, os dispositivos e os aplicativos usados pelo usuário que resultaram na primeira infecção.
Então, isso pode ajudar a descobrir os ataques laterais que, por fim, resultaram na violação.
Em resumo, o reconhecimento de identidade no SASE ajuda a:

Definição de políticas de acesso diferenciadas entre firewall, SWG, CASB e ZTNA para vários usuários
Definição de políticas de rede diferenciadas em QoS, roteamento para vários usuários
Forense digital
Análise comportamental do usuário

Identidade nas políticas de SASE

Os componentes do SASE controlam o acesso a vários serviços/sites em diferentes granularidades.
O firewall do SASE controla o acesso nas camadas L3/L4.
O SWG controla o acesso no nível dos URLs.
O ZTNA e o CASB controlam o acesso no nível das APIs.
O SWG, o ZTNA e o CASB com DLP podem controlar o acesso no nível dos dados.
Todos esses controles são necessários com o usuário como um dos seletores pelos motivos explicados acima e para atender às diretrizes de confiança zero especificadas pelo NIST.
Qualquer política de controle de acesso contém um conjunto de regras, principalmente regras ordenadas.
Essas regras são verificadas para cada sessão de tráfego.
Se a regra corresponder, serão executadas as ações especificadas na regra correspondente.
As ações típicas incluem permitir o tráfego, negar o tráfego ou apenas monitorar e registrar o tráfego.
A correspondência de qualquer regra é feita com um conjunto de atributos.
Cada regra é especificada com os valores desses atributos.
Tradicionalmente, esses atributos incluem 5 tuplas (IP de origem, IP de destino, protocolo, porta de origem e porta de destino), zonas e locais.
Em uma nova sessão de tráfego, os valores são extraídos do pacote e do contexto (zona, local) e combinados com os valores dos atributos da regra.
Se eles corresponderem, diz-se que a regra foi correspondida.
Com o SASE de reconhecimento de identidade, os atributos de correspondência de regras incluem atributos de usuário.
Os atributos do usuário podem ser um conjunto de nomes de usuários individuais, grupos de usuários, funções de usuários, nomes de sujeitos de certificados de clientes ou nomes alternativos de sujeitos de certificados.
A correspondência de políticas deve incluir a correspondência com o contexto do usuário para o SASE baseado em identidade.
A correspondência de política típica em uma nova sessão de tráfego é a seguinte:

Extraia 5 tuplas (endereço IP de origem, endereço IP de destino, protocolo IP, porta de origem e porta de destino) do pacote.
Obtenha a zona de origem e o local de onde a sessão de tráfego se originou.
Obtenha as informações do usuário (nome, grupo de usuários e função do usuário) que iniciou a sessão de tráfego.
Obter a postura do dispositivo da máquina de onde a sessão de tráfego se originou.
Percorra as regras de cima para baixo da política, fazendo a correspondência das informações extraídas acima com os valores de atributo de correspondência de regras.
Se houver uma correspondência, execute a ação especificada nessa regra.
Caso contrário, passe para a próxima regra.
Se não houver nenhuma regra correspondente, o senhor tomará a ação configurada para esse nível da tabela de políticas.

Identificação e autenticação do usuário

Como um usuário precisa ser identificado antes de qualquer verificação de política nas sessões de tráfego, surgem algumas perguntas:

Como o SASE autentica os usuários?
Como o SASE identifica o usuário quando recebe o tráfego?

Antes disso, vamos ver algumas das considerações que as soluções SASE devem fazer.
A SASE precisa levar em conta os seguintes tipos de clientes:

Usuários humanos que usam navegadores para acessar serviços
Usuários humanos que usam aplicativos que não são do navegador para acessar serviços
Aplicativos sem navegador que funcionam sem intervenção humana para acessar serviços
Aplicativos que não são de navegador com fixação de certificado CA
Dispositivos IoT que acessam serviços

A implicação é que as soluções SASE não podem presumir que sempre há usuários humanos iniciando as sessões de tráfego.
Pode haver entidades programáticas e dispositivos iniciando as sessões de tráfego. Espera-se que a SASE atenda a ambos os tipos de clientes e, portanto, as soluções SASE oferecem suporte a vários métodos de autenticação.
A SASE precisa considerar os seguintes desafios de experiência do usuário:

Experiência do usuário em que os usuários humanos não recebem nenhuma ou poucas telas pop-up para obter as credenciais do usuário
Experiência do usuário em que os usuários humanos são informados do motivo pelo qual um determinado acesso é negado
Usuários que usam seus próprios dispositivos para acessar os serviços
Usuários que usam dispositivos gerenciados pela Employer para acessar serviços
Experiência uniforme para os usuários, quer estejam trabalhando em casa ou no escritório

Com esses requisitos e implicações acima, as soluções SASE implementam vários modos de autenticação.
A maioria dos modos de autenticação suportados pelas soluções SASE está listada aqui.

Autenticação de proxy reverso
Autenticação de proxy de encaminhamento
Autenticação baseada em portal
Autenticação de túnel
Autenticação do certificado do cliente
Autenticação baseada em chave de API

Depois que os clientes se autenticarem no SASE por meio do acima exposto, o SASE deverá ter uma maneira de associar as sessões de tráfego iniciadas pelo usuário ao usuário certo.
São usadas duas abordagens de mapeamento de identificação.
São elas:

Mapeamento de token: As soluções SASE identificam o usuário a partir do token de autenticação/identidade/portador nos cabeçalhos de solicitação das sessões de tráfego HTTP/HTTPS.
Os clientes recebem tokens como parte da autenticação e o mesmo é apresentado pelos clientes nas sessões de tráfego.
Mapeamento de IP representativo: Nessa abordagem, o endereço IP representa o usuário.
As soluções SASE usam o endereço IP de origem da sessão de tráfego para identificar o usuário.
Quando um usuário se autentica com sucesso pela primeira vez no SASE, o SASE registra o endereço IP do usuário para esse usuário.
Todas as sessões de tráfego, em um momento posterior, provenientes desse endereço IP são associadas ao usuário.

Os tokens são válidos somente para sessões de tráfego HTTP/HTTPS.
Como os tokens estão presentes em todas as sessões HTTP, direta ou indiretamente, por meio de cookies, ele é considerado mais seguro do que o “IP representativo”. Para sessões de tráfego não HTTP/HTTPS, o mapeamento do “IP representativo” é usado pelas soluções SASE.
Observe que o método de mapeamento do “IP representativo” tem alguns desafios, pois o endereço IP é usado por todos os aplicativos da máquina. Ou seja, mesmo que um usuário de navegador esteja autenticado na solução SASE, não apenas o navegador, mas também todos os outros aplicativos clientes em execução na máquina terão o mesmo acesso. No caso de sistemas multiusuários, todos os usuários desse sistema terão acesso, mesmo que um usuário se autentique com sucesso na solução SASE. Mais perigoso ainda é se o sistema usado para se autenticar no sistema SASE estiver atrás de um dispositivo NAT. Todos os usuários por trás desse endereço IP NAT terão acesso. Portanto, é particularmente importante usar o recurso “Representative IP” somente quando necessário e tentar restringir esse mapeamento somente a sessões não HTTP/HTTPS.
Como o token (via cabeçalho proxy-authorization ou cabeçalho de autorização ou via cookie) faz parte de cada solicitação HTTP, somente o aplicativo cliente autenticado com a solução SASE pode enviar o token.
Espera-se que outros aplicativos clientes baseados na Web que exigem acesso se autentiquem na solução SASE para obter acesso.
Devido aos benefícios de segurança, é altamente recomendável usar a abordagem de mapeamento de token para todas as sessões HTTP/HTTPS.

Autenticação e identificação do usuário por vários componentes do SASE

Muitos componentes SASE que fornecem segurança para aplicativos/serviços baseados na Web tendem a identificar e associar usuários a sessões de tráfego por meio de tokens em cabeçalhos de solicitação HTTP, certificados de cliente ou chaves de API.
As seções a seguir fornecem um mapeamento dos modos de autenticação relevantes e melhores para vários componentes SASE.

ZTNA

O ZTNA, conforme discutido neste blog anterior, tem o objetivo de proteger os aplicativos corporativos contra clientes mal-intencionados e infectados.
O ZTNA, por meio de serviços de aplicativos de front-end, oferece os seguintes recursos.

Segurança TLS/SSL para aplicativos não TLS/SSL e para aplicativos que não suportam algoritmos de criptografia robustos
Suporte de acesso RBAC / Least Privilege para aplicativos que não suportam nenhum RBAC e para aplicativos que exigem RBAC de segundo nível
Gerenciamento de acesso a privilégios com mais um nível de MFA
Balanceamento de carga do tráfego em várias instâncias de aplicativos
WAF e segurança de proteção contra ameaças em nível de API para aplicativos

A ZTNA está se tornando cada vez mais uma necessidade, pois está tirando a responsabilidade pela segurança dos serviços de aplicativos.
Os benefícios resultantes incluem um aumento na produtividade do desenvolvimento de aplicativos corporativos, configuração de segurança uniforme em vários serviços de aplicativos e menor superfície de ataque.
O ZTNA destina-se principalmente à proteção de aplicativos baseados na Web.
Os desenvolvedores de aplicativos não estão apenas criando novos aplicativos com protocolos da Web, mas também os aplicativos existentes estão sendo webificados para aproveitar as inovações que estão ocorrendo nos protocolos da Web.
Até mesmo os protocolos de administração tradicionais, como o SSH, estão sendo modificados pela Web usando projetos como o Apache Guacamole.
Dito isso, sempre haverá aplicativos que não são da Web.
Um firewall como parte do SASE fornece controle de acesso e segurança de proteção contra ameaças para serviços não Web instanciados pela empresa.
Consulte a seção sobre firewall para obter mais detalhes. Como a ZTNA obtém acesso ao tráfego? O ZTNA obtém acesso ao tráfego de duas maneiras: por meio do método DNS e do método proxy transparente.
Os administradores dos aplicativos corporativos configuram os servidores de domínio autoritativos para apontar para o ZTNA dos aplicativos.
Ou seja, os administradores configuram os servidores DNS para responder com endereços IP do ZTNA às consultas de DNS nos FQDNs dos aplicativos.
No método de proxy transparente, espera-se que o ZTNA esteja na linha de tráfego, ou que uma entidade na linha de tráfego intercepte o tráfego e o envie para o ZTNA.
Os administradores de aplicativos também configuram o ZTNA com pares de certificados/chaves privadas TLS/SSL em nome dos serviços de aplicativos. Como o ZTNA autentica os usuários e mapeia as sessões de tráfego para os usuários? O ZTNA oferece suporte aos modos de autenticação de proxy reverso, certificado de cliente e chave de API para autenticar vários tipos de clientes: usuários humanos e entidades programáticas.
Ele funciona da seguinte forma:

O ZTNA encerra a conexão TLS/SSL
Se o certificado do cliente for negociado, ele validará o certificado do cliente.
Se for válido, ele extrai o nome do assunto do certificado e o SAN (Subject Alt Name).
Essas são as identidades do usuário do cliente.
Se algum grupo ou função de usuário for provisionado, ele extrai as informações de grupo e função do banco de dados provisionado.
Se o cliente apresentar a chave da API, ele fará referência ao banco de dados interno (provisionado) para extrair a identidade do usuário.
Se algum grupo ou função de usuário for provisionado, ele extrai as informações de grupo e função do banco de dados provisionado.
Se a solicitação HTTP tiver um token de autenticação/identidade associado, isso significa que o usuário foi autenticado anteriormente.
Isso também significa que o contexto do usuário (nome de usuário, grupo de usuários e função do usuário, se houver) é conhecido pela ZTNA.
Se o token for inválido ou se não houver token, ele solicita que o usuário se identifique e se autentique por meio do OIDC.
O corretor OIDC da ZTNA pode, por sua vez, usar vários protocolos de autenticação para permitir que o usuário se autentique com os serviços de autenticação da Enterprise.
Para contas privilegiadas, a ZTNA executa sua própria MFA para garantir que o usuário seja realmente um usuário genuíno.
Se o usuário for autenticado com êxito, o componente OIDC da ZTNA configurará o token de identidade.
Ele também anota as informações do usuário (nome de usuário, grupo de usuários, se houver, e função do usuário, se houver)
Em seguida, o ZTNA estabelece uma conexão com uma das instâncias do serviço de aplicativos.
Ele executa decisões de controle de acesso baseadas no usuário por transação HTTP.
Se o ZTNA estiver configurado para proteção avançada contra ameaças, ele também examinará o tráfego em busca de explorações, malware e vazamentos de dados confidenciais.

Um usuário é apresentado a uma tela para fornecer credenciais apenas uma vez até que o token de identidade expire.
Devido à política de mesma origem dos clientes, eles sempre apresentam o token de identidade correto nas transações HTTP para os serviços de aplicativos.
Se o token de identidade for válido, o ZTNA usará essa informação para mapear a sessão para o usuário certo.

SWG e CASB

O componente SWG protege os usuários de visitar sites de malware, phishing e inseguros.
Ele também protege os aplicativos clientes contra o contato com sites de botnet C&C após a infecção.
Além disso, o SWG oferece uma maneira de fornecer acesso diferenciado a vários sites com base na função dos usuários na organização e no grupo ao qual os usuários pertencem.
O SWG também registra os metadados da sessão de tráfego junto com as informações do usuário, o que pode ajudar em várias análises e perícias digitais.
O componente CASB protege os dados corporativos mantidos pelos provedores de SaaS, garantindo que somente os usuários certos acessem e modifiquem os dados usando o controle de acesso em nível de API para vários aplicativos de SaaS.
O CASB, assim como o SWG, também registra os metadados da API com as informações do usuário para várias análises e análises forenses digitais.
Os componentes SWG e CASB exigem a inspeção do tráfego HTTP/HTTPS que vai dos usuários aos sites da Internet.
O SWG e o CASB encerram as conexões do cliente, interceptam SSL, se permitido, e fazem uma inspeção mais profunda do conteúdo para detectar e evitar malware e impedir qualquer vazamento de dados confidenciais. Como o SWG e o CASB têm acesso ao tráfego? O proxy SWG e CASB obtém o tráfego por meio de dois métodos: o método proxy/PAC e o método transparente.
No método Proxy/PAC, os aplicativos/máquinas clientes são configurados manualmente com definições de proxy ou os aplicativos clientes se autoconfiguram por meio da descoberta automática de proxies.
Depois que os aplicativos clientes conhecem os proxies, eles usam o método HTTP CONNECT para fazer o túnel das sessões de dados, que normalmente seriam transações HTTP e HTTPS.
O URI HTTP CONNECT indica o destino pretendido das transações HTTP e HTTPS internas.
O proxy usa esse URL para fazer a conexão com o site de destino.
Os proxies executam qualquer controle de acesso e serviços de proteção contra ameaças antes de permitir que os dados passem de clientes e servidores e vice-versa.
No método de proxy transparente, os clientes não sabem sobre os proxies.
O que se espera é que os proxies estejam na linha de tráfego para obter o tráfego. Como o proxy SWG/CASB autentica os usuários e mapeia as sessões de tráfego para os usuários? Se o método proxy/PAC for usado para alcançar o proxy do SWG/CASB, os proxies terão a chance de autenticar os usuários como parte da transação HTTP CONNECT.
Isso é chamado de “autenticação de proxy avançado”.
A autenticação de proxy avançado baseada em HTTP CONNECT é descrita aqui muito bem.
Embora esse link descreva a autenticação NTLM, um fluxo semelhante também se aplica à autenticação Kerberos.
Como o HTTP CONNECT precede cada sessão de tráfego HTTP/HTTPS, o usuário é conhecido pelo proxy em cada sessão.
Um aspecto positivo desse método é que a maioria dos aplicativos clientes nativos, além dos aplicativos de navegador, também respeita as configurações de proxy e pode se autenticar com os proxies, abrangendo assim a maioria dos casos de uso de acesso à Internet.
No método de proxy transparente, não há transação HTTP CONNECT.
Portanto, a autenticação de proxy direto não é possível.
Qualquer autenticação de usuário precisa ocorrer com esquemas regulares de autenticação HTTP, como o redirecionamento da solicitação HTTP para o portal SASE, que, por sua vez, usa os métodos OIDC e SAML para autenticar os usuários.
Esse tipo de autenticação é chamado de “autenticação baseada em portal”.
Depois que o usuário faz login com êxito, o portal pode definir o cookie, mas isso não fica visível para o proxy quando o usuário navega em sites da Internet devido à política de mesma origem nos navegadores.
Devido a esse desafio, quando o usuário faz login com êxito, o portal cria o mapeamento entre o nome de usuário e o endereço IP de origem da sessão de autenticação do usuário e informa o proxy sobre esse mapeamento.
Posteriormente, o proxy usa esse mapeamento para mapear as sessões de tráfego para o usuário.
Se não houver mapeamento disponível, o proxy redirecionará a sessão de tráfego para o portal para login.
Esse “mapeamento” é chamado de “mapeamento de IP representativo”.
Conforme descrito anteriormente, esse método de mapeamento deve ser usado com cuidado, pois pode abrir o acesso a partes não intencionais.
Os métodos de proxy transparente dependem do redirecionamento das transações HTTP de entrada.
Isso significa que ele precisa se apoderar do tráfego claro por meio de interceptação SSL.
Há casos em que a interceptação SSL/TLS não é permitida ou não é possível.
Como o redirecionamento não é possível nesses casos, espera-se que o usuário seja autenticado no SASE por meio de outros mecanismos, como autenticação proativa com o portal ou via “Tunnel Authentication”.

Funções baseadas em firewall e L3/L4

O firewall e as funções associadas de NAT, roteamento e QoS funcionam em pacotes no nível das camadas L3/L4.
Essas funções precisam estar em sistemas que estejam na linha de tráfego.
Na maioria das vezes, os sistemas SASE com essas funções são gateways para o tráfego proveniente de sites e usuários remotos.
Como o firewall lida com todos os tipos de protocolos além de HTTP e HTTPS com relação ao controle de acesso, proxy reverso e proxy direto, os mecanismos de autenticação de portal sob demanda não são possíveis.
Há dois modos usados predominantemente para autenticar os usuários: autenticação explícita do portal e autenticação de túnel.
No modo de autenticação explícita do portal, espera-se que os usuários se autentiquem no portal SASE apontando o navegador para o portal SASE.
O portal SASE, juntamente com o OIDC, autentica os usuários.
Nesse caso, também, a SASE usa o método de mapeamento de “IP representativo”.
O portal SASE envia o mapeamento do endereço IP vs. usuário para o firewall após a autenticação bem-sucedida do usuário.
As funções de firewall e L3/L4 usam esses registros de mapeamento para associar as sessões de tráfego aos usuários.
O modo de autenticação de túnel requer a instalação de um software especial nos dispositivos clientes.
Os clientes fazem sessões de túnel com o SASE de forma proativa.
Parte desse túnel é autenticada com o SASE.
Se forem usados túneis baseados em IPSec, a autenticação do túnel será feita pelo componente SASE/IKEv2.
O componente SASE/IKEv2 anuncia o usuário (ID do iniciador) e o mapeamento do endereço IP virtual para os serviços de rede e segurança do SASE.
As funções de firewall e L3/L4 usam o método de mapeamento “IP representativo” para mapear as sessões de tráfego para o usuário.
Embora esses dois modos de autenticação sejam explicitamente mencionados aqui, o mapeamento do endereço IP para o usuário também pode vir de proxies, quando um usuário se autentica em proxies nos modos “Reverse Proxy” e “Forward Proxy”.
Um ponto a ser observado aqui é que se espera que a autenticação do usuário ocorra para que as regras específicas do usuário sejam eficazes.
Se o usuário não for autenticado, a lógica de correspondência de políticas presumirá que o usuário é desconhecido.
Devido a isso, as políticas baseadas no usuário no firewall e no nível L3/L4 são consideradas oportunistas.
Para incentivar/lembrar os usuários de fazer login de forma proativa, as soluções SASE tendem a gerar notificações no navegador para informar aos usuários que devem fazer login no portal SASE.

SASE e identidade unificadas

O SASE unificado foi discutido aqui, e essa postagem forneceu várias vantagens que as empresas obtêm com as ofertas de “SASE unificado”.
Se a SASE for criada a partir de vários componentes discretos, a autenticação do usuário poderá ocorrer várias vezes, o que não é uma ótima experiência para o usuário.
Com o “SASE unificado”, espera-se que os usuários sejam autenticados apenas uma vez para todo o SASE.
Esse é um benefício adicional do “SASE unificado”. As ofertas de SASE unificado adicionam informações do usuário a mensagens de registro relevantes de maneira uniforme e abrangente a uma plataforma de observabilidade comum.
Isso ajuda em várias análises e na detecção de anomalias, monitorando o comportamento do usuário nos serviços de SDWAN e segurança.

Resumo

A abordagem de microssegmentação é necessária, mas estender a microssegmentação para categorizar vários usuários não é uma solução dimensionável.
As soluções SASE estão permitindo cada vez mais a definição e a aplicação de políticas baseadas em identidade.
As soluções SASE fazem isso autenticando os usuários e, em seguida, mapeando as sessões de tráfego para os usuários.
As soluções SASE oferecem várias maneiras de os usuários se autenticarem na SASE.
Este post descreveu alguns desses métodos.
A Aryaka iniciou a jornada do “SASE com reconhecimento de identidade”.
A solução Aryaka SWG suporta a aplicação de políticas específicas do usuário.
Saiba mais sobre a solução Aryaka SWG aqui: https://www.aryaka.com/secure-web-gateway/

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.

Realização de SASE com reconhecimento de identidade