Re: safe way to store passwords in unix OS

From: David Robillard <david.robillard_at_gmail.com>
Date: Fri, 16 Dec 2011 11:37:50 -0500
Message-ID: <CADH15Ggoug8+613E=WxXesedVnRyig-3utCBCJjpx8eqEq5Mww_at_mail.gmail.com>



Hi,

I know it's probably quite a lot of work to do, but have you thought about migrating the various jobs out from the crontab and into DBMS.SCHEDULER instead?
That would solve your credential security problem outlined in your email.

The learning curve for DBMS.SCHEDULER can be a little steep, but IMHO it's worth it. And since you already have to work on fixing the problem, might as well learn DBMS.SCHEDULER no? And the « program/process/script that has customizable logic that only lets specific jobs access the password » part of your plan sounds to me like quite a task anyway :)

You could for example setup one or more schemas that would hole the various jobs you need to run. Grant whatever access these users need to perform the job properly. Then keep these user's passwords secure. If you have a security manager or simply work with SYS, you don't even have to grant create session to this or these job-related schemas. Think of these schemas as some sort of crontab repository inside the database.

Just an idea, HTH,

David

On Thu, Dec 15, 2011 at 5:30 PM, Dba DBA <oracledbaquestions_at_gmail.com> wrote:
> This is not exactly an Oracle question, but I am asking it here in case
> someone has solved this. We have alot of jobs that log into our Oracle
> databases. Some of them use ops$oracle accounts. In the future we are not
> allowed to use ops$oracle and need to provide passwords. I am trying to
> find a method, or program/script that allows us to do the following.
> 1. store oracle passwords in unix in a lock box
> 2. only given processes and users can access specific passwords
> 3. program/process/script has customizable logic that only lets specific
> jobs access the password.
> 4. We are mainly using Cron for our jobs, but may be using some other job
> schedulers in the future that have more features.
> 5. you cannot access the passwords from a user account
>
> basically you give the password to the script/program, etc and tell it
> which jobs/users can retrieve it. Those jobs call the script/program and
> the program can accurately decide which job gets which password.
>
> This is about all the requirements I have on this. Sorry if this is kind of
> vague.

--
David Robillard
http://www.linkedin.com/in/davidrobillard
http://itdavid.blogspot.com/
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 16 2011 - 10:37:50 CST

Original text of this message