Azure Managed Identities: migliorare l’autenticazione delle applicazioni in Azure e Microsoft 365

Che sia l’automazione di operazioni ripetitive, la gestione standardizzata di eventi, o la semplice necessità di spostare script dall’esecuzione periodica dai server on-premise ad Azure, è importante che la gestione delle identità applicative venga fatta in modo corretto, evitando quando possibile di impersonare un utente con tutte le controindicazioni del caso. In questo articolo vediamo i vantaggi di utilizzare le Azure managed identities e qualche caso d’uso.

Che cosa sono le Managed Identities?

Le Managed Identities sono un sistema sviluppato per migliorare la gestione delle identità applicative usate nel mondo di Microsoft Entra ID. Esse semplificano di molto la creazione e l’usufrutto dei cosiddetti “Service Principal” per l’autenticazione delle risorse Azure che lo supportano verso altri servizi nel mondo Microsoft.

Esistono due tipi di Managed Identity:

  • System-assigned: questo tipo di managed identity è il più semplice, il suo utilizzo è infatti guidato da Microsoft, viene infatti creata in pochi click direttamente dalla pagina di amministrazione della risorsa Azure a cui vogliamo associarla, ed a cui rimarrà legata senza possibilità di modifica fino alla disattivazione della stessa, oppure all’eliminazione completa della risorsa.

    Immagine che mostra la pagina di attivazione della system assigned managed identity all'interno della pagina della risorsa.
    Figura 1 – Pagina per l’attivazione della system assigned managed identity
  • User-assigned: in questo caso la managed identity si concretizza in una risorsa Azure indipendente dal servizio che la utilizzerà, potrà essere riutilizzata in seguito alla dismissione oppure assegnata contemporaneamente a più risorse Azure usufruenti. Potrà essere istanziata dal marketplace

    Immagine rappresentante la pagina dell'Azure marketplace dedicata alla user assigned managed identity
    Figura 2 – User assigned managed identity nel marketplace

    per poi essere associata nella pagina dedicata nella risorsa:

    Immagine raffigurante la pagina dedicata all'associazione delle user assigned managed identity alla risorsa che ne usufruisce
    Figura 3 – Pagina di associazione delle user assigned managed identity alla risorsa

Relazione tra Managed Identity ed Enterprise Application

Alla creazione della Managed Identity (indipendentemente dal tipo) viene creata un’Enterprise Application all’interno del nostro tenant. Quest’ultima rappresenterà il service principal autenticato quando verranno effettuate le operazioni sul tenant MS 365. È importante capire che il sistema di managed identity non è un vero e proprio service principal autorizzabile, ma è si limita a semplificare, all’interno del mondo Microsoft, l’autenticazione delle risorse Azure con l’enterprise application, sollevando gli sviluppatori dall’onere di gestire client secret o certificati, necessari per l’autenticazione applicativa prima dell’introduzione di questo nuovo sistema, o ancora oggi per client non ospitati in Azure. Ciò è verificabile nella colonna relativa alla scadenza del certificato dell’enterprise app collegata alla managed identity, dove è specificato che esso è gestito da Microsoft:

Immagine che dimostra il fatto che la modalità di autenticazione (certificato) della risorsa Azure verso l'enterprise app viene gestita da Microsoft
Figura 4 – Come appare l’enterprise app legata ad una managed identity,

Assegnazione dei diritti

Una volta attivata la managed identity, dovremo autorizzarla ad accedere ai dati / effettuare le modifiche necessarie.

Diritti su un’altra risorsa Azure

Questa è la casistica più semplice, in quanto durante il processo di assegnazione ruoli su una risorsa Azure (quella da utilizzare / manipolare), ci viene esplicitamente richiesto se il nuovo assegnatario è un utente / gruppo di utenti, oppure una managed identity, a quel punto sarà sufficiente selezionare la seconda opzione e specificare qual è la nuova idenità applicativa che dovrà avere il diritto in questione.

Immagine raffigurante l'aggiunta di un diritto su una risorsa Azure per una managed identity
Figura 5 – Aggiunta di un diritto alla managed identity

Diritti di accesso al tenant Microsoft 365

Questa seconda casistica riguarda i diritti di accesso ai dati con cui possono interagire anche gli utenti, ad esempio un sito SharePoint Online, una mailbox di Exchange Online oppure una programmazione dei turni effettuata con Shifts.

La nuova modalità con cui Microsoft abilita l’accesso degli applicativi a questi dati è Microsoft Graph, le API messe a disposizione da questo servizio possono interagire con la quasi totalità dei servizi Microsoft 365. Tuttavia, contrariamente alle app registration, le enterprise application non presentano ancora alcuna interfaccia GUI per l’attivazione granulare degli ambiti MS Graph (noti come “Scopes”), pertanto sarà necessario procedere tramite PowerShell.

Per effettuare tale assegnazione sarà necessario aver installato il modulo “Microsoft.Graph.Applications” e possedere un’utenza abilitata agli ambiti MS Graph descritti alla seguente pagina: Grant an appRoleAssignment to a service principal.

NB: l’abilitazione dell’utenza agli ambiti MS Graph avviene al momento dell’assegnazione di certi ruoli Entra ID all’utenza stessa, i ruoli abilitanti sono descritti alla stesso link riportato sopra.

Procedere quindi con:

Step

Comando

Descrizione

1

$managedIdentityObjID = “<Inserire ID>”

Definizione della variabile contenente l’object ID dell’enterprise application da autorizzare.

2

$ambitoGraph = “<Inserire identificativo ambito Graph>”

Definizione della variabile contenente il nome dell’ambito MS Graph da assegnare all’enterprise app.

3

Connect-MgGraph -Scope AppRoleAssignment.ReadWrite.All

Connessione a Microsoft Graph (verrà aperto il prompt di autenticazione utente).

4

$graphSPs = Get-MgServicePrincipal -Filter “AppId eq ‘00000003-0000-0000-c000-000000000000′”

Scarico i service principal di Microsoft Graph

5

$ruoloAppGraph = $graphSPs.AppRoles | Where-Object {$_.Value -eq $ambitoGraph}

Effettuo il filtro per ottenere l’oggetto rappresentate l’ambito MS Graph da autorizzare all’enterprise app.

6

$assegnazioneRuolo = @{
“principalId” = $managedIdentityObjID
“resourceId” = $graphSPs.Id
“appRoleId” = $ruoloAppGraph.Id
}

Preparo l’oggetto con cui verrà effettuata l’assegnazione del ruolo Graph, tale oggetto contiene il principalId (Object ID dell’enterprise app), il resourceId (ID univoco del service principal MS Graph) e l’ID del ruolo MS Graph che dobbiamo autorizzare, ottenuto tramite il comando precedente partendo dal nome del ruolo stesso.

7

New-MgServicePrincipalAppRoleAssignment
-ServicePrincipalId $managedIdentityObjID
-BodyParameter $assegnazioneRuolo

Questo comando esegue l’effettiva assegnazione del ruolo MS Graph tramite gli oggetti passati come parametri.

Se non vengono visualizzati messaggi di errore l’assegnazione è avvenuta con successo, tuttavia se volessimo verificare (subito o in seguito) gli ambiti MS Graph abilitati sull’applicazione sarà possibile utilizzando il comando:

Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId ‘<Inserire ID>’ | Format-List

Per rimuovere eventuali abilitazioni ad ambiti non più necessari, è possibile utilizzare la cmdlet Remove-MgServicePrincipalAppRoleAssignment documentata a questo link.

Nota importante: quando si abilitano le applicazioni all’utilizzo degli ambiti Graph è fondamentale limitare l’accesso ai dati in modo da rispettare il principio “least privilege”. A titolo esemplificativo (ma non esaustivo) riporto che:

  • Per SharePoint Online è possibile utilizzare l’ambito “Sites.Selected” per autorizzare l’accesso dell’app solo ai siti per cui lo necessita, per approfondire lascio il link alla documentazione ufficiale;
  • Per Exchange Online sarà necessario utilizzare un’application access policy per le quali lascio il link per approfondire;
  • Per quanto riguarda Microsoft Teams il meccanismo di limitazione prende il nome di “resource specific consent” ed è documentato qui.

Diritti amministrativi sul tenant Microsoft 365

Un’altra esigenza che dovremmo poter fronteggiare è quella di automatizzare operazioni che richiedono diritti di amministrazione sul tenant.

Anche in questo caso dovremo ricorrere alla PowerShell per concedere all’app i diritti necessari, in quanto l’interfaccia grafica ancora non ci consente di assegnarle tutti i ruoli amministrativi.

Step

Comando

Descrizione

1

$nomeRuolo = “<Nome del ruolo da assegnare>”

Definizione della variabile contenente il nome del ruolo amministrativo da assegnare all’enterprise app.

2

$managedIdentityObjID = “<Inserire il service principal ID>”

Definizione della variabile contenente l’object ID dell’enterprise application.

3

Connect-MgGraph -Scopes “Application.Read.All”,”RoleManagement.Read.Directory”,”User.Read.All”, “RoleManagement.ReadWrite.Directory”

Connessione a MS Graph con gli ambiti necessari per per l’assegnazione di ruoli.

4

$definizioneRuolo = Get-MgRoleManagementDirectoryRoleDefinition -Filter “DisplayName eq ‘${nomeRuolo}'”

Salvataggio dell’oggetto rappresentatne la definizione del ruolo.

5

New-MgRoleManagementDirectoryRoleAssignment -DirectoryScopeId “/” -RoleDefinitionId $definizioneRuolo.Id -PrincipalId $managedIdentityObjID Assegnazione del ruolo all’enterprise App

Anche in questo caso, se non riceviamo messaggi di errore l’operazione sarà andata a buon fine, nel caso in cui volessimo verificare i ruoli assegnati ad una determinata app potremo usare il comando Get-MgRoleManagementDirectoryRoleAssignment -Filter “PrincipalId eq ‘<Inserire il service principal ID>’”, il comando è documentato in modo approfondito a questa pagina.
Inoltre, è opportuno valutare la limitazione dei privilegi alle administrative units (se implementate) per cui sono necessari, anche se bisogna considerare che non tutti i ruoli supportano tale funzionalità.

Utilizzo con un Azure Automation Account

Per sfruttare i diritti concessi alla managed identity legata all’automation account dovremo prima di tutto creare un runbook, in questo caso di tipo PowerShell, ed installare il modulo di nostro interesse.

Controllare altre risorse Azure

Nel caso di dover controllare un’altra risorsa Azure il modulo da installare sarà Azure PowerShell, che con la cmdlet “Connect-AzAccount -Identity” eseguita all’interno del runbook, utilizzerà la managed identity per autenticarsi.

NB: il modulo Azure PowerShell contiene al suo interno tutti i “sotto-moduli” per il controllo delle varie tipologie delle risorse Azure, pertanto dovremo importare solamente quelli che necessitiamo. Ad esempio, il modulo Az.Accounts è quello necessario per l’autenticazione (sempre necessario), mentre Az.Automation è quello dedicato al controllo degli automation accounts.

Utilizzare le API di Graph per accedere a dati presenti nel tenant Microsoft 365

In questo caso dovremo usare i sotto-moduli di “Microsoft.Graph”, a partire da Microsoft.Graph.Authentication da cui dipendono tutti gli altri in quanto mette a disposizione il comando “Connect-MgGraph -Identity” per consentirci l’autenticazione con la managed identity. Successivamente sarà necessario determinare quali sono i dati con cui dobbiamo interagire all’interno di MS 365 per portarci a capire quali sono i relativi moduli PowerShell contenenti i comandi corretti.

Moduli per l’amministrazione del tenant Microsoft 365

Contrariamente alle due casistiche viste sopra, l’amministrazione di Microsoft 365 avviene attraverso moduli diversi, slegati tra loro, pertanto sarà necessario esaminare il comando di connessione a ciascuno di questi per determinare quale sia il parametro per sfruttare la managed identity, nei riferimenti ci saranno alcuni esempi.

Conclusione

Le managed identity sono uno strumento molto utile per gestire l’autenticazione di applicazioni e automatismi all’interno di Azure, purtroppo non sempre l’autorizzazione ad operare in certi ambiti è documentata ed alcuni portali ancora non sono stati aggiornati per effettuare tali abilitazioni.

Riferimenti esterni

Connettersi ad Azure con il modulo PowerShell con la managed identity

Connettersi a Microsoft Teams con il modulo amministratore e la managed identity

Connettersi ad Exchange Online con PowerShell e la managed identity

Documentazione ufficiale sulle managed identities