Informazioni sulle entità servizio
Le entità servizio consentono di autenticare pipeline, applicazioni e software. In questa unità si apprenderà perché le entità servizio sono importanti per le pipeline di distribuzione, come si integrano nel modello di sicurezza di Azure e come funzionano.
Perché una pipeline deve autenticarsi?
Quando si distribuisce un modello Bicep, di fatto si chiede ad Azure Resource Manager di creare o modificare le risorse di Azure. In questo scenario di esempio è stato creato un modello Bicep per distribuire il sito Web dell'azienda di giocattoli. Il modello 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 modello, Resource Manager controlla se le risorse esistono. In caso contrario, verranno create da Resource Manager. Se sono già presenti risorse, Resource Manager verifica che la configurazione corrisponda a quella specificata nel modello.
Tutte queste operazioni richiedono autorizzazioni in quanto accedono alle risorse di Azure e le modificano. Le autorizzazioni specifiche necessarie per la distribuzione dipendono dal contenuto del modello. Per distribuire il modello Bicep 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 considerate 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 modelli 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.
Dopo essere passati a una pipeline, è necessario usare un tipo diverso di identità perché la pipeline stessa esegue le distribuzioni senza il coinvolgimento diretto dell'utente.
Tipi di entità di sicurezza
Microsoft Entra ID è il servizio che gestisce le identità per Azure. Microsoft Entra ID offre diversi tipi diversi di identità, dette anche entità di sicurezza:
- 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.
- 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.
- Un'entità servizio rappresenta un processo o un sistema automatizzato, che in genere non viene eseguito direttamente da una persona.
- Un'identità gestita è un tipo speciale di entità servizio ed è progettata per situazioni in cui nel processo di autenticazione non è coinvolto un essere umano.
Entità servizio
Un'entità servizio è un tipo di account. Può accedere a Microsoft Entra ID senza che sia presente una persona a effettuare l'accesso e interagire con il processo di autenticazione. Le entità servizio non hanno l'autenticazione a più fattori o protezioni simili, che richiedono l'intervento di una persona per dimostrare la propria identità.
In Microsoft Entra ID un'entità servizio è identificata da un ID applicazione e da credenziali. L'ID applicazione è un identificatore univoco globale (GUID). Per le pipeline, le credenziali sono in genere costituite da una password complessa detta chiave. In alternativa, come credenziali è possibile usare un certificato.
Identità gestite
A differenza degli altri tipi di entità servizio, un'identità gestita non richiede che l'utente conosca o gestisca le relative credenziali. 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. È anche possibile usare le identità gestite con Azure Arc per altri scenari.
Quando si lavora con le pipeline, in genere non è possibile usare 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 Azure Pipelines, in genere ci si affida all'infrastruttura condivisa fornita da Microsoft.
Nota
Esistono alcune situazioni in cui le pipeline possono usare le identità gestite. In Azure Pipelines è possibile creare un agente self-hosted per eseguire gli script e il codice della pipeline usando la propria macchina virtuale basata su Azure. Poiché si è i proprietari della macchina virtuale, è possibile assegnarle un'identità gestita e usarla dalla pipeline.
Tuttavia, nella maggior parte dei casi, le pipeline vengono eseguite usando un agente ospitato, ovvero un server gestito da Microsoft. Gli agenti ospitati non sono attualmente compatibili con le identità gestite.
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. 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 una pipeline, 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.
Le pipeline sono progettate per eseguire le distribuzioni anche quando nessuno le esegue attivamente. Molti dei vantaggi delle pipeline sono infatti legati al fatto che si tratta di attività completamente automatizzate che non richiedono l'interazione umana. Se si archiviano il nome utente e la password in una pipeline 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 della pipeline che interagiscono con Azure non consentono di specificare le credenziali di un account utente. Richiedono l'uso di un'entità servizio.
Come funzionano le entità servizio?
Quando si usano entità servizio o strumenti come il portale di Azure o l'API Microsoft Graph, è probabile che si noti l'uso di alcuni termini. Sebbene non sia essenziale comprendere questi termini per usare le entità servizio in una pipeline, è utile avere una conoscenza di base dei concetti.
Le entità servizio sono una funzionalità di Microsoft Entra ID. Microsoft Entra ID è un servizio di gestione delle 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. Una pipeline di distribuzione può essere paragonata a un'applicazione.
In Microsoft Entra ID le applicazioni possono eseguire molte operazioni che esulano dall'ambito dell'autenticazione e delle distribuzioni delle pipeline. 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.
Le entità servizio e le applicazioni sono strettamente collegate. Ogni volta che viene aggiunta una registrazione dell'applicazione a un tenant di Microsoft Entra, viene creato un oggetto entità servizio in tale tenant di Microsoft Entra. Quando si osserva un'entità servizio nel portale di Azure, si noteranno molte altre funzionalità e configurazioni che potrebbero non sembrare pertinenti, soprattutto perché le entità servizio sono collegate alle applicazioni.
Quando si crea un'entità servizio, la maggior parte degli strumenti usati crea contemporaneamente anche una registrazione dell'applicazione. Si potrebbe quindi non notare la presenza di due oggetti diversi.
Un tipo di entità servizio non è associato alla registrazione di un'applicazione: l'identità gestita. Come accennato in precedenza, Azure gestisce la configurazione e le credenziali per un'identità gestita.
Nota
Un'entità servizio è chiamata anche applicazione aziendale. Alcuni strumenti usano un nome, altri l'altro. A volte le entità servizio sono denominate anche applicazioni gestite nella directory locale, ma non sono la stessa cosa delle identità gestite.
In sintesi, quando si crea un'entità servizio, prima si crea una registrazione dell'applicazione e quindi si crea un'entità servizio che verrà usata da tale registrazione dell'applicazione. La maggior parte degli strumenti usati esegue questo processo automaticamente, senza che l'utente ne sia consapevole. Quando si usano le pipeline di distribuzione, è possibile che non si usino tutte le funzionalità di Microsoft Entra. Poiché tuttavia le entità servizio sono correlate alle applicazioni, si applica la stessa struttura di oggetti di Microsoft Entra.