Compartilhar via

Abordagens de arquitetura para identidade em soluções multilocatário

  • Artigo

Quase todas as soluções multilocatário exigem um sistema de identidade. Neste artigo, abordaremos componentes comuns de identidade, incluindo autenticação e autorização, e mostraremos como esses componentes podem ser aplicados em uma solução multilocatário.

Observação

Revise as Considerações de arquitetura para identidade em uma solução multilocatário para saber mais sobre os principais requisitos e decisões que você precisa tomar, antes de começar a criar um sistema de identidade para uma solução multilocatário.

Autenticação

A autenticação é o processo pelo qual a identidade de um usuário é estabelecida. Quando você cria uma solução multilocatário, há considerações e abordagens especiais para vários aspectos do processo de autenticação.

Federação

Talvez seja necessário federar com outros provedores de identidade (IdPs). A federação pode ser usada para habilitar os seguintes cenários:

  • Login social, por exemplo, permitindo que os usuários usem suas contas do Google, Facebook, GitHub ou Microsoft pessoais.
  • Diretórios específicos do locatário, por exemplo, permitindo que os locatários façam federação de seu aplicativo com seus próprios provedores de identidade, para que não precisem gerenciar contas em vários lugares.

Para obter informações gerais sobre federação, consulte o padrão de identidade federada.

Se você optar por oferecer suporte a provedores de identidade específicos do locatário, certifique-se de esclarecer quais serviços e protocolos você precisa suportar. Por exemplo, você suportará o protocolo OpenID Connect e o protocolo SAML (Security Assertion Markup Language)? Ou você só dará suporte à federação com instâncias do Microsoft Entra?

Ao implementar qualquer provedor de identidade, considere qualquer escala e limites que possam ser aplicados. Por exemplo, se você usar o Azure Active Directory (Azure AD) B2C como seu próprio provedor de identidade, talvez seja necessário implantar políticas personalizadas para federar com determinados tipos de provedores de identidade de locatário. O Azure AD B2C limita o número de políticas personalizadas que você pode implantar, o que pode limitar o número de provedores de identidade específicos do locatário com os quais você pode federar.

Você também pode considerar o fornecimento de federação como um recurso que só se aplica a clientes em um nível de produto mais alto.

Logon Único

As experiências de logon único permitem que os usuários alternem entre aplicativos perfeitamente, 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 perceber que há uma sessão existente, ele emitirá um novo token, sem exigir que os usuários interajam com o processo de logon. Um modelo de identidade federada oferece suporte a experiências de logon único, permitindo que os usuários usem uma única identidade em vários aplicativos.

Em uma solução multilocatário, você também pode habilitar outra forma de logon único. Se os usuários estiverem autorizados a trabalhar com dados para vários locatários, talvez seja necessário fornecer uma experiência perfeita quando os usuários alterarem seu contexto de um locatário para outro. Descubra se você precisa oferecer suporte a transições perfeitas entre locatários e, em caso afirmativo, se seu provedor de identidade precisa reemitir tokens com declarações de locatário específicas. Por exemplo, um usuário que entrou no portal do Azure pode alternar entre diferentes diretórios do Microsoft Entra, o que causa reautenticação, reemitindo o token da instância do Microsoft Entra recém-selecionada.

Avaliação de risco de logon

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 podem ter perfis de risco e requisitos diferentes dos locatários que trabalham em ambientes menos regulamentados. Ou, você pode optar por permitir que locatários com níveis de preços mais altos especifiquem políticas de entrada mais restritivas do que locatários que compram uma camada inferior do seu serviço.

Se você precisar oferecer 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á fazendo login, para que 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ê se federar aos próprios provedores de identidade dos locatários, suas próprias políticas de mitigação de logon suspeito poderão ser aplicadas, e os locatários poderão controlar as políticas e os controles que devem ser impostos. No entanto, é importante evitar adicionar inadvertidamente cargas desnecessárias aos usuários, como exigir dois desafios de MFA, um do provedor de identidade inicial do usuário e outro do seu próprio. Certifique-se de entender como a federação interage com cada um dos provedores de identidade de seus locatários e as políticas que eles aplicaram.

Representação

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

Em geral, a representação é perigosa e pode ser difícil de implementar e controlar. No entanto, em alguns cenários, a representação é um requisito. Por exemplo, se você opera software como serviço (SaaS), sua equipe de suporte técnico pode precisar assumir a identidade de um usuário, para que ela possa entrar como o usuário e solucionar um problema.

Se você optar por implementar a representação, considere como auditar seu uso. Certifique-se de que seus logs incluam o usuário real que executou a ação e o identificador do usuário que eles representaram.

Algumas plataformas de identidade oferecem suporte à representação, seja como um recurso interno ou usando código personalizado. Por exemplo, no Azure AD B2C, você pode adicionar uma declaração personalizada para a ID de usuário representada ou pode substituir a declaração de identificador de entidade 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:

  • No seu provedor de identidade. Por exemplo, se você usar a ID do Microsoft Entra como seu provedor de identidade, poderá usar recursos como funções de aplicativos 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.
  • No seu aplicativo. Você pode criar sua própria lógica de autorização e, em seguida, 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ário, as atribuições de função e permissão são gerenciadas pelo locatário ou cliente, não por você como fornecedor do sistema multilocatário.

Para obter mais informações, consulte Funções do aplicativo.

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

Considere qual parte, ou partes, de sua solução devem executar solicitações de autorização, incluindo determinar se um usuário tem permissão para trabalhar com dados de um locatário 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 eles têm permissão para acessar. Se você usar o modelo de segurança baseado em função, poderá optar por estender o token com informações sobre a função que um usuário tem no locatário.

No entanto, se um único usuário tiver permissão para acessar vários locatários, talvez você precise de uma maneira de os usuários sinalizarem com qual locatário planejam trabalhar durante o processo de logon. Depois de selecionar seu locatário ativo, o IdP pode incluir a declaração e a função corretas do identificador de locatário para esse locatário, dentro do token que emite. 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 usando 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 contém quais usuários receberam acesso a cada locatário. Em seguida, a camada de aplicativo pode verificar se o usuário especificado deve ter permissão para acessar os dados de um locatário específico, com base na pesquisa dessa lista.

Usar o Microsoft Entra ID ou o Azure AD B2C

A Microsoft fornece o Microsoft Entra ID, a ID Externa do Microsoft Entra e o Azure AD B2C, que são plataformas de identidade gerenciadas que você pode usar em sua própria solução multilocatário.

Muitas soluções multilocatárias são software como serviço (SaaS). Sua escolha de usar o Microsoft Entra ID, a ID Externa do Microsoft Entra ou o Azure AD B2C depende, em parte, de como você define seus locatários ou base de clientes.

  • Se seus locatários ou clientes forem organizações, eles já podem usar o Microsoft Entra ID para serviços como o Office 365, o Microsoft Teams ou para seus próprios ambientes do Azure. Você pode criar um aplicativo multilocatário em seu próprio diretório do Microsoft Entra, para disponibilizar sua solução para outros diretórios do Microsoft Entra. Você pode até listar sua solução no Azure Marketplace e torná-la facilmente acessível para organizações que usam oMicrosoft Entra ID.
  • Se os seus locatários ou clientes não usarem o Microsoft Entra ID ou se forem indivíduos em vez de organizações, considere usar a ID Externa do Microsoft Entra ou o Azure AD B2C. A ID Externa do Microsoft Entra e o Azure AD B2C fornecem um conjunto de recursos para controlar como os usuários se inscrevem e fazem logon. Por exemplo, você pode restringir o acesso à sua solução apenas aos usuários que já convidou, ou pode permitir a inscrição de autoatendimento. Use políticas personalizadas no Azure AD B2C para controlar totalmente como os usuários interagem com a plataforma de identidade. Você pode usar a identidade visual personalizada e federar o Azure AD B2C com seu próprio locatário do Microsoft Entra para permitir que sua própria equipe faça logon. O Azure AD B2C também habilita a federação com outros provedores de identidade.
  • Algumas soluções multilocatário destinam-se às duas situações listadas acima. Alguns locatários podem ter seus próprios locatários do Microsoft Entra, enquanto outros não podem. Você também pode usar o Azure AD B2C para esse cenário e usar políticas personalizadas para permitir a entrada do usuário no diretório Microsoft Entra de um locatário. No entanto, se você usar políticas personalizadas para estabelecer federação entre locatários, certifique-se de considerar os limites no número de políticas personalizadas que um único diretório do Azure AD B2C pode usar.

Para obter mais informações, consulte Considerações sobre o uso do Azure Active Directory B2C em uma arquitetura multilocatário.

Antipadrões a serem evitados

Criando ou executando seu próprio sistema de identidade

Construir uma plataforma de identidade moderna é complexo. Há uma variedade de protocolos e padrões para oferecer suporte, e é fácil implementar incorretamente um protocolo e expor uma vulnerabilidade de segurança. Os padrões e protocolos mudam, e você também precisa atualizar continuamente seu sistema de identidade para mitigar ataques e oferecer suporte a recursos de segurança recentes. Também é importante garantir que um sistema de identidade seja resiliente, pois qualquer tempo de inatividade pode ter consequências graves para o restante da solução. Além disso, na maioria das situações, a implementação de um provedor de identidade não adiciona um benefício ao negócio e é simplesmente uma parte necessária da implementação de um serviço multilocatário. Em vez disso, é melhor usar um sistema de identidade especializado que seja construído, operado e protegido por especialistas.

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. Até mesmo hashing e uso de sal em senhas geralmente são proteções insuficientes, porque o poder computacional disponível para invasores pode tornar possível comprometer essas formas de credenciais.

Ao executar um sistema de identidade, você também é responsável por gerar e distribuir códigos de MFA ou OTP (senha de uso único). Esses requisitos significam que você precisa de um mecanismo para distribuir esses códigos, usando SMS ou email. Além disso, você é responsável por detectar ataques direcionados e de força bruta, limitar tentativas de entrada, realizar auditoria e assim por diante.

Em vez de criar ou executar seu próprio sistema de identidade, é uma boa prática usar um serviço ou componente pronto para uso. Por exemplo, considere usar o Microsoft Entra ID ou o Azure AD B2C, que são plataformas de identidade gerenciadas. Os fornecedores de plataformas de identidade gerenciadas assumem a responsabilidade de operar a infraestrutura de suas plataformas e, normalmente, oferecer suporte aos padrões atuais de identidade e autenticação.

Falha em considerar os requisitos dos seus locatários

Os locatários geralmente têm opiniões enfáticas sobre como a identidade deve ser gerenciada para as soluções que usam. Por exemplo, muitos clientes corporativos exigem federação com seus próprios provedores de identidade, para habilitar experiências de logon único e evitar o gerenciamento de vários conjuntos de credenciais. Outros locatários podem exigir autenticação multifator ou outras formas de proteção em torno dos processos de entrada. Se você não planejou implementar esses requisitos, pode ser um desafio adaptá-los mais tarde.

Certifique-se de entender os requisitos de identidade de seus locatários antes de finalizar o design do seu sistema de identidade. Revise Considerações de arquitetura para identidade em uma solução multilocatário para entender alguns requisitos específicos que geralmente surgem.

Conflito entre usuários e locatários

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

Certifique-se de ter um processo claro para rastrear o contexto do locatário dentro de seu aplicativo e solicitações. Em algumas situações, esse processo pode exigir que você inclua um identificador de locatário em cada token de acesso e que você valide o identificador de locatário em cada solicitação. Em outras situações, você armazena as informações de autorização do locatário separadamente das identidades do usuário e usa um sistema de autorização mais complexo para gerenciar quais usuários podem executar quais operações em relação a quais locatários.

O controle do contexto do locatário de um usuário ou token é aplicável a qualquer modelo de locação, pois uma identidade de usuário sempre tem um contexto de locatário em uma solução multilocatário. É até uma boa prática controlar o contexto do locatário quando você implanta carimbos independentes para um único locatário, o que prepara sua base de código para outras formas de multilocação.

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

É importante que você selecione um modelo de autorização apropriado para sua solução. As abordagens de segurança baseadas em função podem ser simples de implementar, mas a autorização baseada em recursos fornece um controle mais refinado. Considere os requisitos de seus locatários e se eles precisam autorizar alguns usuários a acessar partes específicas de sua solução, e não outras partes.

Falha ao gravar logs de auditoria

Os logs de auditoria são uma ferramenta importante para entender seu ambiente e como os usuários estão implementando 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 solução devem ser disponibilizados aos locatários para revisão.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Próximas etapas

Examine as Considerações de arquitetura para identidade em uma solução multilocatário.