Compartilhar via

O impacto da autenticação multifator na CLI do Azure em cenários de automação

  • Artigo

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.

Important

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 autenticação multifator na automação

Nota

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

  • autenticação interativa: MFA é acionada durante logins interativos com 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 um principal de serviço.

  • Scripted login failures: In automation scenarios like running Azure CLI scripts unattended, an MFA-enabled user identity causes the script to fail when trying to authenticate. Como a MFA requer interação do usuário, ela é incompatível com scripts não interativos. This means you must switch to a managed identity or service principal, both of which use non-interactive authentication.

  • 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 a CLI do Azure. 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.

  • OAuth 2.0 ROPC flow: The OAuth 2.0 Resource Owner Password Credentials (ROPC) token grant flow is incompatible with 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 para o ID do Microsoft Entra: Organizações que utilizam contas de serviço sincronizadas do Active Directory (AD) para o 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 porte ou baixo risco: para tarefas de automação que sejam de pequeno porte 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 na 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.

Para cenários de automação, é necessário mudar para uma identidade gerenciada ou principal de serviço devido à imposição obrigatória de MFA para identidades de usuário do Microsoft Entra.

Como começar

To migrate your Azure CLI scripts from using az login with a Microsoft Entra ID human user account and password, follow these steps:

  1. Determine which workload identity is best for you.

    • Service principal
    • 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. Create the workload identity.

  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 a CLI do Azure, consulte Atribuir funções do Azure usando a CLI do Azure.

  5. Atualize os scripts da CLI do Azure para fazer login usando um principal de serviço ou identidade gerenciada.

Service principal key concepts

  • Uma identidade não humana que pode acessar vários recursos do Azure. A service principal is used by many Azure resources and isn't tied to a single Azure resource.
  • You can alter properties and credentials of a service principal as needed.
  • 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.
  • Often referred to as an "application object" in an Azure tenant or Microsoft Entra ID directory.

To learn more about service principals, see:

Para saber como acessar o Azure usando a CLI do Azure e um principal de serviço, consulte Entrar no Azure com um principal de serviço usando a CLI do Azure

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.
  • Considered less flexible than service principals but more secure.
  • 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.
    • Usuário atribuído: 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 a CLI do Azure e uma identidade gerenciada, consulte Entrar no Azure com uma identidade gerenciada usando a CLI do Azure

Conceitos de chave de identidade federada

  • Uma identidade federada permite que entidades de serviço (registros de aplicativo) e identidades gerenciadas atribuídas a usuários confiem em tokens de um IdP (provedor de identidade externo), como o GitHub ou o Google.
  • Once the trust relationship is created, your external software workload exchanges trusted tokens from the external IdP for access tokens from the Microsoft identity platform.
  • 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
    • Ações do GitHub
    • 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:

Resolução de problemas

Erro ropc: devido a uma alteração de configuração feita pelo administrador

When you try to sign into Azure by using a password, this is known as ROPC flow (Resource Owner Password Credential). Não há suporte para esse método de autenticação com MFA. Veja um exemplo:

az login --username $username –password $password

Se a MFA for necessária para o usuário, o comando acima falhará com a seguinte mensagem de erro:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

Solução : Mudar para um método de autenticação compatível com MFA.

Cross-tenant warning: Authentication failed against tenant

Se você tiver acesso a vários locatários e um deles exigir MFA, a CLI do Azure poderá exibir uma mensagem de aviso semelhante a esta:

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

During the login phase, Azure CLI tries to sign in with the first tenant found. While we are working towards a resolution for this issue, specify the tenant you want to use with the --tenant parameter:

az login --tenant 00000000-0000-0000-0000-000000000000

Saiba mais sobre a autenticação multifator

The Microsoft Entra ID documentation site offers more detail on MFA.

Consulte também