Compartilhar via

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

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

Importante

A ação será necessária se você estiver usando identidades de usuário do Microsoft Entra para automação.

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

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

Observação

Você pode encontrar a mensagem de erro: a autenticação interativa é necessária ao usar uma identidade de usuário com automação.

  • Autenticação interativa: a MFA é disparada 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, a MFA interrompe o processo porque requer etapas extras de verificação. Por exemplo, aplicativo autenticador, chamada telefônica etc., que você não pode automatizar. Essa verificação impede que a automação seja executada, 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 executar scripts do Azure PowerShell autônomos, uma identidade de usuário habilitada para MFA faz com que o script falhe ao tentar se autenticar. Como a MFA requer interação do usuário, ela é incompatível com scripts não interativos. Isso significa que você deve alternar para uma identidade gerenciada ou entidade de serviço, ambas usando autenticação não interativa.

  • Considerações de segurança: embora a MFA adicione uma camada extra de segurança, ela pode limitar a flexibilidade de automação, especialmente em ambientes de produção em que a automação deve ser executada sem intervenção manual. A mudança 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. Essa lista não é completa de todos os cenários.

Aviso

Qualquer cenário de automação que use uma identidade de usuário do Microsoft Entra requer atualização.

  • 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 da ID do Microsoft Entra.

  • Fluxo ROPC do OAuth 2.0: o fluxo de concessão de token ROPC (Credenciais de Senha do Proprietário do Recurso) do OAuth 2.0 é incompatível com a MFA. Os cenários de automação usando 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 Microsoft de um usuário individual.

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

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

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

  • Automação orientada pelo usuário em ambientes de não produção: se a automação for destinada a ambientes pessoais ou não de produção em que um usuário individual seja 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á tem permissões suficientes.

A alternância 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 usando uma conta de usuário e senha humanas do Connect-AzAccount Microsoft Entra ID, siga estas etapas:

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

    • Entidade de serviço
    • Identidade gerenciada
    • Identidade federada

  2. Obtenha as permissões necessárias para criar uma nova identidade de carga de trabalho ou contate 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 de 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 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.
  • Geralmente chamado de "objeto de aplicativo" em um locatário do Azure ou diretório da ID do Microsoft Entra.

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

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 de 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 que as entidades de serviço, mas mais seguro.
  • Há dois tipos de identidades gerenciadas:
    • Sistema atribuído: esse tipo é um link de acesso 1:1 (um para um) entre dois recursos do Azure.
    • Atribuído pelo usuário: esse tipo tem uma relação 1:M (uma para muitas) 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 fazer logon no Azure usando o Azure PowerShell e uma identidade gerenciada, consulte Entrar no Azure com uma identidade gerenciada usando o Azure PowerShell

Conceitos de chave de identidade federada

  • Uma identidade federada permite que entidades de serviço (registros de aplicativo) e identidades gerenciadas atribuídas pelo usuário confiem em tokens de um IdP (provedor de identidade externo), 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 para 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 recebe acesso.
  • Identidades federadas geralmente são a melhor solução para os seguintes cenários:
    • Carga de trabalho em execução em qualquer cluster do Kubernetes
    • GitHub Actions
    • Carga de trabalho em execução em plataformas de computação do Azure usando identidades de aplicativo
    • Google Cloud
    • Amazon Web Services (AWS)
    • Carga de trabalho em execução em plataformas de computação fora do Azure

Para saber mais sobre identidades federadas, confira:

Saiba mais sobre a autenticação multifator

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

Consulte também

  • Last updated on