Extract data to read-only format (a bit off topic...)
-
While not directly a SQL Server issue, here's my dilemna. I have a requirement (a government regulation, not something I can change) to be able to extract records from a SQL2K table to a file and have that file be read-only. Basically, this is an application's system log table and the read-only requirement is so that someone can't manually manipulate the archived log entries. Any thoughts? TIA... Steve
-
Use NTFS permissions and allow the file to be only read (not delete, modified, moved..). Make sure only the server and administrators can access it.
-
Export to PDF and disable print and copy of the file properties and there is more you can add including password protecting. Hope this helps.
Kind regards,
Gift Peddie -
Gift Peddie... the problem with that approach is that PDF requires a security password be set. You also have to confirm the password, so you can't just hit a bunch of keys. If someone knows the password, they can re-open the document, remove security, and modify the document. My requirement is for the file to be permanently read-only for everyone (admins included).
Same issue WRT the NTFS permission idea -- if someone can reset the permissions, that won't work.
-
I don't think there's any way of making this totally read only. There's always someone who's gonna have to have access to that file (like the server).
There's one other way however >> Print it.
-
Export to Excel or Word save as HTML. Hope this helps.
Kind regards,
Gift Peddie -
Same problem... just access the source file and edit.
-
There is no such thing as 100% security - you just can make it more or less difficult for someone to break.
However you do it, if you add a checksum, at least you know if its been tampered (but somebody theoretically could reproduce the checksum). Also, you could have two or three copies encrypted differently and an app to read them. Tampering would have to break the multiple encryptions and change everything to match. How far do you want/need to go?
-
NTFS permissions are definitely the way to go. Only trusted personnel should be able to make changes to the permissions, and hence be able to make changes to the file. For all other personnel, the file will be read only. Digitally signing the file will allow you to track whether anyone does make any changes, so that even a trusted person won't be able to change it without someone knowing. There are practical limits to ANY security system, and trusted personnel are an intrinsic and inescapable part of those limits.
-
Alternatively, get someone to password protect it, don't let them tell anyone the password, and then kill them
Might be considered a little on the extreme side though... -
Thre's always physical security. Stick it on a CD rather than a network drive. Keep a copy locked in a safe for comparison.
-
I think I like Ian's last suggestion. We'll hire a contractor and tell them it's for a "short term" position. 🙂 Thanks everyone for the suggestions. I'll offer up these ideas and let management decide what they want to do.
-
There is one problem with that I experienced it so I know we had a 500 pages use case document the developers and the business team have read and write access to the file I tried to check it out one day and it says it was already checked out by my userID so I checked and found out it was checked out by another developer. Word files caches userID.
Kind regards,
Gift Peddie
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply