Conceitos básicos de gerenciamento de recursos do Azure
É importante entender a estrutura e os termos específicos aos recursos do Azure. A imagem a seguir mostra um exemplo dos quatro níveis de escopo fornecidos pelo Azure:
Terminologia
Estes são alguns dos termos com os quais você deve estar familiarizado:
Recurso – um item gerenciável que está disponível por meio do Azure. Máquinas virtuais, contas de armazenamento, aplicativos Web, bancos de dados e redes virtuais são exemplos de recursos.
Grupo de recursos – Um contêiner que contém recursos relacionados para uma solução do Azure, como uma coleção de máquinas virtuais, VNets associadas e balanceadores de carga que exigem gerenciamento por equipes específicas. O grupo de recursos inclui esses recursos que você deseja gerenciar como um grupo. Você decide quais recursos pertencem a um grupo de recursos com base no que faz mais sentido para sua organização. Os grupos de recursos também podem ser usados para ajudar no gerenciamento do ciclo de vida excluindo todos os recursos que têm a mesma vida útil ao mesmo tempo. Essa abordagem também oferece benefícios de segurança, não deixando fragmentos que possam ser explorados.
Assinatura – Do ponto de vista da hierarquia organizacional, uma assinatura é um contêiner de cobrança e gerenciamento de recursos e grupos de recursos. Uma assinatura do Azure tem uma relação de confiança com a ID do Microsoft Entra. Uma assinatura confia na ID do Microsoft Entra para autenticar usuários, serviços e dispositivos.
Observação
Uma assinatura pode confiar em apenas um locatário do Microsoft Entra. No entanto, cada locatário pode confiar em várias assinaturas, e as assinaturas podem ser movidas entre locatários.
Grupo de gerenciamento - Os grupos de gerenciamento do Azure fornecem um método hierárquico de aplicação de políticas e conformidade em diferentes escopos acima das assinaturas. Ele pode estar no grupo de gerenciamento raiz do locatário (escopo mais alto) ou em níveis inferiores na hierarquia. Você organiza assinaturas em contêineres chamados "grupos de gerenciamento" e aplica as condições de governança aos grupos de gerenciamento. Todas as assinaturas dentro de um grupo de gerenciamento herdam automaticamente as condições aplicadas ao grupo de gerenciamento. Observe que as definições de política podem ser aplicadas a um grupo de gerenciamento ou assinatura.
Provedor de recursos – Um serviço que fornece recursos do Azure. Por exemplo, um provedor de recursos comum é a Microsoft. Computação, que fornece o recurso da máquina virtual. Microsoft. Armazenamento é outro provedor de recursos comum.
Modelo do Resource Manager – Um arquivo JSON (JavaScript Object Notation) que define um ou mais recursos para implantação em um grupo de recursos, assinatura, locatário ou grupo de gerenciamento. O modelo pode ser usado para implantar os recursos de forma consiste e repetida. Confira Visão geral da implantação de modelo. Além disso, a linguagem Bicep pode ser usada em vez de JSON.
Modelo de gerenciamento de recursos do Azure
No entanto, uma assinatura do Azure é associada aos controles usados pelo Azure Resource Manager. O Gerenciador de Recursos é o serviço de implantação e gerenciamento do Azure, ele tem uma relação de confiança com a ID do Microsoft Entra para gerenciamento de identidades para organizações e a conta Microsoft (MSA) para indivíduos. O Resource Manager fornece uma camada de gerenciamento que permite criar, atualizar e excluir recursos em sua assinatura do Azure. Use recursos de gerenciamento, como controle de acesso, bloqueios e marcas, para proteger e organizar seus recursos após a implantação.
Observação
Antes do ARM, havia outro modelo de implantação chamado ASM (Gerenciador de Serviços do Azure) ou "clássico". Para obter mais informações, consulte Azure Resource Manager versus implantação clássica. O gerenciamento de ambientes com o modelo ASM está fora do escopo desse conteúdo.
O Azure Resource Manager é o serviço front-end, que hospeda as APIs REST usadas pelo PowerShell, o portal do Azure ou outros clientes para gerenciar recursos. Quando um cliente faz uma solicitação para gerenciar um recurso específico, o Resource Manager faz um proxy da solicitação ao provedor de recursos para concluir a solicitação. Por exemplo, se um cliente fizer uma solicitação para gerenciar um recurso de máquina virtual, o Resource Manager faz um proxy da solicitação à Microsoft. Provedor de recursos de computação. O Resource Manager requer que o cliente especifique um identificador para a assinatura e o grupo de recursos a fim de gerenciar o recurso da máquina virtual.
Antes que qualquer solicitação de gerenciamento de recursos possa ser executada pelo Resource Manager, um conjunto de controles é verificado.
Verificação de usuário válida - O usuário que solicita gerenciar o recurso deve ter uma conta no locatário do Microsoft Entra associada à assinatura do recurso gerenciado.
Verificação de permissão do usuário – As permissões são atribuídas aos usuários que usam o RBAC (controle de acesso baseado em função). Uma função RBAC especifica um conjunto de permissões que um usuário pode executar em um recurso específico. O RBAC ajuda você a gerenciar quem tem acesso aos recursos do Azure, o que eles podem fazer com esses recursos e a quais áreas eles têm acesso.
Verificação de política do Azure - As políticas do Azure especificam as operações permitidas ou explicitamente negadas para um recurso específico. Por exemplo, uma política pode especificar que os usuários só têm permissão (ou não têm) para implantar um tipo específico de máquina virtual.
O diagrama a seguir resume o modelo de recurso que acabamos de descrever.
Azure Lighthouse - Azure Lighthouse permite o gerenciamento de recursos entre locatários. As organizações podem delegar funções no nível de assinatura ou de grupo de recursos para identidades em outro locatário.
As assinaturas que habilitam o gerenciamento de recursos delegados com o Azure Lighthouse têm atributos que indicam as IDs de locatário que podem gerenciar assinaturas ou grupos de recursos e o mapeamento entre a função RBAC interna no locatário do recurso para identidades no locatário do provedor de serviços. Em runtime, o Azure Resource Manager consumirá esses atributos para autorizar tokens provenientes do locatário do provedor de serviços.
Vale a pena observar que o próprio Azure Lighthouse é modelado como um provedor de recursos do Azure, o que significa que aspectos da delegação em um locatário podem ser direcionados por meio das Políticas do Azure.
Microsoft 365 Lighthouse - O Microsoft 365 Lighthouse é um portal de administração que ajuda os MSPs (provedores de serviços gerenciados) a proteger e gerenciar dispositivos, dados e usuários em escala para clientes de pequenas e médias empresas que estão usando o Microsoft 365 Business Premium, o Microsoft 365 E3 ou o Windows 365 Business.
Gerenciamento de recursos do Azure com a ID do Microsoft Entra
Agora que você entende melhor sobre o modelo de gerenciamento de recursos no Azure, vamos examinar brevemente alguns dos recursos da ID do Microsoft Entra que podem fornecer gerenciamento de identidade e acesso para recursos do Azure.
Cobrança
A cobrança é importante para o gerenciamento de recursos porque algumas funções de cobrança interagem ou podem gerenciar recursos. A cobrança funciona de forma diferente dependendo do tipo de contrato que você tem com a Microsoft.
Contratos Enterprise Azure
Os clientes do Azure EA (Contratos Enterprise Azure) são integrados ao Portal do Azure EA após a execução de seu contrato comercial com a Microsoft. Após a integração, uma identidade é associada a uma função de cobrança "raiz" do Administrador Corporativo. O portal fornece uma hierarquia de funções de gerenciamento:
Os departamentos ajudam a segmentar os custos em agrupamentos lógicos e permitem definir um orçamento ou uma cota no nível do departamento.
As contas são usadas para outros departamentos de segmento. Você pode usar as contas para gerenciar assinaturas e acessar relatórios. O portal da EA pode autorizar contas Microsoft (MSA) ou contas Microsoft Entra (identificadas no portal como "Contas corporativas ou de estudante"). Identidades com a função "Proprietário da Conta" no portal do EA podem criar assinaturas do Azure.
Cobrança corporativa e locatários do Microsoft Entra
Quando um Proprietário da Conta cria uma assinatura do Azure em um contrato enterprise, o gerenciamento de acesso e identidade da assinatura é configurado da seguinte maneira:
A assinatura do Azure está associada ao mesmo locatário do Microsoft Entra do proprietário da conta.
O proprietário da conta que criou a assinatura receberá as funções de administrador de serviço e administrador de conta. (O Portal do Azure EA atribui funções ASM (Gerenciador de Serviços do Azure) ou "clássicas" para gerenciar assinaturas. Para obter mais informações, consulte Azure Resource Manager versus implantação clássica.)
Um contrato enterprise pode ser configurado para dar suporte a vários locatários definindo o tipo de autenticação "Entre locatários de conta corporativa ou de estudante" no Portal do Azure EA. Considerando o indicado acima, as organizações podem definir várias contas para cada locatário e várias assinaturas para cada conta, conforme mostrado no diagrama abaixo.
É importante observar que a configuração padrão descrita acima concede privilégios aos proprietários da conta do Azure EA para gerenciar os recursos em todas as assinaturas que eles criaram. Para assinaturas que contêm cargas de trabalho de produção, considere desacoplar o gerenciamento de cobrança e de recursos alterando o administrador de serviços da assinatura logo após a criação.
Para desassociar ainda mais e impedir que o proprietário da conta recupere o acesso de administrador de serviços à assinatura, o locatário da assinatura pode ser alterado após a criação. Se o proprietário da conta não tiver um objeto de usuário no locatário do Microsoft Entra para o qual a assinatura foi movida, ele não poderá recuperar a função de proprietário do serviço.
Para saber mais, visite funções do Azure, funções do Microsoft Entra e funções clássicas de administrador de assinatura.
Contrato de Cliente da Microsoft
Os clientes registrados com um MCA (Contrato de Cliente da Microsoft) têm um sistema de gerenciamento de cobrança diferente com suas próprias funções.
Sua conta de cobrança para o Contrato de Cliente da Microsoft contém um ou mais perfis de cobrança que lhe permitem gerenciar suas faturas e formas de pagamento. Cada perfil de cobrança contém uma ou mais seções de fatura para organizar os custos na fatura do perfil de cobrança.
Em um Contrato de Cliente da Microsoft, as funções de cobrança vêm de um único locatário do Microsoft Entra. Para provisionar assinaturas para vários locatários, as assinaturas devem ser inicialmente criadas no mesmo locatário do Microsoft Entra que o MCA e, em seguida, alteradas. No diagrama abaixo, as assinaturas do ambiente de pré-produção de TI corporativo foram movidas para o locatário ContosoSandbox após a criação.
RBAC e atribuições de função no Azure
Na seção de conceitos básicos do Microsoft Entra, você aprendeu que o Azure RBAC é o sistema de autorização que fornece gerenciamento de acesso refinado aos recursos do Azure e inclui muitas funções internas. Você pode criar funções personalizadas e atribuir funções em escopos diferentes. As permissões são impostas atribuindo funções de RBAC a objetos que solicitam acesso aos recursos do Azure.
As funções do Microsoft Entra operam em conceitos como controle de acesso baseado em função do Azure. A diferença entre esses dois sistemas de controle de acesso baseados em função é que o RBAC do Azure usa o Gerenciamento de Recursos do Azure para controlar o acesso a recursos do Azure, como máquinas virtuais ou armazenamento, e as funções do Microsoft Entra controlam o acesso à ID do Microsoft Entra, aplicativos e serviços da Microsoft, como o Office 365.
As funções Microsoft Entra e RBAC do Azure se integram ao Microsoft Entra Privileged Identity Management para habilitar políticas de ativação just-in-time, como fluxo de trabalho de aprovação e MFA.
ABAC e atribuições de função no Azure
O ABAC (controle de acesso baseado em atributo) é um sistema de autorização que define o acesso com base em atributos associados a entidades de segurança, recursos e ambiente. Com o ABAC, você pode conceder acesso de entidade de segurança a um recurso com base em atributos. O ABAC do Azure refere-se à implementação do ABAC para Azure.
O ABAC do Azure baseia-se no RBAC do Azure pela adição de condições de atribuição de função com base em atributos no contexto de ações específicas. Uma condição de atribuição de função é uma verificação adicional que você pode opcionalmente adicionar à atribuição de função para fornecer controle de acesso mais refinado. Uma condição filtra as permissões concedidas como parte da definição de função e da atribuição de função. Por exemplo, você pode adicionar uma condição que exige que um objeto tenha uma marca específica para ler o objeto. Não é possível negar explicitamente o acesso a recursos específicos usando condições.
Acesso Condicional
O acesso condicional do Microsoft Entra pode ser usado para gerenciar o acesso aos pontos de extremidade de gerenciamento do Azure. As políticas de Acesso Condicional podem ser aplicadas ao aplicativo de nuvem API de Gerenciamento de Serviços do Windows Azure para proteger os pontos de extremidade de gerenciamento de recursos do Azure, como:
Provedor do Azure Resource Manager (serviços)
APIs do Azure Resource Manager
Azure PowerShell
CLI do Azure
Portal do Azure
Por exemplo, um administrador pode configurar uma política de acesso condicional, que permite que um usuário entre no portal do Azure somente de locais aprovados e também requer autenticação multifator (MFA) ou um dispositivo híbrido ingressado no domínio do Microsoft Entra.
Identidades gerenciadas do Azure
Um desafio comum ao criar aplicativos de nuvem é como gerenciar as credenciais no código para autenticar serviços de nuvem. Proteger as credenciais é uma tarefa importante. O ideal é que as credenciais nunca apareçam em estações de trabalho do desenvolvedor e não sejam verificadas no controle de origem. As Identidades gerenciadas para recursos do Azure fornecem aos serviços do Azure uma identidade gerenciada automaticamente na ID do Microsoft Entra. Você pode usar a identidade para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem nenhuma credencial em seu código.
Há dois tipos de identidades gerenciadas:
Uma identidade gerenciada atribuída pelo sistema é habilitada diretamente em um recurso do Azure. Quando o recurso está habilitado, o Azure cria uma identidade para o recurso no locatário confiável do Microsoft Entra da assinatura associada. Depois que a identidade é criada, as credenciais são provisionadas para o recurso. O ciclo de vida de uma identidade atribuída ao sistema está diretamente associado ao recurso do Azure. Se o recurso for excluído, o Azure limpará automaticamente as credenciais e a identidade na ID do Microsoft Entra.
Uma identidade gerenciada atribuída pelo usuário é criada como um recurso autônomo do Azure. O Azure cria uma identidade no locatário do Microsoft Entra confiável pela assinatura à qual o recurso está associado. Depois que a identidade é criada, ela pode ser atribuída a um ou mais recursos do Azure. O ciclo de vida de uma identidade atribuída pelo usuário é gerenciado separadamente do ciclo de vida dos recursos do Azure aos quais ela está atribuída.
Internamente, as identidades gerenciadas são entidades de serviço de um tipo especial, que só podem ser usadas por recursos específicos do Azure. Quando a identidade gerenciada é excluída, a entidade de serviço correspondente é removida automaticamente. Note que a autorização de permissões de API do Graph só pode ser feita pelo PowerShell, portanto, nem todos os recursos da Identidade Gerenciada são acessíveis por meio da interface do usuário do Portal.
Serviços de Domínio do Microsoft Entra
O Microsoft Entra Domain Services fornece um domínio gerenciado para facilitar a autenticação de cargas de trabalho do Azure usando protocolos herdados. Os servidores com suporte são movidos de uma floresta AD DS local e ingressados em um domínio gerenciado do Microsoft Entra Domain Services e continuam a usar protocolos herdados para autenticação (por exemplo, autenticação Kerberos).
Diretórios do Azure AD B2C e Azure
Um locatário do Azure AD B2C está vinculado a uma assinatura do Azure para fins de cobrança e comunicação. Os locatários do Azure AD B2C têm uma estrutura de função autocontida no diretório, que é independente das funções privilegiadas do RBAC do Azure da assinatura do Azure.
Quando o locatário do Azure AD B2C é provisionado inicialmente, o usuário que cria o locatário do B2C deve ter permissões de colaborador ou proprietário na assinatura. Posteriormente, eles podem criar outras contas e atribuí-las a funções de diretório. Para obter mais informações, confira Visão geral do controle de acesso baseado em função no Microsoft Entra ID.
É importante observar que os proprietários e colaboradores da assinatura vinculada do Microsoft Entra podem remover o link entre a assinatura e o diretório, o que afetará a cobrança contínua do uso do Azure AD B2C.
Considerações de identidade para soluções de IaaS no Azure
Esse cenário aborda os requisitos de isolamento de identidade que as organizações têm para cargas de trabalho de IaaS (infraestrutura como serviço).
Há três opções principais sobre o gerenciamento de isolamento de cargas de trabalho IaaS:
Máquinas virtuais unidas ao AD DS (Active Directory Domain Services autônomo)
Máquinas virtuais ingressadas no Microsoft Entra Domain Services
Entrar em máquinas virtuais no Azure usando a autenticação do Microsoft Entra
Um conceito fundamental a ser abordado com as duas primeiras opções é que há dois realms de identidade envolvidos nesses cenários.
Quando você entra em uma VM do Windows Server do Azure por meio do protocolo RDP (protocolo de área de trabalho remota), geralmente está fazendo logon no servidor usando suas credenciais de domínio, que executa uma autenticação Kerberos em um controlador de domínio AD DS local ou no Microsoft Entra Domain Services. Como alternativa, se o servidor não estiver conectado ao domínio, uma conta local poderá ser usada para entrar nas máquinas virtuais.
Quando você entra no portal do Azure para criar ou gerenciar uma VM, você está autenticando na ID do Microsoft Entra (potencialmente usando as mesmas credenciais se tiver sincronizado as contas corretas), e isso pode resultar em uma autenticação em seus controladores de domínio caso você esteja usando os Serviços de Federação do Active Directory (AD FS) ou a Autenticação de Passagem.
Máquinas virtuais ingressadas no Active Directory Domain Services autônomo
O AD DS é o serviço de diretório baseado no Windows Server que as organizações adotaram em grande parte para serviços de identidade locais. O AD DS pode ser implantado quando existe um requisito para implantar cargas de trabalho de IaaS no Azure que exigem isolamento de identidade de administradores e usuários do AD DS em outra floresta.
As seguintes considerações precisam ser feitas neste cenário:
Controladores de domínio do AD DS: um mínimo de dois controladores de domínio do AD DS devem ser implantados para garantir que os serviços de autenticação estejam altamente disponíveis e funcionais. Para obter mais informações, consulte Design e planejamento do AD DS.
Design e Planejamento do AD DS – Uma nova floresta do AD DS deve ser criada com os seguintes serviços configurados corretamente:
DNS (Serviços de Nomes de Domínio) do AD DS – O DNS do AD DS deve ser configurado para as zonas relevantes dentro do AD DS para garantir que a resolução de nomes funcione corretamente para servidores e aplicativos.
Sites e Serviços do AD DS – Esses serviços devem ser configurados para garantir que os aplicativos tenham baixa latência e acesso com desempenho aos controladores de domínio. As redes virtuais relevantes, sub-redes e locais de data center nos quais os servidores estão localizados devem ser configurados em sites e serviços.
FSMOs do AD DS – As funções FSMO (Flexible Single Master Operation) que são necessárias devem ser revisadas e atribuídas aos controladores de domínio do AD DS apropriados.
Ingresso no domínio do AD DS – Todos os servidores (excluindo "jumpboxes") que exigem o AD DS para autenticação, configuração e gerenciamento precisam ser ingressados na floresta isolada.
GPO (Política de Grupo) do AD DS – Os GPOs do AD DS devem ser configurados para garantir que a configuração atenda aos requisitos de segurança e que a configuração seja padronizada entre os computadores ingressados na floresta e conectados ao domínio.
UO (Unidades Organizacionais) do AD DS – As OUs do AD DS devem ser definidas para garantir o agrupamento de recursos do AD DS em silos de configuração e gerenciamento lógico para fins de administração e aplicação de configuração.
Controle de acesso baseado em função – O RBAC deve ser definido para administração e acesso aos recursos ingressados nessa floresta. Isso inclui:
Grupos do AD DS – Os grupos devem ser criados para aplicar permissões apropriadas para usuários aos recursos do AD DS.
Contas de administração – Conforme mencionado no início desta seção, há duas contas de administração necessárias para gerenciar essa solução.
Uma conta de administração do AD DS com o acesso menos privilegiado necessário para executar a administração necessária no AD DS e servidores conectados ao domínio.
Uma conta de administração do Microsoft Entra para acesso ao portal do Azure para conectar, gerenciar e configurar máquinas virtuais, redes virtuais, grupos de segurança de rede e outros recursos necessários do Azure.
Contas de usuário do AD DS – Contas de usuário relevantes precisam ser provisionadas e adicionadas aos grupos corretos para permitir o acesso do usuário a aplicativos hospedados por essa solução.
Redes virtuais (VNets) – Diretrizes de configuração
Endereço IP do controlador de domínio do AD DS – Os controladores de domínio não devem ser configurados com endereços IP estáticos dentro do sistema operacional. Os endereços IP devem ser reservados na VNet do Azure para garantir que eles sempre permaneçam iguais e se o DC deve ser configurado para usar DHCP.
Servidor DNS da VNet – Os servidores DNS devem ser configurados em VNets que fazem parte dessa solução isolada para apontar para os controladores de domínio. Isso é necessário para garantir que aplicativos e servidores possam resolver os serviços do AD DS necessários ou outros serviços ingressados na floresta do AD DS.
NSGs (grupos de segurança de rede) – Os controladores de domínio devem estar localizados em sua própria VNet ou sub-rede com NSGs definidos para permitir apenas o acesso a controladores de domínio por meio de servidores necessários (por exemplo, computadores conectados ao domínio ou jumpboxes). As jumpboxes devem ser adicionadas a um ASG (grupo de segurança de aplicativo) para simplificar a criação e a administração do NSG.
Desafios: a lista a seguir destaca os principais desafios com o uso dessa opção para isolamento de identidade:
Uma floresta AD DS adicional para administrar, gerenciar e monitorar resultando em mais trabalho para a equipe de TI executar.
Outra infraestrutura pode ser necessária para gerenciamento de implantações de patch e software. As organizações devem considerar a implantação do Gerenciamento de Atualizações do Azure, GPO (Política de Grupo) ou SCCM (System Center Configuration Manager) para gerenciar esses servidores.
Credenciais adicionais para os usuários lembrarem e usarem para acessar recursos.
Importante
Para esse modelo isolado, supõe-se que não haja conectividade de ou para os controladores de domínio da rede corporativa do cliente e que não haja nenhuma relação de confiança configurada com outras florestas. Um servidor de gerenciamento ou jumpbox deve ser criado para permitir um ponto do qual os controladores de domínio do AD DS podem ser gerenciados e administrados.
Máquinas virtuais ingressadas no Microsoft Entra Domain Services
Quando existe um requisito para implantar cargas de trabalho de IaaS no Azure que exigem isolamento de identidade de administradores e usuários do AD DS em outra floresta, um domínio gerenciado do Microsoft Entra Domain Services pode ser implantado. O Microsoft Entra Domain Services é um serviço que fornece um domínio gerenciado para facilitar a autenticação de cargas de trabalho do Azure usando protocolos herdados. Isso fornece um domínio isolado sem as complexidades técnicas da criação e do gerenciamento do seu próprio AD DS. As seguintes considerações precisam ser feitas.
Domínio gerenciado do Microsoft Entra Domain Services - Somente um domínio gerenciado do Microsoft Entra Domain Services pode ser implantado por locatário do Microsoft Entra e isso está vinculado a uma única rede virtual. É recomendável que essa rede virtual forme o "hub" para autenticação do Microsoft Entra Domain Services. Nesse hub, "spokes" podem ser criados e vinculados para permitir a autenticação herdada para servidores e aplicativos. Os spokes são VNets adicionais nas quais os servidores ingressados no Microsoft Entra Domain Services estão localizados e estão vinculados ao hub usando gateways de rede do Azure ou emparelhamento de VNet.
Local do domínio gerenciado - Um local deve ser definido ao implantar um domínio gerenciado do Microsoft Entra Domain Services. O local é uma região física (data center) onde o domínio gerenciado é implantado. É recomendável que você:
Considere um local geograficamente fechado para os servidores e aplicativos que exigem serviços do Microsoft Entra Domain Services.
Considere as regiões que fornecem recursos de Zonas de Disponibilidade para requisitos de alta disponibilidade. Para obter mais informações, confira Regiões e Zonas de Disponibilidade no Azure.
Provisionamento de objetos - O Microsoft Entra Domain Services sincroniza identidades do Microsoft Entra ID associada à assinatura na qual o Microsoft Entra Domain Services é implantado. Também vale a pena observar que, se o Microsoft Entra ID associada tiver sincronização configurada com o Microsoft Entra Connect (cenário de floresta do usuário), o ciclo de vida dessas identidades também poderá ser refletido no Microsoft Entra Domain Services. Esse serviço tem dois modos que podem ser usados para provisionar objetos de usuário e grupo da ID do Microsoft Entra.
Todos: todos os usuários e grupos são sincronizados Microsoft Entra ID para o Microsoft Entra Domain Services.
Escopo: somente os usuários no escopo de um grupo são sincronizados do Microsoft Entra ID para o Microsoft Entra Domain Services.
Quando você implanta o Microsoft Entra Domain Services pela primeira vez, uma sincronização unidirecional automática é configurada para replicar os objetos do Microsoft Entra ID. Essa sincronização unidirecional continua a ser executada em segundo plano para manter o domínio gerenciado do Microsoft Entra Domain Services atualizado com quaisquer alterações do Microsoft Entra ID. Nenhuma sincronização ocorre do Microsoft Entra Domain Services de volta para o Microsoft Entra ID. Para obter mais informações, consulte Como objetos e credenciais são sincronizados em um domínio gerenciado do Microsoft Entra Domain Services.
Vale a pena observar que, se você precisar alterar o tipo de sincronização de Todos para Escopo (ou vice-versa), o domínio gerenciado do Microsoft Entra Domain Services precisará ser excluído, recriado e configurado. Além disso, as organizações devem considerar o uso de provisionamento "com escopo" para reduzir as identidades apenas àquelas que precisam de acesso aos recursos do Microsoft Entra Domain Services como uma boa prática.
GPO (Objetos de Política de Grupo) - Para configurar o GPO em um domínio gerenciado do Microsoft Entra Domain Services, você deve usar as ferramentas de Gerenciamento de Política de Grupo em um servidor que tenha ingressado no domínio gerenciado do Microsoft Entra Domain Services. Para obter mais informações, consulte Administrar política de grupo em um domínio gerenciado do Microsoft Entra Domain Services.
LDAP Seguro - O Microsoft Entra Domain Services fornece um serviço LDAP seguro que pode ser usado por aplicativos que o exigem. Essa configuração está desabilitada por padrão e, para habilitar o LDAP seguro, um certificado precisa ser carregado, além disso, o NSG que protege a rede virtual na qual o Microsoft Entra Domain Services está implantado deve permitir a conectividade da porta 636 com os domínios gerenciados do Microsoft Entra Domain Services. Para obter mais informações, consulte Configurar LDAP seguro para um domínio gerenciado do Microsoft Entra Domain Services.
Administração - Para executar tarefas de administração no Microsoft Entra Domain Services (por exemplo, ingressar em máquinas de ingresso no domínio ou editar GPO), a conta usada para essa tarefa precisa fazer parte do grupo Administradores de DC do Microsoft Entra. As contas que são membros desse grupo não podem se conectar diretamente aos controladores de domínio para executar tarefas de gerenciamento. Em vez disso, você cria uma VM de gerenciamento que ingressou no domínio gerenciado do Microsoft Entra Domain Services e, em seguida, instala suas ferramentas de gerenciamento regulares do AD DS. Para obter mais informações, consulte Conceitos de gerenciamento para contas de usuário, senhas e administração no Microsoft Entra Domain Services.
Hashes de senha - para que a autenticação com o Microsoft Entra Domain Services funcione, os hashes de senha para todos os usuários precisam estar em um formato adequado para autenticação NT LAN Manager (NTLM) e Kerberos. Para garantir que a autenticação com o Microsoft Entra Domain Services funcione conforme o esperado, os seguintes pré-requisitos precisam ser executados.
Usuários sincronizados com o Microsoft Entra Connect (do AD DS) - Os hashes de senha herdados precisam ser sincronizados do AD DS local para a ID do Microsoft Entra.
Usuários criados no Microsoft Entra ID - precisam redefinir sua senha para que os hashes corretos sejam gerados para uso com o Microsoft Entra Domain Services. Para obter mais informações, consulte Habilitar a sincronização de hashes de senha.
Rede - O Microsoft Entra Domain Services é implantado em uma rede virtual do Azure, portanto, é necessário fazer considerações para garantir que os servidores e aplicativos estejam protegidos e possam acessar o domínio gerenciado corretamente. Para obter mais informações, consulte Considerações sobre design de rede virtual e opções de configuração para os Serviços de Domínio do Microsoft Entra.
O Microsoft Entra Domain Services deve ser implantado em sua própria sub-rede: não use uma sub-rede existente ou uma sub-rede de gateway.
Um grupo de segurança de rede (NSG) - é criado durante a implantação de um domínio gerenciado do Microsoft Entra Domain Services. Esse grupo de segurança de rede contém as regras necessárias para a comunicação correta do serviço. Não crie nem use um grupo de segurança de rede existente com suas próprias regras personalizadas.
O Microsoft Entra Domain Services requer 3-5 endereços IP - certifique-se de que o intervalo de endereços IP da sub-rede pode fornecer esse número de endereços. Restringir os endereços IP disponíveis pode impedir que o Microsoft Entra Domain Services mantenha dois controladores de domínio.
Servidor de DNS de rede virtual - conforme discutido anteriormente sobre o modelo "hub and spoke", é importante ter o DNS configurado corretamente nas redes virtuais para garantir que os servidores ingressados no domínio gerenciado do Microsoft Entra Domain Services tenham as configurações de DNS corretas para resolver o domínio gerenciado do Microsoft Entra Domain Services. Cada rede virtual tem uma entrada de servidor DNS que é passada para os servidores à medida que eles obtêm um endereço IP e essas entradas DNS precisam ser os endereços IP do domínio gerenciado do Microsoft Entra Domain Services. Para obter mais informações, consulte Atualizar as configurações de DNS para a rede virtual do Azure.
Desafios – A lista a seguir destaca os principais desafios com o uso dessa opção para Isolamento de Identidade.
Algumas configurações do Microsoft Entra Domain Services só podem ser administradas a partir de um servidor ingressado no Microsoft Entra Domain Services.
Somente um domínio gerenciado do Microsoft Entra Domain Services pode ser implantado por locatário do Microsoft Entra. Como descrevemos nesta seção, o modelo hub e spoke é recomendado para fornecer autenticação do Microsoft Entra Domain Services para serviços em outras VNets.
Outra infraestrutura pode ser necessária para gerenciamento de implantações de aplicação de patch e software. As organizações devem considerar a implantação do Gerenciamento de Atualizações do Azure, GPO (Política de Grupo) ou SCCM (System Center Configuration Manager) para gerenciar esses servidores.
Para esse modelo isolado, presume-se que não há conectividade com a rede virtual que hospeda o domínio gerenciado do Microsoft Entra Domain Services da rede corporativa do cliente e que não há relações de confiança configuradas com outras florestas. Um jumpbox ou servidor de gerenciamento deve ser criado para permitir um ponto a partir do qual o Microsoft Entra Domain Services pode ser gerenciado e administrado.
Entrar em máquinas virtuais no Azure usando a autenticação do Microsoft Entra
Quando existe um requisito para implantar cargas de trabalho IaaS no Azure que exigem isolamento de identidade, a opção final é usar a ID do Microsoft Entra para fazer logon em servidores nesse cenário. Isso fornece a capacidade de tornar a ID do Microsoft Entra o território de identidade para fins de autenticação e o isolamento de identidade pode ser obtido provisionando os servidores na assinatura relevante, que está vinculada ao locatário necessário do Microsoft Entra. As seguintes considerações precisam ser feitas.
Sistemas operacionais com suporte: atualmente há suporte para entrar em máquinas virtuais no Azure usando a autenticação do Microsoft Entra no Windows e no Linux. Para obter mais detalhes sobre sistemas operacionais com suporte, consulte a documentação para Windows e Linux.
Credenciais: um dos principais benefícios de entrar em máquinas virtuais no Azure usando a autenticação do Microsoft Entra é a capacidade de usar as mesmas credenciais federadas ou gerenciadas do Microsoft Entra que você normalmente usa para acessar os serviços do Microsoft Entra para entrar na máquina virtual.
Observação
O locatário do Microsoft Entra usado para entrar nesse cenário é o locatário do Microsoft Entra associado à assinatura na qual a máquina virtual foi provisionada. Esse locatário do Microsoft Entra pode ser um que tenha identidades sincronizadas do AD DS local. As organizações devem fazer uma escolha informada que se alinhe com suas entidades de isolamento ao escolher qual assinatura e locatário do Microsoft Entra desejam usar para entrar nesses servidores.
Requisitos de rede: essas máquinas virtuais precisarão acessar a ID do Microsoft Entra para autenticação, portanto, você deve garantir que a configuração de rede das máquinas virtuais permita o acesso de saída aos pontos de extremidade do Microsoft Entra no 443. Confira a documentação do Windows e do Linux para obter mais informações.
RBAC (controle de acesso baseado em função): duas funções RBAC estão disponíveis para fornecer o nível apropriado de acesso a essas máquinas virtuais. Essas funções RBAC podem ser configuradas por meio do portal do Azure ou da Experiência do Azure Cloud Shell. Para obter mais informações, consulte Configurar atribuições de função para a VM.
Logon de administrador da máquina virtual: os usuários com essa função atribuída podem fazer logon em uma máquina virtual do Azure com privilégios de administrador.
Logon de usuário da máquina virtual: os usuários com essa função atribuída podem fazer logon uma máquina virtual do Azure com privilégios de usuários regulares.
Acesso condicional: um dos principais benefícios de usar a ID do Microsoft Entra para entrar em máquinas virtuais do Azure é a capacidade de impor o Acesso Condicional como parte do processo de entrada. Isso fornece a capacidade de as organizações exigirem que as condições sejam atendidas antes de permitir o acesso à máquina virtual e usar a autenticação multifator para fornecer autenticação forte. Para obter mais informações, consulte Uso de Acesso Condicional.
Observação
A conexão remota com máquinas virtuais associadas à ID do Microsoft Entra só é permitida a partir de PCs com Windows 10, Windows 11 e Cloud PC que tenham ingressado no Microsoft Entra ou que tenham ingressado no Microsoft Entra híbrido no mesmo diretório que a máquina virtual.
Desafios: a lista a seguir destaca os principais desafios com o uso dessa opção para Isolamento de Identidade.
Nenhum gerenciamento central ou configuração de servidores. Por exemplo, não há Política de Grupo que possa ser aplicada a um grupo de servidores. As organizações devem considerar a implantação do Gerenciamento de Atualizações no Azure para gerenciar a aplicação de patch e atualizações desses servidores.
Não é adequado para aplicativos de várias camadas que têm requisitos para autenticação com mecanismos locais, como a Autenticação Integrada do Windows, nesses servidores ou serviços. Se esse for um requisito para a organização, é recomendável que você explore os cenários Autônomos dos Serviços de Domínio Active Directory ou do Microsoft Entra Domain Services descritos nessa seção.
Para esse modelo isolado, supõe-se que não haja conectividade com a VNet que hospeda as máquinas virtuais da rede corporativa do cliente. Um servidor de gerenciamento ou jumpbox deve ser criado para permitir um ponto do qual esses servidores possa ser gerenciado e administrado.