Condividi tramite

Impatto dell'autenticazione a più fattori in Azure PowerShell negli scenari di automazione

Questo articolo illustra in che modo l'autenticazione a più fattori influisce sulle attività di automazione che usano le identità utente di Microsoft Entra e fornisce indicazioni sugli approcci alternativi per l'automazione senza interruzioni.

Importante

L'azione è necessaria se si usano le identità utente di Microsoft Entra per l'automazione.

I requisiti di autenticazione a più fattori impediscono di usare le identità utente di Microsoft Entra per l'autenticazione negli scenari di automazione. Le organizzazioni devono passare ai metodi di autenticazione progettati per l'automazione, ad esempio identità gestite o entità servizio, che supportano casi d'uso di automazione non interattivi.

Limitazioni delle identità utente con MFA nell'automazione

Annotazioni

È possibile che venga visualizzato il messaggio di errore: l'autenticazione interattiva è necessaria quando si usa un'identità utente con l'automazione.

  • Autenticazione interattiva: l'autenticazione a più fattori viene attivata durante gli accessi interattivi quando si usa un'identità utente di Microsoft Entra. Per gli script di automazione che si basano su un'identità utente, L'autenticazione a più fattori interrompe il processo perché richiede passaggi di verifica aggiuntivi. Ad esempio, app di autenticazione, telefonata e così via, che non è possibile automatizzare. Questa verifica impedisce l'esecuzione dell'automazione a meno che l'autenticazione non venga gestita in modo non interattivo, ad esempio con un'identità gestita o un'entità servizio.

  • Errori di accesso con script: in scenari di automazione come l'esecuzione automatica di script di Azure PowerShell, un'identità utente abilitata per MFA causa l'esito negativo dello script quando si tenta di eseguire l'autenticazione. Poiché L'autenticazione a più fattori richiede l'interazione dell'utente, non è compatibile con gli script non interattivi. Ciò significa che è necessario passare a un'identità gestita o a un'entità servizio, che usano entrambe l'autenticazione non interattiva.

  • Considerazioni sulla sicurezza: mentre MFA aggiunge un ulteriore livello di sicurezza, può limitare la flessibilità di automazione, soprattutto negli ambienti di produzione in cui l'automazione deve essere eseguita senza intervento manuale. Il passaggio alle identità gestite, alle entità servizio o alle identità federate, progettate per scopi di automazione e non richiedono l'autenticazione a più fattori, è più pratico e sicuro in tali ambienti.

Scenari che richiedono aggiornamenti

L'elenco seguente fornisce scenari di esempio in cui i clienti possono usare un'identità utente di Microsoft Entra per l'automazione con Azure PowerShell. Questo elenco non è esaustivo di tutti gli scenari.

Avvertimento

Qualsiasi scenario di automazione che usa un'identità utente di Microsoft Entra richiede l'aggiornamento.

  • Autorizzazioni personalizzate o specifiche: attività di automazione che richiedono autorizzazioni specifiche dell'utente, ad esempio azioni associate al ruolo di un singolo utente o a attributi specifici di Microsoft Entra ID.

  • Flusso ROPC OAuth 2.0: il flusso di concessione del token OAuth 2.0 Resource Owner Password Credentials (ROPC) non è compatibile con MFA. Gli scenari di automazione che usano ROPC per l'autenticazione hanno esito negativo quando è necessaria l'autenticazione a più fattori, perché l'autenticazione a più fattori non può essere completata in un flusso non interattivo.

  • Accesso alle risorse esterne ad Azure: scenari di automazione che richiedono l'accesso alle risorse di Microsoft 365. Ad esempio, SharePoint, Exchange o altri servizi cloud associati all'account Microsoft di un singolo utente.

  • Account del servizio sincronizzati da Active Directory a Microsoft Entra ID: organizzazioni che usano account di servizio sincronizzati da Active Directory (AD) a Microsoft Entra ID. È importante notare che questi account sono soggetti anche ai requisiti MFA e attivano gli stessi problemi delle altre identità utente.

  • Contesto utente per il controllo o la conformità: casi in cui le azioni necessarie per essere controllabili a livello di singolo utente per motivi di conformità.

  • Configurazione semplice per l'automazione su scala ridotta o a basso rischio: per attività di automazione su scala ridotta o a basso rischio. Ad esempio, uno script che gestisce alcune risorse.

  • Automazione guidata dall'utente in ambienti non di produzione: se l'automazione è destinata a ambienti personali o non di produzione in cui un singolo utente è responsabile di un'attività.

  • Automazione all'interno della sottoscrizione di Azure di un utente: se un utente deve automatizzare le attività nella propria sottoscrizione di Azure in cui l'utente dispone già di autorizzazioni sufficienti.

Per gli scenari di automazione è necessario passare a un'identità gestita o a un'entità servizio a causa dell'imposizione dell'autenticazione a più fattori obbligatoria per le identità utente di Microsoft Entra.

Come iniziare

Per eseguire la migrazione degli script di Azure PowerShell dall'uso Connect-AzAccount con un account utente e una password di Microsoft Entra ID umano, seguire questa procedura:

  1. Determinare l'identità del carico di lavoro più adatta.

    • Service Principal
    • Identità gestita
    • Identità federata

  2. Ottenere le autorizzazioni necessarie per creare una nuova identità del carico di lavoro o contattare l'amministratore di Azure per assistenza.

  3. Creare l'identità del carico di lavoro.

  4. Assegnare ruoli alla nuova identità. Per altre informazioni sulle assegnazioni di ruolo di Azure, vedere Passaggi per assegnare un ruolo di Azure. Per assegnare ruoli con Azure PowerShell, vedere Assegnare ruoli di Azure con Azure PowerShell.

  5. Aggiornare gli script di Azure PowerShell per accedere con un'entità servizio o un'identità gestita.

Concetti chiave dell'entità servizio

  • Identità non umana che può accedere a più risorse di Azure. Un'entità servizio viene usata da molte risorse di Azure e non è associata a una singola risorsa di Azure.
  • È possibile modificare le proprietà e le credenziali di un'entità servizio in base alle esigenze.
  • Ideale per le applicazioni che devono accedere a più risorse di Azure tra sottoscrizioni diverse.
  • Considerato più flessibile rispetto alle identità gestite, ma meno sicuro.
  • Spesso definito "oggetto applicazione" in un tenant di Azure o in una directory ID di Microsoft Entra.

Per altre informazioni sulle entità servizio, vedere:

Per informazioni su come accedere ad Azure usando Azure PowerShell e un'entità servizio, vedere Accedere ad Azure con un'entità servizio usando Azure PowerShell

Concetti relativi alle chiavi di identità gestite

  • Associato a una risorsa di Azure specifica che consente a tale singola risorsa di accedere ad altre applicazioni di Azure.
  • Le credenziali non sono visibili all'utente. Azure gestisce segreti, credenziali, certificati e chiavi.
  • Ideale per le risorse di Azure che devono accedere ad altre risorse di Azure all'interno di una singola sottoscrizione.
  • Considerato meno flessibile rispetto alle entità servizio, ma più sicuro.
  • Esistono due tipi di identità gestite:
    • Assegnato dal sistema: questo tipo è un collegamento di accesso 1:1 (uno a uno) tra due risorse di Azure.
    • Assegnata dall'utente: questo tipo ha una relazione 1:M (uno a molti) in cui l'identità gestita può accedere a più risorse di Azure.

Per altre informazioni sulle identità gestite, vedere Identità gestite per le risorse di Azure.

Per informazioni su come accedere ad Azure usando Azure PowerShell e un'identità gestita, vedere Accedere ad Azure con un'identità gestita usando Azure PowerShell

Concetti relativi alle chiavi di identità federate

  • Un'identità federata consente alle entità servizio (registrazioni dell'app) e alle identità gestite assegnate dall'utente di considerare attendibili i token da un provider di identità esterno (IdP), ad esempio GitHub o Google.
  • Dopo aver creato la relazione di trust, il carico di lavoro del software esterno scambia token attendibili dal provider di identità esterno per i token di accesso da Microsoft Identity Platform.
  • Il carico di lavoro software usa tale token di accesso per accedere alle risorse protette di Microsoft Entra a cui viene concesso l'accesso al carico di lavoro.
  • Le identità federate sono spesso la soluzione migliore per gli scenari seguenti:
    • Carico di lavoro in esecuzione in qualsiasi cluster Kubernetes
    • GitHub Actions
    • Carico di lavoro in esecuzione su piattaforme di calcolo di Azure con identità dell'applicazione
    • Google Cloud
    • Amazon Web Services (AWS)
    • Carico di lavoro in esecuzione nelle piattaforme di calcolo all'esterno di Azure

Per altre informazioni sulle identità federate, vedere:

Altre informazioni sull'autenticazione a più fattori

Il sito della documentazione di Microsoft Entra ID offre maggiori dettagli su MFA.

Vedere anche

  • Last updated on