September 29, 2008 at 7:40 am
Hi,
The Payment Card Industry PCI-DSS and PA-DSS audit requirements mandate that all credit card data stored in previous releases of a payment application be "securely deleted" when upgrading the application.
There are utilizes out there to securely delete file data that has been deleted in Windows but still resides on the disk. However, my understanding is that database fields deleted in SQL Server are stored in space allocated by the database and will not be recognized as freed data when securely deleting data from Windows as it is stored in swap space controlled by SQL Server.
Is there a utility or function to securely delete database fields in SQL Server?
If not, if I backup the database, securely wipe the disk, and then restore the database, will fields that were previously deleted be placed back on the disk by the restore or not? How is disk space that SQL Server allocates treated when a backup and restore occurs?
thanks,
Jeff
September 29, 2008 at 9:12 am
Very interesting requirement and thought here.
Honestly I'm not 100% sure, though I'll ask the question of some experts.
My understanding is that when you delete a row, it's marked as deleted and the space in the page/extent is available for reuse by that table. Subsequent updates/inserts might re-use that space if it's proper based on the clustered index and fillfactor.
A rebuild of the clustered index should reallocate extents and so the deleted data in old extents is marked as free, and can be used by any structure, but again they wouldn't be rewritten.
My only thought it that updating the fields to blank/zero, and then deleting them might be the only way to achieve this, but I'll ping a few people.
September 29, 2008 at 9:15 am
Not sure on the restores, based on the "get it out as quick as possible", my guess is the deleted data is in the restore, marked as free.
September 29, 2008 at 9:47 am
That makes no sense. If you do backups of the database that data would be all over anyhow....
If you need to remove it from disk only to the point it could not be found using a file editor.... I would update the columns with junk data, then drop the column. Of course, it still would be in the transaction log somewhere..... unless you change the mode to simple recovery before you updata the column.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply