Crittografia di web.config utilizzando la configurazione protetta inutile?

Question

Mi manca qualcosa ...

Quindi sono in procinto di capire il modo migliore di crittografare le informazioni di connessione di stringa di connessione database e sessione SQL in web.config. Trovo subito una passeggiata su MSDN che spiega utilizzando la configurazione protetta per crittografare parti del web.config: MSDN walkthrough on using Protected Configuration

Così sto pensando grande, v'è un meccanismo in atto per fare questo e sembra molto semplice. Arrivo alla fine della procedura dettagliata e forniscono il codice sorgente per una pagina aspx che può essere utilizzata per decrittografare tutte le stringhe di connessione !!!!

Qual è il punto ??? Non ho alcun servizio ftp in esecuzione su questo server web, l'unico modo in cui chiunque vedrà web.config è se hanno accesso al file system su cui è pubblicato il sito web. Se lo hanno, allora tutto ciò che devono fare è usare il codice fornito per decrittografarlo.

Cosa mi manca? C'è un modo migliore per crittografarli? Se lancio una soluzione personalizzata, funzionerà per la parte dello stato della sessione sql? (non credere che il cane possa essere rimosso da web.config)

Answer 1

È necessario almeno un accesso in scrittura al filesystem per poterlo decodificare, presupponendo che si stia utilizzando il provider DPAPI. Modi per decifrare includono:

• Copia una pagina aspx contenente il codice di decrittazione al server e navigare ad esso
• Entra sul server ed eseguire un'applicazione per decodificarlo.

Ma protegge contro la decrittografia da un utente non autorizzato che ha accesso in lettura al filesystem o un backup del filesystem.

In genere si configurano i server di produzione in modo che solo gli amministratori autorizzati possano accedere al server o scrivere sul proprio file system.

Gli sviluppatori possono avere accesso in lettura remoto a scopo di supporto e non sono in grado di decodificare il file di configurazione in remoto.

La crittografia/decrittografia è facile con le librerie standard: la parte difficile è garantire che solo le persone autorizzate abbiano accesso alle chiavi.

Se si utilizza DPAPI, si sta essenzialmente delegando la gestione delle chiavi di sicurezza di Windows. Se si utilizza un altro provider come RSA, è necessario archiviare la chiave da qualche parte e proteggerla da accessi non autorizzati, ad es. usando un ACL.