O impacto da autenticação multifator na CLI do Azure 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.

Importante

A ação é necessária se você estiver usando identidades de usuário do Microsoft Entra para automação. 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

Observação

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

Autenticação interativa: 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. Esta verificação impede a execução da automação, a menos que a autenticação seja tratada de forma não interativa, tal como através de uma identidade gerida ou um principal de serviço.
Falhas de início de sessão com script: em cenários de automação como a execução autónoma de scripts da CLI do Azure, uma identidade de utilizador habilitada para MFA faz com que o script falhe ao tentar autenticar-se. Como o MFA requer interação do usuário, ele é incompatível com scripts não interativos. Isso significa que é necessário alternar para uma identidade gerida ou um principal de serviço, ambos 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 a CLI do Azure. Esta lista não é exaustiva de todos os cenários.

Advertência

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 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 de pequena escala ou baixo risco: Para tarefas de automação de pequena escala ou baixo risco. 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 se destina a ambientes pessoais ou não produtivos em que um usuário individual é responsável por uma tarefa.
Automação dentro da assinatura do Azure do próprio 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 gerida ou principal de serviço é necessária para cenários de automação devido à exigência obrigatória de MFA para identidades de utilizador do Microsoft Entra.

Como começar

Para migrar os seus scripts da CLI do Azure usando az login com uma conta de utilizador humano e palavra-passe do Microsoft Entra ID, siga estas etapas:

Determine qual identidade de tarefa é melhor para si.
- Principal de serviço
- Identidade gerenciada
- Identidade federada
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.
Crie a identidade da carga de trabalho.
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.
Atualize os seus scripts da CLI do Azure para autenticar-se com uma entidade de serviço ou identidade gerida.

Conceitos-chave da entidade de serviço

Uma identidade não humana que pode acessar vários recursos do Azure. Uma principal 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 um principal 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 aplicação" numa entidade do Azure ou diretório de ID do Microsoft Entra.

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

Para saber como iniciar sessão no Azure utilizando a CLI do Azure e uma entidade de serviço, consulte Iniciar sessão no Azure com uma entidade de serviço utilizando a CLI do Azure

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.
- Utilizador atribuído: este tipo tem uma relação 1:M (um para muitos) em que a identidade gerida pode aceder a 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 a CLI do Azure e uma identidade gerida, consulte Iniciar sessão no Azure com uma identidade gerida utilizando a CLI do Azure

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
- Ações do GitHub
- 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:

Solução de problemas

Erro ROPC: Devido a uma alteração de configuração feita pelo administrador

Quando você tenta entrar no Azure usando uma senha, isso é conhecido como fluxo ROPC (Resource Owner Password Credential). Este método de autenticação não é suportado com MFA. Aqui está um exemplo:

az login --username $username –password $password

Se MFA for necessário 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: Mude para usar um método de autenticação compatível com MFA.

Aviso importante de interlocatários: Falha na autenticação contra locatário

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.

Durante a fase de autenticação, a CLI do Azure tenta efetuar a entrada com o primeiro locatário encontrado. Enquanto estamos trabalhando para uma resolução para esse problema, especifique o locatário que você deseja usar com o parâmetro --tenant:

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

Saiba mais sobre a autenticação multifator

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

Ver também

Feedback

Esta página foi útil?

Last updated on 2025-12-02