Compartilhar via


Criar uma arquitetura multi-inquilino para grandes instituições

Recomenda-se uma arquitetura de inquilino único para instituições mais pequenas. No entanto, para organizações com mais de 1 milhão de utilizadores, recomendamos uma arquitetura multi-inquilino para mitigar problemas de desempenho e limitações de inquilinos, como a subscrição e quotas do Azure e Microsoft Entra limites e restrições do serviço.

Princípios de design

Ao conceber a sua arquitetura multi-inquilino, considere os seguintes princípios de conceção para reduzir os custos e aumentar a eficiência e a segurança:

  • Reduzir custos

  • Aumentar a eficiência

    • Uniformize a arquitetura, configurações e processos entre inquilinos para minimizar problemas administrativos.

    • Minimizar a necessidade de os utilizadores se moverem de um inquilino para outro

  • Aumentar a segurança

    • Concentre-se em garantir que os dados dos estudantes são seguros.

    • Siga o princípio do menor privilégio: conceda apenas os privilégios necessários para realizar as tarefas necessárias e implementar o acesso Just-in-Time (JIT).

    • Permitir que os utilizadores externos acedam apenas através da Gestão de Direitos ou Microsoft Entra colaboração B2B.

    • Delegue a administração de tarefas específicas a utilizadores específicos com Acesso Suficiente (JEA) para fazer o trabalho.

Motivos comuns para vários inquilinos

Recomendamos vivamente que as organizações com menos de 1 milhão de utilizadores criem um único inquilino, a menos que outros critérios indiquem a necessidade de vários inquilinos. Para organizações com um milhão ou mais de objetos de utilizador, recomendamos vários inquilinos através de uma abordagem regional.

A criação de inquilinos separados tem os seguintes efeitos no seu ambiente EDU.

  • Separação administrativa

    • Pode limitar os impactos de um erro de segurança administrativa ou operacional que afeta recursos críticos.

    • Pode limitar o impacto de contas de administrador ou de utilizador comprometidas.

    • Os relatórios de utilização e os registos de auditoria estão contidos num inquilino.

  • Separação de recursos

    • Privacidade dos estudantes. Os objetos de utilizador do estudante só são detetáveis no inquilino onde o objeto reside.

    • Isolamento de recursos. Os recursos num inquilino separado não podem ser detetados ou enumerados por utilizadores e administradores noutros inquilinos.

    • Espaço de Objeto. As aplicações que escrevem no Microsoft Entra ID e noutros serviços Do Microsoft Online através do Microsoft Graph ou de outras interfaces de gestão só podem afetar recursos no inquilino local.

    • Quotas. O consumo de Quotas e Limites do Azure ao nível do inquilino é separado do dos outros inquilinos.

  • Separação de configuração

    • Fornece um conjunto separado de definições ao nível do inquilino que podem acomodar recursos e aplicações de confiança que têm requisitos de configuração diferentes.

    • Ativa um novo conjunto de serviços Online da Microsoft, como Office 365.

Além de ter mais de 1 milhão de utilizadores, as seguintes considerações podem levar a vários inquilinos.

  • Considerações administrativas

    • Opera ao abrigo de regulamentos que restringem quem pode administrar o ambiente com base em critérios como o país de cidadania, o país de residência ou o nível de apuramento.

    • Tem requisitos de conformidade, como a privacidade dos dados dos estudantes, que exigem a criação de identidades em regiões locais específicas.

  • Considerações sobre recursos

    • Tem recursos, talvez para investigação e desenvolvimento, que tem de proteger da deteção, enumeração ou obtenção de controlo por parte dos administradores existentes por razões regulamentares ou críticas para a empresa.

    • Ciclo de desenvolvimento de aplicações personalizadas que podem alterar dados de utilizadores com o MS Graph ou APIs semelhantes em escala (por exemplo, aplicações a que é concedido Directory.ReadWrite.All)

  • Considerações de configuração

    • Recursos com requisitos que entram em conflito com as posturas de segurança ou colaboração existentes ao nível do inquilino, tais como tipos de autenticação permitidos, políticas de gestão de dispositivos, capacidade de gestão personalizada ou verificação de identidades para identidades externas.

Determinar a abordagem multi-inquilino

Nesta secção, consideramos uma universidade fictícia chamada School of Fine Arts com 2 milhões de alunos em 100 escolas ao longo do Estados Unidos. Nestas escolas, há um total de 130.000 professores e 30.000 funcionários e funcionários a tempo inteiro.

Recomendamos uma abordagem regional ao implementar vários inquilinos da seguinte forma:

  1. Comece por dividir a comunidade de estudantes e educadores por regiões geográficas onde cada região contém menos de 1 milhão de utilizadores.

  2. Crie um inquilino Microsoft Entra para cada região.

    abordagem multi-inquilino.

  3. Aprovisione docentes, professores e estudantes na região correspondente para otimizar as experiências de colaboração.

    aprovisionamento em inquilinos.

Porquê utilizar regiões?

Recomenda-se uma abordagem regional para minimizar o número de utilizadores que se deslocam entre inquilinos. Se criasse um inquilino para cada nível escolar (por exemplo, escolas escolares, escolas secundárias e escolas secundárias), teria de migrar os utilizadores no final de cada ano letivo. Se, em vez disso, os utilizadores permanecerem na mesma região, não terá de movê-los entre inquilinos à medida que os respetivos atributos mudam.

Outras vantagens de uma abordagem regional incluem:

  • Colaboração ideal em cada região

  • É necessário um número mínimo de objetos de convidado de outros inquilinos

Quando um inquilino tem mais de 1 milhão de utilizadores, as experiências de gestão e as ferramentas tendem a degradar-se ao longo do tempo. Da mesma forma, algumas experiências de utilizador final, como utilizar o seletor de pessoas, tornar-se-ão complicadas e pouco fiáveis.

As organizações mais pequenas que optem por implementar vários inquilinos sem uma razão convincente irão aumentar desnecessariamente a sobrecarga de gestão e o número de migrações de utilizadores. Ao fazê-lo, também serão necessários passos para garantir experiências de colaboração entre inquilinos.

Colaborar entre inquilinos com Microsoft Entra colaboração B2B

Microsoft Entra colaboração B2B permite que os utilizadores utilizem um conjunto de credenciais para iniciar sessão em vários inquilinos. Para as instituições de ensino, os benefícios da colaboração B2B incluem:

  • Equipa de administração centralizada que gere vários inquilinos

  • Colaboração de professores entre regiões

  • Integrar pais e tutores com as suas próprias credenciais

  • Parcerias externas, como empreiteiros ou investigadores

Com a colaboração B2B, uma conta de utilizador criada num inquilino (o respetivo inquilino doméstico) é convidada como utilizador convidado para outro inquilino (um inquilino de recurso) e o utilizador pode iniciar sessão com as credenciais do respetivo inquilino. Os administradores também podem utilizar a colaboração B2B para permitir que os utilizadores externos iniciem sessão com as contas sociais ou empresariais existentes ao configurar a federação com fornecedores de identidade, como Facebook, contas Microsoft, Google ou um fornecedor de identidade empresarial.

Membros e convidados

Os utilizadores num inquilino Microsoft Entra são membros ou convidados com base na respetiva propriedade UserType. Por predefinição, os utilizadores membros são aqueles que são nativos do inquilino. Um Microsoft Entra utilizador de colaboração B2B é adicionado como um utilizador com UserType = Convidado por predefinição. Os convidados têm permissões limitadas no diretório e nas aplicações. Por exemplo, os utilizadores convidados não podem procurar informações do inquilino para além das suas próprias informações de perfil. No entanto, um utilizador convidado pode obter informações sobre outro utilizador ao fornecer o Nome Principal de Utilizador (UPN) ou objectId. Um utilizador convidado também pode ler as propriedades dos grupos a que pertence, incluindo a associação a um grupo, independentemente das permissões dos utilizadores convidados serem limitadas .

Em alguns casos, um inquilino de recursos pode querer tratar os utilizadores do inquilino raiz como membros em vez de convidados. Se for o caso, pode utilizar as APIs Microsoft Entra Gestor de Convites B2B para adicionar ou convidar um utilizador do inquilino raiz para o inquilino do recurso como membro. Para obter mais informações, veja Propriedades de um utilizador de colaboração B2B Microsoft Entra.

Administração centralizada de vários inquilinos

Integre identidades externas com Microsoft Entra B2B. Em seguida, podem ser atribuídas funções privilegiadas às identidades externas para gerir Microsoft Entra inquilinos como membros de uma equipa de TI centralizada. Também pode utilizar Microsoft Entra B2B para criar contas de convidado para outros docentes, como administradores ao nível regional ou distrital.

No entanto, as funções específicas do serviço, como o Administrador do Exchange ou o Administrador do SharePoint, necessitam de uma conta local nativa do respetivo inquilino. ​

As seguintes funções podem ser atribuídas a contas B2B

  • Administrador de Aplicativos

  • Desenvolvedor de Aplicativo

  • Administrador de Autenticação

  • Administrador do Conjunto de Chaves IEF B2C

  • Administrador de Políticas do IEF B2C

  • Administrador de Política do IEF da Aplicação na Cloud B2C

  • Administrador de Política do IEF do Dispositivo cloud B2C

  • Administrador de Acesso Condicional

  • Administradores de Dispositivos

  • Associação ao Dispositivo

  • Utilizadores de Dispositivos

  • Leitores de Diretórios

  • Escritores de diretório

  • Contas de Sincronização de Diretórios

  • Administrador do Fluxo de Utilizador ID externa

  • ID externa Administrador de Atributos do Fluxo de Utilizador

  • Fornecedor de Identidade Externa

  • Administrador do 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 Palavras-passe

  • Administrador de Autenticação Privilegiada

  • Administrador de Função Privilegiada

  • Leitor de Relatórios

  • Utilizador Convidado Restrito

  • Administrador de Segurança

  • Leitor de Segurança

  • Administrador de Conta de Usuário

  • Associação a Dispositivos na Área de Trabalho

As funções de administrador personalizadas no Microsoft Entra ID aparecem as permissões subjacentes das funções incorporadas, para que possa criar e organizar as suas próprias funções personalizadas. Esta abordagem permite-lhe conceder acesso de uma forma mais granular do que as funções incorporadas, sempre que forem necessárias.

Eis um exemplo que ilustra como a administração funcionaria para funções administrativas que podem ser delegadas e utilizadas em vários inquilinos.

A conta nativa da Susie está no inquilino da Região 1 e Microsoft Entra B2B é utilizada para adicionar a conta como Administrador de Autenticação à equipa de TI central nos inquilinos da Região 2 e região 3.

administração centralizada.

Utilizar aplicações em vários inquilinos

Para mitigar problemas associados à administração de aplicações num ambiente multi-inquilino, deve considerar escrever aplicações multi-inquilino. Também terá de verificar quais das suas aplicações SaaS suportam várias ligações IdP. As aplicações SaaS que suportam várias ligações IDP devem configurar ligações individuais em cada inquilino. As aplicações SaaS que não suportam múltiplas ligações IDP podem necessitar de instâncias independentes. Para obter mais informações, veja How to: Sign in any Microsoft Entra user using the multi-tenant application pattern (Como: Iniciar sessão em qualquer utilizador Microsoft Entra com o padrão de aplicação multi-inquilino).

Nota: os modelos de licenciamento podem variar de uma aplicação SaaS para outra. marcar com o fornecedor para determinar se serão necessárias várias subscrições num ambiente multi-inquilino.

Administração por inquilino

A administração por inquilino é necessária para funções específicas do serviço. As funções específicas do serviço exigem ter uma conta local nativa do inquilino. Além de ter uma equipa de TI centralizada em cada inquilino, também terá de ter uma equipa de TI regional em cada inquilino para gerir cargas de trabalho como o Exchange, o SharePoint e o Teams.

As seguintes funções requerem contas nativas de cada inquilino

  • Administrador do Azure DevOps

  • Administrador Proteção de Informações do Azure

  • Administrador de Cobrança

  • Administrador do Serviço CRM

  • Administrador de Conformidade

  • Administrador de Dados de Conformidade

  • Aprovador de Acesso ao Sistema de Proteção de Dados do Cliente

  • Administrador do Análise de Área de Trabalho

  • Administrador do Exchange

  • Insights do Administrador

  • Insights do Líder de Negócios

  • Administrador do Kaizala

  • Administrador do Serviço Lync

  • Leitor de Privacidade do Centro de Mensagens

  • Leitor do Centro de Mensagens

  • Administrador da Impressora

  • Técnico de Impressora

  • Administrador de Pesquisa

  • Procurar 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 inquilino

Se tiver uma equipa de TI nativa de cada região, poderá ter um desses administradores locais a gerir a administração do Teams. No exemplo seguinte, o Carlos reside no inquilino 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, respetivamente, e têm o mesmo papel nas respetivas regiões. Cada administrador local tem uma única conta nativa da respetiva região.

Imagem 7.

Administração funções entre inquilinos

Se não tiver um conjunto de administradores locais para cada região, poderá atribuir a função de Administrador de Serviços do Teams a apenas um utilizador. Neste cenário, conforme ilustrado abaixo, pode fazer com que Bob, da Equipa Central de TI, atue como Administrador de Serviços do Teams nos três inquilinos ao criar uma conta local para Bob em cada inquilino.

Imagem 9.

Delegação de funções de administrador num inquilino

As unidades administrativas (AUs) devem ser utilizadas para agrupar logicamente Microsoft Entra utilizadores e grupos. Restringir o âmbito administrativo através de unidades administrativas é útil em organizações educativas compostas por diferentes regiões, distritos ou escolas.

Por exemplo, a nossa Escola fictícia de Belas Artes está distribuída por três regiões, cada uma contendo várias escolas. Cada região tem uma equipa de administradores de TI que controlam o acesso, gerem os utilizadores e definem políticas para as respetivas escolas.

Por exemplo, um administrador de TI pode:

  • Crie uma AU para os utilizadores de cada uma das escolas na Região 1, para gerir todos os utilizadores nessa escola. (não na imagem)

  • Crie uma AU que contenha os professores em cada escola para gerir as contas de professores.

  • Crie uma AU separada que contenha os alunos de cada escola para gerir contas de estudantes.

  • Atribua aos professores na escola a função Administrador de Palavras-passe para a AU de Estudantes, para que os professores possam repor as palavras-passe dos estudantes, mas não repor as palavras-passe dos outros utilizadores.

Unidades administrativas.

As funções que podem ser confinadas a unidades administrativas incluem:

  • Administrador de Autenticação

  • Administrador do Grupos

  • Administrador da Assistência Técnica

  • Administrador de Licenças

  • Administrador de Palavras-passe

  • Administrador do usuário

Para obter mais informações, veja Atribuir funções no âmbito a uma unidade administrativa.

Gestão entre inquilinos

As definições são configuradas individualmente em cada inquilino. Configure então como parte da criação do inquilino, sempre que possível, para ajudar a minimizar a possibilidade de rever essas definições. Embora algumas tarefas comuns possam ser automatizadas, não existe um portal de gestão entre inquilinos incorporado.

Gerir objetos em escala

O Microsoft Graph (MS Graph) e o Microsoft Graph PowerShell permitem-lhe gerir objetos de diretório em escala. Também podem ser utilizadas para gerir a maioria das políticas e definições no seu inquilino. No entanto, deve compreender as seguintes considerações de desempenho:

  • O MS Graph limita a criação de utilizadores, grupos e alterações de associação a 72 000 por inquilino, por hora.

  • O desempenho do MS Graph pode ser afetado por ações orientadas pelo utilizador, como ações de leitura ou escrita no inquilino

  • O desempenho do MS Graph pode ser afetado por outras tarefas de administrador de TI concorrentes no inquilino

  • PowerShell, SDS, Microsoft Entra Connect e soluções de aprovisionamento personalizadas adicionam objetos e associações através do MS Graph a taxas diferentes

Próximas etapas

Se ainda não reviu a Introdução ao Microsoft Entra inquilinos, poderá querer fazê-lo. Em seguida, consulte: