“Segurança de software é um problema complexo, e tem se tornado ainda mais complexo com o avanço dos microsserviços, onde cada serviço precisa tratar da segurança”, afirmou David Borsos, especialista no tema, na Microservices Conference, em Londres, durante sua apresentação sobre opções de autenticação de usuário final dentro de sistemas baseados em microsserviços.
Em uma arquitetura monolítica tradicional, um único servidor contém todos os dados do usuário e pode verificar e criar uma sessão http quando um usuário é autenticado. Em uma arquitetura de microsserviço, um usuário interage com uma coleção de serviços, cada um com uma necessidade potencial de saber quem é o usuário. Uma solução ingênua é aplicar o mesmo padrão do sistema monolítico em um sistema de microsserviços; é então que surge o problema de como dar acesso a todos os serviços de dados do usuário. Ao usar um banco de dados de usuários compartilhados, atualizar o schema torna-se um problema difícil, pois todos os serviços devem ser atualizados ao mesmo tempo. Ao distribuir os mesmos dados para todos os serviços, há o problema de como fazer cada serviço saber quando um usuário está autenticado.
Analisando diferentes soluções, Borsos observa que uma solução de login único – single sign-on (SSO) – pode parecer boa ideia, mas isso significa que todos os serviços públicos devem conversar com o serviço de autenticação, criando assim um tráfego bastante intenso. É também bastante complexo de implementar. Por outro lado, a segurança é tão boa como o SSO escolhido e o estado de login do usuário é opaco, impedindo que um invasor infira qualquer informação útil do estado.
Com uma solução de sessão distribuída, as informações sobre a autenticação do usuário são armazenadas em um data store compartilhado, muitas vezes um simples mapa de hash distribuído iniciado pela sessão do usuário. Quando um usuário acessa um microserviço, seus dados podem ser extraídos do armazenamento de dados. Outra vantagem desta solução é que o estado de login do usuário é opaco. Ao usar um banco de dados distribuído, também é uma solução altamente disponível e escalável. As desvantagens incluem o fato de que o armazenamento de dados deve ser protegido e, portanto, somente acessível através de uma conexão segura, e a implementação da solução geralmente contempla uma complexidade bastante alta.
Usando tokens do lado do cliente, o usuário é autenticado e um token é criado no lado do cliente. Este token é assinado por um serviço de autenticação e deve conter informações suficientes para que a identidade do usuário possa ser estabelecida em todos os microsserviços. O token é anexado a cada solicitação, dando a um serviço a possibilidade de verificar o usuário. A segurança é relativamente boa com esta solução, mas um grande problema é a dificuldade de logout. Formas de mitigar isso incluem o uso de tokens de curta duração e verificações frequentes com o serviço de autenticação. Borsos prefere usar o JSON Web Tokens (JWT) para tokens do lado do cliente, entre outras coisas, por sua simplicidade e bom suporte de biblioteca.
Usar um token do lado do cliente junto com um gateway API significa que todos os pedidos estão passando por um gateway, ocultando efetivamente os microsserviços. Em uma requisição, o gateway transforma o token original de usuário em um token ID de sessão interna. O logout não é um problema aqui porque o gateway pode revogar o token do usuário quando desconectado. Mesmo que o suporte da biblioteca seja bom, a implementação pode ser complexa.
Por isso, como recomendação geral, Borsos sugere o uso de tokens do lado do cliente, com o JWT, e um gateway API porque geralmente é mais fácil e mais simples de implementar e tem um bom desempenho. O SSO também pode funcionar, mas ele acha que deve ser evitado. Usar sessões distribuídas pode ser interessante, especialmente nos casos de uso em que as tecnologias necessárias já estão em andamento. Ele enfatiza a importância de considerar a questão do logout ao escolher uma solução.
Abaixo os slides da palestra de David Borsos:
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.