Share via

Abordagens arquitetônicas para identidade em soluções multilocatárias

  • Artigo

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

Nota

Analise Considerações arquitetônicas para identidade em uma solução multilocatária 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 aspetos do processo de autenticação.

de 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 pessoais da Microsoft.
  • Diretórios específicos de locatário, como permitir que os locatários federam seu aplicativo com seus próprios provedores de identidade, para que não precisem gerenciar contas em vários locais.

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ó suportará a 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 Ative Directory (Azure AD) B2C como seu próprio provedor de identidade, talvez seja necessário implantar políticas personalizadas para federar com certos 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 se aplica apenas a clientes em uma camada de produto mais alta.

Início de sessão único

As experiências de logon único permitem que os usuários alternem entre aplicativos sem problemas, sem serem solicitados a autenticar novamente em cada ponto.

Quando os usuários visitam um aplicativo, o aplicativo os direciona para um IdP. Se o IdP vir que tem uma sessão existente, ele emitirá um novo token sem exigir que os usuários interajam com o processo de login. 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. Considere se você precisa oferecer suporte a transições contínuas 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, e reemite o token da instância do Microsoft Entra recém-selecionada.

Avaliação do risco de início de sessão

As plataformas de identidade modernas suportam uma avaliação de risco durante o processo de início de sessão. Por exemplo, se um usuário entrar em um local ou dispositivo incomum, o sistema de autenticação poderá exigir verificações de identidade adicionais, como autenticação multifator (MFA), antes de permitir que a solicitação de entrada prossiga.

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 inquilinos em um setor altamente regulamentado, eles podem ter perfis de risco e requisitos diferentes dos locatários que trabalham em ambientes menos regulamentados. Em alternativa, pode optar por permitir que os inquilinos com níveis de preços mais elevados especifiquem políticas de início de sessão mais restritivas do que os inquilinos que adquirem um nível inferior do seu serviço.

Se você precisar oferecer suporte a diferentes políticas de risco para cada locatário, seu sistema de autenticação precisará saber em qual locatário o usuário está entrando, 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 complexos e propensos a erros para serem implementados por conta própria.

Como alternativa, se você federar aos próprios provedores de identidade dos locatários, suas próprias políticas de mitigação de entrada arriscadas poderão ser aplicadas e eles poderão controlar as políticas e os controles que devem ser aplicados. No entanto, é importante evitar adicionar inadvertidamente encargos desnecessários ao usuário, como exigir dois desafios de MFA - um do provedor de identidade residencial 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 dos locatários e as políticas que eles aplicaram.

Falsificação de identidade

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 falsificação de identidade é perigosa e pode ser difícil de implementar e controlar. No entanto, em alguns cenários, a falsificação de identidade é um requisito. Por exemplo, se você opera software como serviço (SaaS), a equipe do helpdesk pode precisar assumir a identidade de um usuário, para que ele 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 assunto nos tokens emitidos.

Autorização

A autorização é o processo de determinar o que um usuário pode fazer.

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

  • No seu provedor de identidade. Por exemplo, se você usar o Microsoft Entra ID como seu provedor de identidade, poderá usar recursos como funções e grupos de aplicativos para armazenar informações de autorização. Seu aplicativo pode usar as declarações de token associadas para impor suas regras de autorização.
  • Na sua candidatura. 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 projetar 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 identidade de locatário e informações de função a tokens

Considere qual parte, ou partes, da 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 dentro do 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 login. 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 ele 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 aplicativos

Uma abordagem alternativa é tornar o sistema de identidade agnóstico aos 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 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 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 a ID do Microsoft Entra 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. Pode até listar a sua solução no Azure Marketplace e torná-la facilmente acessível a organizações que utilizam o Microsoft Entra ID.
  • Se os seus inquilinos ou clientes não utilizarem o Microsoft Entra ID ou se forem indivíduos em vez de organizações, considere utilizar o Azure AD B2C. O Azure AD B2C fornece um conjunto de recursos para controlar como os usuários se inscrevem e entram. 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 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 entre. O Azure AD B2C também permite a federação com outros provedores de identidade.
  • Algumas soluções multilocatárias destinam-se a ambas as situações listadas acima. Alguns locatários podem ter seus próprios locatários do Microsoft Entra e outros não. 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 a partir do diretório Microsoft Entra de um locatário. No entanto, se você usar políticas personalizadas para estabelecer federação entre locatários, considere os limites do 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 Ative Directory B2C em uma arquitetura multilocatário.

Antipadrões a evitar

Construindo ou executando seu próprio sistema de identidade

Construir uma plataforma de identidade moderna é complexo. Há uma variedade de protocolos e padrões para suportar, 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, porque qualquer tempo de inatividade pode ter consequências graves para o resto da sua 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 os invasores. Até mesmo hashing e salga de senhas geralmente é uma proteção insuficiente, porque o poder computacional disponível para os 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 MFA ou OTP (one-time password). Esses requisitos significam que você precisa de um mecanismo para distribuir esses códigos, usando SMS ou e-mail. Além disso, você é responsável por detetar ataques direcionados e de força bruta, limitar as tentativas de login, auditar 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, de oferecer suporte aos padrões atuais de identidade e autenticação.

Não considerar os requisitos dos seus inquilinos

Os locatários geralmente têm opiniões fortes 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 projetou para 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. Analise Considerações arquitetônicas para identidade em uma solução multilocatário, para entender alguns requisitos específicos que geralmente surgem.

Confundindo 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 acompanhar 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 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 de 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 rastreamento do contexto de locatário de um usuário ou token é aplicável a qualquer modelo de locação, porque uma identidade de usuário sempre tem um contexto de locatário em uma solução multilocatário. É até uma boa prática acompanhar 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.

Confundindo função e 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ções podem ser simples de implementar, mas a autorização baseada em recursos fornece um controle mais refinado. Considere os requisitos dos locatários e se eles precisam autorizar alguns usuários a acessar partes específicas da 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 todos os eventos relacionados à identidade, muitas vezes você pode determinar se seu sistema de identidade está sob ataque e pode revisar como seu sistema está sendo usado. Certifique-se de escrever 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.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

  • Jelle Druyts - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
  • Sander van den Hoven - Brasil | Estrategista Sênior de Tecnologia de Parceiros
  • Nick Ward - Brasil | Arquiteto de Soluções Cloud Sênior

Próximos passos

Analise Considerações arquitetônicas para identidade em uma solução multilocatário.