RE: EM access to developers
- From: "Ruel, Chris" <Chris.Ruel@xxxxxxx>
- To: "kylelf@xxxxxxxxx" <kylelf@xxxxxxxxx>, ORACLE-L <Oracle-L@xxxxxxxxxxxxx>
- Date: Fri, 30 Jan 2015 18:41:35 +0000
We are currently undergoing an initiative to provide some level of access to
developers. It can seem like opening a can of worms, but, at the same time, I
think there are some benefits. There’s a lot to it but I will summarize some
stuff the best I can.
OEM itself can pretty easily be locked down for “view only” of just the targets
to which you want to grant them access.
Where it gets a little tricky is when they need to provide credentials for the
database…for example, to see the performance page, which is usually what
everyone wants.
Each developer has their own access in the databases. We can’t control what
they do in SQL Developer any more than we can in OEM 12c so that lets us sleep
at night. However, we did ask ourselves the question, OEM 12c makes things so
much easier for them to leverage their access, are we asking for trouble? We
decided no, it is what it is. Same access as before, just with pretty pictures.
Where things do change in OEM 12c are the roles they need. The fact is, no
matter what access the developers have in the database traditionally, in order
for their access to really be worthwhile in OEM, they need the OEM_MONITOR
role. The OEM_MONITOR role gives them the following:
ANALYZE ANY
ADVISOR
CREATE JOB
MANAGE ANY QUEUE
SELECT ANY DICTIONARY
ANALYZE ANY DICTIONARY
CREATE SESSION
This is a little more risky. A couple of things above are obvious problems.
We have been talking about changing this role or rather creating one like it to
use instead.
One of the big ones that is always hard to grasp is SELECT ANY DICTIONARY.
Does this pose a security problem? Now, they can see who has what, where
directories are located, and even perhaps schema definitions (which in some
shops might be a concern…not really ours).
Honestly, I wonder if create session, and select any dictionary might be
enough? Advisor however does offer some self-service benefits that could even
reduce the workload of the DBAs. However, we don’t want developers running SQL
Tune jobs all day log killing database performance. Also, we don’t want
developers implementing the results of advisors without our review. We have
some very strong developers who could easily be trusted with this
power…however, as with any larger company, we have to consider that there are
some out there that cannot be trusted or are not trained. There is still some
work for us to do before we market this too much within our company.
Currently, we are in a POC stage of rolling out access to our developers. No
production access has been granted yet. We need to do more testing and
evaluation. However, the direction still points to allowing this. We just
need to make sure we have everything tightened up and auditing is set
appropriately. We have a “speech” that we give them when they get their
access…something to the effect that with great power comes great responsibility
and what we giveth we can taketh away…yada yada.
I think in the end, it is about transparency and cooperation amongst the teams
at our company. Nobody likes working around a black box. We are a strong team
and run a tight ship so there is nothing to hide. As much as it is easy to
find all the problems with OEM access, there will be some benefits as well.
_____________________________________________________________________
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
cruel@xxxxxxx<mailto:cruel@xxxxxxx> * Desk:317.759.2172 * Cell 317.523.8482
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of kyle Hailey
Sent: Friday, January 30, 2015 12:15 PM
To: ORACLE-L
Subject: EM access to developers
Quick poll : how many folks give developers logins to EM?
Last I was talking to people about 4 years ago no one was doing that. Have
times changed?
I know EM Express looks perfect for developers but I'm asking about access to
regular EM.
Thanks
Kyle Hailey
http://kylehailey.com
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged,
confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or
entity to
which it is addressed. If you are not the intended recipient of this E-mail,
you are
hereby notified that any dissemination, distribution, copying, or action taken
in
relation to the contents of and attachments to this E-mail is strictly
prohibited
and may be unlawful. If you have received this E-mail in error, please notify
the
sender immediately and permanently delete the original and any copy of this
E-mail
and any printout. Thank You.**
Other related posts:
