Condividi tramite

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

  • Articolo

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

Nota

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

  • autenticazione interattiva: MFA (autenticazione a più fattori) viene attivata durante gli accessi interattivi quando si usa 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.

  • fallimenti di accesso con script: in scenari di automazione come l'esecuzione automatica di script di Azure PowerShell, un'identità utente abilitata per l'autenticazione multifattoriale causa il fallimento dello script durante il tentativo di 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 principale del 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 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.

  • Accedere 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 la verifica o la conformità: casi in cui le azioni devono essere verificabili 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à principale del 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 di Connect-AzAccount con un account utente umano e una password di Microsoft Entra ID, seguire questi passaggi:

  1. Determina quale identità del carico di lavoro è la migliore per te.

    • Principale del servizio
    • 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 usando Azure PowerShell.

  5. Aggiornare gli script di Azure PowerShell per accedere con un principal del 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 principale del 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 di Microsoft Entra ID.

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:
    • sistema assegnato: questo tipo è un collegamento di accesso 1:1 (uno a uno) tra due risorse di Azure.
    • 'utente assegnato: 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 ai principali del servizio (registrazioni delle applicazioni) e alle identità gestite assegnate dall'utente di fidarsi dei token provenienti 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 i token attendibili dal provider di identità esterno con i token di accesso dalla piattaforma di identità Microsoft.
  • Il carico di lavoro software utilizza tale token di accesso per accedere alle risorse protette di Microsoft Entra per le quali ha l'autorizzazione.
  • 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