Informazioni sulle identità dei carichi di lavoro

7 minuti

I flussi di lavoro di distribuzione, le applicazioni e il software richiedono un modo speciale per eseguire l'autenticazione. In questa unità verrà illustrato perché le identità dei carichi di lavoro sono importanti per i flussi di lavoro di distribuzione, come si integrano nel modello di sicurezza di Azure e come funzionano.

Perché un flusso di lavoro deve eseguire l'autenticazione?

Quando si distribuisce un file Bicep, di fatto si chiede ad Azure Resource Manager di creare o modificare le risorse di Azure. Nello scenario di esempio è stato creato un file Bicep per distribuire il sito Web dell'azienda di giocattoli. Il file Bicep dichiara le risorse, tra cui un piano di servizio app di Azure, un'app e un'istanza di Application Insights.

Quando si distribuisce il file, Resource Manager controlla se le risorse esistono. In caso contrario, verranno create da Resource Manager. Se esistono già risorse, Resource Manager verifica che la configurazione corrisponda a quella specificata nel file Bicep.

Tutte queste operazioni richiedono un'autorizzazione in quanto accedono alle risorse di Azure e le modificano. Le autorizzazioni specifiche necessarie per la distribuzione dipendono dal contenuto del file Bicep. Per distribuire il file di esempio per il sito Web dell'azienda di giocattoli, sono necessarie le autorizzazioni seguenti all'interno del gruppo di risorse in cui si esegue la distribuzione:

Possibilità di creare distribuzioni. Le distribuzioni sono risorse con un tipo Microsoft.Resources/deployments.
Possibilità di creare e modificare piani di servizio app e app.
Possibilità di creare e modificare istanze di Application Insights.

Fino a questo momento è probabile che i file Bicep siano stati distribuiti manualmente usando l'interfaccia della riga di comando di Azure o Azure PowerShell. Quando si usano questi strumenti, in genere si usa il proprio account utente e si esegue l'autenticazione nel browser. In questo caso si usa la propria identità. Quando si invia una distribuzione, Azure verifica che l'identità abbia le autorizzazioni necessarie per eseguire le operazioni specificate dal modello Bicep.

Quando si passa a un flusso di lavoro di distribuzione di GitHub Actions, è necessario usare un tipo di identità diverso perché il flusso di lavoro esegue le distribuzioni automaticamente senza il coinvolgimento diretto dell'utente.

Tipi di identità

Microsoft Entra ID è il servizio che gestisce le identità per Azure. Alcuni dei tipi di identità principali sono:

Identità utente: un utente rappresenta una persona, che in genere accede in modo interattivo usando un browser. Gli utenti devono spesso eseguire controlli di sicurezza aggiuntivi quando effettuano l'accesso, ad esempio l'autenticazione a più fattori (MFA) e l'accesso condizionale in base alla posizione o alla rete.
Gruppi: un gruppo rappresenta una raccolta di utenti. I gruppi non si autenticano direttamente, ma costituiscono un modo pratico per assegnare in blocco le autorizzazioni a un set di utenti.
Identità del carico di lavoro: un carico di lavoro è un processo o un sistema automatizzato, che in genere non viene eseguito direttamente da una persona. Un carico di lavoro può accedere a Microsoft Entra ID senza che sia presente una persona a effettuare l'accesso e interagire con il processo di autenticazione. Le identità dei carichi di lavoro non hanno l'autenticazione a più fattori o protezioni simili, che richiedono l'intervento di una persona per dimostrare la propria identità.

Questo modulo è incentrato sulle identità dei carichi di lavoro.

Identità gestite

Un'identità gestita è associata a una risorsa di Azure. Azure gestisce automaticamente le credenziali. Quando la risorsa deve accedere a un elemento, Azure esegue automaticamente l'accesso usando le credenziali.

Le identità gestite sono disponibili per le risorse ospitate da Azure, ad esempio le macchine virtuali e le app di Servizio app. Offrono alle risorse di Azure la possibilità di autenticarsi efficacemente in situazioni come l'automazione della gestione di Azure, la connessione ai database e la lettura dei dati dei segreti da Azure Key Vault. È possibile usare le identità gestite con Azure Arc anche per altri scenari.

Quando si lavora con i flussi di lavoro di distribuzione, in genere non si usano le identità gestite. Le identità gestite richiedono infatti che l'utente sia proprietario delle risorse di Azure che eseguono le distribuzioni e che gestisca tali risorse. Quando si usa GitHub Actions, in genere ci si affida all'infrastruttura condivisa fornita da Microsoft o da GitHub. Tuttavia, quando si usa un'identità del carico di lavoro con GitHub Actions, si ottiene il vantaggio principale delle identità gestite: non è necessario gestire le credenziali.

Suggerimento

In altri ambiti della soluzione, se è possibile scegliere tra l'uso di un'identità gestita o di una normale entità servizio, è meglio preferire un'identità gestita. Le identità gestite sono più facili da usare e in genere più sicure.

Perché non è possibile usare solo l'account utente?

Ci si potrebbe chiedere perché è necessario creare questo nuovo tipo di oggetto solo per autenticare un flusso di lavoro di distribuzione, quando gli account utente funzionano già perfettamente.

Gli account utente non sono progettati per essere usati in modo automatico. Il processo di autenticazione per un account utente spesso controlla che un essere umano sia l'entità che sta cercando di eseguire l'accesso. Le organizzazioni usano sempre più spesso controlli di sicurezza aggiuntivi durante l'autenticazione. Questi controlli includono l'autenticazione a più fattori, i controlli CAPTCHA e l'esame del dispositivo e della rete che l'utente sta usando in modo da poter verificare la legittimità di una richiesta di accesso.

I flussi di lavoro sono progettati per eseguire le distribuzioni anche quando non è presente una persona per eseguirle attivamente. Molti dei vantaggi dei flussi di lavoro di distribuzione sono infatti legati al fatto che si tratta di attività automatizzate che non richiedono l'interazione umana.

Se si archiviano il nome utente e la password in un flusso di lavoro e si prova a usarli per l'accesso, probabilmente non funzioneranno. Anche se sembrano funzionare, è probabile che non sarà così in futuro se l'amministratore di Microsoft Entra ID o dell'organizzazione aggiunge altri controlli di sicurezza al processo di autenticazione utente.

Avviso

Non è inoltre una buona idea salvare il nome utente e la password ovunque, perché qualcun altro potrebbe accedervi e usarli rappresentando l'utente.

Per questi motivi, le attività predefinite di GitHub Actions che interagiscono con Azure non consentono di specificare le credenziali di un account utente. Richiedono l'uso di un'identità del carico di lavoro.

Come funzionano le identità del carico di lavoro?

Le identità del carico di lavoro sono una funzionalità di Microsoft Entra ID, ovvero un servizio di identità globale. Molte aziende usano Microsoft Entra ID e ognuna viene chiamata tenant.

Alla sfera di Microsoft Entra ID appartiene il concetto di applicazione, che rappresenta un sistema, un software, un processo o un altro agente non umano. Un flusso di lavoro di distribuzione può anche essere considerato un'applicazione.

Quando si crea un'applicazione e lo si comunica a Microsoft Entra ID, si crea un oggetto detto registrazione dell'applicazione. Una registrazione dell'applicazione rappresenta l'applicazione in Microsoft Entra ID.

A una registrazione dell'applicazione possono essere associate credenziali federate. Le credenziali federate non richiedono l'archiviazione di segreti. Consentono invece a un servizio supportato come GitHub di usare un'applicazione Microsoft Entra.

Quando il flusso di lavoro GitHub Actions deve eseguire l'autenticazione, contatta Microsoft Entra ID tramite GitHub. GitHub indica a Microsoft Entra ID il nome dell'organizzazione e del repository GitHub e, facoltativamente, altre informazioni. Se è stata configurata una credenziale federata corrispondente ai dettagli del repository, Microsoft Entra autentica il flusso di lavoro di distribuzione. Il flusso di lavoro può usare le autorizzazioni assegnate all'applicazione.

Suggerimento

Quando si osserva una registrazione dell'applicazione nel portale di Azure, si noteranno molte altre funzionalità e configurazioni che potrebbero non sembrare pertinenti. Ecco perché le applicazioni possono eseguire in Microsoft Entra ID molte operazioni che esulano dall'ambito dell'autenticazione e delle distribuzioni dei flussi di lavoro.

È anche possibile creare un oggetto entità servizio nel tenant di Microsoft Entra. Un'entità servizio è simile a una copia dell'applicazione che verrà usata dal proprio tenant di Microsoft Entra. Le entità servizio e le applicazioni sono strettamente collegate. Si userà un'entità servizio più avanti in questo modulo, quando si concederà al flusso di lavoro l'autorizzazione per accedere ad Azure.

Nota