Corretor de identidade Em meu blog anterior sobre SASE com reconhecimento de identidade, discuti a confiança zero, a função da SASE e a importância da identidade nos controles de acesso.
Outro blog sobre proxy SASE explicou como as soluções SASE obtêm as identidades dos usuários depois de autenticá-los por meio de IdPs (Identity Providers, provedores de identidade).
Em resumo, a parte do proxy de encaminhamento das soluções SASE autentica os usuários por meio dos métodos de autenticação Kerberos, NTLM, Digest e Basic.
Enquanto isso, os portais cativos autenticam os usuários por meio do Kerberos ou do OIDC.
A parte do proxy reverso das soluções SASE normalmente usa o Kerberos ou o OIDC para autenticar os usuários.
O gateway VPN da SASE também autentica os usuários com bancos de dados de autenticação corporativa.
As soluções SASE esperam informações do usuário, como o provedor de identidade que validou as credenciais do usuário, o endereço de e-mail do usuário, os grupos e as funções aos quais o usuário pertence etc. no formato JWT (JSON Web Token).
As soluções SASE usam essas informações (conhecidas como reivindicações na terminologia JWT) para aplicar controles de acesso específicos da identidade.

Corretor de identidade

Um corretor de identidade é um serviço que atua como intermediário, facilitando a autenticação de usuários finais por soluções SASE com vários provedores de identidade (IdPs).
Nem todos os IdPs implementam todos os protocolos de autenticação; alguns podem implementar apenas OIDC, OAuth2 ou SAMLv2.
Como as soluções SASE são projetadas para trabalhar com vários IdPs, sua complexidade aumenta à medida que elas precisam oferecer suporte a diferentes protocolos de autenticação.
Os Identity Brokers, como serviços intermediários confiáveis, podem permitir que a solução SASE use um único protocolo de autenticação no backend e deixar que o Identity Broker faça o proxy do processo de autenticação para os IdPs por meio dos protocolos de autenticação suportados pelos IdPs.
A figura a seguir mostra a solução SASE com e sem o agente de identidade. Solução SASE O lado esquerdo da imagem mostra o SASE sem um agente de identidade: Os navegadores/aplicativos do usuário se autenticam no proxy de encaminhamento do SASE usando Kerberos, NTLM, nome de usuário/senha, nome de usuário/senha digest.
O SASE precisa validar as credenciais do usuário.
Ele usa vários módulos funcionais de backend para se comunicar com vários IdPs/sistemas de autenticação.
No caso do Kerberos, o tíquete de serviço é validado localmente no plano de dados do SASE e, em seguida, ele obtém as decorações do usuário dos sistemas de autenticação, como o AD via LDAP ou SCIM.
No caso de nome de usuário/senha, o backend LDAP também é usado para validar as credenciais do usuário.
O proxy reverso SASE e os portais cativos autenticam os usuários por meio do OIDC (Open ID Connect) ou do SAMLv2.
Se os IdPs de backend também forem baseados em OIDC ou SAMLv2, ele redirecionará os usuários para os IdPs.
No caso de sistemas baseados em LDAP, espera-se que o SASE funcione como IdP e use o LDAP para o AD para validar as credenciais do usuário e também para obter as decorações do usuário para criar o token de identidade no formato JWT.
O VPN Gateway é outro módulo usado para acesso remoto.
Como parte do estabelecimento do túnel IKEv2, o gateway de VPN autentica o usuário.
As credenciais do usuário são validadas com o banco de dados local, o servidor RADIUS ou o servidor LDAP.
Como o senhor pode ver, são necessários vários componentes do plano de dados para dar suporte a diferentes protocolos para trabalhar com vários navegadores de usuário e aplicativos nativos.
Além disso, eles precisam trabalhar com vários IdPs não apenas de vários locatários, mas também com vários requisitos de IdPs em um ambiente de locatário.
O lado direito da imagem mostra o SASE com um corretor de identidade integrado: Com o corretor de identidade, o plano de dados da SASE é bastante simplificado.
O plano de dados do SASE só precisa trabalhar com um protocolo de autenticação para o agente.
Na imagem acima, o OIDC é o único protocolo ao qual o plano de dados do SASE precisa dar suporte.
O agente pode orquestrar/federar sessões de autenticação com vários IdPs.
Espera-se também que o agente de identidade crie o JWT a partir das informações do usuário do token de segurança SAMLv2, do JWT proveniente dos servidores IdP upstream ou das informações do usuário no banco de dados local ou acessíveis via LDAP.
Ou seja, espera-se que o corretor de identidade projetado para o SASE forneça JWT em todos os casos – quer o usuário esteja se autenticando usando o Kerberos por meio de cabeçalhos de proxy, Kerberos por meio de cabeçalhos WWW, OIDC, IKEv2 e se os IdPs são baseados em OIDC, SAMLv2 ou LDAP.
Há várias vantagens em separar o plano de dados do SASE do corretor de identidade do SASE.
Algumas vantagens estão listadas abaixo.

  1. A modularidade torna a solução inteira menos complexa, menos propensa a erros e, portanto, mais robusta.
  2. O Secure:Identity broker pode ser instanciado separadamente do plano de dados do SASE em ambientes de computação confidenciais para garantir que as chaves/senhas/credenciais usadas para se comunicar com os IdPs sejam protegidas mesmo quando estiverem em uso.
  3. Extensibilidade: é possível oferecer suporte a novos IdPs com protocolos de autenticação mais recentes sem afetar o plano de dados do SASE.
  4. Consolidação: as soluções de corretor de identidade estão sendo cada vez mais consideradas também para outros aplicativos.
    As empresas podem usar o agente de identidade que vem com a solução SASE para seus aplicativos, em vez de optar por um serviço/solução de agente de identidade separado.

Recursos específicos do SASE

A funcionalidade do agente de identidade pode, de fato, desempenhar um papel importante na interrupção do acesso direto aos serviços SaaS/nuvem, aplicando verificações de políticas e garantindo que somente usuários autenticados com controle de acesso adequado possam acessar esses recursos.
Além disso, os corretores de identidade tradicionais podem não ter um bom suporte para o Kerberos proxy, que é essencial para a autenticação SASE.
Portanto, é importante que os agentes de identidade ofereçam suporte ao Kerberos proxy e a outros requisitos da SASE para se integrarem efetivamente às soluções SASE.
Ao fornecer esses aprimoramentos, os agentes de identidade podem melhorar a segurança e a facilidade de uso das soluções SASE para as empresas.

  1. Garantir o controle de acesso baseado em identidade para SaaS e serviços em nuvem de forma contínua e determinística: As empresas estão cada vez mais usando SaaS e serviços de infraestrutura em nuvem, que podem ser acessados de qualquer lugar.
    Essa é uma grande vantagem, mas também uma preocupação de segurança para muitas empresas.
    As empresas querem restringir o acesso aos seus dados em serviços de SaaS/nuvem para funcionários específicos, e espera-se que o SASE garanta isso.
    No entanto, isso só é possível se o tráfego do usuário para os serviços de SaaS/nuvem passar pelo plano de dados do SASE.
    Se o tráfego estiver indo diretamente para os serviços de SaaS/nuvem, ignorando o plano de dados do SASE, espera-se que o acesso seja negado.
    Um agente de identidade pode ajudar a interromper esses acessos.
    Ao configurar os serviços de SaaS/nuvem para usar o agente de identidade SASE, qualquer nova sessão de autenticação de usuário chega primeiro ao agente de identidade SASE.
    O agente de identidade SASE, por meio de suas verificações de política, pode impedir que os usuários acessem os serviços diretamente.
  2. Suporte para concessão do Kerberos: Para muitos casos de uso, o tipo de concessão de autorização implícita e os tipos de concessão de senha são suficientes.
    No entanto, esses dois tipos de concessão não são suficientes para dar suporte à autenticação Kerberos.
    A expectativa é que o plano de dados do SASE, depois de receber o tíquete de serviço Kerberos, seja por meio de cabeçalhos de proxy ou cabeçalhos WWW do usuário (navegadores, por exemplo), valide o tíquete de serviço e obtenha as decorações de usuário correspondentes dos bancos de dados de autenticação.
    Como o corretor é usado para validar as credenciais, a implementação do protocolo OIDC requer aprimoramento para dar suporte ao envio do tíquete de serviço do plano de dados SASE para o corretor de identidade e obter o JWT se as credenciais forem validadas.

Considerações finais

Os agentes de identidade podem, de fato, desempenhar um papel crucial em uma solução SASE (Secure Access Service Edge) abrangente.
Ao integrar um agente de identidade à arquitetura SASE, as organizações podem simplificar a integração das soluções de gerenciamento de identidade e acesso (IAM) com sua infraestrutura SASE.
Isso pode levar a um processo de autenticação e controle de acesso mais simplificado e seguro para os usuários.
Além disso, ao aplicar os princípios de segurança de confiança zero, um agente de identidade pode ajudar a garantir que somente os usuários autorizados acessem os recursos no ambiente SASE.
Isso pode ajudar a reduzir o risco de violações de dados e outros incidentes de segurança.
Embora os analistas do setor talvez não estejam discutindo atualmente os corretores de identidade no contexto da SASE, é possível que isso mude à medida que as organizações continuem buscando maneiras de aumentar a segurança e a eficiência de seus ambientes de TI.

  • 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.