 | |
Re: Securing the database from the DBA
comp.database.oracle comp.database.oracle
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Re: Securing the database from the DBA -
03-31-2004
, 08:36 PM
|
What do you do if you want to protect the data from the DBA? |
efforts.
Yes - security costs money, and all managers MUST remember that.
If you take people like trash and change them on positions like gloves
- what do you expect as payback? :-)
#2
| |||
| |||
|
|
What do you do if you want to protect the data from the DBA? ... give him a competitive sallary and proper recognition of his efforts. Yes - security costs money, and all managers MUST remember that. If you take people like trash and change them on positions like gloves - what do you expect as payback? :-) |
If you can't trust your DBA, then you should fire him.
Mike
#3
| |||
| |||
|
|
I've been thinking a lot lately about the additional security requirements that the recent onslaught of legislations placed on databases (HIPAA, Sarbanes-Oxley, Gramm-Leach-Bliley, California SB 1386). Specifically, consider the requirements for keeping an audit trail of data accesses and modifications. Within Oracle, triggers can be used to track DDL, DML, logon, logoff, and a myriad of other interesting events. Fine Grain Auditing can be used to audit SQL queries, and can be coupled with Flashback so that you can see exactly what was seen by those queries. All of these methods, and many of Oracle's other security features, put the responsibility on the shoulders of the DBA. But doesn't this also give the DBA the powers to circumvent these measures? Can't he delete rows from the audit logs? Can't he disable triggers or FGA policies before doing something sneaky? When using the database's facilities as your audit trail tool, doesn't the DBA have the knowledge and ability to circumvent and cover up _anything_? What do you do if you want to protect the data from the DBA? Many companies now have separate security departments, as seen by the rise of the 'Chief Security Officer'. If they wanted to put the responsibilities of maintaining the database audit trail in the security department, would they hire a DBA in that department to watch the DBA in the IT department? Or should they use mechanisms outside of Oracle for securing the database, such as some third party tool? Maybe these concerns too far from the real world. Do most companies simply let the DBA handle the database security, and worry about whether he _should_ be the one handling security only after there is an incident? Thanks for your opinions! dave |
We're in the same situation - trying to address the concerns of
Sarbanes-Oxley and FDA 21CFR Part 11. Like you said, it's a catch-22,
that you can't truly secure the database from the people who are
responsible for maintaining it.
All parties involved have to realize that, but still make a serious
effort at following good security practices, with the knowlege that
nothing is perfect. One important thing that we are working on is
separation of duties: the Security group will have 3rd party tools to
monitor audit trails and security related database configuration.
Account creation and granting of application access is handled by
another group who insures that no access is granted without proper
authorization, performing periodic user access reviews, etc. DBAs
will use their own personal accounts for DBA work instead of SYS,
SYSTEM, etc. Good change management procedures with an approval
process should be followed so that no unauthorized changes are made to
a system.
DBAs will always be able to do anything in the database of course, but
you try to put certain practices in place so that with the right
monitoring, something suspicious would be recognized as such. That
alone could be a big deterrent.
With the right type of database auditing enabled, a DBA would have to
be very careful to sneak something by: if they try to disable a
trigger or modify a stored procedure in order to change data
undetected, that type of DDL would be audited. If they try to delete
that audit record from aud$, that deletion can be audited. Turning
audit options on and off should be audited. A dba could try changing
the init.ora parameter audit_trail to false but that needs a database
shutdown, and when it comes back up the security group's tools should
notice that audit_trail is set wrong. Shutdowns should not happen
output of approved maintenance windows or change management, so any
unexpected shutdowns should be investigated.
All of this is not perfect, and it is a lot of work, but in some
environments you just have to try your best. Auditors always like to
see some measure of control in place.
--
Joe
http://www.cafeshops.com/joekaz
http://www.joekaz.net
#4
| |||
| |||
|
|
We're in the same situation - trying to address the concerns of Sarbanes-Oxley and FDA 21CFR Part 11. Like you said, it's a catch-22, that you can't truly secure the database from the people who are responsible for maintaining it. |
group? If not, then why not make the DBA a member of that group?
/Hans
#5
| |||
| |||
|
|
Joe wrote: We're in the same situation - trying to address the concerns of Sarbanes-Oxley and FDA 21CFR Part 11. Like you said, it's a catch-22, that you can't truly secure the database from the people who are responsible for maintaining it. Dumb question - does the system need to be protected from the security group? |
them. A security group probably only needs read-only access - access
to the dictionary and audit trails, but not the application data.
Quote:
|
If not, then why not make the DBA a member of that group? |
the system. Having the DBA who maintains the database report into the
security group (or the other way around) defeats that concept, so it's
best to keep them as 2 distinct entities.
--
Joe
http://www.cafeshops.com/joekaz
http://www.joekaz.net/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.