Home > Ask the Oracle Database / Applications Experts > Questions & Answers > Security guidelines for different user groups on Unix
Ask The Oracle Expert: Questions & Answers
EMAIL THIS

Security guidelines for different user groups on Unix

Dan Norris EXPERT RESPONSE FROM: Dan Norris

Pose a Question
Other Oracle Categories
Meet all Oracle Experts
Become an Expert for this site
>
QUESTION POSED ON: 03 September 2004

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.


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary



Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and answer pairs from more than 250 TechTarget industry experts.
Browse our Expert Advice



Oracle White Papers: Fusion Middleware
HomeNewsTopicsTipsAsk the ExpertsMultimediaWhite PapersProductsBlogs
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2003 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts