Re: Service Account Security and Handling

[Larry Brennan <larrybrennan () GMAIL COM>]

One suggestion would be to have the automated processes be authorized
(and performed) under a non-interactive ID. The non-interactive is an
ID is only to be used by individual processes and not for routine
logon by individual users. Additionally, these IDs would have their
passwords set to never expire so you don't have to worry about the 90
day expiration issue.. To help mitigate risks from the password
expiration issue, you can restrict what this ID can acess, and log the
living daylights of all activity related to that ID.

If you are not willing to rework all of those existing processes for
the new ID(s), you could start to change how you deploy these
processes in the future - so you don't get any further into the hole,
so to speak.

Best regards,
Larry Brennan

On 8/8/07, Wade, Russ <Russ.Wade () wichita edu> wrote:
> Dear Colleagues,
>
> I am interested in accepted practices for maintaining passwords and access
> to service accounts.
>
> We have several Oracle accounts with broad access to the database that are
> used by automated processes.  The passwords for these are known by the DBA
> and a small number of lead programmers who developed and provide technical
> support for these processes.
>
> We presently are using a profile which requires the passwords for these
> accounts to change every 90 days.  Most of the time, the DBA and involved
> developer successfully coordinate the password change in Oracle and in the
> application process before the 90 day limit.
>
> However, this sometimes is missed and the automated processes fail.  We have
> also experienced issues with automated processes which must have embedded
> passwords being missed when the change is made.  This can result in getting
> the service account locked after they retry with the old password beyond our
> 6 try limit.  Then, the other processes fail as well until someone notices
> and fixes it.
>
> Does anyone have a better idea for how to achieve proper security for these
> privileged access service accounts and operational reliability as well?
> Also, please describe the roles of the individuals involved with this
> function.
>
> Thank you,
>
> Russ
>
> Russ Wade,
>
> Banner Security Specialist
>
> Wichita State University
>
> University Computing and Telecommunications Services
>
> 1845 Fairmount
>
> Wichita, KS  67260-0098
>
> Email:
>
> Russ.Wade () Wichita edu<mailto:Russ.Wade () wichita edu>
>
> Office:
>
> (316) 978-3859
>
> Mobile:
>
> (316) 312-0185
>
> Fax:
>
> (316) 978-3894