Come dovrei cancellare i dati sensibili da un database?

Questo tipo di requisito è impossibile da soddisfare finché non chiari il livello di "eliminazione" richiesto.

La cosa più semplice da ottenere è modificare il database in modo che i record in questione non vengano più restituiti dalle operazioni richiamate nell'interfaccia normale. Per questo, devi solo contrassegnare le cose come cancellate ed estendere la tua logica di business in modo che ignori gli elementi con questo marchio. Potrebbe essere o non essere sufficiente per soddisfare l'utente.

Se l'utente (o la legge) richiede che le informazioni sensibili non siano più disponibili anche agli operatori del software , le cose diventano molto più difficili. Ciò significa che devi effettivamente eliminare i record e, come hai visto, questo potrebbe comportare l'eliminazione di molto più di quanto sia ovvio a prima vista.

Ma anche allora la domanda è se sia sufficiente eliminare solo le cose già esistenti. I dati all'interno di un record sono scomparsi quando lo elimini, ma per quanto riguarda il fatto che c'era un record? Le informazioni sensibili possono consistere semplicemente nel fatto che un utente ha usato un sistema a tutti in un momento specifico, e la semplice eliminazione di elementi lascia vuoti riconoscibili in sequenze ID, tabelle di allocazione, ecc. Che potrebbe essere reverse engineering per ricostruirne alcuni. Inoltre, che dire dei file di registro? Backup di sistema? Motori di ricerca di Internet? L'elenco di luoghi in cui i dati potrebbero o non potrebbero ancora esistere è sorprendentemente lungo.

Come vedi, la quantità di lavoro da svolgere in ciascun caso è molto diversa. Pertanto, l'unico modo utile per eliminare i dati sensibili è innanzitutto stabilire chiaramente quale livello di eliminazione è richiesto. Per utenti non tecnici, potresti esprimere le alternative in termini di capacità :

• semplice revoca: altri utenti non possono più ricostruire i tuoi dati.
• cancellazione vera: tu stesso non puoi ricostruire i tuoi dati.
• cancellazione a livello di sistema: gli operatori non possono ricostruire i tuoi dati, anche se li volevi.
• cancellazione delle armi: la NSA non è riuscita a ricostruire i tuoi dati.

Kilian ha ragione che c'è più da considerare del database di produzione, e che bisogna pensare a quanto deve essere sicura la cancellazione. Ma c'è ancora la tua domanda principale a cui rispondere, come eliminare le cose giuste, all'interno del database, assumendo che tu abbia già in mente anche i suoi altri punti. Hai scritto

the system is complex ... If I simply do a cascade delete, it can easily affect how other functionality might operate in unpredictable ways.

Questo mi dà l'impressione che tu non abbia effettuato una analisi di impatto approfondita sulla cancellazione, che semantica hanno le relazioni tra record di dati, se tutti i requisiti di integrità dell'azienda sono modellati esplicitamente utilizzando l'integrità referenziale meccanismi del database, quali delle applicazioni esistenti trattano le parti del modello di dati in cui avverrà la cancellazione e così via.

Ma questo è obbligatorio per farlo bene, non c'è nessun collegamento a questo . Devi capire esattamente le conseguenze della tua azione nel miglior modo possibile, specialmente perché il sistema è complesso, non "nonostante". In genere, non è sufficiente guardare il modello dei dati, è necessario leggere la documentazione, scoprire in quali dati "porzioni" vengono aggiunti al database (in questo modo è possibile dedurre cosa eliminare invertendo tale processo) e capire i relativi processi aziendali, almeno fino a un certo punto. Se sei fortunato, puoi chiedere ad altri colleghi che hanno queste informazioni o, se sei molto fortunato, ad altri che hanno contribuito a sviluppare le parti del sistema con cui hai a che fare.

Una volta comprese le relazioni nel tuo modello di dati, avrai risolto oltre il 50% del tuo compito e sono abbastanza sicuro che potrai rispondere alla tua domanda da solo.

Naturalmente, attraverso tale analisi, potresti trascurare qualcosa, ed è per questo che i tuoi script di cancellazione devono essere testati come qualsiasi altro software - non sul "database live", ma su un sistema di test, idealmente pieno di dati dal sistema live.

Sì, non vi è alcun modo per approfondire l'analisi di questo requisito di cancellazione. E non c'è scorciatoia per proteggere le informazioni sensibili. Oltre alle belle risposte già fatte, vorrei condividere alcuni pensieri:

• se si riuscisse a eliminare tutto ciò che era necessario dal database, ci sarebbero ancora molte prove di questi dati nei backup più vecchi, nei registri e, soprattutto, nei file gestiti dal DBMS (Ad esempio, molti sistemi db utilizzano questo spazio file come una sorta di blocco di memoria e non sovrascrivono necessariamente i dati eliminati fino a quando non saranno aggiunti abbastanza nuovi dati). Se il tuo db è conservato nell'archivio SSD, è anche peggio perché il driver SSD eviterà la sovrascrittura il più possibile. Pertanto, la cancellazione totale per garantire un livello di sensibilità governativo richiederebbe diverse procedure operative per completare l'azione del database.
• ma dalla tua formulazione, comprendo che il tuo problema riguarda più la gestione delle dipendenze, eliminando solo il minimo ma, se possibile, nulla a causa di tutte le relazioni che potrebbero interrompere la coerenza dell'applicazione. Se è così (e la sensibilità non è di livello riservato) potresti considerare l'approccio di marcatura per la cancellazione con sovrascrittura di informazioni critiche (es. Contrassegnare per cancellare il record, filtrarlo a livello di app e sovrascrivere alcuni campi sensibili come il nome del prodotto nel db che potrebbe consentire di riconoscere il marcato per i dati cancellati). Questo approccio è una soluzione alternativa per i sistemi legacy, ma a lungo termine è necessario comprendere a fondo le relazioni con gli altri in modo da poter effettuare interventi chirurgici del genere.
• Infine, devi comprendere appieno la necessità, non solo di scegliere la soluzione migliore, ma anche di vedere se è ragionevole ed evitare di essere complice di alcune attività ovviamente illegali (specialmente se lavori su sistemi finanziari o sistemi sottoposti a SOX o regolamento GMP)

Avevo un requisito simile per un'applicazione di gestione dei casi governativa in cui il database memorizzava le informazioni personali per molte persone. I requisiti legali erano che dopo 10 anni tutte le informazioni dovrebbero essere rimosse / eliminate / distrutte. La struttura del database era tale che la cancellazione delle informazioni personali era impossibile in quanto era collegata al lavoro che doveva essere mantenuto.

La mia soluzione era aggiornare le informazioni personali. Laddove le informazioni come i numeri di telefono non erano fondamentali per l'integrità dei dati, l'ho aggiornata a null. Anche gli indirizzi e i codici postali / postali potrebbero essere impostati su null.

Data la scelta di aggiornare migliaia di record di nomi di persone a John Doe o Jane Doe, ho creato una tabella di nomi falsi e li ho usati come origine per l'aggiornamento.

L'unico problema che non ero in grado di risolvere era la città in cui la gente viveva. Questo è stato usato anche dalle società i cui indirizzi non dovevano essere puliti. se avessi aggiornato New York con un nome falso, tutte le corporazioni mostrerebbero quel nome.

Questo sottolinea il problema che la rimozione di informazioni sensibili o la conservazione è un requisito aziendale che dovrebbe essere covato quando l'applicazione è progettata o può essere molto doloroso da fare in seguito.