Compartilhar via

Abordagens arquitetônicas para identidade em soluções multiinquilino

Quase todas as soluções multilocatário exigem um sistema de identidade. Este artigo descreve componentes comuns de identidade, incluindo autenticação e autorização, e como você pode aplicar esses componentes em uma solução multilocatário.

Observação

Antes de começar a criar um sistema de identidade para uma solução multilocatário, consulte considerações de arquitetura para identidade em uma solução multilocatário.

Autenticação

A autenticação é o processo que estabelece a identidade de um usuário. Ao criar uma solução multilocatário, considere as várias abordagens para diferentes aspectos do processo de autenticação.

Federação

Talvez seja necessário federar com IdPs (provedores de identidade externos). Você pode usar a federação para habilitar os seguintes cenários:

  • Logon social, que permite que os usuários entrem com sua conta do Google, Facebook, GitHub ou pessoal da Microsoft

  • Diretórios específicos do locatário, que permitem aos locatários federar seu aplicativo com seus próprios IdPs para que eles não precisem gerenciar contas em vários locais

Para obter mais informações, consulte o padrão de Identidade Federada.

Se você optar por dar suporte a IdPs específicos do locatário, certifique-se de esclarecer quais serviços e protocolos seu aplicativo dá suporte. Por exemplo, determine se deve oferecer suporte ao protocolo OpenID Connect e ao protocolo Security Assertion Markup Language, ou se a federação deve ser limitada às instâncias do Microsoft Entra ID.

Ao implementar um IdP, considere a escala e os limites que podem ser aplicados. Por exemplo, seu IdP pode ser capaz de federar com apenas um número limitado de outros IdPs.

Considere também disponibilizar a federação como uma funcionalidade que se aplica apenas aos clientes de um nível de produto mais elevado.

Logon Único

O logon único permite que os usuários alternem entre aplicativos sem serem solicitados a se autenticar novamente em cada ponto.

Quando os usuários visitam um aplicativo, o aplicativo os direciona para um IdP. Se o IdP detectar uma sessão existente, ele emitirá um novo token sem exigir que os usuários interajam com o processo de entrada. Um modelo de identidade federado dá suporte ao logon único, permitindo que os usuários usem uma única identidade em vários aplicativos.

Em uma solução multilocatário, você pode habilitar outra forma de logon único. Se os usuários estiverem autorizados a acessar dados em vários locatários, talvez seja necessário fornecer uma experiência perfeita quando os usuários alterarem o contexto de um locatário para outro. Considere se sua solução precisa dar suporte a transições perfeitas entre locatários. Nesse caso, considere se o IdP deve reemitir tokens com declarações de locatário específicas. Por exemplo, quando um usuário entra no portal do Azure, ele pode alternar entre diferentes diretórios da ID do Microsoft Entra. Essa transição dispara a reautenticação e gera um novo token da instância da ID do Microsoft Entra recém-selecionada.

Avaliação de riscos de login

As plataformas de identidade modernas oferecem suporte a uma avaliação de risco durante o processo de entrada. Por exemplo, se um usuário entrar de um local ou dispositivo incomum, o sistema de autenticação poderá exigir verificações de identidade extras, como MFA (autenticação multifator), antes de permitir que a solicitação de entrada continue.

Considere se seus locatários podem ter políticas de risco diferentes que precisam ser aplicadas durante o processo de autenticação. Por exemplo, se você tiver alguns locatários em um setor altamente regulamentado, eles poderão ter perfis e requisitos de risco diferentes dos locatários que trabalham em ambientes menos regulamentados. Ou você pode permitir que locatários em níveis de preços mais altos especifiquem políticas de entrada mais restritivas do que os locatários que compram uma camada mais baixa do serviço.

Se você precisar dar suporte a políticas de risco diferentes para cada locatário, seu sistema de autenticação precisará saber em qual locatário o usuário está entrando para que ele possa aplicar as políticas corretas.

Se o seu IdP incluir esses recursos, considere usar os recursos nativos de avaliação de risco de entrada do IdP. Esses recursos podem ser muito complexos e propensos a erros para serem implementados por você mesmo.

Como alternativa, se você federar com os IdPs dos locatários, suas políticas de mitigação para entradas suspeitas poderão ser aplicadas, o que lhes permite controlar a aplicação de políticas e controles. Por exemplo, exigir dois desafios de MFA, um do IdP inicial do usuário e outro do seu próprio, pode dificultar o processo de entrada. Verifique se você entende como a federação interage com cada um dos IdPs do locatário e as políticas que eles têm em vigor.

Representação

A representação permite que um usuário assuma a identidade de outro usuário sem usar as credenciais desse usuário.

A representação geralmente é perigosa e pode ser difícil de implementar e controlar. No entanto, em alguns cenários, a personificação é necessária. Por exemplo, se você opera em um ambiente saaS (software como serviço), talvez a equipe de suporte técnico precise assumir a identidade de um usuário para que ele possa entrar como usuário e solucionar um problema.

Se você implementar a representação, considere como auditar seu uso. Verifique se os logs incluem o usuário que executou a ação e o identificador do usuário que ele representou.

Algumas plataformas de identidade oferecem suporte à representação, seja como um recurso interno ou usando código personalizado. Por exemplo, você pode adicionar uma declaração personalizada na ID Externa do Microsoft Entra para a ID de usuário representada ou substituir a declaração do identificador de assunto nos tokens emitidos.

Autorização

A autorização é o processo de determinação daquilo que um usuário tem permissão para fazer.

Os dados de autorização podem ser armazenados em vários locais, inclusive nos seguintes locais:

  • Em seu IdP: Por exemplo, se você usar a ID do Microsoft Entra como seu IdP, poderá usar recursos como funções de aplicativo e grupos para armazenar informações de autorização. Seu aplicativo pode usar as declarações de token associadas para impor suas regras de autorização.

  • Em seu aplicativo: Você pode criar sua própria lógica de autorização e armazenar informações sobre o que cada usuário pode fazer em um banco de dados ou sistema de armazenamento semelhante. Em seguida, você pode criar controles refinados para autorização baseada em função ou em nível de recurso.

Na maioria das soluções multilocatários, o cliente ou locatário gerencia atribuições de função e permissão, e não o fornecedor do sistema multilocatário.

Adicionar informações de identidade e função do locatário aos tokens

Determine quais partes da solução devem lidar com solicitações de autorização. Avalie se deve permitir que um usuário acesse dados de um inquilino específico.

Uma abordagem comum é que seu sistema de identidade incorpore uma declaração de identificador de locatário em um token. Essa abordagem permite que seu aplicativo inspecione a declaração e verifique se os usuários estão trabalhando com o locatário que têm permissão para acessar. Se você usar o modelo de segurança baseado em função, poderá estender o token para incluir informações sobre a função do usuário dentro do locatário.

No entanto, se um único usuário tiver permissão para acessar vários locatários, talvez seja necessário uma maneira de seus usuários sinalizarem com qual locatário eles planejam trabalhar durante o processo de entrada. Depois que o usuário seleciona seu locatário ativo, o IdP pode emitir um token que inclua a declaração e a função corretas do identificador de locatário para esse locatário. Você também precisa considerar como os usuários podem alternar entre locatários, o que requer a emissão de um novo token.

Autorização baseada em aplicativo

Uma abordagem alternativa é tornar o sistema de identidade independente dos identificadores e funções do locatário. Os usuários são identificados por meio de suas credenciais ou uma relação de federação, e os tokens não incluem uma declaração de identificador de locatário. Uma lista ou banco de dados separado mantém registros de quais usuários têm acesso a cada inquilino. Em seguida, a camada de aplicativo verifica se um usuário especificado está autorizado a acessar dados de um locatário específico com base nessa lista.

Usar Microsoft Entra ID ou ID Externa

As identidades Microsoft Entra ID e ID Externa são plataformas de identidade gerenciadas que você pode utilizar em sua própria solução multitenant.

Muitas soluções multiclientes operam como SaaS. Sua escolha de usar a ID do Microsoft Entra ou a ID Externa depende, em parte, de como você define seus locatários ou base de clientes.

Importante

O Azure AD B2C também dá suporte a muitos dos cenários neste artigo. No entanto, a partir de 1º de maio de 2025, ele não está mais disponível para compra para novos clientes, portanto, não recomendamos isso para novas soluções. Para obter mais informações, consulte perguntas frequentes sobre o Azure AD B2C.

Antipadrões a serem evitados

Criando ou executando seu próprio sistema de identidade

Construir uma plataforma de identidade moderna é complexo. Ele requer suporte para uma variedade de protocolos e padrões, e uma implementação incorreta pode introduzir vulnerabilidades de segurança. Como os padrões e os protocolos mudam, você precisa atualizar continuamente seu sistema de identidade para reduzir os ataques e incorporar os recursos de segurança mais recentes. Também é importante garantir que um sistema de identidade seja resiliente porque qualquer tempo de inatividade pode ter sérias consequências para o resto da solução. Na maioria dos cenários, a implementação de um IdP não beneficia diretamente os negócios, mas é necessário para implementar um serviço multilocatário. É melhor usar um sistema de identidade especializado que os especialistas criam, operam e protegem.

Quando você executa seu próprio sistema de identidade, você precisa armazenar hashes de senha ou outras formas de credenciais, que se tornam um alvo tentador para invasores. Mesmo o hash e o salting de senhas muitas vezes são uma proteção insuficiente, pois os invasores têm poder computacional suficiente para potencialmente comprometer essas credenciais.

Ao executar um sistema de identidade, você é responsável por gerar e distribuir códigos de MFA ou senha única. Você precisa de um mecanismo para enviar esses códigos por SMS ou email. Você também é responsável por detectar ataques direcionados e de força bruta, controlar as tentativas de entrada e a manutenção de logs de auditoria.

Em vez de criar ou gerenciar seu próprio sistema de identidade, é melhor usar um serviço ou componente predefinido. Por exemplo, considere plataformas de identidade gerenciada, como a ID do Microsoft Entra ou a ID Externa. Os fornecedores dessas plataformas são responsáveis por operar a infraestrutura e normalmente garantem suporte para padrões atuais de identidade e autenticação.

Falha em considerar os requisitos dos seus locatários

Os locatários geralmente têm preferências fortes sobre como gerenciar a identidade nas soluções que usam. Por exemplo, muitos clientes corporativos exigem federação com seus próprios IdPs para habilitar o logon único e evitar o gerenciamento de vários conjuntos de credenciais. Outros locatários podem exigir MFA ou medidas de segurança extras para o processo de entrada. Se você não considerar esses requisitos durante o design, adicioná-los posteriormente poderá ser difícil.

Certifique-se de entender os requisitos de identidade de seus locatários antes de finalizar o design do seu sistema de identidade. Para obter mais informações sobre requisitos específicos, consulte considerações de arquitetura para identidade em uma solução de multitenância.

Conflito entre usuários e locatários

É importante considerar claramente como sua solução define um usuário e um locatário. Em muitos cenários, a relação pode ser complexa. Por exemplo, um locatário poderia conter vários usuários, e um único usuário poderia ingressar em vários locatários.

Certifique-se de que você tem um processo claro para monitorar o contexto do locatário dentro de seu aplicativo e solicitações. Em alguns cenários, esse processo exige que você inclua um identificador de locatário em cada token de acesso e valide-o em cada solicitação. Em outros casos, as informações de autorização do locatário são armazenadas separadamente das identidades do usuário. Essa abordagem requer um sistema de autorização mais complexo para gerenciar quais usuários podem executar operações específicas em cada locatário.

O rastreamento do contexto de locatário de um usuário ou token é aplicável a qualquer modelo de locação, já que uma identidade de usuário sempre tem um contexto de locatário dentro de uma solução multitenant. É uma boa prática acompanhar o contexto do locatário quando você implanta selos independentes para um único locatário, o que torna sua base de código à prova de futuro para outras formas de multilocatário.

Conflito entre a função e a autorização de recursos

É importante escolher um modelo de autorização que atenda à sua solução. A segurança baseada em função é simples de implementar, mas a autorização baseada em recursos fornece um controle mais refinado. Avalie os requisitos de seus locatários e determine se eles precisam autorizar alguns usuários a acessar apenas partes específicas da sua solução.

Falha ao gravar logs de auditoria

Os logs de auditoria são uma ferramenta importante para entender seu ambiente e como os usuários implementam seu sistema. Ao auditar cada evento relacionado à identidade, você geralmente pode determinar se seu sistema de identidade está sob ataque e pode revisar como seu sistema está sendo usado. Certifique-se de gravar e armazenar logs de auditoria em seu sistema de identidade. Considere se os logs de auditoria de identidade da sua solução devem ser disponibilizados aos locatários para revisão.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos no LinkedIn, entre no LinkedIn.