Re: Oracle lockdown, agents, and EM Jobs

  • From: Seth Miller <sethmiller.sm@xxxxxxxxx>
  • To: dedba@xxxxxxxxxx
  • Date: Wed, 18 Jun 2014 20:47:11 -0500

David,

Kudos to your organization for taking this on. I hope you will share this
experience with the community through blogs and presentations. I could see
these topics easily being accepted as a presentation at any of the
conferences.

With the exception of a very few (and by very few I mean less than five)
situations, there should not be any scripts that need to run as oracle. I
am including the EM agent as one of those things that does not require
oracle. Those few things that are required to be run as oracle should be
done through sudo. If executing something using sudo is leaving environment
variables in place that shouldn't be there, then sudo is not set up
properly.

Your messages were quite complex but you are asking very good questions
here. I suggest you break it down into one or two issues per post and hash
them out before moving to the next issues.

Tony,

You're quite right that jobs that need to persist across employees should
never be run with credentials of an individual. Jobs should be run under a
common system user. As long as no one can use this user for anything other
than jobs (no local access to the servers), security would not be an issue
since authorization and auditing is taken care of with EM. If separation of
duties is the issue, each individual could have their own system user that
could just be reassigned to someone else if necessary.

Seth



On Wed, Jun 18, 2014 at 7:59 PM, De DBA <dedba@xxxxxxxxxx> wrote:

> This is becoming a very interesting story indeed. How about putting the
> common oracle environment in a file in a common location, e.g.
> /var/opt/oracle/oraenv.sh, and having each script and perhaps
> .bashrc/.bash_profile source that as appropriate? Access to this directory
> should already be allowed. We tend to do this, even where security is not
> as overzealous as what you're facing. It just makes managing environments
> more easy when everything is in one common location, whilst allowing DBAs
> to choose whether to use the common environment or not.
>
> I wonder how you are going to set up EM jobs that need os logon
> credentials. If you use a DBA's credentials, then those jobs will start to
> fail when the DBA in question leaves the organisation and his account gets
> disabled or removed from the directory.. Could be an administrative
> nightmare waiting to happen?
>
> Cheers,
> Tony
>
>
> On 19/06/14 08:18, Herring, David wrote:
>
>> Options:
>>
>> 1)  Every DBA has their own .bash_profile created as a copy of Oracle's.
>>  This is what I started with thinking it was simple but after one week I've
>> found 2 examples where DBAs didn't bother to follow this rule.  I can't
>> control them and have no authority to force them to do anything other than
>> the bare minimum of their job.
>>
>> 2)  Open permissions on /user/oracle (710) and /user/oracle/.bash_profile
>> (750) so that each EM Job could issue at the start: ".
>> ~oracle/.bash_profile".  So whether daveh or markb or timg have their
>> credentials set for the target, all can execute Oracle's .bash_profile and
>> we're fine.
>>
>> Everything else I've come up with is a variation on the above 2 options,
>> either modifying DBA .bash_profiles in some way or something within
>> Oracle's home directory that requires permissions to be relaxed a bit.
>>
>> Does this make sense?
>>
>> Am I making this overly complex?
>>
>> Anyone else in a similar situation and have a better solution?
>>
>> Dave Herring
>> --
>> //www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 06-2014