Criar uma arquitetura multilocatário para instituições grandes
Uma arquitetura de locatário único é recomendada para instituições menores. No entanto, para organizações com mais de 1 milhão de usuários, recomendamos uma arquitetura multilocatário para mitigar problemas de desempenho e limitações de locatário, como assinatura e cotas do Azure elimites e restrições de serviço Microsoft Entra.
Princípios de design
Ao projetar sua arquitetura multilocatário, considere os seguintes princípios de design para reduzir custos e aumentar a eficiência e a segurança:
Reduzir custos
Reduza a dependência da infraestrutura local e de vários provedores de identidade.
Permitir que os usuários desbloqueiem sua conta ou redefinam senhas usando o autoatendimento (por exemplo, Microsoft Entra redefinição de senha de autoatendimento).
Aumentar a eficiência
Padronizar arquitetura, configurações e processos entre locatários para minimizar problemas administrativos.
Minimizar a necessidade de os usuários passarem de um locatário para outro
Aumentar a segurança
Concentre-se em garantir que os dados do aluno sejam seguros.
Siga o princípio do privilégio mínimo: conceda apenas os privilégios necessários para executar tarefas necessárias e implementar o acesso JIT (Just in Time).
Habilitar o acesso de usuários externos somente por meio do Gerenciamento de Direitos ou Microsoft Entra colaboração B2B.
Delegar a administração de tarefas específicas para usuários específicos com JEA (Acesso Suficiente) para fazer o trabalho.
Motivos comuns para vários locatários
Recomendamos fortemente que organizações com menos de 1 milhão de usuários criem um único locatário, a menos que outros critérios indiquem a necessidade de vários locatários. Para organizações com 1 milhão ou mais objetos de usuário, recomendamos vários locatários usando uma abordagem regional.
A criação de locatários separados tem os seguintes efeitos em seu ambiente EDU.
Separação administrativa
Pode limitar os impactos de um erro administrativo ou operacional que afeta recursos críticos.
Pode limitar o impacto de contas de usuário ou administrador comprometidas.
Relatórios de uso e logs de auditoria estão contidos em um locatário.
Separação de recursos
Privacidade do aluno. Os objetos de usuário do aluno só são detectáveis dentro do locatário em que o objeto reside.
Isolamento de recursos. Recursos em um locatário separado não podem ser descobertos ou enumerados por usuários e administradores em outros locatários.
Pegada de objeto. Aplicativos que gravam em Microsoft Entra ID e outros serviços do Microsoft Online por meio do Microsoft Graph ou outras interfaces de gerenciamento podem afetar apenas os recursos no locatário local.
Quotas. O consumo de Cotas e Limites do Azure em todo o locatário é separado do dos outros locatários.
Separação de configuração
Fornece um conjunto separado de configurações em todo o locatário que podem acomodar recursos e aplicativos confiáveis que têm requisitos de configuração diferentes.
Habilita um novo conjunto de serviços do Microsoft Online, como Office 365.
Além de ter mais de 1 milhão de usuários, as considerações a seguir podem levar a vários locatários.
Considerações administrativas
Você opera sob regulamentos que restringem quem pode administrar o ambiente com base em critérios como país de cidadania, país de residência ou nível de liberação.
Você tem requisitos de conformidade, como privacidade de dados do aluno, que exigem que você crie identidades em regiões locais específicas.
Considerações sobre recursos
Você tem recursos, talvez para pesquisa e desenvolvimento, que devem ser protegidos contra descoberta, enumeração ou aquisição por administradores existentes por razões regulatórias ou comerciais críticas.
Ciclo de desenvolvimento de aplicativos personalizados que podem alterar dados de usuários com MS Graph ou APIs semelhantes em escala (por exemplo, aplicativos que recebem Directory.ReadWrite.All)
Considerações de configuração
- Recursos com requisitos que entram em conflito com posturas de segurança ou colaboração existentes em todo o locatário, como tipos de autenticação permitidos, políticas de gerenciamento de dispositivos, capacidade de autoatendimento ou comprovação de identidade para identidades externas.
Determinar a abordagem multilocatário
Nesta seção, consideramos uma universidade fictícia chamada School of Fine Arts com 2 milhões de alunos em 100 escolas em todo o Estados Unidos. Nessas escolas, há um total de 130.000 professores e 30.000 funcionários e funcionários em tempo integral.
Recomendamos uma abordagem regional ao implantar vários locatários da seguinte maneira:
Comece dividindo sua comunidade de alunos e educadores por regiões geográficas onde cada região contém menos de 1 milhão de usuários.
Crie um locatário Microsoft Entra para cada região.
Provisionar funcionários, professores e alunos em sua região correspondente para otimizar experiências de colaboração.
Por que usar regiões?
Recomenda-se uma abordagem regional para minimizar o número de usuários que se deslocam entre locatários. Se você criou um locatário para cada nível escolar (por exemplo, escolas de ensino fundamental, ensino médio e ensino médio) você teria que migrar usuários no final de cada ano letivo. Se, em vez disso, os usuários permanecerem na mesma região, você não precisará movê-los entre locatários à medida que seus atributos são alterados.
Outros benefícios de uma abordagem regional incluem:
Colaboração ideal em cada região
Um número mínimo de objetos convidados de outros locatários é necessário
Quando um locatário tem mais de 1 milhão de usuários, experiências de gerenciamento e ferramentas tendem a se degradar ao longo do tempo. Da mesma forma, algumas experiências do usuário final, como usar o seletor de pessoas, se tornarão complicadas e não confiáveis.
Organizações menores que optam por implantar vários locatários sem um motivo convincente aumentarão desnecessariamente sua sobrecarga de gerenciamento e o número de migrações de usuários. Isso também exigirá etapas para garantir experiências de colaboração entre locatários.
Colaborar entre locatários usando Microsoft Entra colaboração B2B
Microsoft Entra colaboração B2B permite que os usuários usem um conjunto de credenciais para entrar em vários locatários. Para instituições de ensino, os benefícios da colaboração B2B incluem:
Equipe de administração centralizada gerenciando vários locatários
Colaboração de professores entre regiões
Integrando pais e responsáveis com suas próprias credenciais
Parcerias externas, como empreiteiros ou pesquisadores
Com a colaboração B2B, uma conta de usuário criada em um locatário (seu locatário doméstico) é convidada como usuário convidado para outro locatário (um locatário de recursos) e o usuário pode entrar usando as credenciais de seu locatário doméstico. Os administradores também podem usar a colaboração B2B para permitir que usuários externos entrem com suas contas sociais ou empresariais existentes, configurando a federação com provedores de identidade, como Facebook, contas da Microsoft, Google ou um provedor de identidade empresarial.
Membros e convidados
Os usuários em um locatário Microsoft Entra são membros ou convidados com base em sua propriedade UserType. Por padrão, os usuários membros são aqueles que são nativos do locatário. Um Microsoft Entra usuário de colaboração B2B é adicionado como usuário com UserType = Guest por padrão. Os convidados têm permissões limitadas no diretório e nos aplicativos. Por exemplo, os usuários convidados não podem procurar informações do locatário além de suas próprias informações de perfil. No entanto, um usuário convidado pode recuperar informações sobre outro usuário fornecendo o Nome da Entidade de Usuário (UPN) ou objectId. Um usuário convidado também pode ler propriedades de grupos aos quais pertence, incluindo associação de grupo, independentemente das permissões dos usuários convidados serem configurações limitadas .
Em alguns casos, um locatário de recursos pode querer tratar os usuários do locatário doméstico como membros em vez de convidados. Se assim for, você pode usar as APIs Microsoft Entra B2B Invitation Manager para adicionar ou convidar um usuário do locatário da casa para o locatário do recurso como membro. Para obter mais informações, consulte Propriedades de um Microsoft Entra usuário de colaboração B2B.
Administração centralizada de vários locatários
Integrar identidades externas usando Microsoft Entra B2B. Em seguida, as identidades externas podem receber funções privilegiadas para gerenciar Microsoft Entra locatários como membros de uma equipe de TI centralizada. Você também pode usar Microsoft Entra B2B para criar contas de convidado para outros membros da equipe, como administradores no nível regional ou distrital.
No entanto, funções específicas do serviço, como Administrador do Exchange ou Administrador do SharePoint, exigem uma conta local nativa do locatário.
As funções a seguir podem ser atribuídas a contas B2B
Administrador de Aplicativos
Desenvolvedor de Aplicativo
Administrador de Autenticação
Administrador de conjunto de chaves do IEF B2C
Administrador de política do IEF B2C
Administrador de política do IEF do Cloud Application B2C
Administrador de política do IEF do Dispositivo de Nuvem B2C
Administrador de Acesso Condicional
Administradores de dispositivos
Junção do dispositivo
Usuários do Dispositivo
Leitores de Diretório
Escritores de diretório
Contas de sincronização de diretório
Administrador de Fluxo de Usuário de ID Externo
Administrador de atributo de fluxo de usuário da ID externa
Provedor de Identidade Externa
Administrador de grupos
Convidado
Administrador da Assistência Técnica
Administrador de identidade híbrida
Administrador de Serviços do Intune
Administrador de Licenças
Administrador de Senhas
Administrador de Autenticação Privilegiada
Administrador de Função Privilegiada
Leitor de Relatórios
Usuário convidado restrito
Administrador de Segurança
Leitor de Segurança
Administrador de Conta de Usuário
Ingressar no dispositivo do local de trabalho
Funções de administrador personalizadas em Microsoft Entra ID aparecem as permissões subjacentes das funções internas, para que você possa criar e organizar suas próprias funções personalizadas. Essa abordagem permite que você conceda acesso de forma mais granular do que funções internas sempre que elas forem necessárias.
Aqui está um exemplo que ilustra como a administração funcionaria para funções administrativas que podem ser delegadas e usadas em vários locatários.
A conta nativa de Susie está no locatário da Região 1 e Microsoft Entra B2B é usado para adicionar a conta como Administrador de Autenticação à equipe central de TI nos locatários da Região 2 e Região 3.
Usando aplicativos em vários locatários
Para atenuar problemas associados à administração de aplicativos em um ambiente multilocatário, considere escrever aplicativos multilocatários. Você também precisará verificar qual dos seus aplicativos SaaS dá suporte a várias conexões IdP. Os aplicativos SaaS que dão suporte a várias conexões IDP devem configurar conexões individuais em cada locatário. Aplicativos SaaS que não dão suporte a várias conexões IDP podem exigir instâncias independentes. Para obter mais informações, consulte Como entrar em qualquer usuário Microsoft Entra usando o padrão de aplicativo multilocatário.
Observação: os modelos de licenciamento podem variar de um aplicativo SaaS para outro. marcar com o fornecedor para determinar se várias assinaturas serão necessárias em um ambiente multilocatário.
Administração por locatário
A administração por locatário é necessária para funções específicas do serviço. Funções específicas do serviço exigem ter uma conta local nativa do locatário. Além de ter uma equipe de TI centralizada em cada locatário, você também precisará ter uma equipe de TI regional em cada locatário para gerenciar cargas de trabalho como Exchange, SharePoint e Teams.
As funções a seguir exigem contas nativas para cada locatário
Administrador do Azure DevOps
Administrador do Azure Proteção de Informações
Administrador de Cobrança
Administrador de serviços do CRM
Administrador de Conformidade
Administrador de Dados de Conformidade
Aprovador de acesso da caixa de bloqueio do cliente
Administrador Análise de Área de Trabalho
Administrador do Exchange
Insights do Administrador
Insights do Líder de Negócios
Administrador kaizala
Administrador de Serviços do Lync
Leitor de Privacidade do Centro de Mensagens
Leitor do Centro de Mensagens
Administrador de Impressoras
Técnico de Impressora
Administrador de Pesquisa
Pesquisar Editor
Operador de Segurança
Administrador do Suporte de Serviços
Administrador do SharePoint
Administrador de Comunicações do Teams
Engenheiro de Suporte de Comunicações de Equipes
Especialista em suporte à comunicação de equipes
Administrador de Serviço do Teams
Administradores exclusivos em cada locatário
Se você tiver uma equipe de TI nativa de cada região, poderá ter um desses administradores locais gerenciando a administração do Teams. No exemplo a seguir, Charles reside no locatário da Região 1 e tem a função de Administrador de Serviços do Teams. Alice e Ichiro residem nas regiões 2 e 3, respectivamente, e têm a mesma função em suas regiões. Cada administrador local tem uma única conta nativa de sua região.
Administração funções entre locatários
Se você não tiver um pool de administradores local para cada região, poderá atribuir a função administrador do Serviço do Teams a apenas um usuário. Nesse cenário, conforme ilustrado abaixo, você pode fazer com que Bob da Equipe Central de TI atue como Administrador de Serviços do Teams em todos os três locatários criando uma conta local para Bob em cada locatário.
Delegação de funções de administrador dentro de um locatário
As AUs (unidades administrativas) devem ser usadas para agrupar logicamente Microsoft Entra usuários e grupos. Restringir o escopo administrativo usando unidades administrativas é útil em organizações educacionais compostas por diferentes regiões, distritos ou escolas.
Por exemplo, nossa escola fictícia de Belas Artes está espalhada por três regiões, cada uma contendo várias escolas. Cada região tem uma equipe de administradores de TI que controlam o acesso, gerenciam usuários e definem políticas para suas respectivas escolas.
Por exemplo, um administrador de TI poderia:
Crie uma UA para usuários de cada uma das escolas da Região 1, para gerenciar todos os usuários dessa escola. (não retratado)
Crie uma UA que contenha os professores em cada escola, para gerenciar contas de professores.
Crie uma UA separada que contenha os alunos em cada escola, para gerenciar contas de alunos.
Atribua aos professores na escola a função Administrador de Senhas para a UA dos Alunos, para que os professores possam redefinir as senhas dos alunos, mas não redefinir as senhas de outros usuários.
As funções que podem ser escopo para unidades administrativas incluem:
Administrador de Autenticação
Administrador de grupos
Administrador da Assistência Técnica
Administrador de Licenças
Administrador de Senhas
Administrador do usuário
Para obter mais informações, consulte Atribuir funções com escopo a uma unidade administrativa.
Gerenciamento entre locatários
As configurações são configuradas em cada locatário individualmente. Configure então como parte da criação do locatário, sempre que possível, para ajudar a minimizar a necessidade de revisitar essas configurações. Embora algumas tarefas comuns possam ser automatizadas, não há um portal interno de gerenciamento entre locatários.
Gerenciando objetos em escala
O Microsoft Graph (MS Graph) e o Microsoft Graph PowerShell permitem gerenciar objetos de diretório em escala. Eles também podem ser usados para gerenciar a maioria das políticas e configurações em seu locatário. No entanto, você deve entender as seguintes considerações de desempenho:
O MS Graph limita a criação de usuários, grupos e alterações de associação para 72.000 por locatário, por hora.
O desempenho do MS Graph pode ser afetado por ações orientadas pelo usuário, como ações de leitura ou gravação no locatário
O desempenho do MS Graph pode ser afetado por outras tarefas de administrador de TI concorrentes dentro do locatário
PowerShell, SDS, Microsoft Entra Connect e soluções de provisionamento personalizadas adicionam objetos e associações por meio do MS Graph a taxas diferentes
Próximas etapas
Se você ainda não revisou Introdução aos locatários Microsoft Entra, talvez queira fazê-lo. Consulte: