Configuração de confiança zero para organizações de defesa multilocatário
Este artigo mostra às organizações multilocatários como aplicar configurações na ID do Microsoft Entra e atender aos requisitos comuns de confiança zero de defesa. Siga estas recomendações para estabelecer a arquitetura de identidade multilocatário correta e implementar a confiança zero em seu ambiente.
Figura 1: Exemplo de arquitetura de defesa multilocatário com configurações de confiança zero.
Determinar a arquitetura de identidade
Os locatários do Microsoft Entra são a base de sua arquitetura de identidade. Um locatário é um limite de identidade na ID do Microsoft Entra. Uma organização com um locatário do Microsoft Entra tem uma arquitetura de locatário único. As organizações que usam mais de um locatário do Microsoft Entra têm uma arquitetura multilocatário.
Benefícios de um único inquilino. Um único locatário é mais fácil de gerenciar e reduz os custos por meio da eficiência operacional. Ele permite que você configure um ambiente de confiança zero com mais facilidade. Um único locatário evita fragmentar a experiência do usuário com várias credenciais de entrada. Também ajuda a evitar soluções isoladas que você precisa integrar posteriormente. Você deve se esforçar para ter seus dados, Microsoft 365 e serviços de nuvem do Azure em um único locatário. Se você já tiver vários locatários do Microsoft Entra, considere consolidar seu ambiente para usar um único locatário. Você pode consolidar locatários transferindo assinaturas do Azure de seus locatários secundários para o locatário primário. Para obter mais informações, consulte transferir uma assinatura do Azure para um diretório diferente do Microsoft Entra.
Casos de uso multilocatários. Há razões para uma organização de defesa usar uma arquitetura multilocatário. Organizações de defesa grandes e complexas podem precisar de vários locatários do Microsoft Entra para segurança, conformidade e colaboração (consulte a tabela 1).
Tabela 1. Motivos para ter ou criar vários locatários.
| Motivo | Exemplo |
|---|---|
| Privacidade ou segurança requer uma separação mais profunda de dados | Uma organização do Escritório do Inspetor Geral deve ter independência. |
| Delegação e Segmentação da administração | Uma organização não tem a capacidade de gerenciar outra organização. |
| Soberania e/ou propriedade de dados | Uma organização não tem autoridade legal para gerenciar dados de outra organização. |
| Organização de Redes e TI | Não é possível nem favorável colapsar várias arquiteturas de TI corporativas de grande porte em uma única arquitetura corporativa. |
| Monitoramento SOC e Resposta a Incidentes | O SOC precisa de um locatário separado para gerenciar suas funções e responsabilidades. |
Se você precisar de vários locatários do Microsoft Entra, deverá usar a B2B (ID Externa) do Microsoft Entra e o Azure Lighthouse. Esses recursos ajudam a oferecer suporte a ambientes de defesa multilocatários. Para obter mais informações, consulte Modelos de locação para uma solução multilocatário.
Identificar tipos de locatário
As organizações de defesa multilocatário podem categorizar as instâncias do Microsoft Entra que usam como primárias ou secundárias. Cada organização deve identificar e designar um locatário como o locatário principal. Todos os outros inquilinos são secundários. A Figura 1 mostra uma organização de defesa com um locatário primário e n locatários secundários (dois locatários secundários mostrados).
Identifique o locatário principal. A maioria das organizações de defesa cria o locatário primário quando se inscreve no Microsoft 365. O locatário primário contém (1) todas as identidades de usuário e licenças do Microsoft 365, (2) dispositivos e (3) aplicativos (consulte a figura 1). As organizações de defesa geralmente usam o Microsoft Entra Connect para sincronizar as identidades do Active Directory local com o locatário principal do Microsoft Entra.
Algumas organizações de defesa consomem o Microsoft 365 em um locatário compartilhado de propriedade e operado por uma agência externa. Essa agência atua como um provedor de serviços compartilhados para o Microsoft 365. Sua organização pode não gerenciar ou controlar o locatário compartilhado, mas ele contém as identidades licenciadas do Microsoft Entra que seus usuários provavelmente usam para o Office 365 e outros aplicativos. Nesse cenário, o locatário do provedor de serviços compartilhados é seu locatário principal.
Identifique todos os locatários secundários (se multilocatários). Todos os outros locatários que a organização gerencia são locatários secundários. Você pode ter locatários secundários se tiver migrado aplicativos para a nuvem antes de criar uma zona de destino do Azure em escala empresarial. Normalmente, você usa locatários secundários para gerenciar (4) cargas de trabalho do Azure com usuários externos (convidados B2B) ou (5) contas somente na nuvem (consulte a figura 1).
Use a árvore de decisão. A maneira mais fácil de encontrar seu locatário principal é considerar as licenças de identidade que você tem na ID do Microsoft Entra.
O locatário com suas licenças do Microsoft 365 é seu locatário principal (consulte a figura 2). O locatário primário pode não ser o primeiro locatário criado por sua organização, mas deve ser o locatário principal com todos os seus usuários e licenças do Microsoft 365.
Se sua organização não usar o Microsoft 365, qualquer locatário do Microsoft Entra com licenças do Enterprise Mobility and Security (EMS) será seu locatário principal. Esse locatário é onde você adicionou e verificou o nome de domínio da sua organização. O locatário geralmente usa identidade híbrida ou se integra a um sistema de RH (recursos humanos) (consulte a figura 2).
Figura 2. Uma árvore de decisão para determinar o locatário primário e o locatário secundário do Microsoft Entra.
Para estabelecer a ID do Microsoft Entra como uma plataforma de confiança zero, você precisa de um locatário preenchido com suas identidades de usuário e licenciado para políticas de acesso baseadas em usuário e dispositivo. O licenciamento do Microsoft 365 agrupa esses recursos de confiança zero com o Office 365. Se você não usa o Microsoft 365, considere o Enterprise Mobility + Security E5 para estabelecer um provedor de identidade baseado em nuvem para confiança zero. Para obter mais informações, consulte Escolhendo sua autoridade de identidade.
Configurar a proteção do acesso a
Ao gerenciar identidades na ID do Microsoft Entra, você deve considerar as recomendações a seguir para cada tipo de locatário. Há recomendações gerais para todos os tipos de locatário que você deve adotar primeiro. Depois de implementar essas recomendações gerais, localize as recomendações para seu tipo de locatário específico (primário ou secundário) e aplique essas recomendações.
Para saber mais sobre como proteger locatários do Microsoft Entra com confiança zero, consulte Plano de Modernização Rápida de Confiança Zero e Plano de Modernização Rápida de Segurança.
Todos os locatários
Você deve implementar as recomendações a seguir em todos os locatários do Microsoft Entra.
Estabeleça contas e procedimentos de acesso de emergência. Crie duas ou mais contas de acesso de emergência para evitar ser bloqueado do locatário do Microsoft Entra. Você precisa atribuir a função de Administrador Global a essas contas. As contas devem ser contas somente na nuvem. As contas somente na nuvem usam o domínio *.onmicrosoft.com . Para obter mais informações, consulte Gerenciar contas de administrador de acesso de emergência.
Importante
A Microsoft recomenda que você use funções com o menor número de permissões. Isso ajuda a melhorar a segurança da sua organização. Administrador Global é uma função altamente privilegiada que deve ser limitada a cenários de emergência quando não for possível usar uma função existente.
Proteja a ID do Microsoft Entra contra ataques locais. Siga as práticas recomendadas descritas em Protegendo o acesso privilegiado. Atribua permissões do Microsoft Entra apenas a contas de usuário somente na nuvem com credenciais resistentes a phishing, como Chave de Senha de Hardware ou Autenticação Baseada em Certificado. Não use identidades federadas para fins administrativos. Para obter mais informações, consulte Proteger o Microsoft 365 contra ataques locais.
Usar o Privileged Identity Management. Use o Microsoft Entra Privileged Identity Management (PIM) para gerenciar atribuições de função para a ID do Microsoft Entra e funções do Azure. Você também deve usar o PIM para gerenciar a associação de grupo qualificada para grupos de segurança privilegiados. Estabeleça revisões periódicas de acesso para administradores qualificados e usuários externos (convidados B2B).
Habilite a autenticação baseada em nuvem para todos os usuários. Os métodos de autenticação baseados em nuvem são mais seguros do que a autenticação federada. Eles oferecem uma melhor experiência de logon único quando combinados com dispositivos ingressados no Microsoft Entra. A autenticação federada expõe a ID do Microsoft Entra a comprometimentos do Active Directory local.
A CBA (autenticação baseada em certificado) do Microsoft Entra torna desnecessário federar domínios do Microsoft Entra. A autenticação do Microsoft Entra dá suporte aos seguintes métodos de autenticação sem senha:
- Chaves de acesso (chaves de segurança FIDO2)
- Autenticação com base em certificado
- Autenticador Microsoft
- Windows Hello for Business
Estabeleça políticas de acesso condicional de linha de base. A linha de base de acesso condicional varia de acordo com a organização e os requisitos. Estabeleça um conjunto principal de políticas de acesso condicional para todos os locatários do Microsoft Entra. Use identidade, dispositivo, aplicativo e condições de risco em seu conjunto de políticas. Exclua contas de Acesso de Emergência de suas políticas de Acesso Condicional.
O Microsoft Entra ID Protection ajuda as organizações a detectar, investigar e corrigir riscos baseados em identidade. Para proteger entradas e usuários arriscados, crie políticas de Acesso Condicional com condições de risco. Use políticas separadas para usuários arriscados e entradas arriscadas. Aumente os controles aplicados com o nível de risco para cada tipo de risco. Para equilibrar a produtividade do usuário com a segurança, evite usar o controle Bloquear em políticas baseadas em risco.
Observação
Os usuários podem corrigir automaticamente os riscos de entrada com MFA. Para permitir que os usuários corrijam automaticamente o risco de entrada, configure o controle de concessão de MFA ou Força de Autenticação em uma política de Acesso Condicional baseada em risco de entrada.
Os usuários podem corrigir automaticamente os riscos do usuário alterando suas senhas. Para permitir que os usuários corrijam automaticamente o risco do usuário, configure uma política de Acesso Condicional baseada em risco do usuário com Exigir controle de concessão de alteração de senha.
Cuidado
Os usuários sem senha que entrarem apenas com métodos sem senha, como autenticação baseada em certificado do Entra, chave de acesso ou Windows Hello para Empresas, poderão ser bloqueados pelo controle de concessão Exigir alteração de senha se não puderem redefinir sua senha na ID do Microsoft Entra.
Crie políticas de Acesso Condicional para sua organização, usando a lista de verificação de política de Acesso Condicional de Exemplo (consulte a tabela 2). Use o modo somente relatório para testar as políticas de Acesso Condicional antes de implantar na produção.
Tabela 2: Exemplo de lista de verificação de política de Acesso Condicional.
| Nome da política | Usuários | Aplicativos | Condições | Controle de concessão |
|---|---|---|---|---|
| MFA para todos os usuários | Todos os usuários | Todos os aplicativos | Nenhum | - MFA resistente a phishing |
| Exigir dispositivo gerenciado | Todos os usuários | Todos os aplicativos | Nenhum | - Exigir dispositivo híbrido ingressado ou compatível com o Microsoft Entra |
| Proteger entradas de risco médio | Todos os usuários | Todos os aplicativos | Risco médio de entrada | - MFA resistente a phishing - Exigir dispositivo compatível - Frequência de entrada: 1 hora (ajuste de acordo com a tolerância ao risco da sua organização) |
| Proteger entradas de alto risco | Todos os usuários | Todos os aplicativos | Alto risco de entrada | - MFA resistente a phishing - Exigir dispositivo compatível - Frequência de login: sempre |
| Proteja usuários de alto risco | Todos os usuários | Todos os aplicativos | Alto risco para o usuário | - MFA resistente a phishing - Exigir dispositivo compatível - Frequência de login: sempre |
| Administração segura do Microsoft Entra | Funções do Microsoft Entra | Todos os aplicativos | Nenhum | - MFA resistente a phishing - Exigir estação de trabalho de acesso privilegiado (PAW) compatível usando filtros de dispositivo |
| Gerenciamento seguro da nuvem | Todos os usuários | Gerenciamento do Azure Google Cloud Platform Amazon Web Services |
Nenhum | - MFA resistente a phishing - Exigir estação de trabalho de acesso privilegiado (PAW) compatível usando filtros de dispositivo |
O exemplo de política definido na tabela 2 é para organizações sem senha em que todos os usuários usam apenas MFA resistente a phishing de dispositivos gerenciados. Os usuários privilegiados usam as Estações de Trabalho de Acesso Privilegiado (PAW) gerenciadas pelo Intune. Em vez de exigir uma alteração de senha para usuários de alto risco, a política de usuário arriscado impõe controles de força de autenticação e frequência de entrada. Esses controles oferecem algumas proteções, mas não corrigem o nível de risco do usuário na Proteção de ID do Microsoft Entra. Sua equipe de operações de segurança deve investigar e corrigir usuários de alto risco.
Para saber mais sobre a implantação do Acesso Condicional, consulte Planejar uma implantação de Acesso Condicional.
Use identidades de locatário primário para acessar todos os aplicativos. Os usuários devem ser capazes de acessar aplicativos usando sua identidade no locatário primário. Você precisa registrar aplicativos no locatário primário. Estabeleça uma política para registrar aplicativos com o locatário primário, independentemente do local de hospedagem da infraestrutura do aplicativo.
Para aplicativos herdados que não dão suporte a protocolos de autenticação modernos, use o serviço de proxy de aplicativo Microsoft Entra no locatário primário. O proxy de aplicativo do Microsoft Entra traz recursos de confiança zero do Microsoft Entra para aplicativos herdados existentes sem alterações de código.
Quando um provedor de serviços compartilhados ou uma agência externa controla seu locatário principal, eles devem delegar permissões de registro de aplicativo. Se o provedor de serviços não oferecer essa delegação, você precisará registrar aplicativos com o locatário secundário que sua organização controla. No entanto, os usuários ainda devem acessar esses aplicativos sem criar uma nova identidade no locatário secundário. Para essa configuração, atribua acesso de usuário usando identidades externas (convidados B2B) para seus usuários no locatário primário. Para obter mais informações, consulte Proteger aplicativos com confiança zero.
Use a ID do Microsoft Entra para gerenciar outros ambientes de nuvem. A ID do Microsoft Entra não é apenas uma plataforma de identidade para o Azure e o Microsoft 365. Use a ID do Microsoft Entra para obter acesso a outros ambientes de nuvem. Esses ambientes incluem produtos populares de software como serviço (SaaS) e plataformas de nuvem como Amazon Web Services (AWS) e Google Cloud Platform (GCP). Para obter mais informações, consulte a galeria de aplicativos do Microsoft Entra.
Use uma arquitetura de computação em nuvem segura (SCCA). Cada organização de defesa deve implantar uma arquitetura de zona de destino compatível com SCCA. A zona de destino deve estar em assinaturas do Azure anexadas ao locatário primário.
Segmente o gerenciamento de recursos do Azure em um único locatário. Você deve usar funções do Azure para isolamento de recursos e gerenciamento para assinaturas em uma zona de destino do Azure de escala empresarial. Considere transferir assinaturas de locatários secundários para o locatário primário.
Use o Gerenciamento de Permissões do Microsoft Entra. O Microsoft Entra Permissions Management é a solução de Gerenciamento de Direitos de Infraestrutura de Nuvem (CIEM) da Microsoft. Você deve usar o Gerenciamento de Permissões do Microsoft Entra para obter visibilidade das permissões atribuídas a todas as identidades. Você também deve usá-lo para rastrear o aumento de permissões no ambiente multinuvem da sua organização.
Use a governança de ID do Microsoft Entra. Use a Governança de ID do Microsoft Entra para automatizar o ciclo de vida de atribuição de acesso para usuários e convidados. Realize revisões de acesso para remover o acesso ao seu ambiente de nuvem para usuários que não precisam mais dele.
Identidades de carga de trabalho seguras. Use os recursos de ID de carga de trabalho do Microsoft Entra para gerenciar e aplicar políticas de confiança zero adaptáveis para identidades de aplicativo (entidades de serviço) no Microsoft Entra ID.
Habilite o Defender para Nuvem para sua empresa. Use o Defender para Nuvem para seu ambiente multinuvem. Certifique-se de ativar os recursos de segurança aprimorados para monitorar os recursos do Azure e corrigir o risco de configuração. A proteção do Defender para Nuvem vai além do Azure para ajudá-lo a proteger ambientes híbridos e multinuvem.
Implante o Sentinel e conecte todas as fontes de dados disponíveis. Agregue sinais de segurança em um SIEM como o Microsoft Sentinel. Implante o Sentinel e conecte todas as fontes de dados de sinal de segurança configurando conectores de dados.
Locatários primários
Você deve implementar as recomendações a seguir somente no locatário primário.
Os usuários finais têm apenas uma identidade no ID do Entra. Sincronize os Serviços de Domínio Active Directory locais com o locatário primário do Microsoft Entra. A sincronização preenche a ID do Microsoft Entra com usuários, grupos e dispositivos para a organização. Convidados B2B externos podem existir em locatários secundários, mas os usuários só precisam se lembrar de um nome de usuário para todos os aplicativos e serviços. A experiência do usuário e os resultados de confiança zero são melhores quando você usa as identidades no locatário primário para entrada do Windows e acesso ao aplicativo.
Ingresse e gerencie dispositivos com o locatário primário. O locatário principal do Microsoft Entra contém todos os usuários e dispositivos dentro da organização. O Microsoft Entra ingressa (ou ingressa híbrida no Microsoft Entra) dispositivos Windows ao locatário primário e gerencia com Microsoft Intune. Use a política do Intune para implantar o Microsoft Defender para Ponto de Extremidade habilitando a funcionalidade XDR (detecção e resposta estendida).
Delegar permissões de registro de aplicativo. Os Aplicativos Empresariais, incluindo o código do aplicativo em execução em qualquer assinatura do Azure, usam o locatário primário da ID do Microsoft Entra para a identidade do usuário. Torne os desenvolvedores qualificados para a função Desenvolvedor de Aplicativos do Microsoft Entra ou uma função de registro de aplicativo personalizada usando o Privileged Identity Management. Essa configuração permite que os desenvolvedores que criam aplicativos em locatários secundários os registrem no locatário primário para identidade.
Anexe serviços de plataforma como serviço (PaaS) que precisam de identidade de usuário final. Alguns serviços de PaaS, como Arquivos do Azure e Área de Trabalho Virtual do Azure, dependem da configuração de identidade híbrida ou direitos de licença. Você deve implantar esses serviços em assinaturas do Azure no locatário primário.
Locatários secundários
Você deve implementar as recomendações a seguir no locatário secundário.
Adquira as licenças necessárias para o gerenciamento do Microsoft Entra. Você precisa de licenças para ativar recursos avançados de segurança em locatários secundários. Considere as licenças necessárias para usuários, cargas de trabalho e dispositivos.
Identidades do usuário. Você precisa ter licenças do Microsoft Entra ID Premium P2 para administradores de locatários e contas de acesso de emergência. Se você usar um modelo de gerenciamento de identidade externa (convidado B2B), deverá atribuir pelo menos uma licença do Microsoft Entra ID Premium P2 a um usuário local no locatário. Essa configuração permite habilitar recursos premium, como Acesso Condicional e Proteção de Identidade. Para obter mais informações, consulte Considerações comuns para o gerenciamento de usuários multilocatários.
Identidades de carga de trabalho. Você deve usar identidades de carga de trabalho premium para proteger identidades de carga de trabalho com acesso a recursos no locatário primário, como a API do MS Graph.
Gerenciamento de dispositivo. Talvez seja necessário gerenciar dispositivos com Microsoft Intune no locatário secundário. Nesse caso, você precisa adquirir licenças Enterprise Mobility and Security (EMS).
Configure políticas de acesso entre locatários (XTAP). As configurações de acesso entre locatários da ID Externa do Microsoft Entra (colaboração B2B do Microsoft Entra) permitem que um locatário secundário confie em determinadas declarações do locatário primário inicial. Adicione o locatário primário do Microsoft Entra como uma organização e atualize as configurações de confiança de entrada para incluir:
- Confiar na MFA (autenticação multifator) de locatários do Microsoft Entra
- Dispositivos em conformidade com confiança
- Confiar em dispositivos ingressados híbridos no Microsoft Entra
- Opcional: resgatar convites automaticamente com o locatário
Gerencie o locatário secundário com identidades do locatário primário. Reduza a sobrecarga administrativa e o custo usando usuários externos (convidados B2B) do locatário primário para gerenciar o locatário secundário e os recursos do Azure. Atribua funções do Microsoft Entra seguindo a função do Microsoft Entra com privilégios mínimos por tarefa usando o Microsoft Entra Privileged Identity Management. Use o acesso iniciado pelo usuário final ou a sincronização entre locatários para reduzir a sobrecarga de gerenciamento de integração de identidades externas no locatário secundário.
Use o Azure Lighthouse para facilitar o acesso do Sentinel do locatário primário. O Azure Lighthouse oferece outra maneira de gerenciar o Azure entre locatários. O Azure Lighthouse usa modelos do ARM (Azure Resource Manager) para atribuir funções do Azure a identidades em um locatário externo. Essa abordagem não usa objetos de usuário convidado B2B. Quando um administrador entra no portal para gerenciar o Azure, ele vê todos os recursos em todos os locatários. Essa exibição consolidada inclui assinaturas com permissões atribuídas pelo Azure Lighthouse. Como não há objeto convidado B2B, o administrador não precisa alternar diretórios. Use o Azure Lighthouse para facilitar o gerenciamento do Microsoft Sentinel entre locatários.