L'architettura di una soluzione moderna prevede nella maggior parte dei casi la presenza di molti attori che lavorano tra di loro. I nostri applicativi non sono rappresentati solamente dalla parte computazionale, che nel mondo di Microsoft Azure trova posto in una Web App, ma usufruiscono di un database, come SQL Database o CosmosDB, necessitano di un bus di comunicazione, come Service Bus, e memorizzano file su un servizio come Blob Storage.

Tutti questi servizi sono praticamente raggiungibili pubblicamente e, salvo qualche limitazione che possiamo dare sui firewall, la loro sicurezza è affidata alla crittografia del canale di comunicazione, tipicamente HTTPS/TLS, e all'autenticazione / autorizzazione affidata a chiavi d'accesso. Ad eccezione di SQL Database che sfrutta username/password, gli altri servizi si basano sulle Access Key: due chiavi di accesso che vengono erogate per ogni rispettivo servizio. Esse andrebbero teoricamente ruotate nell'uso invalidando la precedente chiave, al fine di limitare potenziali danni o furto di dati nel caso la chiave d'accesso sia compromessa.

Oltre a questi servizi di Azure, inoltre, il nostro applicativo può necessitare di altre chiavi, valori segreti, certificati e materiale di qualsiasi genere che possa essere sensibile al furto o all'utilizzo improprio. Gestire queste informazioni non è facile perché dobbiamo osservare le seguenti buone norme:

• Non inserire mai chiavi nel codice sorgente: rimarrebbe poi traccia nello storico;
• Dare agli sviluppatori solo chiavi di test e non di produzione;
• Avere il controllo di chi ha visione di queste chiavi;
• Mantenere le chiavi al sicuro, crittografandole.

Dai framework, come ASP.NET Core, passando per gli strumenti di sviluppo, come Visual Studio, fino ai controlli sorgenti, come GitHub, ci vengono in aiuto con strumenti che tengono private certe informazioni o ci avvisano se le stiamo condividendo.

Quando poi andiamo su Microsoft Azure sappiamo che è buona norma inserire le chiavi negli application settings, direttamente nel portale, le quali vengono custodite in modo sicuro e vanno a sovrascrivere eventuali impostazioni del nostro codice. Questo però può non bastare perché chi amministra la web app o una virtual machine ha anche accesso a queste chiavi, nonostante possa avere questi permessi solo per motivi tecnici (supporto e manutenzione). Gli applicativi possono essere molteplici e di conseguenza perdiamo in poco tempo la fotografia di chi ha accesso alle risorse, rendendo complicate operazioni di rinnovo ciclico delle chiavi, costringendoci ad inseguire le chiavi laddove sono state utilizzate.

Insomma, serve qualcosa di diverso che sposti la detenzione delle chiavi e semplifichi gli aspetti di distribuzione degli applicativi. Managed Identities per Azure, già Managed Service Identity (MSI), è una funzionalità di Azure Active Directory (AAD) che soddisfa questi aspetti e si integra nella maggior parte dei servizi disponibili sulla piattaforma.

Come funziona Managed Identities

L'idea che sta alla base di MSI consiste nel dare ad ogni applicativo o macchina virtuale un'identità, come se fosse un utente, e su di essa dare i permessi di accesso ad altri servizi, sempre della piattaforma Azure. Di conseguenza non è più l'applicativo a veicolare chiavi verso i servizi, ma è l'applicativo stesso che si rappresenta e lo fa attraverso un access token che deve presentare in alternativa alle chiavi. Questo viene rilasciato da AAD ed ha tutte le caratteristiche di un token, perciò scade, ed è onere dell'applicativo quindi tenerlo aggiornato. I permessi non sono contenuti nel token stesso, ma vengono controllati dalla risorsa finale, così da garantire gli immediati effetti qualora cambiassimo le caratteristiche di un'identità.

Lo schema sottostante, proveniente dalla documentazione ufficiale Microsoft, ci mostra gli attori e le fasi coinvolte.

Le fasi sono:

1. Viene richiesto di creare un'identità tramite Azure Resource Manager (ARM);
2. ARM crea un'identità all'interno del tenant di AAD;
3. In caso di macchina virtuale (VM) vengono aggiornate le informazioni locali e un'estensione che permette il rilascio del token locale (verrà deprecato). Nel caso di una Web App, vengono aggiunte due variabili d'ambienti nel runtime;
4. Diamo i permessi ai servizi per l'identità creata;
5. Il nostro codice si rivolge a Azure Instance Metadata Service (IMDS) per farsi rilasciare un token tramite flusso client credentials per la risorsa desiderata;
6. IMDS chiede a AAD di farsi rilasciare un JSON Web Token (JWT);
7. Il nostro codice accompagna le richieste alla risorsa con il token rilasciato.

I primi 4 passaggi devono essere eseguiti una tantum, mentre il resto viene eseguito poi ad applicativi avviati. Quello che può sembrare un meccanismo complicato e lungo, in realtà si dimostra molto più semplice nel suo utilizzo grazie al supporto del portale, di PowerShell, di CLI e degli SDK.

Partiamo quindi prima di tutto nel capire come creare le identità.