WEBVTT 00:00:00.000 --> 00:00:07.000 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. 00:00:07.500 --> 00:00:10.860 Quindi la inserisci direttamente nel codice, magari in un file di configurazione, non avrai vari vari. 00:00:11.580 --> 00:00:15.620 Funziona tutto bene finché non carichi quel codice su GitHub o condividi un notebook con un collega. 00:00:16.580 --> 00:00:18.940 Ed ecco che così il tuo segreto non è più tanto segreto. 00:00:19.540 --> 00:00:22.420 Se quel codice finisce nelle mani sbagliate, l'intero sistema è esposto. 00:00:23.120 --> 00:00:25.660 Ora, Azure Key Vault è lo strumento che risolve questo problema. 00:00:25.900 --> 00:00:29.420 Ti offre un posto sicuro dove archiviare i segreti così non finiscono mai nel tuo codice. 00:00:30.000 --> 00:00:31.240 Ma ecco la cosa che molti sbagliano. 00:00:31.700 --> 00:00:34.380 Avere solo un Key Vault non ti rende automaticamente sicuro. 00:00:34.840 --> 00:00:38.480 Il modo in cui lo configuri, controlli l'accesso e assegni le autorizzazioni con te altrettanto. 00:00:39.020 --> 00:00:46.700 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. 00:00:47.320 --> 00:00:49.740 Tu in parole semplici, senza gergo, solo le informazioni che ti servono. 00:00:50.200 --> 00:00:51.460 Quindi cos'è esattamente Azure Key Vault? 00:00:52.220 --> 00:00:53.020 Cos'è Azure Key Vault? 00:00:53.540 --> 00:00:54.680 Ecco la definizione più semplice. 00:00:55.080 --> 00:00:58.040 Azure Key Vault è una cassaforte digitale basata su cloud per i tuoi segreti. 00:00:58.040 --> 00:01:05.200 È un servizio gestito da Microsoft per chiavi AI, password e database, stringhe di connessione, chiavi di criptografia e certificati in un unico posto centrale. 00:01:05.980 --> 00:01:09.580 Non devi preoccuparti dell'infrastruttura perché Azure gestisce patch, uptime e sicurezza. 00:01:10.180 --> 00:01:10.880 Tu devi solo usarlo. 00:01:11.280 --> 00:01:12.460 Immagina come un edificio per ufino. 00:01:12.860 --> 00:01:18.060 Hai postazioni di lavoro, sale, riunioni e schedari, ma da qualche parte nel seminterrato c'è una stanza blindata dove tieni le cose importanti. 00:01:18.900 --> 00:01:20.820 Chiavi principali con tanti documenti legali. 00:01:20.820 --> 00:01:23.000 Nessuno entra senza permesso o autenticazione. 00:01:23.500 --> 00:01:25.160 Ogni volta che qualcuno apre la porta viene registrato. 00:01:25.540 --> 00:01:26.060 Questo è Key Vault. 00:01:26.700 --> 00:01:28.780 La stanza è sicura nel seminterrato della tua architettura Azure. 00:01:29.940 --> 00:01:31.340 Ora confrontalo con il vecchio metodo. 00:01:31.740 --> 00:01:40.540 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. 00:01:40.540 --> 00:01:43.180 Se qualcuno avesse ottenuto l'accesso a quel server, avrai avuto tutto. 00:01:43.700 --> 00:01:46.660 E se avessi dovuto cambiare quella password, avresti dovuto aggiornarla ovunque. 00:01:47.340 --> 00:01:50.380 Ogni file di configurazione, ogni ambiente e ogni distribuzione era un incubo. 00:01:50.740 --> 00:01:51.680 Key Vault cambia tutto questo. 00:01:52.300 --> 00:01:56.340 Invece di spargere segreti tra codice e file di configurazione, li archivi in un unico posto centrale. 00:01:57.100 --> 00:01:59.900 Le tue applicazioni le richiedono in fase di esecuzione solo quando ne hanno bisogno. 00:02:00.180 --> 00:02:08.540 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. 00:02:08.540 --> 00:02:12.020 Ma ecco il punto, Key Vault non è solo un gestore di password per le due app. 00:02:12.540 --> 00:02:13.740 È un servizio di sicurezza fondamentale. 00:02:14.140 --> 00:02:15.860 Ogni servizio è azzurro, può integrarsi con esso. 00:02:16.620 --> 00:02:22.060 App Service, Functions, HIS, Data Factory, Synapse, Logic Apps e le Pipeline DevOps sanno tutti come comunicare con Key Vault. 00:02:22.660 --> 00:02:24.620 Diventa la spina dorsale della tua architettura CloudSQ. 00:02:25.060 --> 00:02:28.440 Una volta configurato correttamente smetterai completamente di pensare alla gestione dei credenziali. 00:02:29.200 --> 00:02:29.880 Cosa puoi archiviare? 00:02:30.740 --> 00:02:33.520 Ora che sai cos'è Key Vault parliamo di cosa puoi effettivamente inserirvi. 00:02:34.080 --> 00:02:37.760 Hai tre categorie principali, segreti, chiavi e certificati. 00:02:37.760 --> 00:02:42.600 Ognuna svolge una funzione diversa e comprendere questa differenza ti aiuta a usare Key Vault nel modo corretto. 00:02:42.920 --> 00:02:43.800 Iniziamo dai segreti. 00:02:44.080 --> 00:02:45.660 Questa è la cosa che le persone archiviano più comunemente. 00:02:46.040 --> 00:02:50.560 I segreti sono stringhe di connessione, chiavi API, password di database, chiavi di account e di archiviazione, 00:02:50.680 --> 00:02:54.120 praticamente tutte le credenziali quotidiane che le tue app necessitano per comunicare con altri servizi. 00:02:54.280 --> 00:02:57.420 Invece di inserirli nel codice o nel file di configurazione, li metti in Key Vault. 00:02:58.000 --> 00:03:01.000 La tua app li recupera durante l'esecuzione e nessuno li vedrà mai in testo normale. 00:03:01.500 --> 00:03:04.000 Immaginalo come un cassetto chiuso a chiave nel tuo archivio digitale. 00:03:04.540 --> 00:03:05.640 Successivamente abbiamo le chiave. 00:03:05.640 --> 00:03:07.280 Si tratta di chiavi di crittografia per le dati net. 00:03:07.660 --> 00:03:12.700 Se stai utilizzando chiavi gestite dal cliente per Azure Storage, database SQL o per crittografare dischi di macchine virtuali, 00:03:12.940 --> 00:03:14.340 tali chiavi possono risiedere in Key Vault. 00:03:14.760 --> 00:03:17.140 Ciò ti offre il pieno controllo su chi può usarle e quando. 00:03:17.560 --> 00:03:20.040 E se hai bisogno di chiavi supportate da hardware per motivi di conformità, 00:03:20.160 --> 00:03:22.040 il livello premium ti copre con la protezione HSM. 00:03:22.460 --> 00:03:23.300 Poi abbiamo i certificati. 00:03:23.300 --> 00:03:27.480 Certificati TLSSL per le tue web app, API e servizi interni. 00:03:27.900 --> 00:03:31.980 Key Vault può archiviarli, gestirne il ciclo di vita e persino rinnovarle automaticamente quando sono vicini alla scheda. 00:03:32.300 --> 00:03:36.660 È un vero salvavita per chiunque abbia mai avuto un certificato scaduto alle 3 del mattino di una domenica. 00:03:37.220 --> 00:03:38.020 Ecco un esempio reale. 00:03:38.380 --> 00:03:42.940 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. 00:03:43.340 --> 00:03:45.220 Nel vecchio modo metteresti entrambi nel tuo file JSON. 00:03:45.220 --> 00:03:51.360 Probabilmente se quel file finisce nel tuo repository, chiunque abbia accesso al codice può vedere le cadenziali del tuo database. 00:03:52.220 --> 00:03:54.220 Con Key Vault archivi entrambi i valori come segreti. 00:03:54.900 --> 00:03:57.820 La tua app li recupera all'avvio e non appaiono mai nel tuo codice sorgente. 00:03:58.120 --> 00:04:00.640 Devi ruotare la password database, aggiornare in Key Vault. 00:04:01.100 --> 00:04:03.880 L'app recupera il nuovo valore automaticamente al riavvio successivo. 00:04:04.220 --> 00:04:05.880 Nessuna modifica il codice e nessuna distribuzione. 00:04:06.100 --> 00:04:08.320 Una cosa che spesso sorprende è che il versionamento è integrato. 00:04:08.700 --> 00:04:11.200 Quando aggiori un segreto Key Vault non sovrascrive il vecchio valore. 00:04:11.600 --> 00:04:12.560 Crea una nuova versione. 00:04:12.560 --> 00:04:15.900 Le vecchie versioni sono conservate così puoi ripristinarle se qualcosa va storto. 00:04:16.160 --> 00:04:17.800 È incredibilmente utile durante gli incidenti. 00:04:18.500 --> 00:04:22.100 Puoi tornare rapidamente a un segreto precedente senza dover ricordare il vecchio valore. 00:04:23.100 --> 00:04:26.500 Puoi archiviare tutti e tre i tipi, segreti, chiavi e certificati nello stesso Vault. 00:04:27.340 --> 00:04:29.420 Tuttavia la best practice è separare per ambiente. 00:04:30.040 --> 00:04:32.940 Usa un Vault per lo sviluppo, uno per i test e uno per la produzione. 00:04:33.720 --> 00:04:37.280 Ciò impedisce di usare accidentalmente un segreto di produzione in ambiente di sviluppo 00:04:37.280 --> 00:04:39.740 e limita i danni se un Vault viene compromesso. 00:04:40.360 --> 00:04:42.320 Ma archiviare i segreti è solo metà dell'opera. 00:04:42.740 --> 00:04:44.260 La vera domanda è chi può accedervi. 00:04:45.180 --> 00:04:46.300 Come funziona il controllo degli accessi? 00:04:46.800 --> 00:04:47.720 Parliamo di chi può entrare. 00:04:48.340 --> 00:04:52.700 Key Vault ha due modi diversi per controllare l'accesso a ciò che contiene e la scelta che fai conta molto. 00:04:53.340 --> 00:04:55.000 Primo modello sono le policy di accesso legacy. 00:04:55.560 --> 00:04:56.240 Questo è il vecchio metodo. 00:04:57.440 --> 00:05:03.460 Crea le policy direttamente sul Vault e assegna autorizzazioni a utenti o gruppi specifici per tipi di dati, segreti, chiavi o certificati. 00:05:03.460 --> 00:05:07.140 Il problema è che queste policy sono legate direttamente al Vault. 00:05:07.580 --> 00:05:10.300 Se hai più Vault, devi gestire le policy in ognuno separatamente. 00:05:10.860 --> 00:05:11.700 Non è facilmente scalabile. 00:05:12.280 --> 00:05:15.740 Microsoft ora sconsiglia di usarle perché presentano problemi di sicurezza noti, 00:05:16.580 --> 00:05:20.840 non supportano la gestione delle identità privilegiate, possono creare percorsi di escalation dei privilegi imprevisti. 00:05:20.840 --> 00:05:24.600 Secondo modello è Azure Bugs, controllo degli accessi basato sui ruoli. 00:05:24.960 --> 00:05:25.840 Questo è il metodo moderno. 00:05:26.260 --> 00:05:30.080 Usa l'identità in 3D ed è coerente con il modo in cui gestisci i permessi ovunque in Azure. 00:05:30.760 --> 00:05:34.080 Se sai già come dare accesso a un account di archiviazione o a una macchina virtuale, 00:05:34.460 --> 00:05:35.860 sai già come dare accesso a Key Vault. 00:05:36.860 --> 00:05:38.040 Stesso sistema, stessi path. 00:05:38.500 --> 00:05:40.260 Ecco la regola d'oro, minimo privilegio. 00:05:40.880 --> 00:05:43.480 Concedi solo il minimo accesso necessario, nulla di più. 00:05:44.300 --> 00:05:47.600 Se qualcuno deve solo leggere i segreti, non dargli il permesso di crearli e eliminarli. 00:05:47.600 --> 00:05:51.160 Se qualcuno deve solo gestire i certificati, non dargli accesso alle chiavi. 00:05:51.760 --> 00:05:52.880 Lascia che ti illustri i ruoli chiave. 00:05:53.280 --> 00:05:54.200 Hai il ruolo Key Vault Reader. 00:05:54.820 --> 00:05:56.900 Permette di elencare i segreti, ma non di leggerne i valori. 00:05:57.540 --> 00:05:58.420 Key Vault Secrets User. 00:05:58.920 --> 00:06:01.000 Questo permette di leggere effettivamente i valori dei segreti. 00:06:01.260 --> 00:06:02.320 E Key Vault Secrets Officer. 00:06:02.980 --> 00:06:05.300 Questo permette di creare, aggiornare ed eliminare segreti. 00:06:05.920 --> 00:06:06.480 Nota il pattern. 00:06:07.020 --> 00:06:10.080 Ogni ruolo è specifico per i dati all'interno del Vault, non per il Vault stesso. 00:06:10.620 --> 00:06:13.380 Ora confrontiamo questo aspetto con i ruoli generali di proprietario o collaboratore. 00:06:13.780 --> 00:06:16.720 Questi si applicano al Vault come risorsa, non ai dati contenuti dal suo interno. 00:06:16.720 --> 00:06:18.480 Un proprietario può eliminare l'intero Vault. 00:06:18.800 --> 00:06:20.700 Un collaboratore può modificare le impostazioni del Vault. 00:06:21.100 --> 00:06:24.680 Tuttavia, nessuno di questi ruoli garantisce di per sé l'accesso ai segreti contenuti. 00:06:25.120 --> 00:06:27.740 Si tratta di un livello di autorizzazione separato ed è questo il punto fondamento. 00:06:27.960 --> 00:06:29.440 Il controllo degli accessi è una struttura strana. 00:06:29.860 --> 00:06:32.020 Serve l'accesso al Vault stesso, che è il primo livello, 00:06:32.380 --> 00:06:35.260 e l'accesso ai dati al suo interno, che è il secondo, che è il secondo. 00:06:35.560 --> 00:06:36.900 Entrambi devono essere concessi separatamente. 00:06:37.240 --> 00:06:40.140 La maggior parte dei principianti pensa solo al primo livello e dimentica il secondo. 00:06:40.580 --> 00:06:41.480 È lì che iniziano i problemi. 00:06:42.220 --> 00:06:43.340 L'errore di sicurezza numero uno. 00:06:43.620 --> 00:06:44.060 Ecco il punto. 00:06:44.060 --> 00:06:47.160 Molte persone guardano il ruolo di collaboratore Key Vault e pensano sia sicuro. 00:06:47.260 --> 00:06:48.520 Leggono la parola a collaboratore. 00:06:48.780 --> 00:06:51.800 Presumano di poter gestire le impostazioni del Vault, ma non toccare i segreti all'interno. 00:06:51.980 --> 00:06:54.680 La documentazione stessa di Microsoft inizialmente affermava esattamente questo. 00:06:54.900 --> 00:06:57.840 Questo ruolo non ti consente di accedere a segreti, chiavi o certificati. 00:06:58.340 --> 00:06:59.880 Peccato che non sia del tutto vero. 00:06:59.920 --> 00:07:03.820 Un utente con il ruolo di collaboratore Key Vault può modificare le policy di accesso del Vault. 00:07:04.240 --> 00:07:07.300 E se quel Vault utilizza ancora le policy di accesso Legacy, come molti fanno, 00:07:07.300 --> 00:07:12.340 allora può semplicemente concedersi l'accesso completo in lettura a ogni segreto, chiave e certificato presente. 00:07:12.340 --> 00:07:15.140 Nessun exploit speciale necessario, nessuna vulnerabilità da correo. 00:07:15.300 --> 00:07:16.780 È semplicemente così che funzionano i permessi. 00:07:17.000 --> 00:07:19.680 I ricercatori di sicurezza di Datadog lo hanno dimostrato nel 2024. 00:07:20.060 --> 00:07:25.000 Hanno mostrato che un collaboratore può ottenere l'accesso completo ai dati in qualsiasi Vault che utilizzi policy di accesso Legacy. 00:07:25.820 --> 00:07:27.000 La risposta di Microsoft è stata interessante. 00:07:27.520 --> 00:07:32.360 Hanno dichiarato che non si tratta di una vulnerabilità perché i collaboratori sono progettati per gestire le policy di accesso, 00:07:32.360 --> 00:07:36.520 ma hanno aggiornato la documentazione per avvertire esplicitamente che il ruolo può concedere a se stesso le piano dati. 00:07:36.520 --> 00:07:42.860 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. 00:07:43.540 --> 00:07:47.540 Il collaboratore non sembra qualcuno in grado di leggere le password del database, ma in pratica può farlo. 00:07:48.020 --> 00:07:48.700 Refletti sul rischio. 00:07:49.120 --> 00:07:52.940 Se un utente malintenzionato compromette un account con un ruolo di collaboratore sul tuo Key Vault, 00:07:53.400 --> 00:07:56.380 non ha bisogno di violare il Vault, non ha bisogno di cifrare la criptografia. 00:07:56.380 --> 00:08:02.080 Gli basta modificare la policy di accesso, concedersi l'accesso in lettura ed esfiltrare silenziosamente ogni segreto archiviato, 00:08:02.180 --> 00:08:05.200 stringhe di commissione, chiavi API, certificati, tutto quanto. 00:08:05.200 --> 00:08:10.360 E poiché le modifiche e le policy di accesso sono normali attività amministrative, potrebbero non attivare alcun avviso. 00:08:10.680 --> 00:08:11.240 Di quale è la soluzione? 00:08:11.620 --> 00:08:14.800 Innanzitutto usa Azure Back per l'accesso al piano dati invece delle policy di accesso legacy. 00:08:15.400 --> 00:08:17.940 Arbac separa la gestione del Vault dai dati contenuti al suo interno. 00:08:18.620 --> 00:08:22.220 Secondo, non assegnare mai il ruolo di collaboratore Key Vault a chi non ne ha assolutamente bisogno. 00:08:22.960 --> 00:08:25.640 Terzo, se hai già utenti con quel ruolo, controllali oggi stesso. 00:08:26.340 --> 00:08:30.720 Sostituisci il collaboratore con ruoli più specifici come utente dei segreti di Key Vault o responsabile dei segreti di Key Vault. 00:08:31.300 --> 00:08:34.860 C'è un secondo errore che aggrava il primo, mettere tutti i propri segreti in un unico Vault 00:08:34.860 --> 00:08:40.380 se hai un solo Vault per tutto, sviluppo, test, staging, produzione, tutte le tue applicazioni 00:08:40.380 --> 00:08:44.740 e quel Vault viene compromesso, tutto è esposto, è un singolo punto di guasto. 00:08:45.200 --> 00:08:48.440 Parleremo più approfonditamente della strategia Multivolt tra poco, ma il principio è semplice. 00:08:48.820 --> 00:08:52.980 Non mettere tutte le uova nello stesso paniere, specialmente quando quel paniere contiene le chiavi dell'intera infrastruttura. 00:08:54.140 --> 00:08:55.820 Identità gestita, lo standard di riferimento. 00:08:56.260 --> 00:08:57.260 Quindi fare le cose in modo giusto. 00:08:57.260 --> 00:08:59.300 Parliamo del modo migliore per accedere a Key Vault. 00:08:59.700 --> 00:09:00.560 C'è un problema fondamentale. 00:09:00.980 --> 00:09:05.940 Per ottenere credenziali da Key Vault, l'applicazione deve autenticarsi, ma per autenticarsi ha bisogno di credenziali. 00:09:06.540 --> 00:09:09.280 Dove memorizzare i credenziali che la tua app usa per ottenere le credenziali? 00:09:09.700 --> 00:09:10.640 Il problema dell'uovo è della gallina. 00:09:11.220 --> 00:09:15.800 La vecchia risposta era un'entità a servizio con un segreto client, ma quel segreto deve risiedere da qualche parte, 00:09:16.040 --> 00:09:19.700 magari in un file di configurazione, nelle variabili d'ambiente o in una pipeline di distribuzione. 00:09:19.700 --> 00:09:21.260 E ora sei tornato allo stesso problema? 00:09:21.740 --> 00:09:23.100 Hai solo spostato il segreto altrove? 00:09:23.580 --> 00:09:25.340 L'identità gestita risolve completamente questo aspetto. 00:09:25.340 --> 00:09:26.320 Ecco come funziona. 00:09:26.580 --> 00:09:31.720 Quando abiliti l'identità gestita su una risorsa Azure, come una web app, una funzione o una macchina virtuale, 00:09:32.280 --> 00:09:35.240 Azure crea automaticamente un'identità per quella risorsa in Entry ID. 00:09:35.820 --> 00:09:37.460 Quell'identità è gestita interamente da Azure. 00:09:38.020 --> 00:09:41.420 Nessuna credenziale da creare, nessun segreto da ruotare, nulla da memorizzare. 00:09:41.980 --> 00:09:44.400 La risorsa possiede semplicemente un'identità nota da Azure. 00:09:44.960 --> 00:09:45.660 Esistono due tipi. 00:09:45.660 --> 00:09:49.240 L'identità gestita assegnata dal sistema è legata a una risorsa specifica. 00:09:49.980 --> 00:09:51.880 Se elimini la risorsa, anche l'identità viene eliminata. 00:09:52.380 --> 00:09:54.900 Condividono lo stesso ciclo di vita, che semplifica l'amministrazione. 00:09:55.540 --> 00:10:00.000 L'identità gestita assegnata dall'utente è un'identità indipendente che puoi assegnare a più risorse. 00:10:00.660 --> 00:10:04.740 Non condivide il ciclo di vita con nessuna di esse, quindi è utile quando serve la stessa identità su più servizi. 00:10:05.900 --> 00:10:07.000 Ecco come appare nella pratica. 00:10:07.640 --> 00:10:11.000 Hai una web app che deve leggere una stringa di connessione al database da Key Vault. 00:10:11.000 --> 00:10:14.420 Abilita l'identità gestita assegnata dal sistema sulla web app. 00:10:14.960 --> 00:10:18.740 Quindi assegna a quell'identità il ruolo di utente dei segreti di Key Vault sul tuo vault. 00:10:19.520 --> 00:10:22.580 Nessuna stringa di connessione del codice, nessun segreto client nei file di configurazione. 00:10:23.080 --> 00:10:28.660 L'app web si autentica a Key Vault usando la sua identità gestita e Azure gestisce tutte le credenziali dietro le quinte. 00:10:29.220 --> 00:10:31.920 È quanto di più vicino esista l'autenticazione senza credenziali in Azure. 00:10:31.920 --> 00:10:37.120 È una svolta per la sicurezza perché elimina il vettore di attacco più comune e il furto di credenziali. 00:10:37.940 --> 00:10:40.920 Se non ci sono credenziali da rubare, non c'è nulla che un attaccante possa compromettere. 00:10:42.000 --> 00:10:43.280 Lasciatemi fare un esempio reale. 00:10:43.900 --> 00:10:47.060 Immaginate una pipeline di dati in Synapse che debba accedere a un account di archiviazione. 00:10:47.600 --> 00:10:50.840 In passato avreste memorizzato la chiave dell'account di archiviazione della pipeline. 00:10:51.560 --> 00:10:53.860 Se qualcuno avesse ottenuto l'accesso alla pipeline avrebbe avuto la chiave. 00:10:54.400 --> 00:10:56.920 Con l'identità gestita, l'area di lavoro Synapse possiede un'identità propria. 00:10:57.280 --> 00:11:01.240 Quell'identità ottiene l'accesso al Key Vault dove è conservata la chiave dell'account di archiviazione. 00:11:01.240 --> 00:11:05.360 La pipeline recupera la chiave al runtime, la usa e non la memorizza mai da nessuna parte. 00:11:06.060 --> 00:11:08.700 Nessuna chiave nel codice, nessun segreto nella configurazione della pipeline. 00:11:09.220 --> 00:11:11.980 Quando combini l'identità gestita con airbag e il privilegio minimo, 00:11:12.100 --> 00:11:14.200 ottieni una base sicura per ogni carico di lavoro Azure. 00:11:14.800 --> 00:11:16.800 Le tue applicazioni si autenticano senza credenziali. 00:11:17.340 --> 00:11:20.040 Accedono solo a ciò che serve e ogni accesso registrato è verificabile. 00:11:20.800 --> 00:11:23.320 È il modello che Microsoft raccomanda per quasi ogni scenario. 00:11:24.100 --> 00:11:26.780 Una volta iniziato a usarlo, ti chiederai perché tu abbia mai fatto diversamente. 00:11:27.640 --> 00:11:28.920 Costi e strategia multivolt 00:11:28.920 --> 00:11:30.680 Quindi parliamo di costi. 00:11:30.680 --> 00:11:32.540 Qui la maggior parte delle persone rimane sorpresa. 00:11:33.020 --> 00:11:34.540 Quanto costa effettivamente Azure Key Vault? 00:11:35.000 --> 00:11:35.920 Il dato di prezzo è semplice. 00:11:36.340 --> 00:11:37.880 Nessuna tariffa di archiviazione per singolo segreto. 00:11:38.140 --> 00:11:40.120 Non paghi per ogni password o chiave API che archivi. 00:11:40.340 --> 00:11:41.200 Paghi per operazione. 00:11:41.880 --> 00:11:44.780 Per il livello standard sono circa 3 centesimi ogni 10.000 operazioni. 00:11:45.500 --> 00:11:47.240 Una chiamata GetSecret con operazione. 00:11:47.700 --> 00:11:50.000 Così come creare un segreto e elencare ciò che è presente nel vault. 00:11:50.460 --> 00:11:53.360 Per una tipica applicazione medio piccola si tratta di pochi centesimi al mese. 00:11:54.000 --> 00:11:54.900 Letteramente pochi centesimi. 00:11:54.900 --> 00:11:57.000 Confrontalo con la AWS Secrets Manager. 00:11:57.660 --> 00:12:01.800 Debitano 40 centesimi per segreto al mese solo per l'archiviazione e più costi extra per le chiamate API. 00:12:02.300 --> 00:12:05.160 600 segreti sono 40 dollari al mese prima ancora di leggerne uno. 00:12:05.580 --> 00:12:09.480 Con Azure Key Vault, 100 segreti con utilizzo moderato potrebbero costarti 15 centesimi. 00:12:09.480 --> 00:12:11.460 La differenza cresce rapidamente su Argasca. 00:12:11.720 --> 00:12:12.660 Esiste poi il livello premio. 00:12:13.040 --> 00:12:17.600 Aggiunge chiavi supportate da HSM per i carichi di lavoro che necessitano del massimo livello di garanzia cartografica. 00:12:17.740 --> 00:12:20.660 Pensa alle transazioni finanziarie, dati sanitari, sistemi governativi. 00:12:21.100 --> 00:12:26.400 Il costo per operazione è più alto, circa 15 centesimi ogni 10.000 operazioni per tipi di chiave avanzati. 00:12:26.740 --> 00:12:28.340 Più una tarifa mensile per chiave HSM. 00:12:28.860 --> 00:12:31.780 Ma per la maggior parte delle applicazioni, livello standard è più che sufficiente. 00:12:32.160 --> 00:12:34.460 Ecco la sorpresa sui costi che coglie tutti di sorpresa. 00:12:34.460 --> 00:12:40.080 Per una tipica applicazione web, con pochi segreti e alcune migliaia di operazioni al mese, Key Vault costa meno di un dollaro. 00:12:40.620 --> 00:12:42.800 Spenderai di più per il caffè che bevi mentre lo configuri. 00:12:43.460 --> 00:12:45.260 Ma c'è una strategia che conta più del costo. 00:12:45.720 --> 00:12:46.540 Quanti Vault utilizzi? 00:12:46.960 --> 00:12:48.680 L'approccio intelligente è una strategia a multi Vault. 00:12:49.460 --> 00:12:52.100 Usa Vault separati per sviluppo, test, staging e produzione. 00:12:52.680 --> 00:12:54.020 Questo previene l'incidente più comune. 00:12:54.540 --> 00:12:59.480 Qualcuno che esegue uno script di test e legge accidentalmente un database di produzione perché la stringa di connessione ha nello stesso Vault. 00:13:00.040 --> 00:13:02.460 Quando gli ambienti sono separati, quell'errore diventa impossibile. 00:13:02.460 --> 00:13:05.340 Dovresti anche separare per unità aziendale o dominio di conformità. 00:13:05.860 --> 00:13:09.040 Se gestisci dati di carta di pagamento, metti quei segreti nel loro Vault dedicato. 00:13:09.480 --> 00:13:12.500 I carichi di lavoro aziendali generali vanno in un altro, i dati sanitari in un terzo. 00:13:12.800 --> 00:13:15.680 Non si tratta di complicarsi la vita, ma di limitare la ragione di un eventuale danno. 00:13:15.980 --> 00:13:19.080 Se un Vault viene compromesso, solo i segreti in quel Vault sono esposti. 00:13:19.480 --> 00:13:21.100 Il resto della tua infrastruttura rimane al sicuro. 00:13:21.400 --> 00:13:23.420 E due reti di sicurezza integrate che dovresti sempre abilitare. 00:13:23.420 --> 00:13:27.200 L'eliminazione temporanea, soft e delete, significa che se qualcuno eliminò un segreto non è perso definitiva. 00:13:27.540 --> 00:13:31.380 Vai in uno stato recuperabile per un periodo di conservazione a tua scelta fino a 90 giorni? 00:13:31.380 --> 00:13:34.060 Protezione dell'eliminazione definitiva approach protect. 00:13:34.520 --> 00:13:38.340 Nessuno può eliminare permanentemente il Vault e il suo contenuto finché quel periodo di conservazione non scala. 00:13:38.620 --> 00:13:42.800 Insieme impediscono il tipo di partita accidentale di dati che tiene svegli i team di sicurezza. 00:13:43.580 --> 00:13:44.240 Come si collega tutto? 00:13:44.660 --> 00:13:46.780 Mettiamo tutto insieme e vediamo come i pezzi si incastrano. 00:13:47.220 --> 00:13:51.380 Chi Vault non è un'isola, è il sistema nervoso centrale per i segreti nella tua architettura azzurra. 00:13:51.940 --> 00:13:55.260 Quando capisci come fluisce l'intero sistema, tutto va al suo posto. 00:13:55.620 --> 00:13:57.840 Ecco cosa succede quando un'applicazione ha bisogno di un segreto. 00:13:58.160 --> 00:14:00.480 L'applicazione lo richiede usando la sua identità gestita. 00:14:00.480 --> 00:14:02.760 Quell'identità è già registrata in EntraID. 00:14:03.440 --> 00:14:06.860 Azzurra l'ha creata automaticamente quando è abilitato l'identità gestita sulla risorsa. 00:14:08.240 --> 00:14:12.060 EntraID convalida che l'identità sia legittima, poi passa la richiesta a Key Vault. 00:14:12.660 --> 00:14:14.800 Key Vault controlla le autorizzazioni RBA che ha assegnato. 00:14:15.440 --> 00:14:19.160 Se l'identità è il ruolo giusto, ad esempio, utente segreti Key Vault, il segreto viene restituito. 00:14:19.660 --> 00:14:20.880 Tutto questo avviene in pochi millisecondi. 00:14:21.240 --> 00:14:22.680 L'applicazione non vede mai una credenziale. 00:14:23.060 --> 00:14:23.960 Non memorizza mai una paso. 00:14:24.320 --> 00:14:25.660 Tiene semplicemente il valore di cui ha bisogno. 00:14:25.660 --> 00:14:28.140 Ora pensa a quanti servizi Azure possono connettersi a questi. 00:14:28.460 --> 00:14:32.380 App Service, Functions, HES, Data Factory, Synapse, Logic Apps, DevOps, Pipelines. 00:14:32.840 --> 00:14:34.240 Sanno tutti come comunicare con Key Vault. 00:14:34.640 --> 00:14:38.580 Puoi configurare un'app web per fare riferimento a un segreto direttamente nelle impostazioni dell'applicazione. 00:14:39.380 --> 00:14:43.620 Puoi configurare una pipeline di Data Factory per recuperare una chiave di account ed archiviazione da Key Vault in fase di eseguzione. 00:14:44.120 --> 00:14:47.900 Puoi configurare un cluster Kubernetes per recuperare i segreti usando il driver CSI di Key Vault. 00:14:47.900 --> 00:14:54.140 Ogni servizio si integra allo stesso modo, usando lo stesso sistema di identità, gli stessi ruoli airback e lo stesso log di controllo. 00:14:54.800 --> 00:14:56.700 Il modello CCD è particolarmente potente. 00:14:57.160 --> 00:14:59.760 Le tue pipeline prelevano i segreti da Key Vault al momento del deploy. 00:14:59.960 --> 00:15:02.800 Non li memorizzano mai nelle variabili di pipeline o nei segreti del repository. 00:15:03.340 --> 00:15:09.460 Se devi ruotare una password del database e l'aggiorni in Key Vault, la volta successiva che la pipeline è eseguita recupera automaticamente il nuovo. 00:15:09.940 --> 00:15:12.620 Nessuna modifica la pipeline, nessun cambiamento del codice, nessun redeploy. 00:15:12.940 --> 00:15:14.120 Ecco cosa rende tutto perfetto. 00:15:14.120 --> 00:15:19.580 Una volta configurato Key Vault con l'identità gestita airback, smetti di pensare alla gestione delle credenziali. 00:15:19.880 --> 00:15:21.040 Le tue applicazioni funzionano semplicemente. 00:15:21.360 --> 00:15:23.380 I segreti vengono ruotati senza che nessuno se ne come. 00:15:23.660 --> 00:15:25.360 I certificati si rinnovano senza emergenza. 00:15:25.660 --> 00:15:27.140 Il sistema gestisce il tuo background. 00:15:27.680 --> 00:15:29.180 Questa è l'approccio alla sicurezza che conta. 00:15:29.840 --> 00:15:31.480 L'identità è il perimetro, non la rete. 00:15:31.940 --> 00:15:34.880 Non importa se qualcuno si trova all'interno o all'esterno della tua rete virtuale. 00:15:35.380 --> 00:15:38.260 Ciò che conta è se possiedono un'identità valida con i permessi corretti. 00:15:38.780 --> 00:15:40.220 Key Vault lo impone per progettazione. 00:15:40.220 --> 00:15:44.520 Ogni richiesta di accesso passa attraverso l'autenticazione EntraID e l'autorizzazione RBH, 00:15:44.620 --> 00:15:47.620 indipendentemente dalla provenienza, e tutto viene registrato. 00:15:47.960 --> 00:15:50.460 Ogni lettura di segreto, ogni operazione su chiave, ogni recupero dei certificati. 00:15:50.660 --> 00:15:52.020 Puoi vedere chi ha avuto accesso a quasi quanti. 00:15:52.320 --> 00:15:54.680 Se qualcosa sembra sospetto, hai dati per indagare. 00:15:55.280 --> 00:15:59.180 Questo è fondamentale per la conformità alla risposta agli incidenti e per sapere cosa succede nel tuo ambiente. 00:15:59.760 --> 00:16:00.780 Questa è la bellezza di tutto ciò. 00:16:00.780 --> 00:16:05.920 Key Vault, EntraID, RBH e identità gestita lavorano insieme come un framework di sicurezza unificato. 00:16:06.620 --> 00:16:07.740 Ogni elemento rafforza gli altri. 00:16:07.740 --> 00:16:13.900 Quando sono configurati correttamente, è un sistema di gestione delle credenziali più sicuro e semplice da usare di qualsiasi cosa. 00:16:14.020 --> 00:16:16.960 Potresti costruire da solo consigli pratici. 00:16:17.520 --> 00:16:18.720 Quindi, cosa dovresti fare concretamente? 00:16:19.220 --> 00:16:20.700 Trasformiamo queste conoscenze in azione. 00:16:21.220 --> 00:16:22.680 Ecco le cose che puoi affrontare questa settimana. 00:16:23.120 --> 00:16:24.040 Inizia dal tuo modello di permette. 00:16:24.440 --> 00:16:27.840 Apri il tuo Key Vault nel portale e vai alla configurazione di accesso e controlla cosa dice. 00:16:27.840 --> 00:16:30.260 Se vedi criteri di accesso al Vault, quello è il vecchio metodo. 00:16:30.800 --> 00:16:33.320 Dovresti usare invece il controllo degli accessi basato sui ruoli di Azure. 00:16:33.600 --> 00:16:34.520 La migrazione è semplice. 00:16:34.520 --> 00:16:39.660 Cambia il modello di autorizzazione e assegni i ruoli Airbac alle stesse persone che avevano già i criteri di accesso. 00:16:40.160 --> 00:16:40.640 Fallo oggi. 00:16:41.080 --> 00:16:44.400 Microsoft lo consiglia e la ricerca di cui abbiamo parlato ne ha mostrato esattamente il motivo. 00:16:45.300 --> 00:16:48.080 Successivamente, controlla gli account che detengono il ruolo di collaboratore Key Vault. 00:16:48.620 --> 00:16:51.420 Apri la scheda IEM sul tuo Vault e guarda chi ha l'accesso come collaboratore. 00:16:51.960 --> 00:16:53.880 Ogni persona con quel ruolo deve avere una valida ragione. 00:16:54.220 --> 00:16:55.200 Più delle volte non lo fanno. 00:16:55.200 --> 00:16:57.740 Sostituisci i contributor con qualcosa di più specifico. 00:16:57.960 --> 00:17:00.520 Se qualcuno deve solo leggere i segreti, usa Key Vault Secrets User. 00:17:01.140 --> 00:17:03.960 Se deve gestire i segreti, usa Key Vault Secrets Office. 00:17:04.520 --> 00:17:06.700 L'obiettivo è chiudere completamente quel percorso di escalation. 00:17:07.200 --> 00:17:08.660 Poi, sfrutta le manager identity. 00:17:09.380 --> 00:17:11.920 Qualsiasi servizio Azure che necessitera Key Vault dovrebbe usarle. 00:17:11.920 --> 00:17:15.940 Se hai una web app, una function, una data factory o una virtual machine 00:17:15.940 --> 00:17:20.100 che usa ancora una service principal, con un client secret, passa alle manager identity. 00:17:20.780 --> 00:17:23.860 È più semplice e più sicuro e risolve il problema dell'uovo e della gallina che abbiamo visto. 00:17:24.640 --> 00:17:27.080 Azure gestisce la gestione delle credenziali per te dietro le quinte. 00:17:27.660 --> 00:17:28.320 Un'ultima cosa. 00:17:28.420 --> 00:17:30.780 Abilita Soft Delete e Purge Protection su ogni Vault. 00:17:31.220 --> 00:17:34.700 Soft Delete è attivo di default per i nuovi Vault, ma Purge Protection no. 00:17:35.100 --> 00:17:35.460 Attivala. 00:17:35.920 --> 00:17:39.200 Quell'impostazione impedisce a chiunque di eliminare permanentemente un Vault o il suo contenuto 00:17:39.200 --> 00:17:40.360 durante il periodo di conservazione. 00:17:40.360 --> 00:17:42.940 Ha salvato più di un team da un errore disastroso. 00:17:43.460 --> 00:17:44.420 Ecco la tua call to action. 00:17:45.060 --> 00:17:46.360 Analizza il totale approccio alla gestire. 00:17:46.880 --> 00:17:51.020 Trova un segreto che ancora in un file di configurazione, una variabile d'ambiente o scritto nel codice, 00:17:51.620 --> 00:17:52.800 spostalo in Key Vault questa settimana. 00:17:53.100 --> 00:17:53.440 Solo uno. 00:17:53.700 --> 00:17:55.760 Una volta visto quanto è semplice, vorrei spostare anche il resto. 00:17:56.000 --> 00:17:58.200 La sicurezza non è una configurazione nata, è una pratica. 00:17:58.600 --> 00:18:01.520 Key Vault rende questa pratica più semplice, ma solo se usato correttamente. 00:18:01.860 --> 00:18:02.580 Gli strumenti ci sono. 00:18:02.900 --> 00:18:03.800 I pattern sono collaudati. 00:18:04.360 --> 00:18:05.420 Raspettate a implementarli. 00:18:06.120 --> 00:18:06.720 Questo è il sistema. 00:18:07.140 --> 00:18:10.340 Key Vault è la tua cassaforte digitale, ma è sicura solo quanto i controlli di accesso, 00:18:10.360 --> 00:18:11.280 che imposti attorno ad essa. 00:18:11.560 --> 00:18:13.080 Inizia con l'audit che ho appena descritto. 00:18:13.360 --> 00:18:14.100 Controllo i permessi? 00:18:14.460 --> 00:18:17.400 Verifica l'assegnazione di contributo e risposta a un segreto in un vault questa settimana. 00:18:17.880 --> 00:18:20.580 Iscriviti per altri consigli sulla sicurezza cloud in parole semplici 00:18:20.580 --> 00:18:23.440 e condividi questo video con chi archivi ancora i segreti nei file di configurazione.