Gerenciamento de identidade e acesso com servidores habilitados para Azure Arc

Gerenciamento de identidade para servidores tradicionalmente girados em torno do Active Directory: os servidores são ingressados no domínio, os administradores recebem contas de domínio que são adicionadas aos administradores locais por meio de grupos de domínio e as configurações do Windows são gerenciadas usando a Política de Grupo. No modelo de gerenciamento de nuvem, o Microsoft Entra torna-se a base da identidade e do acesso, enquanto o Active Directory (AD) ainda pode ser usado para autenticação de aplicativo e protocolos herdados em computadores Windows locais.

A identidade nativa da nuvem no gerenciamento de servidores é obtida usando o Microsoft Entra para autenticar administradores e os próprios servidores. Os servidores ingressados no domínio do AD local ainda podem ser acessados por dispositivos windows nativos de nuvem (estação de trabalho) ou usuários nesses dispositivos. Por meio do Microsoft Entra, você obtém credenciais unificadas, pois a ID do Microsoft Entra pode gerenciar VMs (máquinas virtuais), servidores habilitados para Arc, Office 365 e muito mais. Recursos como MFA (autenticação multifator) e acesso condicional melhoram a segurança. Os servidores em seu ambiente híbrido podem usar o sistema de identidade do Azure para acessar recursos com segurança. Esses benefícios permitem reduzir o tempo gasto para manter contas de serviço ou conceder direitos de administrador local por computador. É uma transição no pensamento, mas que se alinha a um ecossistema totalmente gerenciado pela nuvem.

Vamos examinar como o mundo de um administrador do sistema muda com os benefícios do Microsoft Entra.

Integração do Microsoft Entra

O Microsoft Entra ID é um serviço de identidade baseado em nuvem. Ao contrário do AD DS (Active Directory Domain Services), a ID do Microsoft Entra não é estruturada em Unidades Organizacionais e não se concentra na autenticação Kerberos. Em vez disso, a ID do Microsoft Entra gerencia identidades de usuário, aplicativos e acesso a recursos da Microsoft, incluindo Azure, Microsoft 365 e outros aplicativos e sistemas operacionais que dão suporte à ID do Microsoft Entra.

Os próprios servidores não "ingressam" na ID do Microsoft Entra da maneira como ingressam em um domínio. Em vez disso, um servidor habilitado para Arc é ingressado em um locatário do Azure regido pela ID do Microsoft Entra quando ele se conecta pela primeira vez ao Azure. Com a ID do Microsoft Entra, os usuários podem receber funções a um escopo designado (ou adicionados a um grupo com essas permissões) usando o RBAC (controle de acesso baseado em função) do Azure. Em seguida, os usuários com as permissões apropriadas podem usar uma conexão de Área de Trabalho Remota para acessar computadores Windows Server ou usar o SSH para acessar o Linux.

Sua "conta de administrador" é sua identidade de ID do Microsoft Entra (ou uma conta do AD sincronizada) com funções apropriadas no Azure. Por exemplo, para gerenciar servidores habilitados para Arc, um usuário da ID do Microsoft Entra pode ter a função interna de Logon do Administrador de Máquina Virtual do Azure ou uma atribuição de função personalizada criada com as permissões apropriadas. Em vez de ter uma conta de administrador que permita acesso total a cada servidor, a ID do Microsoft Entra permite que você escopo funções para um conjunto específico de cargas de trabalho do Azure, concedendo apenas as permissões necessárias para executar as tarefas necessárias em servidores habilitados para Arc e recursos nativos do Azure.

Identidade gerenciada atribuída pelo sistema

Os servidores habilitados para Arc exigem uma identidade gerenciada atribuída pelo sistema. Esse é um tipo de aplicativo empresarial que representa a identidade de um recurso de computador no Azure. Em vez de armazenar credenciais, os aplicativos em execução no servidor podem usar a identidade gerenciada do servidor para autenticar no Azure. O agente de computador conectado do Azure Arc expõe um ponto de extremidade que o aplicativo pode usar para solicitar um token. O aplicativo não precisa se autenticar no serviço Web não disponível que fornece tokens diferentes da formatação correta da solicitação (incluindo um cabeçalho de metadados), portanto, o limite de segurança esperado é a VM. Seu servidor local pode acessar diretamente os serviços do Azure sem exigir credenciais codificadas, pois o Azure sabe que a solicitação vem desse servidor e autoriza-a somente com base nas atribuições de função definidas.

Para um administrador do sistema, um cenário comum pode estar executando um comando da CLI do Azure no servidor (que tem a CLI do Azure instalada) que chama o Armazenamento do Azure para recuperar um artefato usado por um script de automação. Como o servidor tem um acesso autorizado de identidade a essa conta de armazenamento, a solicitação é concluída sem a necessidade de uma conta de serviço ou um PAT (token de acesso pessoal).

Controle de acesso baseado em função (RBAC)

O modelo do Azure incentiva o RBAC granular. Como diferentes funções internas permitem diferentes tipos de acesso, você pode atribuir funções com permissões muito limitadas. Por exemplo, um usuário pode ter uma função que concede apenas a capacidade de usar o Run Command em servidores habilitados para Arc ou permite o acesso somente leitura a uma configuração e nada mais.

Uma função interna comum usada com o Azure Arc é a função de Integração de Máquina Conectada do Azure. Os usuários com essa função podem integrar servidores ao Azure Arc, mas não podem realizar a maioria das outras tarefas de gerenciamento, a menos que funções adicionais sejam concedidas. Da mesma forma, você pode fornecer funções de proprietários de aplicativos que permitem que eles implantem patches em seus servidores por meio da Automação do Azure sem dar a eles acesso real de logon do sistema operacional. Esse nível de ajuste fino dá suporte a princípios de administração "just-enough".

Acesso just-in-time

Para controlar ainda mais o acesso elevado aos servidores habilitados para Arc e outros recursos do Azure, você pode habilitar o PIM (Microsoft Entra Privileged Identity Management). O PIM pode ser usado para acesso just-in-time (JIT), portanto, você pode exigir que alguém eleve explicitamente para uma função específica para executar tarefas que exijam maiores níveis de acesso. Você pode exigir que um administrador aprove esse acesso e defina os períodos de expiração automáticos para a função com privilégios elevados. O PIM também inclui um histórico de auditoria para ver todas as atribuições de função e ativações para todas as funções privilegiadas nos últimos 30 dias (ou um período mais longo configurado).

O uso do PIM ajuda a reduzir o acesso contínuo de administradores e dá suporte ao princípio de privilégios mínimos. Por exemplo, você pode usar o PIM para conceder a determinados usuários a capacidade de elevar sua função para o Administrador de Recursos do Azure Connected Machine, permitindo que eles executem tarefas de gerenciamento mais avançadas em servidores habilitados para Arc.

Configurações de identidade híbrida

Na prática, muitas empresas executam servidores habilitados para Arc que também são ingressados no domínio no AD. Elas não são mutuamente exclusivas; eles complementam um ao outro. Você pode fazer logon no servidor por meio do AD quando necessário, mas executar tarefas de gerenciamento no Azure.

Em servidores individuais, você ainda pode gerenciar contas locais por meio do AD, como usar a LAPS (Solução de Senha de Administrador Local) para girar a senha do administrador local. Como o Azure Arc não gerencia contas locais, talvez você queira continuar usando esse processo. Você pode até mesmo usar o Azure Policy para garantir que o LAPS esteja habilitado e armazene senhas no Microsoft Entra.

Há muita flexibilidade para usar os recursos do Microsoft Entra e do Azure, mantendo ainda soluções de identidade locais que funcionam para você. Ao longo do tempo, você descobrirá que precisa interagir menos com a manutenção de contas de serviço ou a concessão de direitos de administrador local, já que você pode ter opções de gerenciamento de identidades na nuvem.