Immagina questo scenario. Stai creando un'applicazione e ti serve una chiave API per connetterti a un servizio, una password di database o una chiave di account e archiviazione. Quindi la inserisci direttamente nel codice, magari in un file di configurazione, non avrai vari vari. Funziona tutto bene finché non carichi quel codice su GitHub o condividi un notebook con un collega. Ed ecco che così il tuo segreto non è più tanto segreto. Se quel codice finisce nelle mani sbagliate, l'intero sistema è esposto. Ora, Azure Key Vault è lo strumento che risolve questo problema. Ti offre un posto sicuro dove archiviare i segreti così non finiscono mai nel tuo codice. Ma ecco la cosa che molti sbagliano. Avere solo un Key Vault non ti rende automaticamente sicuro. Il modo in cui lo configuri, controlli l'accesso e assegni le autorizzazioni con te altrettanto. Alla fine di questo episodio saprai cos'è davvero Key Vault, cosa puoi memorizzarvi, come funziona l'accesso e il più grande errore che potrebbe lasciare i tuoi segreti esposti.

Tu in parole semplici, senza gergo, solo le informazioni che ti servono. Quindi cos'è esattamente Azure Key Vault? Cos'è Azure Key Vault? Ecco la definizione più semplice. Azure Key Vault è una cassaforte digitale basata su cloud per i tuoi segreti. È un servizio gestito da Microsoft per chiavi AI, password e database, stringhe di connessione, chiavi di criptografia e certificati in un unico posto centrale. Non devi preoccuparti dell'infrastruttura perché Azure gestisce patch, uptime e sicurezza. Tu devi solo usarlo. Immagina come un edificio per ufino. Hai postazioni di lavoro, sale, riunioni e schedari, ma da qualche parte nel seminterrato c'è una stanza blindata dove tieni le cose importanti. Chiavi principali con tanti documenti legali. Nessuno entra senza permesso o autenticazione. Ogni volta che qualcuno apre la porta viene registrato. Questo è Key Vault. La stanza è sicura nel seminterrato della tua architettura Azure.

Ora confrontalo con il vecchio metodo. Vent'anni fa, se ti serviva una password di database, l'avresti scritta nel codice, in un file di configurazione, magari in una variabile d'ambiente o peggio lasciata in chiaro nel codice sorgente. Se qualcuno avesse ottenuto l'accesso a quel server, avrai avuto tutto. E se avessi dovuto cambiare quella password, avresti dovuto aggiornarla ovunque. Ogni file di configurazione, ogni ambiente e ogni distribuzione era un incubo. Key Vault cambia tutto questo. Invece di spargere segreti tra codice e file di configurazione, li archivi in un unico posto centrale. Le tue applicazioni le richiedono in fase di esecuzione solo quando ne hanno bisogno. Poiché tutto è centralizzato, puoi ruotare un segreto in un unico posto e ogni applicazione che lo utilizza recupera automaticamente il nuovo valore senza modifiche al codice o ridistribuzioni. Ma ecco il punto, Key Vault non è solo un gestore di password per le due app.

È un servizio di sicurezza fondamentale. Ogni servizio è azzurro, può integrarsi con esso. App Service, Functions, HIS, Data Factory, Synapse, Logic Apps e le Pipeline DevOps sanno tutti come comunicare con Key Vault. Diventa la spina dorsale della tua architettura CloudSQ. Una volta configurato correttamente smetterai completamente di pensare alla gestione dei credenziali. Cosa puoi archiviare? Ora che sai cos'è Key Vault parliamo di cosa puoi effettivamente inserirvi. Hai tre categorie principali, segreti, chiavi e certificati. Ognuna svolge una funzione diversa e comprendere questa differenza ti aiuta a usare Key Vault nel modo corretto. Iniziamo dai segreti. Questa è la cosa che le persone archiviano più comunemente. I segreti sono stringhe di connessione, chiavi API, password di database, chiavi di account e di archiviazione, praticamente tutte le credenziali quotidiane che le tue app necessitano per comunicare con altri servizi.

Invece di inserirli nel codice o nel file di configurazione, li metti in Key Vault. La tua app li recupera durante l'esecuzione e nessuno li vedrà mai in testo normale. Immaginalo come un cassetto chiuso a chiave nel tuo archivio digitale. Successivamente abbiamo le chiave. Si tratta di chiavi di crittografia per le dati net. Se stai utilizzando chiavi gestite dal cliente per Azure Storage, database SQL o per crittografare dischi di macchine virtuali, tali chiavi possono risiedere in Key Vault. Ciò ti offre il pieno controllo su chi può usarle e quando. E se hai bisogno di chiavi supportate da hardware per motivi di conformità, il livello premium ti copre con la protezione HSM. Poi abbiamo i certificati. Certificati TLSSL per le tue web app, API e servizi interni. Key Vault può archiviarli, gestirne il ciclo di vita e persino rinnovarle automaticamente quando sono vicini alla scheda. È un vero salvavita per chiunque abbia mai avuto un certificato scaduto alle 3 del mattino di una domenica.

Ecco un esempio reale. Immagina di avere una web app che necessita di una stringa di connessione al database e di una chiave API per un servizio di terze parti. Nel vecchio modo metteresti entrambi nel tuo file JSON. Probabilmente se quel file finisce nel tuo repository, chiunque abbia accesso al codice può vedere le cadenziali del tuo database. Con Key Vault archivi entrambi i valori come segreti. La tua app li recupera all'avvio e non appaiono mai nel tuo codice sorgente. Devi ruotare la password database, aggiornare in Key Vault. L'app recupera il nuovo valore automaticamente al riavvio successivo. Nessuna modifica il codice e nessuna distribuzione. Una cosa che spesso sorprende è che il versionamento è integrato. Quando aggiori un segreto Key Vault non sovrascrive il vecchio valore. Crea una nuova versione. Le vecchie versioni sono conservate così puoi ripristinarle se qualcosa va storto.

È incredibilmente utile durante gli incidenti. Puoi tornare rapidamente a un segreto precedente senza dover ricordare il vecchio valore. Puoi archiviare tutti e tre i tipi, segreti, chiavi e certificati nello stesso Vault. Tuttavia la best practice è separare per ambiente. Usa un Vault per lo sviluppo, uno per i test e uno per la produzione. Ciò impedisce di usare accidentalmente un segreto di produzione in ambiente di sviluppo e limita i danni se un Vault viene compromesso. Ma archiviare i segreti è solo metà dell'opera. La vera domanda è chi può accedervi. Come funziona il controllo degli accessi? Parliamo di chi può entrare. Key Vault ha due modi diversi per controllare l'accesso a ciò che contiene e la scelta che fai conta molto. Primo modello sono le policy di accesso legacy. Questo è il vecchio metodo. Crea le policy direttamente sul Vault e assegna autorizzazioni a utenti o gruppi specifici per tipi di dati, segreti, chiavi o certificati.

Il problema è che queste policy sono legate direttamente al Vault. Se hai più Vault, devi gestire le policy in ognuno separatamente. Non è facilmente scalabile. Microsoft ora sconsiglia di usarle perché presentano problemi di sicurezza noti, non supportano la gestione delle identità privilegiate, possono creare percorsi di escalation dei privilegi imprevisti. Secondo modello è Azure Bugs, controllo degli accessi basato sui ruoli. Questo è il metodo moderno. Usa l'identità in 3D ed è coerente con il modo in cui gestisci i permessi ovunque in Azure. Se sai già come dare accesso a un account di archiviazione o a una macchina virtuale, sai già come dare accesso a Key Vault. Stesso sistema, stessi path. Ecco la regola d'oro, minimo privilegio. Concedi solo il minimo accesso necessario, nulla di più. Se qualcuno deve solo leggere i segreti, non dargli il permesso di crearli e eliminarli. Se qualcuno deve solo gestire i certificati, non dargli accesso alle chiavi.

Lascia che ti illustri i ruoli chiave. Hai il ruolo Key Vault Reader. Permette di elencare i segreti, ma non di leggerne i valori. Key Vault Secrets User. Questo permette di leggere effettivamente i valori dei segreti. E Key Vault Secrets Officer. Questo permette di creare, aggiornare ed eliminare segreti. Nota il pattern. Ogni ruolo è specifico per i dati all'interno del Vault, non per il Vault stesso. Ora confrontiamo questo aspetto con i ruoli generali di proprietario o collaboratore. Questi si applicano al Vault come risorsa, non ai dati contenuti dal suo interno. Un proprietario può eliminare l'intero Vault. Un collaboratore può modificare le impostazioni del Vault. Tuttavia, nessuno di questi ruoli garantisce di per sé l'accesso ai segreti contenuti. Si tratta di un livello di autorizzazione separato ed è questo il punto fondamento. Il controllo degli accessi è una struttura strana.

Serve l'accesso al Vault stesso, che è il primo livello, e l'accesso ai dati al suo interno, che è il secondo, che è il secondo. Entrambi devono essere concessi separatamente. La maggior parte dei principianti pensa solo al primo livello e dimentica il secondo. È lì che iniziano i problemi. L'errore di sicurezza numero uno. Ecco il punto. Molte persone guardano il ruolo di collaboratore Key Vault e pensano sia sicuro. Leggono la parola a collaboratore. Presumano di poter gestire le impostazioni del Vault, ma non toccare i segreti all'interno. La documentazione stessa di Microsoft inizialmente affermava esattamente questo. Questo ruolo non ti consente di accedere a segreti, chiavi o certificati. Peccato che non sia del tutto vero. Un utente con il ruolo di collaboratore Key Vault può modificare le policy di accesso del Vault. E se quel Vault utilizza ancora le policy di accesso Legacy, come molti fanno, allora può semplicemente concedersi l'accesso completo in lettura a ogni segreto, chiave e certificato presente.

Nessun exploit speciale necessario, nessuna vulnerabilità da correo. È semplicemente così che funzionano i permessi. I ricercatori di sicurezza di Datadog lo hanno dimostrato nel 2024. Hanno mostrato che un collaboratore può ottenere l'accesso completo ai dati in qualsiasi Vault che utilizzi policy di accesso Legacy. La risposta di Microsoft è stata interessante. Hanno dichiarato che non si tratta di una vulnerabilità perché i collaboratori sono progettati per gestire le policy di accesso, ma hanno aggiornato la documentazione per avvertire esplicitamente che il ruolo può concedere a se stesso le piano dati. Quindi non è un bug di Key Vault, è una trappola di configurazione e metti in difficoltà anche i team esperti perché il nome del ruolo sembra innocuo. Il collaboratore non sembra qualcuno in grado di leggere le password del database, ma in pratica può farlo. Refletti sul rischio. Se un utente malintenzionato compromette un account con un ruolo di collaboratore sul tuo Key Vault, non ha bisogno di violare il Vault, non ha bisogno di cifrare la criptografia.

Gli basta modificare la policy di accesso, concedersi l'accesso in lettura ed esfiltrare silenziosamente ogni segreto archiviato, stringhe di commissione, chiavi API, certificati, tutto quanto. E poiché le modifiche e le policy di accesso sono normali attività amministrative, potrebbero non attivare alcun avviso. Di quale è la soluzione? Innanzitutto usa Azure Back per l'accesso al piano dati invece delle policy di accesso legacy. Arbac separa la gestione del Vault dai dati contenuti al suo interno. Secondo, non assegnare mai il ruolo di collaboratore Key Vault a chi non ne ha assolutamente bisogno. Terzo, se hai già utenti con quel ruolo, controllali oggi stesso. Sostituisci il collaboratore con ruoli più specifici come utente dei segreti di Key Vault o responsabile dei segreti di Key Vault. C'è un secondo errore che aggrava il primo, mettere tutti i propri segreti in un unico Vault se hai un solo Vault per tutto, sviluppo, test, staging, produzione, tutte le tue applicazioni e quel Vault viene compromesso, tutto è esposto, è un singolo punto di guasto.

Parleremo più approfonditamente della strategia Multivolt tra poco, ma il principio è semplice. Non mettere tutte le uova nello stesso paniere, specialmente quando quel paniere contiene le chiavi dell'intera infrastruttura. Identità gestita, lo standard di riferimento. Quindi fare le cose in modo giusto. Parliamo del modo migliore per accedere a Key Vault. C'è un problema fondamentale. Per ottenere credenziali da Key Vault, l'applicazione deve autenticarsi, ma per autenticarsi ha bisogno di credenziali. Dove memorizzare i credenziali che la tua app usa per ottenere le credenziali? Il problema dell'uovo è della gallina. La vecchia risposta era un'entità a servizio con un segreto client, ma quel segreto deve risiedere da qualche parte, magari in un file di configurazione, nelle variabili d'ambiente o in una pipeline di distribuzione. E ora sei tornato allo stesso problema? Hai solo spostato il segreto altrove?

L'identità gestita risolve completamente questo aspetto. Ecco come funziona. Quando abiliti l'identità gestita su una risorsa Azure, come una web app, una funzione o una macchina virtuale, Azure crea automaticamente un'identità per quella risorsa in Entry ID. Quell'identità è gestita interamente da Azure. Nessuna credenziale da creare, nessun segreto da ruotare, nulla da memorizzare. La risorsa possiede semplicemente un'identità nota da Azure. Esistono due tipi. L'identità gestita assegnata dal sistema è legata a una risorsa specifica. Se elimini la risorsa, anche l'identità viene eliminata. Condividono lo stesso ciclo di vita, che semplifica l'amministrazione. L'identità gestita assegnata dall'utente è un'identità indipendente che puoi assegnare a più risorse. Non condivide il ciclo di vita con nessuna di esse, quindi è utile quando serve la stessa identità su più servizi. Ecco come appare nella pratica.

Hai una web app che deve leggere una stringa di connessione al database da Key Vault. Abilita l'identità gestita assegnata dal sistema sulla web app. Quindi assegna a quell'identità il ruolo di utente dei segreti di Key Vault sul tuo vault. Nessuna stringa di connessione del codice, nessun segreto client nei file di configurazione. L'app web si autentica a Key Vault usando la sua identità gestita e Azure gestisce tutte le credenziali dietro le quinte. È quanto di più vicino esista l'autenticazione senza credenziali in Azure. È una svolta per la sicurezza perché elimina il vettore di attacco più comune e il furto di credenziali. Se non ci sono credenziali da rubare, non c'è nulla che un attaccante possa compromettere. Lasciatemi fare un esempio reale. Immaginate una pipeline di dati in Synapse che debba accedere a un account di archiviazione. In passato avreste memorizzato la chiave dell'account di archiviazione della pipeline.

Se qualcuno avesse ottenuto l'accesso alla pipeline avrebbe avuto la chiave. Con l'identità gestita, l'area di lavoro Synapse possiede un'identità propria. Quell'identità ottiene l'accesso al Key Vault dove è conservata la chiave dell'account di archiviazione. La pipeline recupera la chiave al runtime, la usa e non la memorizza mai da nessuna parte. Nessuna chiave nel codice, nessun segreto nella configurazione della pipeline. Quando combini l'identità gestita con airbag e il privilegio minimo, ottieni una base sicura per ogni carico di lavoro Azure. Le tue applicazioni si autenticano senza credenziali. Accedono solo a ciò che serve e ogni accesso registrato è verificabile. È il modello che Microsoft raccomanda per quasi ogni scenario. Una volta iniziato a usarlo, ti chiederai perché tu abbia mai fatto diversamente. Costi e strategia multivolt Quindi parliamo di costi. Qui la maggior parte delle persone rimane sorpresa.

Quanto costa effettivamente Azure Key Vault? Il dato di prezzo è semplice. Nessuna tariffa di archiviazione per singolo segreto. Non paghi per ogni password o chiave API che archivi. Paghi per operazione. Per il livello standard sono circa 3 centesimi ogni 10.000 operazioni. Una chiamata GetSecret con operazione. Così come creare un segreto e elencare ciò che è presente nel vault. Per una tipica applicazione medio piccola si tratta di pochi centesimi al mese. Letteramente pochi centesimi. Confrontalo con la AWS Secrets Manager. Debitano 40 centesimi per segreto al mese solo per l'archiviazione e più costi extra per le chiamate API. 600 segreti sono 40 dollari al mese prima ancora di leggerne uno. Con Azure Key Vault, 100 segreti con utilizzo moderato potrebbero costarti 15 centesimi. La differenza cresce rapidamente su Argasca. Esiste poi il livello premio. Aggiunge chiavi supportate da HSM per i carichi di lavoro che necessitano del massimo livello di garanzia cartografica.

Pensa alle transazioni finanziarie, dati sanitari, sistemi governativi. Il costo per operazione è più alto, circa 15 centesimi ogni 10.000 operazioni per tipi di chiave avanzati. Più una tarifa mensile per chiave HSM. Ma per la maggior parte delle applicazioni, livello standard è più che sufficiente. Ecco la sorpresa sui costi che coglie tutti di sorpresa. Per una tipica applicazione web, con pochi segreti e alcune migliaia di operazioni al mese, Key Vault costa meno di un dollaro. Spenderai di più per il caffè che bevi mentre lo configuri. Ma c'è una strategia che conta più del costo. Quanti Vault utilizzi? L'approccio intelligente è una strategia a multi Vault. Usa Vault separati per sviluppo, test, staging e produzione. Questo previene l'incidente più comune. Qualcuno che esegue uno script di test e legge accidentalmente un database di produzione perché la stringa di connessione ha nello stesso Vault.

Quando gli ambienti sono separati, quell'errore diventa impossibile. Dovresti anche separare per unità aziendale o dominio di conformità. Se gestisci dati di carta di pagamento, metti quei segreti nel loro Vault dedicato. I carichi di lavoro aziendali generali vanno in un altro, i dati sanitari in un terzo. Non si tratta di complicarsi la vita, ma di limitare la ragione di un eventuale danno. Se un Vault viene compromesso, solo i segreti in quel Vault sono esposti. Il resto della tua infrastruttura rimane al sicuro. E due reti di sicurezza integrate che dovresti sempre abilitare. L'eliminazione temporanea, soft e delete, significa che se qualcuno eliminò un segreto non è perso definitiva. Vai in uno stato recuperabile per un periodo di conservazione a tua scelta fino a 90 giorni? Protezione dell'eliminazione definitiva approach protect. Nessuno può eliminare permanentemente il Vault e il suo contenuto finché quel periodo di conservazione non scala.

Insieme impediscono il tipo di partita accidentale di dati che tiene svegli i team di sicurezza. Come si collega tutto? Mettiamo tutto insieme e vediamo come i pezzi si incastrano. Chi Vault non è un'isola, è il sistema nervoso centrale per i segreti nella tua architettura azzurra. Quando capisci come fluisce l'intero sistema, tutto va al suo posto. Ecco cosa succede quando un'applicazione ha bisogno di un segreto. L'applicazione lo richiede usando la sua identità gestita. Quell'identità è già registrata in EntraID. Azzurra l'ha creata automaticamente quando è abilitato l'identità gestita sulla risorsa. EntraID convalida che l'identità sia legittima, poi passa la richiesta a Key Vault. Key Vault controlla le autorizzazioni RBA che ha assegnato. Se l'identità è il ruolo giusto, ad esempio, utente segreti Key Vault, il segreto viene restituito. Tutto questo avviene in pochi millisecondi. L'applicazione non vede mai una credenziale.

Non memorizza mai una paso. Tiene semplicemente il valore di cui ha bisogno. Ora pensa a quanti servizi Azure possono connettersi a questi. App Service, Functions, HES, Data Factory, Synapse, Logic Apps, DevOps, Pipelines. Sanno tutti come comunicare con Key Vault. Puoi configurare un'app web per fare riferimento a un segreto direttamente nelle impostazioni dell'applicazione. Puoi configurare una pipeline di Data Factory per recuperare una chiave di account ed archiviazione da Key Vault in fase di eseguzione. Puoi configurare un cluster Kubernetes per recuperare i segreti usando il driver CSI di Key Vault. Ogni servizio si integra allo stesso modo, usando lo stesso sistema di identità, gli stessi ruoli airback e lo stesso log di controllo. Il modello CCD è particolarmente potente. Le tue pipeline prelevano i segreti da Key Vault al momento del deploy. Non li memorizzano mai nelle variabili di pipeline o nei segreti del repository.

Se devi ruotare una password del database e l'aggiorni in Key Vault, la volta successiva che la pipeline è eseguita recupera automaticamente il nuovo. Nessuna modifica la pipeline, nessun cambiamento del codice, nessun redeploy. Ecco cosa rende tutto perfetto. Una volta configurato Key Vault con l'identità gestita airback, smetti di pensare alla gestione delle credenziali. Le tue applicazioni funzionano semplicemente. I segreti vengono ruotati senza che nessuno se ne come. I certificati si rinnovano senza emergenza. Il sistema gestisce il tuo background. Questa è l'approccio alla sicurezza che conta. L'identità è il perimetro, non la rete. Non importa se qualcuno si trova all'interno o all'esterno della tua rete virtuale. Ciò che conta è se possiedono un'identità valida con i permessi corretti. Key Vault lo impone per progettazione. Ogni richiesta di accesso passa attraverso l'autenticazione EntraID e l'autorizzazione RBH, indipendentemente dalla provenienza, e tutto viene registrato.

Ogni lettura di segreto, ogni operazione su chiave, ogni recupero dei certificati. Puoi vedere chi ha avuto accesso a quasi quanti. Se qualcosa sembra sospetto, hai dati per indagare. Questo è fondamentale per la conformità alla risposta agli incidenti e per sapere cosa succede nel tuo ambiente. Questa è la bellezza di tutto ciò. Key Vault, EntraID, RBH e identità gestita lavorano insieme come un framework di sicurezza unificato. Ogni elemento rafforza gli altri. Quando sono configurati correttamente, è un sistema di gestione delle credenziali più sicuro e semplice da usare di qualsiasi cosa. Potresti costruire da solo consigli pratici. Quindi, cosa dovresti fare concretamente? Trasformiamo queste conoscenze in azione. Ecco le cose che puoi affrontare questa settimana. Inizia dal tuo modello di permette. Apri il tuo Key Vault nel portale e vai alla configurazione di accesso e controlla cosa dice.

Se vedi criteri di accesso al Vault, quello è il vecchio metodo. Dovresti usare invece il controllo degli accessi basato sui ruoli di Azure. La migrazione è semplice. Cambia il modello di autorizzazione e assegni i ruoli Airbac alle stesse persone che avevano già i criteri di accesso. Fallo oggi. Microsoft lo consiglia e la ricerca di cui abbiamo parlato ne ha mostrato esattamente il motivo. Successivamente, controlla gli account che detengono il ruolo di collaboratore Key Vault. Apri la scheda IEM sul tuo Vault e guarda chi ha l'accesso come collaboratore. Ogni persona con quel ruolo deve avere una valida ragione. Più delle volte non lo fanno. Sostituisci i contributor con qualcosa di più specifico. Se qualcuno deve solo leggere i segreti, usa Key Vault Secrets User. Se deve gestire i segreti, usa Key Vault Secrets Office. L'obiettivo è chiudere completamente quel percorso di escalation.

Poi, sfrutta le manager identity. Qualsiasi servizio Azure che necessitera Key Vault dovrebbe usarle. Se hai una web app, una function, una data factory o una virtual machine che usa ancora una service principal, con un client secret, passa alle manager identity. È più semplice e più sicuro e risolve il problema dell'uovo e della gallina che abbiamo visto. Azure gestisce la gestione delle credenziali per te dietro le quinte. Un'ultima cosa. Abilita Soft Delete e Purge Protection su ogni Vault. Soft Delete è attivo di default per i nuovi Vault, ma Purge Protection no. Attivala. Quell'impostazione impedisce a chiunque di eliminare permanentemente un Vault o il suo contenuto durante il periodo di conservazione. Ha salvato più di un team da un errore disastroso. Ecco la tua call to action. Analizza il totale approccio alla gestire. Trova un segreto che ancora in un file di configurazione, una variabile d'ambiente o scritto nel codice, spostalo in Key Vault questa settimana.

Solo uno. Una volta visto quanto è semplice, vorrei spostare anche il resto. La sicurezza non è una configurazione nata, è una pratica. Key Vault rende questa pratica più semplice, ma solo se usato correttamente. Gli strumenti ci sono. I pattern sono collaudati. Raspettate a implementarli. Questo è il sistema. Key Vault è la tua cassaforte digitale, ma è sicura solo quanto i controlli di accesso, che imposti attorno ad essa. Inizia con l'audit che ho appena descritto. Controllo i permessi? Verifica l'assegnazione di contributo e risposta a un segreto in un vault questa settimana. Iscriviti per altri consigli sulla sicurezza cloud in parole semplici e condividi questo video con chi archivi ancora i segreti nei file di configurazione.