1. Is it a good design to use a generic Oracle account?
2. The application uses a config file, and this file holds the username/password in clear text of our generic Oracle account. Do you know any tips or advice to secure that?
Yes, it is good design. We use many different type of 3rd party applications from a variety of vendors. And most of those applications only use one Oracle account. This centralizes everything in the database to one schema. It makes the DBA's life much easier this way too. But one of the downsides is that you have very little control of users' access to the application. You can't easily lock out a user unless this is coded in the application. So there are pros and cons, with no one-size-fits-all answer. But I wouldn't worry too much about this.
Since you didn't write this application, you have little control over the fact that this config file is there and that it is needed by the application. You can't really do too much about that fact. So you are really only left with securing the config file as much as possible. Since this is Unix based, make sure that you install the application on the Unix server under it's own account. Then use file permissions on sensitive files such as this config file. Issue the following command "chmod 600 config_file". This will let only the application user see and modify that file. No other users on the system will be able to see and modify this file.
For More Information
- What do you think about this answer? E-mail the editors at editor@searchDatabase.com with your feedback.
- The Best Oracle Web Links: tips, tutorials, scripts, and more.
- Have an Oracle or SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical Oracle and SQL questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, Oracle, SQL Server, DB2, metadata, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
This was first published in March 2002