I am currently researching how best to secure our database environment. We have 9iR2 EE installed on HP-UX.
There will be a number of different databases on the database server, each with its own DBA and developers. The server is Raid 1+0. Oracle is installed on one filesystem, and the plan is to create each database on its own separate filesystem. I know this diverts from Oracle's OFA, but it will make the Unix administration/security easier to have each database contained within one mount point. Is this reasonable, or are there potential issues?
What are your recommendations with regards to Unix users, groups and
security? At the moment the OS user Oracle is the software owner and is
a member of the dba group. What about group and security settings for
our other users, DBAs and developers?
In particular, my concern is for one particular database, payroll. I
don't want other Unix users to be able to access any of the Oracle
related files, SQLs, reports, etc.
Some of the applications also have OS-authenticated users. We have
these as members of the DBA group, but this will be reduced.
What should happen the init, log, trace, and .ora files in this type of
setup? Should they all be owned by Oracle?
Requires Free Membership to View
If you have different DBAs for the different environments, then you should
probably have an ORACLE_HOME for each of them. The OSDBA and OSOPER groups
are defined in the oracle binary at link time, so if you're a DBA for one
database running from the ORACLE_HOME, then you're a DBA for *all* databases
running in that ORACLE_HOME. The only way to separate these privileges in the
current Oracle installation method is to have separate ORACLE_HOMEs, each with
its own DBA group (do a custom install so that it will prompt you for the name
of the OSDBA group and choose something descriptive like "dbapayroll" for
payroll, "dbahr" for HR, etc.). The oracle accounts will also be different,
so you will end up with multiple software owners (like orapay, orahr, oraerp,
etc.) and each of those will have its own dba group (like dbapay, dbahr,
dbaerp, etc.). With this one-to-one mapping, you'll be able to safely
maintain all environments on the same hardware and OS without compromising
security for any of the apps. The cost is a few extra GBs for Oracle
binaries, but disk is cheap -- security isn't. This was first published in September 2004
Join the conversationComment
Share
Comments
Results
Contribute to the conversation