Gerenciamento de identidade e acesso com servidores habilitados para Azure Arc

O gerenciamento de identidade para servidores tradicionalmente girava em torno do Ative Directory: os servidores são associados ao 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 Diretiva de Grupo. No modelo de gerenciamento de nuvem, o Microsoft Entra se torna a pedra angular da identidade e do acesso, enquanto o Ative Directory (AD) ainda pode ser usado para autenticação de aplicativos e protocolos herdados em máquinas 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 locais associados ao domínio do AD ainda podem ser acessados por dispositivos Windows (estação de trabalho) nativos da nuvem ou usuários nesses dispositivos. Através do Microsoft Entra, você obtém credenciais unificadas, pois o Microsoft Entra ID pode gerenciar máquinas virtuais (VMs), servidores habilitados para Arc, Office 365 e muito mais. Recursos como autenticação multifator (MFA) 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 na manutenção de contas de serviço ou na concessão de direitos de administrador local por máquina. É uma transição de pensamento, mas que se alinha com um ecossistema totalmente gerenciado pela nuvem.

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

Integração com o Microsoft Entra

O Microsoft Entra ID é um serviço de identidade baseado na nuvem. Ao contrário dos Serviços de Domínio Ative Directory (AD DS), o Microsoft Entra ID não está estruturado em Unidades Organizacionais e não se concentra na autenticação Kerberos. Em vez disso, o Microsoft Entra ID gerencia identidades de usuário, aplicativos e acesso a recursos da Microsoft, incluindo Azure, Microsoft 365 e outros aplicativos e sistemas operacionais que oferecem suporte ao Microsoft Entra ID.

Os próprios servidores não "aderem" ao Microsoft Entra ID da mesma forma que ingressam em um domínio. Em vez disso, um servidor habilitado para Arc é associado a um locatário do Azure regido pela ID do Microsoft Entra quando ele se conecta ao Azure pela primeira vez. Com o Microsoft Entra ID, os usuários podem receber funções a um escopo designado (ou adicionados a um grupo com essas permissões) usando o controle de acesso baseado em função do Azure (Azure RBAC). Em seguida, os usuários com as permissões apropriadas podem usar uma conexão de Área de Trabalho Remota para acessar máquinas Windows Server ou usar 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 do Microsoft Entra ID pode ter a função interna do Azure Logon de Administrador de Máquina Virtual ou uma atribuição de função personalizada criada com as permissões apropriadas. Em vez de ter uma conta de administrador que permite acesso total a todos os servidores, o Microsoft Entra ID permite que você defina o escopo de 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 ao sistema. Este é um tipo de aplicativo empresarial que representa a identidade de um recurso de máquina no Azure. Em vez de armazenar credenciais, os aplicativos em execução no servidor podem usar a identidade gerenciada do servidor para se autenticar no Azure. O agente de máquina do Azure Arc Connected 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 roteável que fornece tokens além de formatar corretamente a 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, porque o Azure sabe que a solicitação vem desse servidor e a autoriza somente com base nas atribuições de função que você definiu.

Para um administrador de sistema, um cenário comum pode ser a execução de 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 token de acesso pessoal (PAT).

Controlo de acesso baseado em funções (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 conceda apenas a capacidade de usar o Run Command em servidores habilitados para Arc, ou permita 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 fazer a maioria das outras tarefas de gerenciamento, a menos que funções adicionais sejam concedidas. Da mesma forma, você pode dar aos proprietários de aplicativos funções que lhes permitem implantar patches em seus servidores por meio da Automação do Azure sem dar a eles acesso real de logon do sistema operacional. Este nível de ajuste fino suporta princípios de administração "just-enough".

Acesso oportuno

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

O uso do PIM ajuda a reduzir o acesso contínuo do administrador e suporta o princípio do menor privilégio. Por exemplo, você pode usar o PIM para conceder a determinados usuários a capacidade de elevar sua função a Administrador de Recursos de Máquina Conectada do Azure, 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 associados ao AD. Estes não são mutuamente exclusivos; complementam-se. Você pode fazer logon no servidor via AD quando necessário, mas executar tarefas de gerenciamento no Azure.

Em servidores individuais, você ainda pode gerenciar contas locais via AD, como usar a Solução de Senha de Administrador Local (LAPS) para girar a senha de administrador local. Como o Azure Arc não gerencia contas locais, convém continuar usando esse processo. Você pode até usar a Política do Azure para garantir que o LAPS esteja habilitado e armazenando senhas no Microsoft Entra.

Há muita flexibilidade para usar os recursos do Microsoft Entra e do Azure, enquanto ainda mantém soluções de identidade locais que funcionam para você. Com o 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 pode ter opções de gerenciamento de identidades na nuvem.