The first requirement is a locked down db server in a secure location
(with physical access to the hardware *all* security is invalidated -
even a bank TPM given sufficient time and technology).
The WORM approach can be circumvented by re-coding the whole disk, or
all the disks, or the entire [tape] library!
Encryption and hashing are a deterrent but it's difficult to see how you
could defend against in-house attack .
Given such a secure server I would implement instead of triggers calling
SP's that write hash-authenticated logs wrapped in the same transaction
as the main update. As a normal data security rule I would always block
actual deletes (substituting a 'deleted' flag). You obviously need Add,
and at that point in the design I would ask the client whether that want
updates to be a) logged b) blocked but replaced by delete + add or c)
not allowed at all (really? never?? not ever???)
I think you could then 'claim' to have an immutable system.
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
