O guia definitivo para configurar autenticação e autorização multi-tenant

Construir um aplicativo multi-tenant pode ser desafiador, com muitos aspectos a serem considerados. Este artigo compila todos os nossos postagens de blog anteriores sobre compreensão de práticas multi-tenant e organizacionais. Para um início rápido e para economizar tempo, basta conferir este artigo, ele inclui tudo o que você precisa!

As diretrizes gerais estão delineadas nos seguintes passos:

1. Compreender a arquitetura multi-tenant
2. Mapear os casos de uso do seu aplicativo multi-tenant
3. Alcançar isolamento do locatário
4. Definir como você deseja gerenciar as identidades
5. Escolher os modelos de autorização apropriados

O que é arquitetura multi-tenant#

A multi-locação de software é uma arquitetura de software na qual uma única instância de software é executada em um servidor e atende a vários locatários. Sistemas projetados desta forma são "compartilhados" (em vez de "dedicados" ou "isolados").

Um locatário é um grupo de usuários que compartilham acesso comum com privilégios específicos à instância do software.

Uma das mentalidades principais da multi-locação é "compartilhado". Na definição mais ampla de multi-locação, ser um aplicativo multi-tenant não implica que cada componente em uma solução é compartilhado. Em vez disso, implica que pelo menos alguns componentes de uma solução são reutilizados entre vários locatários. Compreender este termo de forma ampla pode ajudá-lo melhor a simpatizar com as necessidades do seu cliente e de onde eles vêm.

Uma vez que você compreenda a arquitetura multi-tenant, o próximo passo é aplicar seu aplicativo a cenários do mundo real, focando em necessidades específicas de produtos e negócios.

Quais são os casos de uso para aplicações multi-tenant?#

Multi-tenant em SaaS#

Aplicações multi-tenant geralmente encontram seu lugar em soluções business-to-business (B2B), como ferramentas de produtividade, softwares de colaboração e outros produtos de software como serviço (SaaS). Neste contexto, cada "locatário" geralmente representa um cliente empresarial, que pode ter vários usuários (seus funcionários). Além disso, um cliente empresarial pode ter vários locatários para representar organizações distintas ou divisões de negócios.

Multi-tenant em casos de uso genéricos B2B#

Aplicações B2B vão além dos produtos SaaS e muitas vezes envolvem o uso de aplicativos multi-tenant. Em contextos B2B, esses aplicativos servem como uma plataforma comum para várias equipes, clientes empresariais e empresas parceiras acessarem seus aplicativos.

Por exemplo, considere uma empresa de compartilhamento de caronas que fornece aplicativos tanto B2C quanto B2B. Os aplicativos B2B atendem a vários clientes empresariais, e empregar uma arquitetura multi-tenant pode ajudar no gerenciamento de seus funcionários e recursos. Para ilustrar, se a empresa deseja manter um sistema unificado de identidade de usuário, ela pode projetar uma arquitetura como o exemplo a seguir:

Sarah tem tanto uma identidade pessoal quanto empresarial. Ela usa o serviço de compartilhamento de caronas como passageira e também trabalha como motorista em seu tempo livre. Em sua função profissional, ela também gere seu negócio e usa esta identidade empresarial para ser parceira com o Negócio 1.

Por que você deve empregar multi-locação em produto SaaS#

Escalar com multi-locação#

Para negócios empresariais, a multi-locação é a chave para atender efetivamente seus requisitos de disponibilidade, gerenciamento de recursos, gerenciamento de custos e segurança de dados. Em um nível técnico, adotar uma abordagem multi-tenant agiliza seus processos de desenvolvimento, minimiza desafios técnicos e promove uma expansão contínua.

Criar uma experiência unificada#

Ao examinar as raízes dos produtos SaaS, é semelhante a um edifício que abriga vários apartamentos. Todos os locatários compartilham utilidades comuns, como água, eletricidade e gás, mas mantêm controle independente sobre o gerenciamento de seu próprio espaço e recursos. Esta abordagem simplifica a administração da propriedade.

Garantir a segurança através do isolamento do locatário#

Em uma arquitetura de multi-locação, o termo "locatário" é introduzido para criar fronteiras que separam e protegem os recursos e dados de diferentes locatários dentro de uma instância compartilhada. Isso garante que os dados e operações de cada locatário permaneçam distintos e seguros, mesmo que estejam utilizando os mesmos recursos subjacentes.

Por que você deve alcançar o isolamento do locatário?#

Ao discutir aplicações multi-tenant, é sempre necessário alcançar o isolamento do locatário. Isso significa manter os dados e recursos de diferentes locatários separados e seguros dentro de um sistema compartilhado (por exemplo, uma infraestrutura em nuvem ou uma aplicação multi-tenant). Isso impede qualquer tentativa não autorizada de acessar os recursos de outro locatário.

Embora a explicação possa parecer abstrata, vamos usar exemplos e detalhes chave para explicar melhor a mentalidade de isolamento e a melhor prática para alcançar o isolamento do locatário.

O isolamento do locatário não vai contra a mentalidade de "compartilhado" da multi-locação#

Isso porque o isolamento do locatário não é necessariamente uma construção em nível de recurso de infraestrutura. No reino da multi-locação e isolamento, alguns veem o isolamento como uma divisão estrita entre recursos reais de infraestrutura. Isso geralmente leva a um modelo em que cada locatário tem bancos de dados, instâncias de computação, contas ou nuvens privadas separadas. Em cenários de recursos compartilhados, como aplicativos multi-tenant, a maneira de alcançar o isolamento pode ser uma construção lógica.

O isolamento do locatário foca exclusivamente em usar o contexto "locatário" para limitar o acesso aos recursos. Ele avalia o contexto do locatário atual e usa esse contexto para determinar quais recursos são acessíveis para esse locatário.

Autenticação e autorização não são iguais a "isolamento"#

Usar autenticação e autorização para controlar o acesso ao seu ambiente SaaS é importante, mas não é suficiente para um isolamento completo. Esses mecanismos são apenas uma parte do quebra-cabeça de segurança.

As pessoas muitas vezes perguntam se podem usar soluções gerais de autorização e controle de acesso baseado em funções para alcançar o isolamento do locatário.

A questão é que você pode construir um aplicativo multi-tenant, mas não pode dizer que alcançou e empregou estratégias de isolamento do locatário como uma melhor prática. Nós geralmente não recomendamos porque

Para ilustrar, considere uma situação em que você configurou autenticação e autorização para o seu sistema SaaS. Quando os usuários fazem login, eles recebem um token contendo informações sobre seu papel, ditando o que podem fazer na aplicação. Esta abordagem aumenta a segurança, mas não garante isolamento.

Use "organização" para representar o locatário do produto SaaS, para alcançar o isolamento do locatário#

Confiar apenas na autenticação e autorização não impedirá que um usuário com o papel certo acesse os recursos de outro locatário. Então, precisamos incorporar um contexto de "locatário", como um ID de locatário, para restringir o acesso aos recursos.

É aqui que o isolamento do locatário entra em ação. Ele usa identificadores específicos do locatário para estabelecer fronteiras, muito semelhantes a paredes, portas e trancas, garantindo uma separação clara entre locatários.

Gestão de identidade em aplicativos multi-tenant#

Discutimos o isolamento do locatário, mas e as identidades? Como você decide se suas identidades devem ser "isoladas" ou não?

Há frequentemente confusão em torno do conceito de "isolamento de identidade". Pode referir-se a situações em que um usuário do mundo real tem duas identidades no entendimento geral das pessoas.

1. Ambas as identidades podem existir dentro de um único sistema de identidade. Por exemplo, Sarah pode ter um email pessoal registrado ao lado de um email corporativo conectado por single sign-on (SSO).
2. Os usuários mantêm duas identidades distintas dentro de sistemas de identidade separados, representando produtos completamente separados. Esses produtos são completamente não relacionados entre si.

Às vezes, esses cenários são referidos como "identidade isolada". No entanto, esse rótulo pode não ajudar na tomada de decisão.

Em vez de determinar se você precisa de "isolamento de identidade", considere

Esta resposta pode orientar o design do seu sistema. Para uma resposta breve sobre um aplicativo multi-tenant,

Em aplicações multi-tenant, identidades, ao contrário de recursos e dados específicos do locatário, são compartilhadas entre múltiplos locatários. Imagine-se como o administrador do edifício; você não gostaria de manter duas listas de nomes separadas para gerenciar as identidades dos seus locatários.

Ao buscar o isolamento do locatário, você pode ter observado o foco recorrente no termo "organização", muitas vezes considerado uma prática recomendada para a construção de aplicativos multi-tenant.

Ao empregar a noção de "organização", você pode alcançar o isolamento do locatário em sua aplicação multi-tenant, enquanto mantém um sistema unificado de identidade.

Como escolher e projetar o modelo de autorização apropriado#

Ao selecionar o modelo de autorização certo, considere estas questões:

1. Você está desenvolvendo um produto B2C, B2B, ou uma combinação de ambos os tipos de produtos?
2. Seu aplicativo possui uma arquitetura multi-tenant?
3. Existe a necessidade de um certo nível de isolamento em seu aplicativo, conforme determinado pela unidade de negócios?
4. Quais permissões e funções precisam ser definidas dentro do contexto da organização, e quais não?

Quais modelos de autorização diferentes estão disponíveis no Logto?#

Controle de acesso baseado em função#

RBAC (Controle de Acesso Baseado em Funções) é um método para conceder permissões de usuário com base em seus papéis, permitindo uma gestão eficaz do acesso a recursos.

Esta técnica comum baseia o controle de acesso e é um componente chave das funcionalidades de autorização do Logto. Como uma plataforma abrangente de gestão de identidade, Logto oferece soluções personalizadas para várias camadas e entidades, atendendo a desenvolvedores e empresas para diversas arquiteturas de produtos.

Controle de acesso baseado em função de API#

Para proteger recursos gerais de API que não são específicos de nenhuma organização e não precisam de restrições de contexto, o recurso API RBAC é ideal.

Basta registrar a API e atribuir permissões a cada recurso. Então, controle o acesso através da relação entre papéis e usuários.

Recursos de API, papéis e permissões aqui são "democratizados" sob um sistema unificado de identidade. Isso é bastante comum no produto B2C, com menos hierarquia e que não precisa de um nível profundo de isolamento.

Controle de acesso baseado em função organizacional#

No ambiente B2B e multi-tenant, o isolamento do locatário é necessário. Para alcançar isso, organizações são usadas como um contexto para isolamento, o que significa que o RBAC é eficaz apenas quando um usuário pertence a uma organização específica.

O RBAC organizacional foca no controle de acesso a nível de organização, em vez do nível de API. Isso proporciona uma flexibilidade significativa para a autogestão a nível de organização a longo prazo, mas ainda dentro de um sistema unificado de identidade.

Uma característica chave do RBAC organizacional é que os papéis e permissões são geralmente os mesmos em todas as organizações por padrão, o que torna o “modelo de organização” do Logto extremamente significativo para melhorar a eficiência do desenvolvimento. Isso se alinha com a filosofia compartilhada dos aplicativos multi-tenant, onde políticas de controle de acesso e identidades são componentes de infraestrutura comuns entre todos os locatários (locatários do aplicativo), uma prática comum em produtos SaaS.

Encerramento#

Este artigo fornece tudo o que você precisa para começar a preparar e configurar aplicativos multi-tenant. Experimente o Logto hoje e comece a aplicar as melhores práticas para o desenvolvimento de aplicativos multi-tenant com organizações.