Database Security

Archive of postings to DataStageUsers@Oliver.com. This forum intended only as a reference and cannot be posted to.

Moderators: chulett, rschirm

Locked
admin
Posts: 8720
Joined: Sun Jan 12, 2003 11:26 pm

Post by admin »

Trish,

Every one of our jobs has a DSN, User and Password parameter. Actually to be truthful, they have SourceDSN, SourceUser, SourcePassword, TargetDSN, TargetUser and TargetPassword parameters where "source" always refers to the source system and "target" refers to our data warehouse database.

Visible passwords should not an issue in Director if you use the encrypted parameter type. Much to my embarrassment, it took me a while to figure out that I had to double-click on these parameters to set a default password (if you want to).

As I mentioned in a recent posting, we have a function that compares the parameters of a calling job and an attached job which is about to be run. Where any parameter names match, it automatically sets the parameters of the job which is about to be run. We always call this function before calling DSRunJob.

So, all we have to do is type in the DSN, user, password for the top level job when we submit or schedule it and everything else happens automatically.

However, the other advantage we have is that only developers ever use Director anyway, and they already know all the passwords. We have a separate interface (home grown) for users to submit the few jobs that they are allowed to submit.

Hope this answers you question.

BTW ... it is good to see all the new members on this list. Until this last few days, I could probably count on one hand the number of people who have posted more than one message. (I wont name names for fear of offending
someone by omission :) )

-----Original Message-----
From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
Sent: Thursday, November 02, 2000 1:00 AM
To: informix-datastage@oliver.com
Subject: Database Security

Hi All,

Wondered if anyone had a strategy for database security, i.e., database name, username, password for jobs.

We dont want to hardcode these parameters in any of the jobs, and also do not want them visible in the director to anyone who monitors jobs. Also we are looking for a way to make them dynamic, so that jobs can be run on different Unix servers and access different databases (development vs. test vs. production).

So far, I have included a job control which contains code to read in a text file from the DataStage unix directory, which contains the database, and a valid userid and password for updating the database. Then as each job is added to the job control, I have set the input parameters to those read in from the text file. I wonder if there is an easier way to do this? Perhaps as a function or before subroutine. But I am having trouble understanding how to set the input parameters to values returned from a before subroutine or function.

Any thoughts or opinions?

Thanks,


Trish Adams
Compuware


*************************************************************************
This e-mail and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in
error, please notify the sender by return e-mail, and delete this e-mail from your in-box. Do not copy it to anybody else

*************************************************************************
admin
Posts: 8720
Joined: Sun Jan 12, 2003 11:26 pm

Database Security

Post by admin »

David,

Thanks for your response. I agree that passing this information in as parameters is the way to go, and I have found that encryption works just fine. However, I do have an additional issue.

Our DBAs do not allow anyone access to the password with privs to update the target production database. All applications must access a security routine put together by the dba team, which returns the username and password with the correct privs. This is why I cannot simply type in/submit
these parameters at the time of scheduling.


> ----------
> From: David Barham[SMTP:David.Barham@Anglocoal.com.au]
> Reply To: informix-datastage@oliver.com
> Sent: Wednesday, November 01, 2000 6:42 PM
> To: informix-datastage@oliver.com
> Subject: RE: Database Security
>
> Trish,
>
> Every one of our jobs has a DSN, User and Password parameter.
> Actually to be truthful, they have SourceDSN, SourceUser,
> SourcePassword, TargetDSN, TargetUser and TargetPassword parameters
> where "source" always refers to the source system and "target" refers
> to our data warehouse database.
>
> Visible passwords should not an issue in Director if you use the
> encrypted parameter type. Much to my embarrassment, it took me a
> while to figure out that I had to double-click on these parameters to
> set a default password (if
> you want to).
>
> As I mentioned in a recent posting, we have a function that compares
> the parameters of a calling job and an attached job which is about to
> be run. Where any parameter names match, it automatically sets the
> parameters of the job which is about to be run. We always call this
> function before calling DSRunJob.
>
> So, all we have to do is type in the DSN, user, password for the top
> level job when we submit or schedule it and everything else happens
> automatically.
>
> However, the other advantage we have is that only developers ever use
> Director anyway, and they already know all the passwords. We have a
> separate interface (home grown) for users to submit the few jobs that
> they are allowed to submit.
>
> Hope this answers you question.
>
> BTW ... it is good to see all the new members on this list. Until
> this last few days, I could probably count on one hand the number of
> people who have posted more than one message. (I wont name names for
> fear of offending
> someone by omission :) )
>
> -----Original Message-----
> From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
> Sent: Thursday, November 02, 2000 1:00 AM
> To: informix-datastage@oliver.com
> Subject: Database Security
>
> Hi All,
>
> Wondered if anyone had a strategy for database security, i.e.,
> database name, username, password for jobs.
>
> We dont want to hardcode these parameters in any of the jobs, and
> also do not want them visible in the director to anyone who monitors
> jobs. Also we are looking for a way to make them dynamic, so that
> jobs can be run on different Unix servers and access different
> databases (development vs. test
> vs. production).
>
> So far, I have included a job control which contains code to read in a
> text file from the DataStage unix directory, which contains the
> database, and a valid userid and password for updating the database.
> Then as each job is added to the job control, I have set the input
> parameters to those read in from the text file. I wonder if there is
> an easier way to do this? Perhaps
> as a function or before subroutine. But I am having trouble
> understanding
> how to set the input parameters to values returned from a before
> subroutine
> or function.
>
> Any thoughts or opinions?
>
> Thanks,
>
>
> Trish Adams
> Compuware
>
>
> **********************************************************************
> ***
> This e-mail and any files transmitted with it may be confidential
> and are intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this e-mail in
> error, please notify the sender by return e-mail, and delete this
> e-mail from your in-box. Do not copy it to anybody else
>
> **********************************************************************
> ***
>
admin
Posts: 8720
Joined: Sun Jan 12, 2003 11:26 pm

Post by admin »

How about writing a top level job which calls the security routine and than passes the username/password as parameters to the top level controlling job.

Or, embedding the call to the security routine in a function and call it at the start of each controlling job, passing DSN, user, password to the jobs that they call.

It is nice that your DBAs trust you so much :-)

-----Original Message-----
From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
Sent: Friday, November 03, 2000 12:07 AM
To: informix-datastage@oliver.com
Subject: Database Security

David,

Thanks for your response. I agree that passing this information in as parameters is the way to go, and I have found that encryption works just fine. However, I do have an additional issue.

Our DBAs do not allow anyone access to the password with privs to update the target production database. All applications must access a security routine put together by the dba team, which returns the username and password with the correct privs. This is why I cannot simply type in/submit
these parameters at the time of scheduling.


> ----------
> From: David Barham[SMTP:David.Barham@Anglocoal.com.au]
> Reply To: informix-datastage@oliver.com
> Sent: Wednesday, November 01, 2000 6:42 PM
> To: informix-datastage@oliver.com
> Subject: RE: Database Security
>
> Trish,
>
> Every one of our jobs has a DSN, User and Password parameter.
> Actually to be truthful, they have SourceDSN, SourceUser,
> SourcePassword, TargetDSN, TargetUser and TargetPassword parameters
> where "source" always refers to the source system and "target" refers
> to our data warehouse database.
>
> Visible passwords should not an issue in Director if you use the
> encrypted parameter type. Much to my embarrassment, it took me a
> while to figure out that I had to double-click on these parameters to
> set a default password (if
> you want to).
>
> As I mentioned in a recent posting, we have a function that compares
> the parameters of a calling job and an attached job which is about to
> be run. Where any parameter names match, it automatically sets the
> parameters of the job which is about to be run. We always call this
> function before calling DSRunJob.
>
> So, all we have to do is type in the DSN, user, password for the top
> level job when we submit or schedule it and everything else happens
> automatically.
>
> However, the other advantage we have is that only developers ever use
> Director anyway, and they already know all the passwords. We have a
> separate interface (home grown) for users to submit the few jobs that
> they are allowed to submit.
>
> Hope this answers you question.
>
> BTW ... it is good to see all the new members on this list. Until
> this last few days, I could probably count on one hand the number of
> people who have posted more than one message. (I wont name names for
> fear of offending
> someone by omission :) )
>
> -----Original Message-----
> From: Adams, Trish R (Compuware) [SMTP:AdamsTR@BP.COM]
> Sent: Thursday, November 02, 2000 1:00 AM
> To: informix-datastage@oliver.com
> Subject: Database Security
>
> Hi All,
>
> Wondered if anyone had a strategy for database security, i.e.,
> database name, username, password for jobs.
>
> We dont want to hardcode these parameters in any of the jobs, and
> also do not want them visible in the director to anyone who monitors
> jobs. Also we are looking for a way to make them dynamic, so that
> jobs can be run on different Unix servers and access different
> databases (development vs. test
> vs. production).
>
> So far, I have included a job control which contains code to read in a
> text file from the DataStage unix directory, which contains the
> database, and a valid userid and password for updating the database.
> Then as each job is added to the job control, I have set the input
> parameters to those read in from the text file. I wonder if there is
> an easier way to do this? Perhaps
> as a function or before subroutine. But I am having trouble
> understanding
> how to set the input parameters to values returned from a before
> subroutine
> or function.
>
> Any thoughts or opinions?
>
> Thanks,
>
>
> Trish Adams
> Compuware
>
>
> **********************************************************************
> ***
> This e-mail and any files transmitted with it may be confidential
> and are intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this e-mail in
> error, please notify the sender by return e-mail, and delete this
> e-mail from your in-box. Do not copy it to anybody else
>
> **********************************************************************
> ***
>
Locked