Is a "delete" really 100% gone?

Question

Is a "delete" really 100% gone?

Viewing 9 posts - 31 through 38 (of 38 total)

You must be logged in to reply to this topic. Login to reply

hoo-t SSChampion Points: 12713 More actions · Answer 1

You know, because we're talking about deleted records in an existing database, and the "deleted" records may/may not be completely deleted, those "deleted" records are still as safe as the existing data. In other words, the deleted records exist in the existing database files, which are hopefully well protected already. The only possible issue that I see is if that database file is copied and sent to another party who should not have access to the "deleted" data. In this case, the required data could simply be exported to a flat file, spreadsheet, another db, etc., leaving the deleted records behind.

Steve

lionfan91 SSCrazy Eights Points: 8794 More actions · Answer 2

The only possible issue that I see is...

Not really. The original issue/problem was that the DoD/CIA accreditation guidelines the system is governed by say that when "an object is released" that the memory space the object was using needs to be completely cleaned. In the case of a DB that means that when a record is deleted, the space is was taking up needs to be cleaned out, leaving no trace of the original record. I think collectively this thread has proven that SQL Server doesn't come anywhere close to doing this and if I need to get my system accredited I'll be re-writing it in Oracle. That sucks. I think MS dropped the ball on implementing this type of design. Maybe Yukon will be better??

davidf Right there with Babe Points: 787 More actions · Answer 3

milzs, check out this page on NSA security ratings of software. It appears Informix-OnLine/Secure, Trusted Oracle7, & Sybase's Secure SQL Server are only marginally higher classification than MS SQL Server 2000 (B1 vs. C2). I'd check the details of those products and your issue BEFORE you begin rewriting any code. (note: web page last updated 9/18/2000)

http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html

hoo-t SSChampion Points: 12713 More actions · Answer 4

milzs,

I see where you are coming from. My point is that since the record (deleted or not) is still in the database, no "object is released". Its still held by the database file, which is still held by SQL Server. I don't know if the government would see it in that light, though.

Steve

Stewart Joslyn SSCertifiable Points: 6131 More actions · Answer 5

Perhaps the only solution to meet the spec will be to use SQL Server as an indexing engine but hold all the sensitive data in a separate .dat file that you manage yourself at a low level. The database only holds pointers to your file(s). Messy and slower but at least you have total control.

davidf Right there with Babe Points: 787 More actions · Answer 6

"object is released" as in release to the operating system as free disk space to be used/accessed by the o/s or some other app. Is that the distinction you are trying to make?

davidf Right there with Babe Points: 787 More actions · Answer 7

Stewart, that's the way our document mgmt system works. SQL Server is nothing but document filenames. Who cares if anyone sees the filenames(nothing sensitive about f0000001.dat, & f0000002.dat) , the files themselves are protected by security.

milzs, you could use a pgp protected archive store that is both encrypted and "wipes" release space clean.

hoo-t SSChampion Points: 12713 More actions · Answer 8

Davidf,

Yes, that is the point I was attempting to make. Because the disk space that the data occupied has not been released to the operating system, it is still as secure as the data that has not been deleted.

Steve

Antares686 SSC Guru Points: 125444 More actions · Answer 9

If you were referring to me. Sorry, busy this week. The answer was nothing else whatsoever was occurring on this instance/server as it is my local machine and no accounts were logged in other than me.