Configuração de confiança zero para organizações de defesa multilocatárias
Este artigo mostra às organizações multilocatárias como aplicar configurações no Microsoft Entra ID e atender aos requisitos comuns de confiança zero de defesa. Siga estas recomendações para estabelecer a arquitetura de identidade multilocatária correta e implementar confiança zero em seu ambiente.
Figura 1: Exemplo de arquitetura de defesa multilocatária com configurações de confiança zero.
Determinar a arquitetura de identidade
Os locatários do Microsoft Entra são a base da sua arquitetura de identidade. Um locatário é um limite de identidade no Microsoft Entra ID. 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 inquilino é mais fácil de gerir e reduz os custos através da eficiência operacional. Ele permite que você configure um ambiente de confiança zero mais facilmente. Um único locatário evita fragmentar a experiência do usuário com várias credenciais de entrada. Ele também ajuda a evitar soluções em silos que você precisa integrar mais tarde. Você deve se esforçar para ter seus dados, o Microsoft 365 e os 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 principal. Para obter mais informações, consulte Transferir uma assinatura do Azure para um diretório diferente do Microsoft Entra.
Casos de uso multilocatário. 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. Razões para ter ou criar vários inquilinos.
| Razão | Exemplo |
|---|---|
| Privacidade ou Segurança requer uma separação mais profunda de dados | A organização do Gabinete do Inspetor-geral deve ser independente. |
| 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 dos 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 locatários separados para gerenciar suas funções e responsabilidades. |
Se você precisar de vários locatários do Microsoft Entra, deverá usar a ID Externa do Microsoft Entra (B2B) e o Azure Lighthouse. Esses recursos ajudam a oferecer suporte a ambientes de defesa multilocatário. Para obter mais informações, consulte Modelos de locação para uma solução multilocatário.
Identificar tipos de locatários
As organizações de defesa multilocatárias podem categorizar instâncias do Microsoft Entra que usam como primárias ou secundárias. Cada organização deve identificar e designar um locatário como locatário principal. Todos os outros inquilinos são secundários. A Figura 1 mostra uma organização de defesa com um locatário principal 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 principal quando se inscreve no Microsoft 365. O locatário principal 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 Ative 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. Esta 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 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ário). 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 aterrissagem 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 no Microsoft Entra ID.
O locatário com suas licenças do Microsoft 365 é seu locatário principal (consulte a figura 2). O locatário principal pode não ser o primeiro locatário criado pela 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 usa o Microsoft 365, qualquer locatário do Microsoft Entra com licenças do Enterprise Mobility and Security (EMS) é seu locatário principal. Este 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 integra-se a um sistema de recursos humanos (RH) (veja 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 o Microsoft Entra ID 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 confiança zero
Ao gerenciar identidades no Microsoft Entra ID, você deve considerar as seguintes recomendações para cada tipo de locatário. Há recomendações gerais para todos os tipos de locatários que você deve adotar primeiro. Depois de implementar essas recomendações gerais, localize as recomendações para o seu tipo de inquilino específico (principal ou secundário) e, em seguida, aplique essas recomendações.
Para saber mais sobre como proteger os locatários do Microsoft Entra com confiança zero, consulte Plano de modernização rápida do Zero Trust e Plano de modernização rápida de segurança.
Todos os inquilinos
Você deve implementar as seguintes recomendações 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 seu locatário do Microsoft Entra. Você precisa atribuir a função de Administrador Global a essas contas. As contas devem ser apenas contas na nuvem. As contas apenas na nuvem utilizam 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 você não pode 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 utilizador apenas na nuvem com credenciais resistentes a phishing, como Chave de Acesso de Hardware ou Autenticação Baseada em Certificados. Não use identidades federadas para fins administrativos. Para obter mais informações, consulte Proteger o Microsoft 365 contra ataques locais.
Use o gerenciamento privilegiado de identidades. Use o Microsoft Entra Privileged Identity Management (PIM) para gerenciar atribuições de função para funções do Microsoft Entra ID e 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 na nuvem são mais seguros do que a autenticação federada. Eles oferecem uma melhor experiência de logon único quando combinados com dispositivos associados ao Microsoft Entra. A autenticação federada expõe o Microsoft Entra ID a comprometimentos do Ative Directory local.
A autenticação baseada em certificado (CBA) do Microsoft Entra torna desnecessário federar domínios do Microsoft Entra. A autenticação do Microsoft Entra suporta os seguintes métodos de autenticação sem senha:
- Chaves de acesso (chaves de segurança FIDO2)
- Autenticação baseada em certificado
- Autenticador da Microsoft
- Windows Hello para empresas
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 básico 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 das suas políticas de Acesso Condicional.
O Microsoft Entra ID Protection ajuda as organizações a detetar, 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. Aumentar os controles aplicados com nível de risco para cada tipo de risco. Para equilibrar a produtividade do usuário com a segurança, evite usar o controle Block em políticas baseadas em risco.
Nota
Os usuários podem auto-corrigir 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 auto-remediar 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.
Atenção
Os utilizadores sem palavra-passe que apenas iniciam sessão com métodos sem palavra-passe, como a autenticação baseada em certificado Entra, a chave de acesso ou o Windows Hello para Empresas, podem ser bloqueados pelo controlo de concessão Exigir alteração de palavra-passe se não conseguirem repor a palavra-passe no Microsoft Entra ID.
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 da política de Acesso Condicional.
| Nome da política | Utilizadores | Aplicações | Condições | Controlo de subvenções |
|---|---|---|---|---|
| MFA para todos os utilizadores | Todos os Utilizadores | Todos os apps | Nenhuma | - MFA resistente a phishing |
| Exigir dispositivo gerenciado | Todos os Utilizadores | Todos os apps | Nenhuma | - Exigir dispositivo híbrido associado ou compatível com o Microsoft Entra |
| Proteja entradas de risco médio | Todos os Utilizadores | Todos os apps | Risco médio de início de sessão | - MFA resistente a phishing - Requer dispositivo compatível - Frequência de entrada: 1 hora (ajuste de acordo com a tolerância ao risco da sua organização) |
| Proteja entradas de alto risco | Todos os Utilizadores | Todos os apps | Elevado risco de início de sessão | - MFA resistente a phishing - Requer dispositivo compatível - Frequência de início de sessão: sempre |
| Proteja usuários de alto risco | Todos os Utilizadores | Todos os apps | Elevado risco para o utilizador | - MFA resistente a phishing - Requer dispositivo compatível - Frequência de início de sessão: sempre |
| Administração segura do Microsoft Entra | Funções do Microsoft Entra | Todos os apps | Nenhuma | - MFA resistente a phishing - Requer Compliant Privileged Access Workstation (PAW) usando filtros de dispositivo |
| Gestão segura da nuvem | Todos os Utilizadores | Gestão do Azure Google Cloud Platform Amazon Web Services |
Nenhuma | - MFA resistente a phishing - Requer Compliant Privileged Access Workstation (PAW) usando filtros de dispositivo |
A política de exemplo definida na tabela 2 é para organizações sem senha em que todos os usuários usam apenas MFA resistente a phishing de dispositivos gerenciados. Os utilizadores privilegiados utilizam as Estações de Trabalho de Acesso Privilegiado (PAW) geridas pelo Intune. Em vez de exigir uma alteração de senha para usuários de alto risco, a política de usuário arriscada impõe a força da autenticação e os controles de 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 remediar usuários de alto risco.
Para saber mais sobre a implantação do Acesso Condicional, consulte Planejar uma implantação do Acesso Condicional.
Use identidades de locatário principal para acessar todos os aplicativos. Os usuários devem ser capazes de acessar aplicativos usando sua identidade no locatário principal. Você precisa registrar aplicativos no locatário principal. Estabeleça uma política para registrar aplicativos com o locatário principal, independentemente do local de hospedagem da infraestrutura de aplicativos.
Para aplicativos herdados que não oferecem suporte a protocolos de autenticação modernos, use o serviço de proxy de aplicativo Microsoft Entra no locatário principal. O proxy de aplicativo 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 os 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 principal. Para obter mais informações, consulte Proteger aplicativos com confiança zero.
Use o Microsoft Entra ID para gerenciar outros ambientes de nuvem. O Microsoft Entra ID não é apenas uma plataforma de identidade para o Azure e o Microsoft 365. Use o Microsoft Entra ID 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 pouso compatível com SCCA. A zona de aterrissagem deve estar em assinaturas do Azure anexadas ao locatário principal.
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 dentro de uma zona de aterrissagem do Azure em escala empresarial. Considere transferir assinaturas de locatários secundários para o locatário principal.
Use o Gerenciamento de Permissões do Microsoft Entra. O Microsoft Entra Permissions Management é a solução CIEM (Cloud Infrastructure Entitlement Management) da Microsoft. Você deve usar o Gerenciamento de Permissões do Microsoft Entra para 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 multicloud da sua organização.
Use Microsoft Entra ID Governance. Use o Microsoft Entra ID Governance para automatizar o ciclo de vida da 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.
Proteja as identidades da carga de trabalho. Use os recursos de ID de Carga de Trabalho do Microsoft Entra para gerenciar e aplicar políticas adaptáveis de confiança zero para identidades de aplicativos (entidades de serviço) na ID do Microsoft Entra.
Habilite o Defender for Cloud para sua empresa. Use o Defender for Cloud para seu ambiente multicloud. 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 for Cloud vai além do Azure para ajudá-lo a proteger ambientes híbridos e multicloud.
Implante o Sentinel e conecte todas as fontes de dados disponíveis. Agregar sinais de segurança em um SIEM como o Microsoft Sentinel. Implante o Sentinel e conecte todas as fontes de dados de sinais de segurança configurando conectores de dados.
Inquilinos principais
Você deve implementar as seguintes recomendações somente no locatário principal.
Os usuários finais têm apenas uma identidade no Entra ID. Sincronize os Serviços de Domínio Ative Directory locais com o locatário principal 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 principal para entrada no Windows e acesso ao aplicativo.
Junte-se e gerencie dispositivos com o locatário principal. O locatário principal do Microsoft Entra contém todos os usuários e dispositivos dentro da organização. O Microsoft Entra ingressa (ou o Microsoft Entra associação híbrida) dispositivos Windows ao locatário principal e gerencia com o Microsoft Intune. Utilize a política do Intune para implementar o Microsoft Defender for Endpoint permitindo a capacidade alargada de deteção e resposta (XDR).
Delegue permissões de registro de aplicativo. As Aplicações Empresariais, incluindo o código da aplicação em execução em qualquer subscrição do Azure, utilizam o inquilino principal do Microsoft Entra ID para a identidade do utilizador. Torne os desenvolvedores elegíveis para a função de desenvolvedor de aplicativos 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 com o locatário principal para identidade.
Anexe serviços de plataforma como serviço (PaaS) que precisam de identidade de usuário final. Alguns serviços PaaS, como os Arquivos do Azure e a Área de Trabalho Virtual do Azure, dependem da configuração de identidade híbrida ou dos direitos de licença. Você deve implantar esses serviços em assinaturas do Azure no locatário principal.
Inquilinos secundários
Você deve implementar as seguintes recomendações no locatário secundário.
Obtenha 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 de 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 que você habilite recursos premium como Acesso Condicional e Proteção de Identidade. Para obter mais informações, consulte Considerações comuns para gerenciamento de usuários multilocatário.
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 principal, como a API do MS Graph.
Gestão de dispositivos. Talvez seja necessário gerenciar dispositivos com o Microsoft Intune no locatário secundário. Em caso afirmativo, você precisa adquirir licenças EMS (Enterprise Mobility and Security).
Configure políticas de acesso entre locatários (XTAP). As configurações de acesso entre locatários do Microsoft Entra External ID (colaboração B2B do Microsoft Entra) permitem que um locatário secundário confie em determinadas declarações do locatário principal inicial. Adicione o locatário principal do Microsoft Entra como uma organização e atualize as configurações de confiança de entrada para incluir:
- Confiar na autenticação multifator (MFA) dos locatários do Microsoft Entra
- Confie em dispositivos compatíveis
- Confie nos dispositivos híbridos associados ao Microsoft Entra
- Opcional: resgate automaticamente convites com o locatário
Gerencie o locatário secundário com identidades do locatário principal. Reduza a sobrecarga administrativa e os custos usando usuários externos (convidados B2B) do locatário principal para gerenciar o locatário secundário e os recursos do Azure. Atribua funções do Microsoft Entra seguindo a função de privilégios mínimos do Microsoft Entra 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 ao Sentinel do locatário principal. O Azure Lighthouse oferece outra maneira de gerenciar o Azure entre locatários. O Azure Lighthouse usa modelos do Azure Resource Manager (ARM) 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. Esta vista consolidada inclui subscrições com permissões atribuídas pelo Azure Lighthouse. Como não há nenhum 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.