RE: How to Limit OEM12c user access
- From: Peter Sharman <pete.sharman@xxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 6 Aug 2012 08:10:12 -0700 (PDT)
I'm with Tim and Kellyn on this one. Other than the security / privacy issues
that Tim alludes to, I think as DBA's we have for far too long blocked access
to useful information for developers - and that doesn't contradict the quote in
my signature! ;)
Obviously 12c has a lot more privileges, and a lot more fine grained ones than
we had in previous releases, but I can't see why you wouldn't let them view
database configuration information.
Pete
Pete Sharman
Principal Product Manager
Enterprise Manager Product Suite
33 Benson Crescent CALWELL ACT 2905 AUSTRALIA
Phone: +61262924095 | | Fax: +61262925183 | | Mobile: +61414443449
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
"Oh no, it's not, it's much harder than that!"
Bruce Pihlamae, long term Oracle DBA
-----Original Message-----
From: Tim Gorman [mailto:tim@xxxxxxxxx]
Sent: Monday, 6 August 2012 6:49 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: How to Limit OEM12c user access
> Anyway, I think it is because we want to keep dev access to prod
> environments to a minimum. And having access to data they don't need
> is, as a rule, a bad idea.
The phrase "/access to data they don't need/" might bear closer examination?
One of the keys to hacking is account names, which might even fall into the
category of "PII" (i.e. personally identifiable information), so there is clear
objection to that information, and I think it would be easy to argue that
developers don't need this. Heck, I'd argue that vice presidents and CIOs don't
need that, but that's another story.
But if this community of users has already been given access to EM12c for the
purpose of performance monitoring in production, then it is quite natural and
justifiable for them to be able to view database configuration information.
Knowing SGA and PGA settings is important; knowing what features have been
enabled and how (i.e. parallel execution, star transformation, etc) is
important. So, I can't see this information falling into the category of "/data
they don't need/", as that would contradict the mandate they've already been
granted.
Just my US$0.02...
On 8/5/2012 2:04 PM, Guillermo Alan Bort wrote:
> I'm sad to say that the answer to your question is simply "because my
> boss asked me".
> Anyway, I think it is because we want to keep dev access to prod
> environments to a minimum. And having access to data they don't need
> is, as a rule, a bad idea.
>
> Cheers
> Alan.-
>
>
> On Sun, Aug 5, 2012 at 4:10 PM, kellyn.potvin@xxxxxxxxx <
> kellyn.potvin@xxxxxxxxx> wrote:
>
>> Question, as I'm curious... What is your concern regarding the
>> developers viewing this information?
>> I can understand and support the idea of removing an option to change
>> db parameters or create a user, but viewing? I just don't understand
>> the requirement or the need for control...
>>
>> Kelly Pot'Vin
>> Sr. Technical Consultant
>> Enkitec
>>
>>
>> From my Android phone on T-Mobile. The first nationwide 4G network.
>>
>>
>> -------- Original message -------- Subject: How to Limit OEM12c user
>> access From: Guillermo Alan Bort ** To: oracle-l@xxxxxxxxxxxxx CC:
>>
>> Hi List,
>> This question goes to those of you who use OEM12c.
>>
>> We have a set of developers that want to access OEM to monitor
>> performance in a database. I've found a way to allow them read only
>> access to that database and only that database. However they can do
>> things other than monitoring performance (like viewing the list of
>> users in the database or even spfile parameters).
>> I tried creating a user on the DB with this account and I
>> couldn't, but I would like to completely remove the options from OEM.
>> I just want them to be able to view the performance related tabs.
>>
>> Has anybody done something like this?
>>
>> Cheers
>> Alan.-
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts: