Creare un'entità servizio e una chiave
Dopo aver chiarito il concetto di entità servizio, verrà illustrato come quest'ultima dimostra la propria identità a Microsoft Entra ID. In questa unità verranno fornite informazioni sul processo di autenticazione e sulle credenziali per le entità servizio. Si apprenderà anche come creare un'entità servizio e come assegnarle una chiave.
Comprendere come vengono autenticate le entità servizio
Quando un'entità servizio deve comunicare con Azure, accede a Microsoft Entra ID. Dopo aver verificato l'identità dell'entità servizio,Microsoft Entra ID rilascia un token che viene archiviato dall'applicazione client e usato per effettuare le richieste ad Azure.
In generale, questo processo è simile a quello dell'accesso di un utente ad Azure. Tuttavia, per dimostrare la propria identità, le entità servizio usano un tipo di credenziale leggermente diverso da quello degli utenti. Le entità servizio usano due credenziali principali: chiavi e certificati.
Nota
Tenere presente che le identità gestite sono entità servizio speciali che funzionano all'interno di Azure. Hanno un tipo diverso di processo di autenticazione in cui non è necessario che l'utente conosca o gestisca le credenziali.
Chiavi
Le chiavi sono simili alle password, ma sono molto più lunghe e più complesse. Infatti, per la maggior parte delle situazioni, Microsoft Entra ID genera delle chiavi atte a garantire che:
- Le chiavi siano casuali dal punto di vista crittografico. Ciò significa che sono estremamente difficili da indovinare.
- Le persone non usino accidentalmente password vulnerabili come chiavi.
Le entità servizio spesso hanno autorizzazioni con privilegi molto elevati, quindi è fondamentale che siano sicure. In genere, è necessario gestire la chiave solo brevemente quando si configurano per la prima volta l'entità servizio e la pipeline. Non è quindi necessario che la chiave sia facile da ricordare o da digitare.
Una singola entità servizio può avere più chiavi contemporaneamente, mentre gli utenti non possono avere più password. Analogamente alle password, le chiavi hanno una data di scadenza. Questo aspetto verrà analizzato più in dettaglio a breve.
Nota
Le chiavi possono essere considerate come password molto importanti, simili alle chiavi degli account di archiviazione. È consigliabile applicarvi lo stesso livello di sicurezza e attenzione.
Certificati
I certificati sono un altro modo per autenticare le entità servizio. Sono molto sicuri, ma possono essere difficili da gestire. Alcune organizzazioni richiedono l'uso dei certificati per determinati tipi di entità servizio.
I certificati esulano dall'ambito di questo modulo. Se tuttavia si lavora con un'entità servizio che usa l'autenticazione del certificato, la gestione e la concessione dell'autorizzazione per la pipeline sono fondamentalmente analoghe a quelle per qualsiasi altra entità servizio.
Nota
I certificati sono una buona opzione quando è possibile usarli. Per gli utenti malintenzionati è più difficile rubarli. È anche più difficile intercettare e modificare le richieste che usano i certificati. I certificati richiedono tuttavia un'infrastruttura più estesa e una manutenzione continua.
Usare le chiavi per le entità servizio
Quando si crea un'entità servizio, in genere si chiede ad Azure di creare contemporaneamente anche una chiave. Azure di solito genera automaticamente una chiave casuale.
Nota
Ricordi quando avevamo parlato del funzionamento delle entità servizio? Le chiavi vengono archiviate come parte dell'oggetto della registrazione dell'applicazione. Se si apre il portale di Azure, si esamina la configurazione di Microsoft Entra e quindi si passa alle registrazioni delle applicazioni, è possibile anche creare ed eliminare le chiavi.
Azure mostra la chiave quando si crea l'entità servizio. Questa è l'unica occasione in cui Azure visualizza la chiave. Successivamente, non puoi più recuperarla. È importante copiare la chiave in modo sicuro per poterla usare quando si configura la pipeline. Non condividere la chiave tramite e-mail o altri mezzi non sicuri. Se perdi una chiave, devi eliminarla e crearne una nuova.
Gestire le entità servizio per Azure Pipelines
Quando si crea una chiave per l'entità servizio di una pipeline, è consigliabile copiare immediatamente la chiave nella configurazione della pipeline. In questo modo, si evita di archiviare o trasmettere la chiave inutilmente.
Gli strumenti delle pipeline includono modalità sicure per specificare l'ID applicazione e la chiave dell'entità servizio. Non archiviare mai credenziali di alcun tipo nel controllo del codice sorgente. Usare invece le connessioni del servizio quando si usa Azure Pipelines. In questo modulo viene illustrato solo come creare un'entità servizio e una chiave. Le informazioni su come configurare la pipeline con la chiave verranno fornite in un modulo successivo.
Suggerimento
Azure Pipelines può creare automaticamente entità servizio. In questo modulo creerai manualmente e gestirai le entità servizio per avere una migliore comprensione di ciò che accade. In altri moduli si userà il metodo di creazione automatico per semplicità.
Creare un'entità servizio e una chiave
Per creare e gestire le entità servizio, è possibile usare l'interfaccia della riga di comando di Azure.
Nota
Per creare e modificare le entità servizio devi disporre delle autorizzazioni relative in Microsoft Entra ID. In alcune organizzazioni potrebbe essere necessario rivolgersi a un amministratore per eseguire queste procedure.
Per creare un'entità servizio e una chiave, usare il comando az ad sp create-for-rbac
. Questo comando accetta diversi argomenti e facoltativamente può assegnare i ruoli all'entità servizio. Si apprenderanno altre informazioni su questo argomento più avanti in questo modulo. Per il momento, ecco un esempio che mostra come creare un'entità servizio senza assegnazioni di ruolo di Azure:
az ad sp create-for-rbac --name MyPipeline
Quando si esegue questo comando, l'interfaccia della riga di comando di Azure restituisce una risposta JSON con una proprietà password
. Questa proprietà è la chiave dell'entità servizio. Poiché non sarà possibile ottenerla di nuovo, assicurarsi di usarla immediatamente o di salvarla in una posizione sicura.
Nota
Il comando az ad sp create-for-rbac
crea una registrazione dell'applicazione in Microsoft Entra ID, aggiunge un'entità servizio al tenant di Microsoft Entra e crea una chiave per la registrazione dell'applicazione. Un altro comando, az ad sp create
, crea solo l'entità servizio nel tenant, non la registrazione dell'applicazione. Quando si creano le entità servizio per le pipeline, az ad sp create-for-rbac
è in genere il comando migliore da usare.
Per creare e gestire le entità servizio, è possibile usare i cmdlet di Azure PowerShell.
Nota
Per creare e modificare le entità servizio devi disporre delle autorizzazioni relative in Microsoft Entra ID. In alcune organizzazioni potrebbe essere necessario rivolgersi a un amministratore per eseguire queste procedure.
Per creare un'entità servizio e una chiave, usare il cmdlet New-AzADServicePrincipal
. Questo cmdlet accetta diversi argomenti e facoltativamente può assegnare i ruoli all'entità servizio. Si apprenderanno altre informazioni su questo argomento più avanti in questo modulo. Per il momento, ecco un esempio che mostra come creare un'entità servizio senza assegnazioni di ruolo di Azure:
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
Quando si esegue questo comando, Azure PowerShell popola la variabile servicePrincipal
con le informazioni sull'entità servizio, inclusa la chiave:
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
Poiché non sarà possibile ottenerla di nuovo, assicurarsi di usarla immediatamente o di salvarla in una posizione sicura.
Nota
Il cmdlet New-AzADServicePrincipal
crea essenzialmente una registrazione dell'applicazione in Microsoft Entra ID, aggiunge un'entità servizio al tenant di Microsoft Entra e crea una chiave per la registrazione dell'applicazione.
Identificare un'entità servizio
Le entità servizio hanno diversi identificatori e nomi che consentono di identificarle e usarle. Gli identificatori più usati sono i seguenti:
- ID applicazione: la registrazione dell'applicazione ha un identificatore univoco, spesso detto ID applicazione o talvolta ID client. Viene usato in genere come nome utente quando l'entità servizio accede ad Azure.
- ID oggetto: La registrazione dell'applicazione e l'entità servizio hanno ID oggetto distinti, che sono identificatori univoci assegnati da Microsoft Entra ID. In alcuni casi dovrai usare tali ID oggetto quando gestisci un'entità servizio.
- Nome visualizzato: si tratta di un nome in formato leggibile che descrive l'entità servizio.
Suggerimento
Usare un nome visualizzato chiaro e descrittivo per l'entità servizio. È importante che il team possa comprendere la funzione dell'entità servizio, in modo che nessuno la elimini accidentalmente o ne cambi le autorizzazioni.
Attenzione
Un nome visualizzato non è univoco. Più entità servizio potrebbero condividere lo stesso nome visualizzato. Fare attenzione quando si concedono le autorizzazioni a un'entità servizio usando il relativo nome visualizzato per identificarla. Si potrebbero concedere accidentalmente le autorizzazioni all'entità servizio errata. È consigliabile usare invece l'ID applicazione.
Quando si crea un'entità servizio, in genere si imposta solo il nome visualizzato. Azure assegna gli altri nomi e identificatori automaticamente.
Gestire le chiavi scadute
Le entità servizio non scadono, le chiavi invece sì. Quando si crea una chiave, è possibile configurare la relativa scadenza. Per impostazione predefinita, la scadenza viene impostata dopo un anno. Dopo la scadenza, la chiave non funziona più e la pipeline non può accedere a Microsoft Entra ID. È necessario rinnovare o ruotare regolarmente le chiavi.
Attenzione
Si potrebbe essere tentati di impostare tempi di scadenza lunghi per le chiavi, ma non è consigliabile farlo. Le entità servizio sono protette solo dalle relative credenziali. Se un utente malintenzionato ottiene la chiave di un'entità servizio, può causare molti danni. L'approccio migliore per ridurre al minimo la durata di un attacco consiste nel modificare regolarmente le chiavi. È anche consigliabile eliminare le chiavi e ricrearle se si sospetta una fuga di dati.
Per reimpostare una chiave per un'entità servizio, usare il comando az ad sp
con l'ID applicazione, come in questo esempio:
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
Puoi anche rimuovere la chiave dell'entità servizio e ricrearla in due passaggi separati usando i comandi az ad sp credential delete
e az ad sp credential reset --append
.
Per reimpostare una chiave per un'entità servizio, usare prima di tutto il cmdlet Remove-AzADServicePrincipalCredential
per rimuovere le credenziali esistenti. Usare quindi il cmdlet New-AzADServicePrincipalCredential
per aggiungere le nuove credenziali. Entrambi i cmdlet usano l'ID oggetto dell'entità servizio per l'identificazione. Prima di usare i cmdlet, è necessario ottenere tale ID dall'ID applicazione:
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
Suggerimento
Una singola entità servizio può avere più chiavi. È possibile aggiornare l'applicazione in modo sicuro per usare una nuova chiave mentre la chiave precedente è ancora valida e quindi eliminare la chiave precedente quando non è più in uso. Questa tecnica evita tempi di inattività dovuti alla scadenza della chiave.
Gestire il ciclo di vita dell'entità servizio
È importante considerare l'intero ciclo di vita di ogni entità servizio creata. Quando si crea un'entità servizio per una pipeline, che cosa accade se la pipeline viene eliminata o non viene più usata?
Le entità servizio non vengono rimosse automaticamente, quindi è necessario controllare e rimuovere le entità servizio meno recenti. È importante rimuovere le entità servizio meno recenti per lo stesso motivo per cui si eliminano gli account utente obsoleti: gli utenti malintenzionati potrebbero accedere alle relative chiavi. È preferibile non avere credenziali che non vengono usate attivamente.
È consigliabile documentare le entità servizio in una posizione a cui il team possa accedere facilmente. Per ogni entità servizio si dovrebbero includere le informazioni seguenti:
- Informazioni di identificazione essenziali, inclusi il nome e l'ID applicazione.
- Scopo dell'entità servizio.
- Utente che ha eseguito la creazione, responsabile della gestione dell'entità e delle relative chiavi e persone a cui rivolgersi in caso di problemi.
- Autorizzazioni necessarie e una spiegazione chiara del motivo per cui sono necessarie.
- Qual è la durata prevista.
È consigliabile controllare regolarmente le entità servizio per assicurarsi che siano ancora in uso e che le autorizzazioni assegnate siano ancora corrette.