Qual è una buona pratica di sicurezza per l'archiviazione di un database critico sui laptop degli sviluppatori?

Abbiamo alcuni dati:

1. Gli sviluppatori hanno bisogno di una replica del database di produzione sui loro computer.
2. Gli sviluppatori hanno la password per detto database nei file App.config.
3. Non vogliamo che i dati in detto database siano compromessi.

Alcune soluzioni suggerite e i loro svantaggi:

1. -Disk-crittografia completa. Questo risolve tutti i problemi, ma degrada le prestazioni del laptop e noi siamo una start-up, quindi non abbiamo soldi per i powerhorses.
2. Creazione di una macchina virtuale con disco rigido crittografato e archiviazione del database su di essa. Funziona bene, ma non aiuta molto, dal momento che c'è una password in Web.Config.
3. Soluzione numero 2 + che richiede allo sviluppatore di digitare la password del database ogni volta che esegue qualcosa. Risolve tutti i problemi, ma è davvero complicato per gli sviluppatori che a volte accendono l'applicazione più volte al minuto. Inoltre, abbiamo più applicazioni che si collegano allo stesso database e l'implementazione di una schermata di password dovrà differire in ciascuna.

Quindi, la mia domanda è: se esiste una soluzione comune a tale problema o qualche suggerimento su come rendere praticabile una delle soluzioni sopra?

Non solo non si desidera una copia del database di produzione, ma potrebbe anche essere illegale. Ad esempio, negli Stati Uniti, non è possibile spostare i dati di produzione fuori dall'ambiente di produzione se contengono informazioni regolamentate come dati sulla salute personale, dati finanziari o persino dati che potrebbero essere utilizzati nel furto di identità. In tal caso, potresti essere multato, perdere la tua conformità e quindi essere soggetto a controlli più aggressivi o addirittura essere nominato in una causa.

Se hai bisogno di dati su scala di produzione per i test, hai un paio di opzioni:

1. Genera tutti i dati fittizi. Questo è più complicato di quanto sembri. È sorprendentemente difficile e laborioso generare dati immaginari sensibili.
2. Anonimizza i tuoi dati di produzione. Questo può essere più semplice, ma procedere con cautela.

Per l'opzione n. 2

• Nell'ambiente di produzione, un amministratore di database autorizzato crea una copia dei dati di produzione.
• Sempre nell'ambiente di produzione, lo stesso amministratore autorizzato esegue una routine che anonimizza tutti i dati sensibili. In caso di dubbio, anonimizzare.
• Solo allora i dati dovrebbero essere spostati in un altro ambiente.

Puoi almeno dare agli sviluppatori VM nel tuo datacenter che possono RD per questo lavoro? Mentre dovrebbero davvero lavorare su dati non di produzione, questo sarebbe più sicuro fino a quando non ci si arriva poiché i dati non verrebbero archiviati su laptop rubati facilmente.

Cambia il tuo modo di lavorare, se possibile.

Come altri hanno sottolineato:

• L'uso dei dati di produzione per lo sviluppo non è una buona pratica.
• Avere una password memorizzata in testo normale non è una buona pratica.

Entrambi espongono a rischi significativi e devono essere modificati se possibile. Dovresti almeno valutare seriamente quale sarebbe il costo per apportare queste modifiche. Se questa è una dipendenza esterna che non hai il potere di cambiare, considera di sollevarla come una preoccupazione per chiunque abbia quel potere.

Nel mondo reale, tuttavia, potrebbe davvero non essere possibile cambiarlo. Supponendo che ciò che stai facendo sia legale, potresti dover convivere con questo accordo (almeno temporaneamente).

Se questo è veramente necessario, devi solo eseguire la crittografia dell'intero disco.

Dati i rischi, è necessario utilizzare l'opzione di sicurezza più disponibile e questo è tutto. Se c'è un colpo di prestazione, vivi con esso. È un costo per lavorare con dati sensibili.

Se fossi tuo cliente, non sarei impressionato dal fatto che tu abbia deciso di non utilizzare la migliore opzione di sicurezza disponibile con i miei dati, perché ha reso i tuoi laptop leggermente più lenti.

La risposta di Corbin March è piuttosto buona, aggiungerò solo un dettaglio aggiuntivo, che generalmente hai due classi di dati nel tuo database di produzione: metadati di sistema / applicazione; e dati utente client / dati transazionali. Quest'ultimo non dovrebbe MAI essere usato in un ambiente di sviluppo "così com'è".

È molto raro infatti che siano necessarie informazioni reali sul cliente di produzione per fare lo sviluppo.

Tuttavia, se il problema qui descritto dall'OP riguarda dati segreti commerciali o altrimenti dati di sistema altamente proprietari che non riguardano i dati dei clienti, ciò è richiesto dagli sviluppatori ... l'approccio alla sicurezza deve coinvolgere uno schema che non ha la password db mantenuta in chiaro in un file di risorse da qualche parte. È necessario un meccanismo per, ad esempio, rigenerare una password giornaliera, che non è memorizzata sul disco.

Non si specifica quale database e quale ambiente.

Se è possibile utilizzare la sicurezza integrata, il database non è accessibile senza aver effettuato l'accesso come tale utente. Sì, se i dati si trovano sul disco rigido possono essere compromessi, ma si tratta di una difesa di primo livello.

App.config mi fa pensare che questo possa essere un .NET. Inserisci config in una chiavetta USB e leggila dalla chiavetta USB. Se l'unità non è presente, inserire l'utente nella password.

Esiste un modo per archiviare la password in memoria la prima volta che viene inserita e letta da tutti. Ancora una volta non dichiari l'ambiente. File mappati in memoria

Con alcuni TDE è possibile archiviare la chiave su un dispositivo separato in modo che forniscano semplicemente la chiave all'avvio del server di database.

Un'opzione possibile è quella di creare una copia del database e scrub quella copia con uno script in modo da finire con dati diversi da quelli effettivamente in produzione. Non finirai con gli stessi dati della produzione ma avrai la stessa scala.