O ZTNA atual não é suficiente para diversas aplicações

O Authentication & Authorization vem em várias cores

O componente Zero Trust Network Access (ZTNA) do SASE foi projetado para fornecer acesso seguro de entrada a aplicativos privados corporativos.
Alinhado ao princípio fundamental do controle de acesso baseado em identidade na Zero Trust Architecture (ZTA), o ZTNA desempenha um papel fundamental na autenticação de usuários e na aplicação de controles de acesso com base em tipos de usuários, grupos e funções em todas as sessões de entrada para os aplicativos corporativos.
A segurança da ZTNA oferece vantagens significativas nos seguintes cenários:

• Aplicativos legados: Os aplicativos legados que não possuem medidas de segurança incorporadas geralmente não são expostos aos usuários do Work-From-Anywhere (WFA) devido a preocupações com a segurança.
  Ao utilizar o ZTNA para fazer o front-end desses aplicativos legados, é possível fornecer terminação HTTPS com gerenciamento de certificados, autenticação usando protocolos como o OIDC e autorização com base em controles de acesso com reconhecimento de contexto.
  Isso permite que os aplicativos legados sejam acessados com segurança por usuários WFA pela Internet.
• Aplicativos corrompidos: Apesar de terem sido desenvolvidos com a segurança em mente, alguns aplicativos podem não ter sido atualizados por um longo período.
  Esses aplicativos podem não ter o gerenciamento adequado de certificados, com suporte desatualizado ou sem suporte para upload de novos certificados ou renovação automática.
  O ZTNA pode atuar como um substituto de segurança para esses aplicativos corrompidos, garantindo acesso seguro e superando suas limitações de segurança.
• Nova arquitetura de aplicativos: Os aplicativos corporativos modernos geralmente são projetados com considerações de segurança transferidas para entidades externas, como ZTNA e tecnologias de malha de serviço.
  Essa abordagem alivia os desenvolvedores de aplicativos do ônus de lidar com HTTPS, autenticação e autorização, pois a segurança é transferida para a entidade de front-end.
  Ao centralizar o gerenciamento da segurança, obtêm-se benefícios como a aplicação uniforme da política de segurança, maior produtividade no desenvolvimento de aplicativos e manutenção simplificada.
  Além disso, como as atualizações de segurança são tratadas externamente, a frequência de lançamentos de patches destinados a resolver problemas de segurança pode ser significativamente reduzida.

Atualmente, muitas soluções de ZTNA são boas para front-end de aplicativos corporativos simples, mas não conseguem fornecer autenticação e autorização para aplicativos multilocatários, como os aplicativos SaaS.
A função da ZTNA nos aplicativos SaaS: No contexto dos aplicativos de software como serviço (SaaS), a ZTNA desempenhará um papel fundamental no fortalecimento e no aprimoramento dos mecanismos de autenticação e autorização, na minha opinião.
Os aplicativos SaaS têm requisitos específicos, incluindo multilocação, resiliência contra ataques DoS/DDoS e proteção robusta contra ataques de desvio de autenticação e escalonamento de privilégios.
Este artigo se aprofundará nos recursos da ZTNA de última geração que podem ajudar a descarregar ou aprimorar os processos de autenticação e autorização para aplicativos SaaS.
Observe que este artigo não abordará outros recursos do ZTNA, como WAAP (Web Application and API Protection), terminação de HTTPS, gerenciamento de tráfego de sessões de entrada para várias instâncias de aplicativos, webificação de serviços SSH/RDP/VNC e tornar os aplicativos invisíveis para os verificadores de portas.
Seu foco principal está nos aspectos de autenticação e autorização do ZTNA.
É importante observar que pode haver confusão entre as funções do CASB (Cloud Access Security Broker) e da ZTNA no contexto do SaaS.
O componente CASB do SASE concentra-se na segurança das conexões com os serviços de SaaS usados pelas empresas, em que as empresas são consumidoras de serviços de SaaS e CASB.
Por outro lado, a ZTNA, no contexto do SaaS, foi projetada para proteger o próprio aplicativo SaaS, tornando as empresas de SaaS consumidoras dos serviços da ZTNA.
Essa diferenciação é essencial para entender as diferentes funções e responsabilidades do CASB e da ZTNA nas soluções SASE.
Em um artigo anterior sobre corretores de identidade, exploramos os inúmeros benefícios da integração de corretores às soluções SASE.
As vantagens discutidas giravam principalmente em torno da modularidade e da simplicidade do design, aumentando, em última análise, a resiliência das soluções SASE.
Neste artigo, vamos nos aprofundar no papel fundamental dos agentes de identidade no suporte a aplicativos complexos, com foco especial nos aplicativos SaaS.

Quais são os desafios dos aplicativos multilocatários?

O ZTNA do SASE se destaca por oferecer suporte robusto à autorização baseada em políticas.
Os mecanismos de autorização do SASE oferecem a capacidade de gerenciar várias tabelas de políticas, sendo que cada tabela contém várias políticas.
Cada política é composta de várias regras e especifica a ação a ser tomada em uma correspondência bem-sucedida.
As próprias regras englobam vários atributos de correspondência, que podem ser classificados como atributos de origem e de destino.
Os atributos de destino referem-se principalmente aos recursos dos aplicativos que estão sendo acessados, como URIs e os métodos (por exemplo, GET, PUT, POST, DELETE) usados para interagir com esses recursos.
Por outro lado, os atributos de origem são normalmente associados aos sujeitos que acessam os recursos.
Esses atributos abrangem atributos relacionados ao usuário, como nome, grupo, função, serviço de autenticação que validou as credenciais do usuário e outras reivindicações do usuário.
Eles também incluem atributos de contexto do dispositivo, que capturam a postura segura dos dispositivos utilizados pelo sujeito e o local do dispositivo a partir do qual o usuário está acessando os recursos.
No entanto, muitas soluções de ZTNA ficam aquém quando se trata de abordar cenários de autenticação abrangentes, limitando seus recursos a aplicativos não SaaS.
A inclusão de um agente de identidade nas soluções SASE/SSE é uma etapa progressiva para obter uma autenticação abrangente em todos os tipos de aplicativos.
Embora se possa argumentar que os fornecedores de SaaS possuem a capacidade de lidar com a autenticação e a autorização em seus aplicativos, o cenário evoluiu significativamente.
No ambiente ágil de hoje, os provedores de SaaS reconhecem cada vez mais as vantagens de transferir as responsabilidades de segurança para entidades externas, como a SASE.
Ao fazer isso, eles podem se beneficiar do aumento da produtividade e da maior confiança em sua postura geral de segurança.
Além disso, essa abordagem permite que novos provedores de SaaS entrem no mercado mais rapidamente, pois podem transferir a autenticação e a autorização para uma entidade externa e se concentrar principalmente em sua lógica comercial principal.
As soluções SASE podem desempenhar um papel fundamental no suporte a esses novos provedores de SaaS.
Acreditamos que as soluções SASE devem e estarão prontas para enfrentar esse desafio de fornecer segurança de autenticação e autorização em nome de aplicativos complexos, como os aplicativos SaaS.
O cenário a seguir apresenta um exemplo representativo de um aplicativo SaaS e explora como a SASE, por meio da integração de agentes de identidade, pode ajudar na delegação de autenticação e autorização dos aplicativos.
Considere este exemplo de cenário de aplicativo SaaS (hospedado em app.example.com) que consiste em vários recursos de API:

Nesse cenário, vamos supor também que o IDP do provedor de SaaS seja example-idp.
Há dois locatários: XYZ e ABC, com seus respectivos serviços de IDP sendo XYZ-idp e ABC-idp.
Cada locatário também tem dois parceiros, cada um com seu próprio serviço de IDP.
XYZ-P1-idp e XYZ-P2-idp são serviços de IDP dos parceiros da XYZ.
ABC-P1-idp e ABC-P2-idp são serviços de IDP dos parceiros da ABC.
Além disso, o locatário da XYZ exige autenticação por meio do Google e do Facebook para acessar o espaço público da API, enquanto o locatário da ABC prefere a autenticação por meio do LinkedIn e do GitHub.
As seguintes políticas de autorização são necessárias no ZTNA para atender ao cenário acima:

1. Domínio = app.example.com; user-role=app-admin; authservice=example-idp; uri = /service-admin-api/* ALLOW: Permitir acesso a qualquer usuário que tenha efetuado login com êxito no serviço example-idp e possua a função app-admin para todos os recursos sob o admin-api do aplicativo com o domínio app.example.com.
2. Domínio = app.example.com; user-group=admin-group; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: Permitir acesso a qualquer usuário que tenha efetuado login com êxito no serviço XYZ-idp e que possua a função de grupo de administradores para todos os recursos em XYZ/tenant-admin-api.
3. Domínio = app.example.com; user-role=admin-role; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: Permitir acesso a qualquer usuário com a função de administrador, autenticado com o serviço ABC-idp, acessando os recursos ABC/tenant-admin-api
4. Domínio = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Permite o acesso aos recursos especificados na regra para qualquer usuário que tenha sido autenticado com êxito no serviço XYZ-idp
5. Domínio = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Permite o acesso aos recursos especificados na regra para qualquer usuário que tenha sido autenticado com êxito no serviço ABC-idp
6. Domínio = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Permitir acesso ao espaço de colaboração da XYZ para usuários autenticados com o serviço XYZ-P1-idp.
7. Domínio = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: Permitir acesso ao espaço de colaboração da XYZ para usuários autenticados com o serviço XYZ-P2-idp.
8. Domínio = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Permitir acesso ao espaço de colaboração ABC para usuários autenticados com o serviço ABC-P1-idp.
9. Domínio = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: Permitir acesso ao espaço de colaboração ABC para usuários autenticados com o serviço ABC-P2-idp.
10. Domínio = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* ALLOW: Permitir acesso ao espaço public-api da XYZ para todos os usuários autenticados com google.com.
11. Domínio = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* ALLOW: Permitir acesso ao espaço public-api da XYZ para todos os usuários autenticados com facebook.com
12. Domínio = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* ALLOW: Permitir acesso ao espaço ABC public-api para todos os usuários autenticados com linkedin.com
13. Domínio = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* ALLOW: Permitir acesso ao espaço da API pública XYZ para todos os usuários autenticados com github.com
14. Domínio = app.example.com; DENY: negar acesso ao aplicativo se nenhuma das regras acima corresponder.

As soluções SASE são excelentes no controle de acesso baseado em atributos.
Isso significa que elas lidam bem com a funcionalidade de autorização.
No entanto, elas não são muito abrangentes quando se trata de autenticação.
Nas políticas acima, diferentes níveis de acesso são concedidos com base no serviço de provedor de identidade (IDP) que os usuários escolhem para se autenticar.
Além disso, alguns usuários podem querer deliberadamente se autenticar em um serviço de IDP específico para acessar recursos com permissões mínimas a fim de evitar possíveis erros de exfiltração de dados.

Função dos corretores de identidade

Para lidar com esses cenários, é necessária a funcionalidade integrada de um agente de identidade.
Os corretores de identidade funcionam como provedores OIDC (OpenID Connect) para o componente proxy SASE/SSE e, ao mesmo tempo, atuam como clientes OIDC/SAML/LDAP para os serviços de identidade upstream (serviços de autenticação).
O Keycloak, um sistema IAM de código aberto, é uma escolha popular para muitos.
Ele pode ser configurado para cumprir a função de um corretor de identidade e é comumente usado por provedores de serviços SASE e fornecedores de produtos de malha de serviços.
Por isso, a terminologia Keycloak é usada aqui.
O Keycloak oferece a flexibilidade para lidar com a autenticação de vários tipos de aplicativos, inclusive aplicativos SaaS multilocatários.
A autenticação para aplicativos SaaS multilocatários pode ser obtida usando “corretores de identidade” da seguinte maneira: Um reino com um cliente para cada aplicativo SaaS com fluxos de autenticação modificados: Nos casos em que o locatário do aplicativo não pode ser identificado pelo caminho do URL ou pelos cabeçalhos de solicitação HTTP, o componente proxy SASE pode ter apenas um cliente OIDC para se comunicar com o agente de identidade.
Durante a autenticação do usuário, o agente de identidade precisa saber em qual serviço de IDP o usuário deve ser autenticado.
O Keycloak fornece fluxos de autenticação padrão, como o fluxo do navegador, e permite a criação de fluxos personalizados e associações com clientes Keycloak.
O SASE aproveita esse recurso criando fluxos de autenticação em que os usuários são solicitados a fornecer informações do locatário.
Com base nessas informações, os fluxos de autenticação podem apresentar os provedores de identidade disponíveis para o usuário selecionar.
Com essas informações, o agente pode redirecionar os usuários para o serviço de identidade apropriado. Um reino com vários clientes para cada aplicativo SaaS: Se o locatário do aplicativo puder ser identificado pelo URL ou pelos cabeçalhos de solicitação HTTP, o componente proxy SASE poderá ser configurado para usar um cliente para cada locatário do aplicativo.
Nesse caso, os fluxos padrão do navegador com diferentes conjuntos de provedores de identidade podem ser empregados e associados às entidades de cliente correspondentes no Keycloak.
A vantagem disso é que o usuário não é solicitado a fornecer o nome do locatário, o que melhora a experiência do usuário.
Em resumo, essas estratégias capacitam as soluções SASE a lidar de forma eficaz com a autenticação de aplicativos SaaS multilocatários, aproveitando os recursos do Keycloak como corretor de identidade.

Seleção de clientes OIDC com base em políticas

O corretor Keycloak oferece suporte a vários reinos e vários clientes em cada reino.
Ele permite fluxos de autenticação padrão, a criação de fluxos de autenticação personalizados e a associação desses fluxos com os clientes.
A funcionalidade do corretor Keycloak também permite a intermediação de sessões de autenticação entre mecanismos de autenticação do lado do usuário e serviços de autenticação de backend (upstream).
Já discutimos anteriormente como o Keycloak pode solicitar que os usuários identifiquem seu locatário de aplicativo e selecionem o serviço de identidade para autenticação.
Esses recursos também devem ser aproveitados pelo proxy SASE, que atua como um cliente OIDC (também conhecido como relé OIDC) para vários aplicativos de clientes, inclusive aplicativos multilocatários.
O proxy SASE precisa oferecer suporte a vários clientes OIDC.
Uma abordagem é ter um conjunto de clientes OIDC para cada cliente, garantindo que as configurações relacionadas à autenticação específicas do cliente sejam isoladas das demais.
Normalmente, o conjunto de OIDCs de cada cliente do SASE é associado a um realm no Keycloak.
Em cenários em que um cliente do proxy SASE tem vários aplicativos, cada um com seu próprio nome de domínio, torna-se necessário fornecer isolamento entre vários administradores de aplicativos.
Nesses casos, um subconjunto de clientes OIDC deve ser configurado, com um cliente atribuído a cada aplicativo.
Para muitos aplicativos, um único cliente OIDC é suficiente se for um aplicativo de locatário único ou se o locatário não puder ser identificado pelo tráfego, conforme discutido anteriormente.
No entanto, se o locatário puder ser identificado, um cliente OIDC poderá ser configurado para cada locatário de aplicativo.
Devido ao requisito de vários clientes OIDC, o proxy SASE deve oferecer um mecanismo para selecionar o cliente OIDC apropriado.
É nesse ponto que a seleção de OIDC baseada em políticas se torna crucial.
É utilizada uma tabela de políticas com várias políticas, sendo que cada política aponta para o registro do cliente OIDC correspondente.
Durante o fluxo de tráfego, o proxy SASE verifica se a autenticação OIDC é necessária e, em seguida, compara o cliente, o nome de domínio do aplicativo e o locatário do aplicativo com as políticas da tabela.
Se for encontrada uma correspondência, o registro de cliente OIDC correspondente será usado para se comunicar com o agente.
Algumas implementações podem ter várias tabelas de políticas, com uma tabela dedicada a cada cliente, para agilizar o processo de correspondência de políticas.

O NextGen ZTNA se adaptará a aplicativos multilocatários

O ZTNA (Zero Trust Network Access) dentro das soluções SASE (Secure Access Service Edge) desempenha um papel fundamental na proteção dos aplicativos.
Ele permite a transferência de tarefas de autenticação e autorização dos aplicativos, permitindo que os desenvolvedores se concentrem em sua lógica comercial principal.
Essa abordagem aumenta a produtividade e reforça a segurança geral.
As vulnerabilidades de desvio de autenticação e de escalonamento de privilégios são comuns nos aplicativos, pois nem todos os desenvolvedores têm experiência em segurança.
A transferência da segurança pode eliminar essas vulnerabilidades, garantindo maior resiliência dos aplicativos.
A centralização da segurança em um local comum, como o SASE, simplifica o trabalho dos administradores de segurança, que só precisam gerenciar uma única interface para todos os aplicativos.
Para obter segurança e flexibilidade, a próxima geração de ZTNA dentro das soluções SASE deve abordar diversos tipos de aplicativos.
Muitas das soluções de ZTNA existentes geralmente têm dificuldades para oferecer suporte eficaz a aplicativos multilocatários.
Espera-se que os aprimoramentos futuros incorporem a funcionalidade de corretor de identidade e a seleção de clientes OIDC (OpenID Connect) baseada em políticas para atender a uma ampla gama de cenários de aplicativos.

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