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

A identidade é um aspecto importante de qualquer solução multilocatário. Os componentes de identidade do aplicativo são responsáveis pelas seguintes funções:

• Verificar quem é um usuário (autenticação).
• Impor as permissões do usuário no escopo de um locatário (autorização).

Seus clientes também podem querer autorizar aplicativos externos para acessar dados ou se integrarem à sua solução. A identidade do usuário determina a quais informações um usuário ou um serviço terá acesso. É importante considerar seus requisitos de identidade para isolar o aplicativo e os dados entre locatários.

Antes de definir uma estratégia de identidade multilocatário, você deve primeiro considerar os requisitos de identidade de alto nível do seu serviço, incluindo os seguintes requisitos:

• As identidades de carga de trabalho ou de um usuário serão usadas para acessar um único aplicativo ou vários aplicativos em uma família de produtos? Por exemplo, uma família de produtos de varejo pode ter um aplicativo de ponto de venda e um aplicativo de gerenciamento de estoque, os quais compartilham a mesma solução de identidade.
• Você está planejando implementar autenticação e autorização modernas, como OAuth2 e OpenID Connect?
• Sua solução fornece apenas autenticação para seus aplicativos baseados na interface do usuário? Ou você também fornece acesso à API para seus locatários e terceiros?
• Os locatários precisarão se federar para seu próprio IdP e vários provedores de identidade diferentes precisarão ter suporte para cada locatário? Por exemplo, você poderá ter locatários com Microsoft Entra ID, Auth0 e Serviços de Federação do Active Directory (ADFS), em que cada um deseja federar com sua solução. Você também precisa entender quais protocolos de federação dos IdPs de seus locatários você terá suporte, porque os protocolos influenciam os requisitos para seu próprio IdP.
• Existem requisitos de conformidade específicos que eles precisam atender, como o GDPR?
• Seus locatários requerem exigem que suas informações de identidade estejam localizadas em uma região geográfica específica?
• Os usuários de sua solução requerem acesso a dados de um locatário ou de múltiplos locatários em seu aplicativo? Eles precisam da capacidade de alternar rapidamente entre locatários ou exibir informações consolidadas de múltiplos locatários? Por exemplo, os usuários que entraram no portal do Azure podem alternar facilmente entre diretórios e assinaturas diferentes do Microsoft Entra ID aos quais têm acesso.

Depois de estabelecer seus requisitos de alto nível, você poderá começar a planejar detalhes e requisitos mais específicos, como fontes de diretório de usuário e fluxos de inscrição/entrada.

Diretório de identidade

Para que uma solução multilocatário autentique e autorize um usuário ou serviço, ela precisará de um local para armazenar informações de identidade. Um diretório pode incluir registros autoritativos para cada identidade ou pode conter referências a identidades externas armazenadas no diretório de outro provedor de identidade.

Ao projetar um sistema de identidade para sua solução multilocatário, você precisa considerar quais dos seguintes tipos de IdP podem ser necessários para seus locatários e clientes:

• Provedor de identidade local. Um provedor de identidade local permite que os usuários se inscrevam no serviço. Os usuários fornecem um nome de usuário, um endereço de email ou um identificador, como um número de cartão de recompensa. Eles também fornecem uma credencial, como uma senha. O IdP armazena o identificador do usuário e as credenciais.
• Provedor de identidade social. Um provedor de identidade social permite que os usuários usem uma identidade que eles têm em uma rede social ou outro provedor de identidade pública, como Facebook, Google ou uma conta pessoal da Microsoft.
• Use o diretório do Microsoft Entra ID do locatário. Os locatários talvez já tenha o próprio diretório do Microsoft Entra ID e talvez queiram que a solução use seu diretório como o IdP para acessar sua solução. Essa abordagem é possível quando sua solução é criada como um aplicativo multilocatário do Microsoft Entra.
• Federação com o provedor de identidade de um locatário. Os locatários podem ter seu próprio IdP, além do Microsoft Entra ID, e talvez queiram que sua solução seja federada com ele. A federação permite experiências de logon único (SSO) e permite que os locatários gerenciem o ciclo de vida e as políticas de segurança de seus usuários, independentemente de sua solução.

Você deve considerar se seus locatários precisam oferecer suporte a múltiplos provedores de identidade. Por exemplo, talvez seja necessário oferecer suporte a identidades locais, identidades sociais e identidades federadas, tudo em um único locatário. Essa exigência é comum quando as empresas usam uma solução que é tanto para seus próprios funcionários quanto para os contratados. Eles podem usar a federação para o acesso de seus próprios funcionários à solução, ao mesmo tempo em que permitem o acesso a contratados ou a usuários convidados, que não têm uma conta no IdP federado.

Armazenar informações de autenticação e autorização do locatário

Em uma solução multilocatário, você precisa considerar onde armazenar vários tipos de informações de identidade, incluindo os seguintes tipos:

• Detalhes sobre contas de usuário e serviço, incluindo seus nomes e outras informações exigidas por seus locatários.
• Informações necessárias para autenticar seus usuários com segurança, incluindo informações que são necessárias para fornecer MFA (autenticação multifator).
• Informações específicas do locatário, como funções e permissões do locatário. Essas informações são usadas para autorização.

Considere as seguintes opções para armazenar informações de identidade:

• Armazene todas as informações de identidade e autorização no diretório IdP e compartilhe-as entre múltiplos locatários.
• Armazene as credenciais do usuário no diretório IdP, e armazene as informações de autorização na camada do aplicativo, junto com as informações do locatário.

Determinar o número de identidades para um usuário

É comum que soluções multilocatário permitam que uma identidade de usuário ou carga de trabalho acesse o aplicativo e os dados de múltiplos locatários. Considere se essa abordagem é necessária para sua solução. Se for, você deverá considerar as seguintes perguntas:

• Você deve criar uma única identidade de usuário para cada pessoa ou criar identidades separadas para cada combinação de locatário e usuário?
  • É melhor usar uma única identidade para cada pessoa, sempre que possível. Torna-se difícil gerenciar várias contas de usuário, tanto para você, como o fornecedor da solução, quanto para seus usuários. Além disso, muitas das proteções inteligentes contra ameaças oferecidas por um IdP moderno dependem de cada pessoa ter uma única conta de usuário.
  • No entanto, em algumas situações, pode ser necessário que um usuário tenha várias identidades distintas. Por exemplo, se as pessoas usarem seu sistema para fins profissionais e pessoais, talvez elas queiram separar suas contas de usuário. Ou, se seus locatários tiverem requisitos de armazenamento de dados geográficos ou regulatórios rigorosos, poderão exigir que uma pessoa tenha várias identidades para que possam cumprir regulamentos ou leis.
• Se você usar identidades por locatário, evite armazenar credenciais várias vezes. Os usuários devem ter suas credenciais armazenadas em uma única identidade, e você deve usar recursos, como identidades de convidado para fazer referência às mesmas credenciais de usuário de registros de identidade de múltiplos locatários.

Conceder aos usuários acesso aos dados do locatário

Considere como os usuários serão mapeados para um locatário. Por exemplo, durante o processo de inscrição, você poderá usar um código de convite exclusivo que eles inserirão na primeira vez que acessarem um locatário. Em algumas soluções, você pode usar o nome de domínio dos endereços de email de inscrição dos usuários como uma maneira de identificar o locatário ao qual eles pertencem. Ou, você poderá usar outro atributo do registro de identidade do usuário para mapear o usuário para um locatário. Em seguida, você deve armazenar o mapeamento com base nos identificadores exclusivos imutáveis subjacentes para o locatário e o usuário.

Se sua solução foi projetada para que um único usuário acesse os dados de apenas um único locatário, considere as seguintes decisões:

• Como o IdP detecta qual locatário um usuário está acessando?
• Como o IdP comunica o identificador de locatário ao aplicativo? Normalmente, uma declaração de identificador de locatário é adicionada ao token.

Se um único usuário precisar ter acesso a múltiplos locatários, você precisará considerar as seguintes decisões:

• Como sua solução identifica e concede permissões a um usuário que tem acesso a múltiplos locatários? Por exemplo, um usuário poderá ser um administrador em um locatário de treinamento e ter acesso somente leitura a um locatário de produção? Ou então, você poderá ter locatários separados para diferentes departamentos em uma organização, mas precisará manter identidades de usuário consistentes em todos os locatários?
• Como um usuário alterna entre locatários?
• Se você usar identidades de carga de trabalho, como uma identidade de carga de trabalho especificará o locatário que ela precisa acessar?
• Há informações específicas do locatário armazenadas no registro de identidade do usuário que podem vazar informações entre locatários? Por exemplo, suponha que um usuário se inscreveu com uma identidade social e recebeu acesso a dois locatários. O locatário A enriqueceu a identidade do usuário com mais informações. O locatário B deve ter acesso às informações enriquecidas?

Processo de inscrição do usuário para identidades locais ou sociais

Alguns locatários talvez precisem permitir que os usuários se inscrevam para obter uma identidade em sua solução. A inscrição de autoatendimento poderá ser necessária se você não precisar de federação com o provedor de identidade de um locatário. Se um processo de inscrição de autoatendimento for necessário, você deverá considerar as seguintes perguntas:

• De quais fontes de identidade os usuários podem se inscrever? Por exemplo, um usuário pode criar uma identidade local e também usar um provedor de identidade social?
• Se apenas identidades locais forem permitidas, somente domínios de email específicos serão permitidos? Por exemplo, um locatário pode especificar que apenas os usuários que têm um @contoso.com endereço de email têm permissão para se inscrever?
• Qual é o nome UPN que deve ser usado para identificar exclusivamente cada identidade local durante o processo de entrada? Por exemplo, um endereço de email, nome de usuário, número de telefone e número de cartão de recompensas são opções comuns para UPNs. No entanto, os UPNs podem mudar ao longo do tempo. Quando você se refere à identidade nas regras de autorização ou logs de auditoria do seu aplicativo, é uma boa prática usar o identificador exclusivo imutável subjacente da identidade. O Microsoft Entra ID fornece uma ID de objeto (OID), que é um identificador imutável.
• Será requerido que um usuário verifique seu UPN? Por exemplo, se o endereço de email ou número de telefone do usuário for usado como UPN, como você verificará se as informações são precisas?
• Os administradores de locatários precisam aprovar inscrições?
• Os locatários requerem uma experiência de inscrição ou URL específica do locatário? Por exemplo, seus locatários requerem uma experiência de inscrição com marca quando os usuários se inscrevem? Seus locatários requerem a capacidade de interceptar uma solicitação de inscrição e executar validação extra antes que ela prossiga?

Acesso de locatário para usuários de inscrição de autoatendimento

Quando os usuários têm permissão para se inscrever em uma identidade, geralmente é necessário que haja um processo para que eles tenham acesso a um locatário. O fluxo de inscrição poderá incluir um processo de concessão de acesso ou poderá ser automatizado, com base nas informações sobre os usuários, como seus endereços de email. É importante se planejar para esse processo e considerar as seguintes perguntas:

• Como o fluxo de inscrição determinará que um usuário deve receber acesso a um locatário específico?
• Se os usuários não tiverem mais acesso a um locatário, sua solução revogará automaticamente o acesso deles? Por exemplo, quando os usuários saem de uma organização, é necessário que haja um processo manual ou automatizado que remova seu acesso do locatário.
• Você precisa fornecer uma maneira para os locatários auditarem os usuários que têm acesso a seus locatários e suas permissões?

Gerenciamento automatizado do ciclo de vida da conta

Um requisito comum para clientes corporativos ou empresariais de uma solução é um conjunto de recursos que lhes permitem automatizar a integração e a remoção de contas. Protocolos abertos, como o SCIM (Sistema de Gerenciamento de Usuários entre Domínios), fornecem uma abordagem padrão do setor para a automação. Esse processo automatizado geralmente inclui não somente a criação e remoção de registros de identidade, mas também o gerenciamento de permissões de locatários. Considere as seguintes perguntas ao implementar o gerenciamento automatizado do ciclo de vida da conta em uma solução multilocatário:

• Seus clientes precisam configurar e gerenciar um processo de ciclo de vida automatizado por locatário? Por exemplo, quando um usuário for integrado, talvez seja necessário criar a identidade em múltiplos locatários em seu aplicativo, onde cada locatário terá um conjunto diferente de permissões.
• Você precisa implementar o SCIM ou, em vez disso, pode fornecer federação de locatários, para manter a fonte da verdade para os usuários sob o controle do locatário, em vez de gerenciar usuários locais?

Processo de autenticação de usuário

Quando um usuário entra em um aplicativo multilocatário, seu sistema de identidade autentica o usuário. Você deve considerar as seguintes perguntas ao planejar seu processo de autenticação:

• Seus locatários precisam configurar suas próprias políticas de MFA (autenticação multifator)? Por exemplo, se seus locatários estiverem no setor de serviços financeiros, precisarão implementar políticas rígidas de MFA, enquanto um pequeno varejista online poderá não ter as mesmas exigências.
• Seus locatários precisam configurar as próprias regras de acesso condicional? Por exemplo, diferentes locatários podem precisar bloquear tentativas de entrada de regiões geográficas específicas.
• Seus locatários precisam personalizar o processo de entrada para cada locatário? Por exemplo, você precisa mostrar o logotipo de um cliente? Ou as informações sobre cada usuário precisam ser extraídas de outro sistema, como um número de recompensas, e retornadas ao provedor de identidade para adicionar ao perfil do usuário?
• Seus usuários precisam representar outros usuários? Por exemplo, um membro da equipe de suporte pode querer investigar um problema que outro usuário tem, representando sua conta de usuário sem precisar se autenticar como usuário.
• Seus usuários precisam obter acesso às APIs de sua solução? Por exemplo, usuários ou aplicativos de terceiros talvez precisem chamar diretamente suas APIs para estender sua solução, sem uma interface de usuário para fornecer um fluxo de autenticação.

Identidades de carga de trabalho

Na maioria das soluções, uma identidade geralmente representa um usuário. Alguns sistemas multilocatários também permitem que identidades de carga de trabalho sejam usadas por serviços e aplicativos para obter acesso aos recursos do aplicativo. Por exemplo, seus locatários talvez precisem acessar uma API fornecida por sua solução, para que possam automatizar algumas de suas tarefas de gerenciamento.

As identidades de carga de trabalho são semelhantes às identidades de usuário, mas geralmente exigem métodos de autenticação diferentes, como chaves ou certificados. As identidades de carga de trabalho não usam MFA. Em vez disso, as identidades de carga de trabalho geralmente requerem que outros controles de segurança, como rolagem regular de chaves e expiração de certificado.

Se seus locatários esperam ser capazes de habilitar o acesso de identidade de carga de trabalho à sua solução multilocatário, considere as seguintes perguntas:

• Como as identidades de carga de trabalho serão criadas e gerenciadas em cada locatário?
• Como as solicitações de identidade de carga de trabalho terão o escopo definido para o locatário?
• Você precisa limitar o número de identidades de carga de trabalho criadas por cada locatário?
• Você precisa fornecer controles de acesso condicional em identidades de carga de trabalho para cada locatário? Por exemplo, um locatário pode querer limitar uma identidade de carga de trabalho de ser autenticada de fora de uma região específica.
• Quais controles de segurança você fornecerá aos locatários para garantir que as identidades de carga de trabalho sejam mantidas seguras? Por exemplo, a rolagem automatizada de chaves, a expiração de chaves, a expiração de certificados e o monitoramento de risco de entrada são todos métodos para reduzir o risco, em que uma identidade de carga de trabalho pode ser usada indevidamente.

Federar com um provedor de identidade para logon único (SSO)

Os locatários, que já têm seus próprios diretórios de usuário, podem querer que sua solução seja federada para seus diretórios. A federação permite que sua solução use as identidades em seu diretório, em vez de gerenciar outro diretório com identidades distintas.

A federação é importante principalmente quando alguns locatários desejam especificar suas próprias políticas de identidade ou habilitar experiências de logon único (SSO).

Se você esperar que os locatários se federem com sua solução, deverá considerar as seguintes perguntas:

• Qual é o processo para configurar a federação para um locatário? Os locatários podem configurar a federação por conta própria ou o processo requer configuração e manutenção manuais por sua equipe?
• Quais protocolos de federação você dará suporte?
• Quais processos estão em vigor para garantir que a federação não possa ser configurada incorretamente, para conceder acesso a outro locatário?
• O provedor de identidade de um único locatário precisará ser federado para mais de um locatário em sua solução? Por exemplo, se os clientes tiverem um locatário de treinamento e produção, talvez precisem federar o mesmo provedor de identidade para os dois locatários.

Modelos de autorização

Decida sobre o modelo de autorização que faça mais sentido para sua solução. Duas abordagens comuns de autorização são:

• Autorização baseada em função. Os usuários são atribuídos a funções. Alguns recursos do aplicativo são restritos a funções específicas. Por exemplo, um usuário na função de administrador pode executar qualquer ação, enquanto um usuário em uma função inferior pode ter um subconjunto de permissões em todo o sistema.
• Autorização baseada em recursos. Sua solução fornece um conjunto de recursos distintos, cada um dos quais tem seu próprio conjunto de permissões. Um usuário específico pode ser um administrador de um recurso e não ter acesso a outro recurso.

Esses modelos são distintos e a abordagem selecionada afeta sua implementação e a complexidade das políticas de autorização que você pode implementar.

Direitos e licenciamento

Em algumas soluções, você pode usar o licenciamento por usuário como parte do seu modelo de preços comerciais. Você fornecerá diferentes camadas de licenças de usuário com recursos distintos. Por exemplo, os usuários com uma licença podem ter permissão para usar um subconjunto dos recursos do aplicativo. Os recursos que os usuários específicos têm permissão para acessar, com base em suas licenças, às vezes são chamados de direito.

Embora o rastreamento e a imposição de direitos sejam semelhantes à autorização, ele normalmente é manipulado pelo código do aplicativo ou por um sistema de direitos dedicado, em vez de ser gerenciado pelo sistema de identidade.

Escala de identidade e volume de autenticação

À medida que as soluções multilocatário crescerem, o número de usuários e solicitações de entrada que precisam ser processados pela solução aumentará. Você deve considerar as seguintes questões:

• O diretório do usuário será dimensionado para o número de usuários necessários?
• O processo de autenticação lidará com o número esperado de entradas e inscrições?
• Haverá picos que o sistema de autenticação não poderá lidar? Por exemplo, às 9h PST, todos na região oeste dos Estados Unidos poderão começar a trabalhar e entrar em sua solução, causando um pico nas solicitações de entrada. Às vezes, essas situações são chamadas de storms de login.
• A alta carga em outras partes da solução pode afetar o desempenho do processo de autenticação? Por exemplo, se o processo de autenticação exigir a chamada de uma API de camada de aplicativo, um número alto de solicitações de autenticação causará problemas para o restante da solução?
• O que acontecerá se o seu IdP se tornar indisponível? Existe um serviço de autenticação de backup que possa ser executado para fornecer continuidade de negócios, enquanto o IdP não está disponível?

Colaboradores

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

Principais autores:

• John Downs | Engenheiro de software principal
• Daniel Scott-Raynsford | Estrategista de Tecnologia Do Parceiro
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

Outros colaboradores:

• Jelle Druyts | Engenheiro principal de atendimento ao cliente, FastTrack for Azure
• Landon Pierce | Engenheiro sênior de clientes
• Sander van den Hoven | Estrategista sênior de Tecnologia Do Parceiro
• Nick Ward | Arquiteto de Soluções Cloud Sênior

Próximas etapas

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