RE: How to Limit OEM12c user access

From: Peter Sharman <pete.sharman_at_oracle.com>
Date: Mon, 6 Aug 2012 08:10:12 -0700 (PDT)
Message-ID: <afc9b437-570b-431c-96a2-c352191ce731_at_default>



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_at_evdbt.com] Sent: Monday, 6 August 2012 6:49 AM
To: oracle-l_at_freelists.org
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_at_ymail.com <
> kellyn.potvin_at_ymail.com> 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_at_freelists.org 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.-

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
Received on Mon Aug 06 2012 - 10:10:12 CDT

Original text of this message