Fundamentos de gerenciamento de recursos do Azure
É importante entender a estrutura e os termos específicos dos recursos do Azure. A imagem a seguir mostra um exemplo dos quatro níveis de escopo fornecidos pelo Azure:
Terminologia
A seguir estão alguns dos termos com os quais você deve estar familiarizado:
Recurso - um item gerível que está disponível através do Azure. Máquinas virtuais, contas de armazenamento, aplicações Web, bases 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, redes virtuais associadas e balanceadores de carga que exigem gerenciamento por equipes específicas. O grupo de recursos inclui os recursos que você deseja gerenciar como um grupo. Decide que recursos pertencem a um grupo de recursos com base no que faz mais sentido para a 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.
Subscrição - Do ponto de vista da hierarquia organizacional, uma subscrição é um contentor de faturação e gestão de recursos e grupos de recursos. Uma subscrição do Azure tem uma relação de confiança com uma instância do Microsoft Entra ID. Uma subscrição confia no Microsoft Entra ID para autenticar utilizadores, serviços e dispositivos.
Nota
Uma assinatura pode confiar apenas em 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 escopos diferentes acima das assinaturas. Ele pode estar no grupo de gerenciamento raiz do locatário (escopo mais alto) ou em níveis inferiores na hierarquia. Estes permitem-lhe organizar as subscrições em contentores chamados "grupos de gestão" e aplicar as suas condições de governação aos grupos de gestão. Todas as subscrições num grupo de gestão herdam automaticamente as condições aplicadas ao grupo de gestão. 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 de máquina virtual. Microsoft. O armazenamento é outro provedor de recursos comum.
Modelo do Gerenciador de Recursos - Um arquivo JSON (JavaScript Object Notation) que define um ou mais recursos a serem implantados em um grupo de recursos, assinatura, locatário ou grupo de gerenciamento. O modelo pode ser utilizado para implementar os recursos de forma consistente e repetida. Consulte Visão geral da implantação do modelo. Além disso, a linguagem Bicep pode ser usada em vez de JSON.
Modelo de Gerenciamento de Recursos do Azure
Cada assinatura do Azure está associada a controles usados pelo Azure Resource Manager. O Resource Manager é o serviço de implantação e gerenciamento do Azure, tem uma relação de confiança com a ID do Microsoft Entra para gerenciamento de identidades para organizações e a Conta da 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. Você usa recursos de gerenciamento, como controle de acesso, bloqueios e tags, para proteger e organizar seus recursos após a implantação.
Nota
Antes do ARM, havia outro modelo de implantação chamado Azure Service Manager (ASM) ou "clássico". Para saber mais, consulte Azure Resource Manager vs. implantação clássica. O gerenciamento de ambientes com o modelo ASM está fora do escopo deste conteúdo.
O Azure Resource Manager é o serviço front-end, que hospeda as APIs REST usadas pelo PowerShell, pelo portal do Azure ou por outros clientes para gerenciar recursos. Quando um cliente faz uma solicitação para gerenciar um recurso específico, o Gerenciador de Recursos faz o proxy da solicitação para o 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 Gerenciador de Recursos fará o proxy da solicitação para a Microsoft. Provedor de recursos de computação. O Gerenciador de Recursos requer que o cliente especifique um identificador para a assinatura e o grupo de recursos para gerenciar o recurso de máquina virtual.
Antes que qualquer solicitação de gerenciamento de recursos possa ser executada pelo Gerenciador de Recursos, 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 de usuário - As permissões são atribuídas aos usuários usando o controle de acesso baseado em função (RBAC). Uma função RBAC especifica um conjunto de permissões que um usuário pode assumir 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) para implantar um tipo específico de máquina virtual.
O diagrama a seguir resume o modelo de recursos que acabamos de descrever.
Azure Lighthouse - O Azure Lighthouse permite o gerenciamento de recursos entre locatários. As organizações podem delegar funções no nível da assinatura ou do grupo de recursos a identidades em outro locatário.
As assinaturas que habilitam o gerenciamento delegado de recursos 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 de recursos para identidades no locatário do provedor de serviços. No tempo de execução, 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 os aspetos 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 Provedores de Serviços Gerenciados (MSPs) a proteger e gerenciar dispositivos, dados e usuários em escala para clientes de pequenas e médias empresas (SMB) que usam o Microsoft 365 Business Premium, Microsoft 365 E3 ou Windows 365 Business.
Gerenciamento de recursos do Azure com o Microsoft Entra ID
Agora que você tem uma melhor compreensão do modelo de gerenciamento de recursos no Azure, vamos examinar brevemente alguns dos recursos do Microsoft Entra ID que podem fornecer gerenciamento de identidade e acesso para recursos do Azure.
Faturação
A faturação é importante para a gestão de recursos porque algumas funções de faturação interagem ou podem gerir recursos. A cobrança funciona de forma diferente dependendo do tipo de contrato que você tem com a Microsoft.
Azure Enterprise Agreements
Os clientes do Azure Enterprise Agreement (Azure EA) são integrados ao Portal do Azure EA após a execução do contrato comercial com a Microsoft. Ao integrar, uma identidade é associada a uma função de faturamento "raiz" do Administrador Corporativo. O portal fornece uma hierarquia de funções de gestão:
Os departamentos ajudam a segmentar os custos em agrupamentos lógicos e permitem que você defina um orçamento ou cota no nível do departamento.
As contas são usadas para segmentar ainda mais os departamentos. Pode utilizar contas para gerir subscrições e aceder a relatórios. O portal EA pode autorizar Contas Microsoft (MSA) ou contas Microsoft Entra (identificadas no portal como "Contas Profissionais ou Escolares"). As identidades com a função de "Proprietário da conta" no portal da EA podem criar assinaturas do Azure.
Faturação empresarial e inquilinos do Microsoft Entra
Quando um Proprietário de Conta cria uma assinatura do Azure dentro de um contrato enterprise, o gerenciamento de identidade e acesso 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 EA do Azure atribui funções do Azure Service Manager (ASM) ou "clássicas" para gerenciar assinaturas. Para saber mais, consulte Azure Resource Manager vs. implantação clássica.)
Um contrato empresarial pode ser configurado para dar suporte a vários locatários definindo o tipo de autenticação de "Locatário cruzado de conta corporativa ou de estudante" no Portal EA do Azure. Dado o 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 ao Proprietário da Conta EA do Azure privilégios para gerenciar os recursos em quaisquer assinaturas criadas. Para assinaturas com cargas de trabalho de produção, considere dissociar o gerenciamento de faturamento e recursos alterando o administrador de serviço da assinatura logo após a criação.
Para dissociar ainda mais e impedir que o proprietário da conta recupere o acesso de administrador de serviço à 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 é 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 inscritos com um Contrato de Cliente Microsoft (MCA) têm um sistema de gerenciamento de cobrança diferente com suas próprias funções.
Uma conta de cobrança do Contrato de Cliente Microsoft contém um ou mais perfis de cobrança que permitem gerenciar faturas e métodos de pagamento. Cada perfil de faturamento contém uma ou mais seções de fatura para organizar os custos na fatura do perfil de faturamento.
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 corporativa foram movidas para o locatário ContosoSandbox após a criação.
RBAC e atribuições de função no Azure
Na seção Fundamentos do Microsoft Entra, você aprendeu que o RBAC do Azure é 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 RBAC a objetos que solicitam acesso aos recursos do Azure.
As funções do Microsoft Entra operam em conceitos como o 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 aos 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 do Microsoft Entra e do Azure RBAC integram-se 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 controle de acesso baseado em atributos (ABAC) é 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 a uma entidade de segurança acesso a um recurso com base em atributos. Azure ABAC refere-se à implementação do ABAC para Azure.
O Azure ABAC baseia-se no Azure RBAC adicionando 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 à sua atribuição de função para fornecer um controle de acesso mais refinado. Uma condição filtra as permissões concedidas como parte da definição e atribuição de função. Por exemplo, você pode adicionar uma condição que exija que um objeto tenha uma tag 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 da API de Gerenciamento de Serviços do Windows Azure para proteger os pontos de extremidade de gerenciamento de recursos do Azure, como:
Azure Resource Manager Provider (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 associado ao domínio Microsoft Entra.
Identidades gerenciadas do Azure
Um desafio comum inerente à criação de aplicações na cloud passa pela gestão das credenciais que estão no seu código para a autenticação nos serviços cloud. Manter essas credenciais protegidas é uma tarefa importante. Idealmente, nunca aparecem nas estações de trabalho dos programadores nem são verificadas no controlo de origem. As identidades gerenciadas para recursos do Azure fornecem aos serviços do Azure uma identidade gerenciada automaticamente no Microsoft Entra ID. Você pode usar a identidade para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra sem credenciais em seu código.
Existem dois tipos de identidades geridas:
Uma identidade gerenciada atribuída ao sistema é habilitada diretamente em um recurso do Azure. Quando o recurso é 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 no recurso. O ciclo de vida de uma identidade atribuída pelo sistema está diretamente ligado 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 gerida atribuída pelo utilizador, que é criada como um recurso do Azure autónomo. 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 é atribuída.
Internamente, as identidades gerenciadas são entidades de serviço de um tipo especial, para serem usadas apenas por recursos específicos do Azure. Quando a identidade gerenciada é excluída, a entidade de serviço correspondente é removida automaticamente. Não, a autorização das permissões da 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.
Microsoft Entra Domain Services
Os Serviços de Domínio do Microsoft Entra fornecem um domínio gerenciado para facilitar a autenticação de cargas de trabalho do Azure usando protocolos herdados. Os servidores suportados são movidos de uma floresta AD DS local e ingressados em um domínio gerenciado dos Serviços de Domínio Microsoft Entra 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 independente 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 é inicialmente provisionado, o usuário que cria o locatário B2C deve ter permissões de colaborador ou proprietário na assinatura. Após a criação, esse usuário se torna o primeiro Administrador Global de locatário do Azure AD B2C e pode posteriormente criar outras contas e atribuí-las a funções de diretório.
É 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 IaaS no Azure
Este cenário abrange os requisitos de isolamento de identidade que as organizações têm para cargas de trabalho de infraestrutura como serviço (IaaS).
Há três opções principais em relação ao gerenciamento de isolamento de cargas de trabalho IaaS:
Máquinas virtuais associadas aos Serviços de Domínio Ative Directory (AD DS) autónomos
Máquinas virtuais ingressadas nos Serviços de Domínio Microsoft Entra
Entrar em máquinas virtuais no Azure usando a autenticação do Microsoft Entra
Um conceito-chave a ser abordado com as duas primeiras opções é que há dois reinos 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 nos Serviços de Domínio Microsoft Entra. Como alternativa, se o servidor não estiver associado ao domínio, uma conta local poderá ser usada para entrar nas máquinas virtuais.
Quando inicia sessão no portal do Azure para criar ou gerir uma VM, está a autenticar-se com base no Microsoft Entra ID (potencialmente utilizando as mesmas credenciais se tiver sincronizado as contas corretas), e isso pode resultar numa autenticação nos controladores de domínio, caso esteja a utilizar os Serviços de Federação do Ative Directory (AD FS) ou a Autenticação de Passagem.
Máquinas virtuais unidas aos Serviços de Domínio Ative Directory autônomos
O AD DS é o serviço de diretório baseado no Windows Server que as organizações adotaram amplamente para serviços de identidade locais. O AD DS pode ser implantado quando existe um requisito para implantar cargas de trabalho 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 nesse 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 tenham desempenho. 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:
Serviços de Nomes de Domínio (DNS) DO AD DS - O DNS AD DS deve ser configurado para as zonas relevantes no 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 de alto desempenho aos controladores de domínio. As redes virtuais, sub-redes e locais de data center relevantes 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) 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 (exceto "jumpboxes") que exigem o AD DS para autenticação, configuração e gerenciamento precisam ser associados à floresta isolada.
Política de Grupo do AD DS (GPO) - 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 na floresta e nas máquinas associadas ao domínio.
Unidades Organizacionais (UO) do AD DS - As UOs do AD DS devem ser definidas para garantir o agrupamento de recursos do AD DS em silos lógicos de gerenciamento e configuração para fins de administração e aplicação da configuração.
Controle de acesso baseado em função - O RBAC deve ser definido para administração e acesso aos recursos associados a essa floresta. O que está incluído:
Grupos do AD DS - Os grupos devem ser criados para aplicar permissões apropriadas aos usuários aos recursos do AD DS.
Contas de administração - Como mencionado no início desta seção, há duas contas de administração necessárias para gerenciar esta solução.
Uma conta de administração do AD DS com o acesso menos privilegiado necessário para executar a administração exigida no AD DS e nos servidores associados 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 - As contas de usuário relevantes precisam ser provisionadas e adicionadas aos grupos corretos para permitir o acesso do usuário aos aplicativos hospedados por esta solução.
Redes virtuais (VNets) - Orientações de configuração
Endereço IP do controlador de domínio AD DS - Os controladores de domínio não devem ser configurados com endereços IP estáticos no sistema operacional. Os endereços IP devem ser reservados na VNet do Azure para garantir que permaneçam sempre os mesmos e o DC deve ser configurado para usar DHCP.
Servidor DNS VNet - Os servidores DNS devem ser configurados em redes virtuais que fazem parte desta solução isolada para apontar para os controladores de domínio. Isso é necessário para garantir que os aplicativos e servidores possam resolver os serviços do AD DS necessários ou outros serviços ingressados na floresta do AD DS.
Grupos de segurança de rede (NSGs) - Os controladores de domínio devem estar localizados em sua própria VNet ou sub-rede com NSGs definidos para permitir o acesso apenas aos controladores de domínio a partir dos servidores necessários (por exemplo, máquinas ingressadas no domínio ou jumpboxes). Jumpboxes devem ser adicionadas a um grupo de segurança de aplicativo (ASG) para simplificar a criação e administração do NSG.
Desafios: A lista abaixo destaca os principais desafios do 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.
Pode ser necessária mais infraestrutura para o gerenciamento de patches e implantações de software. As organizações devem considerar a implantação do Azure Update Management, da Política de Grupo (GPO) ou do System Center Configuration Manager (SCCM) 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 há conectividade de ou para os controladores de domínio 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 os controladores de domínio do AD DS possam ser gerenciados e administrados.
Máquinas virtuais ingressadas nos Serviços de Domínio Microsoft Entra
Quando existe um requisito para implantar cargas de trabalho IaaS no Azure que exigem isolamento de identidade de administradores e usuários do AD DS em outra floresta, um domínio gerenciado dos Serviços de Domínio Microsoft Entra pode ser implantado. Os Serviços de Domínio Microsoft Entra são 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 de criar e gerenciar seu próprio AD DS. Impõem-se as seguintes considerações.
Domínio gerenciado dos Serviços de Domínio Microsoft Entra - Apenas um domínio gerenciado dos Serviços de Domínio Microsoft Entra pode ser implantado por locatário do Microsoft Entra e isso está vinculado a uma única VNet. É recomendável que essa VNet forme o "hub" para a autenticação dos Serviços de Domínio do Microsoft Entra. A partir deste hub, "spokes" podem ser criados e vinculados para permitir a autenticação herdada para servidores e aplicativos. Os raios são VNets adicionais nas quais os servidores ingressados nos Serviços de Domínio Microsoft Entra 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 dos Serviços de Domínio Microsoft Entra. O local é uma região física (data center) onde o domínio gerenciado é implantado. Recomenda-se:
Considere um local geograficamente fechado para os servidores e aplicativos que exigem serviços dos Serviços de Domínio Microsoft Entra.
Considere regiões que fornecem recursos de zonas de disponibilidade para requisitos de alta disponibilidade. Para obter mais informações, consulte Regiões e zonas de disponibilidade no Azure.
Provisionamento de objetos - Os Serviços de Domínio do Microsoft Entra sincronizam identidades da ID do Microsoft Entra associada à assinatura na qual os Serviços de Domínio Microsoft Entra estão implantados. Também vale a pena notar que, se o ID do Microsoft Entra associado 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 nos Serviços de Domínio do Microsoft Entra. Este serviço tem dois modos que podem ser usados para provisionar objetos de usuário e grupo a partir do Microsoft Entra ID.
Todos: Todos os usuários e grupos são sincronizados do ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra.
Escopo: Somente os usuários no escopo de um grupo (s) são sincronizados do ID do Microsoft Entra para os Serviços de Domínio do Microsoft Entra.
Quando você implanta pela primeira vez os Serviços de Domínio do Microsoft Entra, uma sincronização unidirecional automática é configurada para replicar os objetos da ID do Microsoft Entra. Essa sincronização unidirecional continua a ser executada em segundo plano para manter o domínio gerenciado dos Serviços de Domínio Microsoft Entra atualizado com quaisquer alterações da ID do Microsoft Entra. Não ocorre nenhuma sincronização entre o Microsoft Entra Domain Services e o Microsoft Entra ID. Para obter mais informações, consulte Como objetos e credenciais são sincronizados em um domínio gerenciado dos Serviços de Domínio Microsoft Entra.
Vale a pena notar que, se você precisar alterar o tipo de sincronização de Tudo para Escopo (ou vice-versa), o domínio gerenciado dos Serviços de Domínio Microsoft Entra 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 dos Serviços de Domínio Microsoft Entra como uma boa prática.
Objetos de Política de Grupo (GPO) - Para configurar o GPO em um domínio gerenciado dos Serviços de Domínio Microsoft Entra, você deve usar as ferramentas de Gerenciamento de Diretiva de Grupo em um servidor que tenha ingressado no domínio gerenciado dos Serviços de Domínio Microsoft Entra. Para obter mais informações, consulte Administrar a Diretiva de Grupo em um domínio gerenciado dos Serviços de Domínio Microsoft Entra.
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 é desabilitada por padrão e, para habilitar o LDAP seguro, um certificado precisa ser carregado, além disso, o NSG que protege a VNet na qual os Serviços de Domínio Microsoft Entra estão implantados deve permitir a conectividade da porta 636 para os domínios gerenciados dos Serviços de Domínio Microsoft Entra. Para obter mais informações, consulte Configurar LDAP seguro para um domínio gerenciado dos Serviços de Domínio Microsoft Entra.
Administração - Para executar tarefas de administração nos Serviços de Domínio do Microsoft Entra (por exemplo, máquinas de ingresso no domínio ou edição de GPO), a conta usada para essa tarefa precisa fazer parte do grupo Administradores de DC do Microsoft Entra. As contas que são membros deste grupo não podem entrar diretamente nos controladores de domínio para executar tarefas de gerenciamento. Em vez disso, você cria uma VM de gerenciamento que ingressa no domínio gerenciado dos Serviços de Domínio Microsoft Entra e 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 nos Serviços de Domínio Microsoft Entra.
Hashes de senha - Para que a autenticação com os Serviços de Domínio Microsoft Entra 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 os Serviços de Domínio Microsoft Entra 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 o 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 os Serviços de Domínio Microsoft Entra. Para obter mais informações, consulte Habilitar a sincronização de hashes de senha.
Rede - Os Serviços de Domínio Microsoft Entra são implantados em uma VNet do Azure, portanto, considerações precisam ser feitas 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 de design e opções de configuração da rede virtual para o Microsoft Entra Domain Services.
Os Serviços de Domínio do Microsoft Entra devem ser implantados em sua própria sub-rede: não use uma sub-rede existente ou uma sub-rede de gateway.
Um NSG (grupo de segurança de rede) - é criado durante a implantação de um domínio gerenciado pelos Serviços de Domínio Microsoft Entra. Este grupo de segurança de rede contém as regras necessárias para a comunicação correta do serviço. Não crie ou use um grupo de segurança de rede existente com suas próprias regras personalizadas.
Os Serviços de Domínio Microsoft Entra requerem 3-5 endereços IP - Certifique-se de que o intervalo de endereços IP da sub-rede pode fornecer este número de endereços. Restringir os endereços IP disponíveis pode impedir que os Serviços de Domínio Microsoft Entra mantenham dois controladores de domínio.
Servidor DNS VNet - Como discutido anteriormente sobre o modelo "hub and spoke", é importante ter o DNS configurado corretamente nas VNets para garantir que os servidores ingressados no domínio gerenciado dos Serviços de Domínio Microsoft Entra tenham as configurações de DNS corretas para resolver o domínio gerenciado dos Serviços de Domínio Microsoft Entra. Cada VNet tem uma entrada de servidor DNS que é passada para os servidores à medida que obtêm um endereço IP e essas entradas DNS precisam ser os endereços IP do domínio gerenciado dos Serviços de Domínio Microsoft Entra. Para obter mais informações, consulte Atualizar 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 dos Serviços de Domínio Microsoft Entra só podem ser administradas a partir de um servidor associado aos Serviços de Domínio Microsoft Entra.
Apenas um domínio gerenciado dos Serviços de Domínio Microsoft Entra pode ser implantado por locatário do Microsoft Entra. Como descrevemos nesta seção, o modelo hub e spoke é recomendado para fornecer autenticação dos Serviços de Domínio Microsoft Entra para serviços em outras redes virtuais.
Pode ser necessária mais infraestrutura para o gerenciamento de patches e implantações de software. As organizações devem considerar a implantação do Azure Update Management, da Política de Grupo (GPO) ou do System Center Configuration Manager (SCCM) para gerenciar esses servidores.
Para esse modelo isolado, presume-se que não há conectividade com a VNet que hospeda o domínio gerenciado dos Serviços de Domínio Microsoft Entra 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 os Serviços de Domínio do Microsoft Entra possam ser gerenciados e administrados.
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 logon em servidores nesse cenário. Isso fornece a capacidade de tornar o Microsoft Entra ID o reino de identidade para fins de autenticação e o isolamento de identidade pode ser alcançado provisionando os servidores na assinatura relevante, que está vinculada ao locatário necessário do Microsoft Entra. Impõem-se as seguintes considerações.
Sistemas operativos suportados: Iniciar sessão em máquinas virtuais no Azure utilizando a autenticação Microsoft Entra é atualmente suportado no Windows e Linux. Para obter mais detalhes sobre os sistemas operacionais suportados, 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.
Nota
O locatário do Microsoft Entra usado para entrar neste cenário é o locatário do Microsoft Entra associado à assinatura na qual a máquina virtual foi provisionada. Este locatário do Microsoft Entra pode ser aquele que tem identidades sincronizadas do AD DS local. As organizações devem fazer uma escolha informada que esteja alinhada 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. Consulte a documentação para Windows e Linux para obter mais informações.
Controle de acesso baseado em função (RBAC): 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 por meio 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 de máquina virtual: os usuários com essa função atribuída a eles podem fazer logon em uma máquina virtual do Azure com privilégios de administrador.
Logon do usuário da máquina virtual: os usuários com essa função atribuída a eles podem fazer logon em uma máquina virtual do Azure com privilégios de usuário 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 para as organizações exigirem que as condições sejam atendidas antes de permitir o acesso à máquina virtual e de usar a autenticação multifator para fornecer autenticação forte. Para obter mais informações, consulte Usando o acesso condicional.
Nota
A ligação remota a máquinas virtuais associadas ao Microsoft Entra ID só é permitida a partir de PCs Windows 10, Windows 11 e Cloud PC associados ao Microsoft Entra ou híbridos do Microsoft Entra associados ao mesmo diretório que a máquina virtual.
Desafios: A lista abaixo destaca os principais desafios com o uso dessa opção para isolamento de identidade.
Sem gerenciamento central ou configuração de servidores. Por exemplo, não há nenhuma Diretiva 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 patches 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 explorar os Serviços de Domínio Ative Directory Autônomos ou os cenários dos Serviços de Domínio Microsoft Entra descritos nesta 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 jumpbox ou servidor de gerenciamento deve ser criado para permitir um ponto a partir do qual esses servidores possam ser gerenciados e administrados.
Próximos passos
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários