O impacto da autenticação multifator no Azure PowerShell em cenários de automação

Este artigo explora como a autenticação multifator (MFA) afeta as tarefas de automação que usam identidades de usuário do Microsoft Entra e fornece orientação sobre abordagens alternativas para automação ininterrupta.

Os requisitos de MFA impedem que você use identidades de usuário do Microsoft Entra para autenticação em cenários de automação. As organizações devem alternar para métodos de autenticação projetados para automação, como identidades gerenciadas ou entidades de serviço, que oferecem suporte a casos de uso de automação não interativa.

Limitações das identidades de usuário com MFA na automação

• Autenticação interativa: a MFA é acionada durante entradas interativas ao usar uma identidade de usuário do Microsoft Entra. Para scripts de automação que dependem de uma identidade de usuário, o MFA interrompe o processo porque requer etapas de verificação extras. Por exemplo, aplicativo autenticador, chamada telefônica, etc., que você não pode automatizar. Essa verificação impede a execução da automação, a menos que a autenticação seja tratada de forma não interativa, como com uma identidade gerenciada ou uma entidade de serviço.

• Falhas de logon com script: em cenários de automação, como a execução autônoma de scripts do Azure PowerShell, uma identidade de usuário habilitada para MFA faz com que o script falhe ao tentar autenticar. Como o MFA requer interação do usuário, ele é incompatível com scripts não interativos. Isso significa que você deve alternar para uma identidade gerenciada ou uma entidade de serviço, que usam autenticação não interativa.

• Considerações de segurança: Embora o MFA adicione uma camada extra de segurança, ele pode limitar a flexibilidade de automação, especialmente em ambientes de produção onde a automação deve ser executada sem intervenção manual. Mudar para identidades gerenciadas, entidades de serviço ou identidades federadas, que são projetadas para fins de automação e não exigem MFA, é mais prática e segura nesses ambientes.

Cenários que exigem atualizações

A lista a seguir fornece cenários de exemplo em que os clientes podem usar uma identidade de usuário do Microsoft Entra para automação com o Azure PowerShell. Esta lista não é exaustiva de todos os cenários.

• Permissões personalizadas ou específicas: tarefas de automação que exigem permissões específicas do usuário, como ações vinculadas à função de um indivíduo ou atributos específicos do Microsoft Entra ID.

• Fluxo ROPC OAuth 2.0: O fluxo de concessão de token OAuth 2.0 Resource Owner Password Credentials (ROPC) é incompatível com MFA. Os cenários de automação que usam ROPC para autenticação falham quando a MFA é necessária, pois a MFA não pode ser concluída em um fluxo não interativo.

• Acesso a recursos externos ao Azure: cenários de automação que exigem acesso aos recursos do Microsoft 365. Por exemplo, SharePoint, Exchange ou outros serviços de nuvem vinculados à conta da Microsoft de um usuário individual.

• Contas de serviço sincronizadas do Ative Directory para o Microsoft Entra ID: organizações que usam contas de serviço sincronizadas do Ative Directory (AD) para o Microsoft Entra ID. É importante notar que essas contas também estão sujeitas aos requisitos de MFA e acionam os mesmos problemas que outras identidades de usuário.

• Contexto do usuário para auditoria ou conformidade: casos em que as ações precisaram ser auditáveis em um nível de usuário individual por motivos de conformidade.

• Configuração simples para automação em pequena escala ou de baixo risco: Para tarefas de automação de pequena ou baixa escala. Por exemplo, um script que gerencia alguns recursos.

• Automação orientada pelo usuário em ambientes que não são de produção: se a automação for destinada a ambientes pessoais ou não produtivos em que um usuário individual é responsável por uma tarefa.

• Automação dentro da própria assinatura do Azure de um usuário: se um usuário precisar automatizar tarefas em sua própria assinatura do Azure em que o usuário já tenha permissões suficientes.

A mudança para uma identidade gerenciada ou entidade de serviço é necessária para cenários de automação devido à imposição obrigatória de MFA para identidades de usuário do Microsoft Entra.

Como começar

Para migrar seus scripts do Azure PowerShell do uso Connect-AzAccount com uma conta de usuário humana e senha do Microsoft Entra ID, siga estas etapas:

1. Determine qual identidade de carga de trabalho é melhor para você.

   • Principal de Serviço
   • Identidade gerenciada
   • Identidade federada

2. Obtenha as permissões necessárias para criar uma nova identidade de carga de trabalho ou entre em contato com o administrador do Azure para obter assistência.

3. Crie a identidade da carga de trabalho.

4. Atribua funções à nova identidade. Para obter mais informações sobre atribuições de função do Azure, consulte Etapas para atribuir uma função do Azure. Para atribuir funções usando o Azure PowerShell, consulte Atribuir funções do Azure usando o Azure PowerShell.

5. Atualize seus scripts do Azure PowerShell para entrar com uma entidade de serviço ou identidade gerenciada.

Conceitos-chave da entidade de serviço

• Uma identidade não humana que pode acessar vários recursos do Azure. Uma entidade de serviço é usada por muitos recursos do Azure e não está vinculada a um único recurso do Azure.
• Você pode alterar as propriedades e credenciais de uma entidade de serviço conforme necessário.
• Ideal para aplicativos que precisam acessar vários recursos do Azure em assinaturas diferentes.
• Considerado mais flexível do que as identidades gerenciadas, mas menos seguro.
• Muitas vezes referido como um "objeto de aplicativo" em um locatário do Azure ou diretório de ID do Microsoft Entra.

Para saber mais sobre entidades de serviço, consulte:

• Aplicativos & entidades de serviço no Microsoft Entra ID
• Proteger principais de serviço no Microsoft Entra ID

Para saber como fazer logon no Azure usando o Azure PowerShell e uma entidade de serviço, consulte Entrar no Azure com uma entidade de serviço usando o Azure PowerShell

Conceitos-chave de identidade gerenciada

• Vinculado a um recurso específico do Azure, permitindo que esse único recurso acesse outros aplicativos do Azure.
• As credenciais não são visíveis para você. O Azure lida com segredos, credenciais, certificados e chaves.
• Ideal para recursos do Azure que precisam acessar outros recursos do Azure em uma única assinatura.
• Considerado menos flexível do que as entidades de serviço, mas mais seguro.
• Existem dois tipos de identidades gerenciadas:
  • Sistema atribuído: este tipo é um link de acesso 1:1 (um para um) entre dois recursos do Azure.
  • Usuário atribuído: esse tipo tem uma relação 1:M (um para muitos) em que a identidade gerenciada pode acessar vários recursos do Azure.

Para saber mais sobre identidades gerenciadas, consulte Identidades gerenciadas para recursos do Azure.

Para saber como iniciar sessão no Azure utilizando o Azure PowerShell e uma identidade gerida, consulte Iniciar sessão no Azure com uma identidade gerida utilizando o Azure PowerShell

Conceitos-chave de identidade federada

• Uma identidade federada permite que entidades de serviço (registros de aplicativos) e identidades gerenciadas atribuídas pelo usuário confiem em tokens de um provedor de identidade externo (IdP), como o GitHub ou o Google.
• Depois que a relação de confiança é criada, sua carga de trabalho de software externo troca tokens confiáveis do IdP externo por tokens de acesso da plataforma de identidade da Microsoft.
• Sua carga de trabalho de software usa esse token de acesso para acessar os recursos protegidos do Microsoft Entra aos quais a carga de trabalho tem acesso.
• As identidades federadas geralmente são a melhor solução para os seguintes cenários:
  • Carga de trabalho em execução em qualquer cluster Kubernetes
  • GitHub Actions
  • Carga de trabalho em execução em plataformas de computação do Azure usando identidades de aplicativo
  • Nuvem do Google
  • Amazon Web Services (AWS)
  • Carga de trabalho em execução em plataformas de computação fora do Azure

Para saber mais sobre identidades federadas, consulte:

• O que é a federação de identidades de carga de trabalho?
• Migrar para a autenticação multifator do Microsoft Entra com federações

Saiba mais sobre a autenticação multifator

O site de documentação do Microsoft Entra ID oferece mais detalhes sobre MFA.

• Planejar a autenticação multifator (MFA) obrigatória do Microsoft Entra
• Como usar o MFA Server Migration Utility para migrar para a autenticação multifator do Microsoft Entra
• Considerações de implantação para autenticação multifator do Microsoft Entra
• Migrar do MFA Server para a autenticação multifator do Microsoft Entra

Consulte também

• Identidades de carga de trabalho, outras identidades de máquina e identidades humanas.
• Reduzindo o uso do token de acesso pessoal (PAT) no Azure DevOps
• Melhorar a postura de segurança nas conexões de serviço do Azure com AzurePipelinesCredential