Oracle segregation/separation of duties

Oracle Expert$$$$$$$

how to technically enforce SOD in an Oracle Database environment

i have one DBA who is controlling every thing.

goal: DBA can not read data (useful info) from the tables, DBA should do only Admin job
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Consider data encription for key/sensitive table columns.
slightwv (䄆 Netminder) Commented:
The only way I know of to ensure the DBA cannot see data is using Oracle Vault.  There is an encryption Wallet Admin that is necessary to properly open the database.

This is a separately licensed product.

There comes a time in every organization when they realize that they have to eventually trust someone with the keys.  DBAs and System Administrator typically hold the keys.

If you have a trust issue with your DBA it may be time to find another DBA.
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

slightwv (䄆 Netminder) Commented:
From the link provided by Jacobfw

Principle 1: Encryption Does Not Solve Access Control Problems
Principle 2: Encryption Does Not Protect Against a Malicious DBA
Principle 3: Encrypting Everything Does Not Make Data Secure
Oracle Database does support limited partitioning of DBA privileges. Oracle Database provides native support for SYSDBA and SYSOPER users. SYSDBA has all privileges, but SYSOPER has a limited privilege set (such as startup and shutdown of the database).

osloboyAuthor Commented:
slightwv: problem is not trust but security Standardization, to have SOD is batter, you can not make one person as ORACLE GOD.

thanks guys for giving great tips but my problem still stands if Encryption is not right call and buying new solution can be out of question at this point.

is there any alternatives    
Two Options:

1) custom roles for speciallized individuals to enforce SOD

Furthermore, an organization can create smaller roles encompassing a number of system privileges. A JR_DBA role might not include all system privileges, but only those appropriate to a junior DBA (such as CREATE TABLE, CREATE USER, and so on).

2) enable auditing to secure location to ensure SOD compliance

Oracle Database also enables auditing the actions taken by SYS (or SYS-privileged users) and storing that audit trail in a secure operating system location. Using this model, a separate auditor who has root privileges on the operating system can audit all actions by SYS, enabling the auditor to hold all DBAs accountable for their actions.

However, in the end someone has to be be ORACLE GOD in a small shop, just like in a small town somebody plays sheriff and carries the GUN.
osloboyAuthor Commented:
Jacobfw: thanks a lot, Sheriff must be systematic :p

option 1 seems to be cool but you need additional resources.

where as option 2 can be carried out even with 3rd party auditor.
any good documentation on OPTION 2  

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
osloboyAuthor Commented:
good one
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.