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

Non solo non vuoi una copia del database di produzione, in realtà potrebbe essere illegale. Ad esempio, negli Stati Uniti, non è possibile spostare i dati di produzione fuori dall'ambiente di produzione se contiene informazioni regolamentate come dati personali sulla salute, dati finanziari o persino dati che potrebbero essere utilizzati nel furto di identità. Se lo fai, potresti essere multato, perdere il tuo livello di conformità e quindi essere soggetto a controlli più aggressivi o persino essere nominato in una causa.

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

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

Per l'opzione # 2

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

Puoi almeno dare agli sviluppatori VM nel tuo datacenter che possono utilizzare RD per questo lavoro? Mentre dovrebbero davvero lavorare su dati non di produzione, questo sarebbe più sicuro finché non ci si può arrivare dato che i dati non verrebbero archiviati su laptop facilmente rubati.

Cambia il tuo modo di lavorare se possibile.

Come altri hanno sottolineato:

• Utilizzare i dati di produzione per lo sviluppo non è una buona pratica.
• Avere una password memorizzata in testo normale non è una buona pratica.

Entrambi ti espongono a rischi significativi e, se possibile, dovrebbero essere modificati. Dovresti almeno valutare seriamente quale sarebbe il costo di tali cambiamenti. Se questa è una dipendenza esterna che non hai il potere di cambiare, prendi in considerazione l'idea di sollevarla come una preoccupazione per chiunque abbia quel potere.

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

Se ciò è veramente necessario, devi solo eseguire la crittografia su disco completo.

Dati i rischi, è necessario utilizzare l'opzione di sicurezza migliore disponibile, e questo è quanto. Se c'è un successo nelle prestazioni, vivi con esso. È un costo del lavoro con dati sensibili.

Se fossi il 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é rendeva i tuoi laptop leggermente più lenti.

La risposta di Corbin March è abbastanza buona, aggiungerò semplicemente un ulteriore dettaglio, 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'è".

È davvero raro che tu abbia bisogno delle attuali informazioni sul cliente di produzione per lo sviluppo.

Tuttavia, se il problema che l'OP sta descrivendo qui coinvolge dati segreti commerciali o dati di sistema altamente proprietari che non coinvolgono i dati dei clienti, richiesto dagli sviluppatori ... l'approccio alla sicurezza deve coinvolgere uno schema che non 't avere 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 è archiviata su disco.

Non si specifica quale database e quale ambiente.

Se è possibile utilizzare la sicurezza integrata, il database non è accessibile senza accedere come tale utente. Sì, se i dati sono sul disco rigido possono essere violati, ma questa è una difesa di primo livello.

App.config mi fa pensare che questo potrebbe essere un .NET. Metti il config in una pen drive e leggilo dalla pen drive. Se l'unità non è presente, inserire l'utente nella password.

C'è un modo per memorizzare la password in memoria la prima volta che viene inserita e letta da tutti. Ancora una volta non si indica l'ambiente. File mappati in memoria

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

Una possibile opzione è creare una copia del database e scriverla con uno script in modo da ottenere dati diversi da quelli effettivamente in produzione. Non ti ritroverai con gli stessi dati della produzione Ma avrai la stessa scala.