Ho letto molto sulla nuova funzionalità di Azure Key Vault e ha alcuni casi d'uso validi. Tuttavia, nel caso di una semplice web app, non vedo il vantaggio di utilizzare variabili di ambiente che possono essere configurate nel portale. Se un hacker ha accesso al tuo portale azzurro, allora ha accesso alla configurazione del tuo vault. Qual è il valore aggiunto?
Mi piacerebbe sentire i tuoi pensieri.
Azure Key Vault non offre solo soluzioni crittografiche. È anche un negozio segreto basato sull'utente. Questo risolve un problema di gestione segreta, che è una soluzione rapida. Immagina di avere un database SQL a cui devono accedere più host, ad esempio host A e B . Se la password del database è compromessa (in genere perché un host è stato attaccato) e li metti in variabili d'ambiente su entrambi gli host, devi curare entrambi gli host.
Con un archivio segreto basato sull'utente, A e B hanno credenziali distinte. Se A viene attaccato, l'attaccante può essere in grado di recuperare la password del database SQL, ma è possibile rimuovere immediatamente l'autorizzazione A dal Key Vault, cambiare la password nel database SQL, e aggiorna Key Vault con la nuova password. Nota che nessuna azione è stata eseguita su B . Quando B si identifica con l'archivio segreto, recupera la password SQL aggiornata e riprende l'operazione.
Ovviamente, se la tua password del database viene utilizzata dalla singola app Web, questo non aiuta molto. Tuttavia, potresti avere applicazioni crittografiche che traggono vantaggio dal non vedere mai la chiave privata, come spiegato dall'altra risposta.
However in the case of a simple web app I don't see the benefit of using environment variables which can be configured in the portal.
Non ho usato Azure Key Vault, ma sembra che l'applicazione client non sia mai vede effettivamente la chiave master :
When a SaaS application needs to perform cryptographic operations by using their customers’ keys, Key Vault does this on behalf of the application. The application does not see the customers’ keys.
Se l'applicazione è compromessa, in entrambi gli scenari l'attaccante può decifrare quello che vuole. Tuttavia, se l'applicazione (e quindi l'utente malintenzionato) non ha mai accesso diretto alle chiavi, una volta che l'autore dell'attacco ha perso l'accesso, non è più possibile decodificare ulteriori dati. Questo protegge i dati futuri e i dati che l'autore dell'attacco non è stato in grado di decodificare prima di perdere l'accesso a causa di una violazione.
Se la chiave principale era semplicemente in una variabile di ambiente e l'utente malintenzionato lo ha compromesso, anche se hai revocato completamente il loro accesso, potevano continuare a decrittografare i dati originariamente rubati.
Un ulteriore vantaggio è che presumibilmente ogni operazione di decrittografia viene registrata, in modo da poter controllare più facilmente l'ambito dei dati che sono stati compromessi. Tuttavia, se l'utente malintenzionato avesse accesso diretto alla chiave, potrebbe decrittografarlo offline e non sapresti mai cosa è stato e non è stato compromesso.
Leggi altre domande sui tag azure environment-variables key-management