February 5, 2010 at 2:33 pm
I've got an application that collects sensitive data, with a SQL backend. Due to some recent developments, an order has come down from regulatory bodies that certain parts of the collected data must be destroyed. We'll need to update some tables, over writing some columns with null values.
What do you think is reasonable to ensure the previous values are not recoverable?
How far do we take this? Do we deal with Transaction logs, SQL Server logs, backups + tapes, bouncing servers to ensure nothing is in memory, wiping hard drives, etc?
I've never been asked to destroy data and make sure it not recoverable. Any input would be appreciated.
February 8, 2010 at 1:34 pm
writing NULLs won't do it... you'd have to fill up each column with different data and even that won't insure that bits and pieces of the original data won't remain in places on the disk because of page splits, rebuilding indexes or transaction log allocations and so forth.
I would think encryption of the sensitive data would be a more controllable methodology.
The probability of survival is inversely proportional to the angle of arrival.
February 8, 2010 at 10:09 pm
Have a look at this thread where the complexities of 'unrecoverable deletes' was discussed.
http://www.sqlservercentral.com/Forums/Topic857162-391-1.aspx
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply