#azurekeyvault

In questo articolo ci dedicheremo all'approfondimento di un aspetto molto importante che riguarda le impostazioni di sicurezza introdotte con ASP.NET Core: le Data Protection APIs, ovvero le interfacce che determinano il funzionamento delle chiavi di sicurezza utilizzate all'interno della nostra applicazione. Come probabilmente già molti sviluppatori sapranno, le applicazioni ASP.NET Core utilizzano infatti un set di chiavi di sicurezza per effettuare molteplici attività di encrypt, decrypt e convalida dei vari token che vengono rilasciate dai vari middleware di autorizzazione e autenticazione: bearer token, cookie di sessione, antiforgery, token che identificano le richieste di cambio password dell'utente, etc.; ciascuno di questi token viene generato automaticamente dall'applicazione utilizzando un set di chiavi di sicurezza univoco, così da minimizzare i rischi che un attacker possa dotarsi degli strumenti necessari per poter generare token "validi". Per impostazione predefinita, queste chiavi di sicurezza vengono generate in memoria nel momento in cui l'applicazione viene avviata. Si tratta di una strategia indubbiamente molto efficace per prevenire gli attacchi malevoli di cui sopra, ma è certamente poco pratico per la gestione ordinaria della maggior parte delle applicazioni: in questo modo, infatti, ogni volta che la app viene riavviata saranno generate delle nuove chiavi di sicurezza, rendendo impossibile effettuare il decrypt o l'identificazione dei contenuti crittografati precedentemente rilasciati: in termini pratici questo significa che, ad esempio, tutti i cookie crittografati rilasciati fino a quel momento (tra cui i cookie di sessione, i cookie "ricordati di me" etc) saranno considerati invalidi, costringendo gli utenti a inserire nuovamente le credenziali. Questo tipo di inconvenienti possono essere trascurabili  quando la nostra web application viene lanciata nell'environment di sviluppo (Development) o in un ambiente di Staging, ma potrebbero risultare molto fastidiosi per la nostra user base quando la nostra app viene pubblicata su un server di Produzione. Per ovviare a questo problema, è possibile configurare un behavior diverso da quello predefinito utilizzando l'apposito metodo services.AddDataProtection() all'interno del file Startup.cs. (o Program.cs, per le app sviluppate a partire da .NET 6). Nell'esempio seguente, ad esempio, viene chiesto all'applicazione di generare le chiavi su un'apposita cartella /App_Keys/ (presente su FileSystem) e rigenerate ogni 90 giorni: services.AddDataProtection() .SetApplicationName("myApp") .SetDefaultKeyLifetime(TimeSpan.FromDays(90)) .PersistKeysToFileSystem(new DirectoryInfo("/App_Keys/")); } Affinché il codice di cui sopra funzioni, è necessario svolgere le seguenti operazioni sulla macchina server: - Creare la cartella /App_Keys/ all'interno del folder di pubblicazione. - Impostare i permessi di scrittura per l'utente IIS_IUSRS (o dell' utente relativo all'Application Pool utilizzata). In assenza di questa cartella o dei permessi di scrittura l'applicazione in produzione darà errore, in quanto non riuscirà a memorizzare le chiavi di sicurezza su disco. Ovviamente l'ipotesi di persistere le chiavi di sicurezza su FileSystem è solo una delle possibili alternative: le Data Protection APIs consentono di implementare soluzioni di memorizzazione anche più sicure ed efficaci, come ad esempio mediante l'utilizzo di Azure Key Vault o altri Key Storage Providers, ovvero servizi che consentono la memorizzazione sicura delle credenziali. Per maggiori informazioni, consigliamo di consultare la guida alla configurazione dei Key Storage Providers su Microsoft Docs.

Riferimenti utili

¡Hola! Ésta será la última parte de esta serie, por si no recordas bien o queres repasar las anteriores, acá están los links:

T1:E1 - Introducción

T1:E2 - Usos Básicos

T1:E3 - Login Automático

Haciendo un breve repaso de la serie, básicamente hemos visto las librerías básicas para interactuar con Azure utilizando PowerShell. Vimos ejemplos de éstas interacciones y la forma de automatizar 100% nuestros scripts para que no requieran interacción alguna con el usuario.

En esta última parte de la serie, vamos a abordar un tema que quedó pendiente en la anterior: no exponer nuestras credenciales a simple vista en el Script. Imagínense lo poco seguro que sería tener la contraseña a simple vista en nuestro script, algo como  $password = "martin123" probablemente nos llevaría (con suerte) a un reto en una inspección de auditoria. Incluso si somos cuidadosos con el script, nos restringe la posibilidad de compartirlo para mostrar la lógica, o subirlo a un repositorio público de github para compartir conocimiento. Por esta razón, el broche de oro de esta serie tendrá foco en formas comunes de evitar exponer nuestras credenciales. Para esto veremos 2 formas, cada una con sus ventajas y desventajas.

Una particularidad de esta entrada en el blog, es que finalmente me mude definitivamente a Linux. Por lo que verán que las rutas a los archivos no comienzan con C:/ como en windows, pero a los fines prácticos es lo mismo. También mencionaré que para esta oportunidad estaré usando el módulo Az para comunicarme con Azure, en lugar de AzureRM como venia haciéndolo en entregas anteriores (ya expliqué sus diferencias, y como llevar los comandos de uno a otro de forma simple).