May 23, 2004 at 4:02 am
Having an audit trail & controls over changes to data within a database is a requirement of the SOX Act. But does this also include providing an audit trail of changes to the database schema, reference tables & stored procedure code?
Thanks,
Darren
May 24, 2004 at 7:37 am
Yes everything needs to be tracked and no changes can be implemented by the developer per our SOX auditor. The developer makes the changes and documents it then sets it up in a test enviornment for the users to test. Once testing passes the change must be handed off to a "migration specialist" whom will be responsible for making the change to the production serves. Change in security, adding new users, etc all needs to be tracked and audited. We are a small shop and still figuring out how to create all then new hats since we are not allowed to wear hats in both the production and developer worlds.
Mike
July 27, 2004 at 6:50 am
I agree with your SOX separation of duties setup and monitoring interpretations. What have you done to monitor the activities of your individuals who have the capability to alter the production schema (such as your 'migration specialists')? Do you have a process built to report any 'DBA' type activities in the Production environment?
July 27, 2004 at 7:09 am
We have the same requirements here. We're doing a few things to insure we're compliant:
1. Seperation of duties. Developers can't change ANYTHING in production.
2. Set up a trace to monitor all metadata changes and permissions changes.
3. Set up a trace to monitor all connections outside of app and web server pairs.
4. Lock down security on applications to only permit needed access per application context.
Derrick Leggett
Mean Old DBA
When life gives you a lemon, fire the DBA.
August 18, 2004 at 8:48 am
We have seperation of duties. All promotions (data/schema) come through the DBA's. We have an audit trail of paper. The developers fill out a form for the promotion. Their manager must also sign off on it. We do the promotion, sign it and put it in a 3 ring binder. We do this for all databases (SQL, Oracle, DB2, Adabase).
I don't know about others, but the auditors we got seem very green. We got told to "audit all transactions on all platforms" basically. We told management that it would require 2 to 4 times the hardware for CPU, memory, ect. Management went back to the auditors and said that was not realistic. No word yet on where this will go.
Our department's philosphy up to this point has been, if there are actions and processes that need to be scrutinized, the application should be auditing those. Actions that need to be tracked (who update what row, what purchasing amount) should be tracked in the application.
Has anyone been hit with "List of those approved to change the list of those approved to be on the list of those who can request promotions?" Our security people are dealing with that.
Joseph
December 20, 2004 at 11:09 am
check out http://www.dbghost.com for a process to follow that can a long way to satisfy any auditing requirements.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply