Q

Security guidelines for different user groups on Unix

This Content Component encountered an error

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?
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

Dig deeper on Oracle database security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close