Our IS director is insisting that he needs sysadmin access to our
Oracle Applications instance, I however disagree. Is there a good
rule of thumb for who does and does not need sysadmin privs to the
DB/Apps? I need some ammo.

thanks,

Scott

scott wrote:

> Our IS director is insisting that he needs sysadmin access to our
> Oracle Applications instance, I however disagree. Is there a good
> rule of thumb for who does and does not need sysadmin privs to the
> DB/Apps? I need some ammo.
>
> thanks,
>
> Scott

Why? Why does he think he needs access? If he just wants to look around
CREATE SESSION and SELECT ANY TABLE are sufficient. If he wants to do
something then it is a question of whether he is qualified. If he is
qualified to do
things he should have the privileges required to do those things. If not
.... absolutely no privileges should be given.

It is a question of security.
It is a question of data integrity.
It is a question of good business practices.

And he bloody well be prepared to clean up his own messes or fall on his
sword if he makes a mistake. Just like
everyone else.

Without knowing how much experience he has, or what he intends to do, I
don't think a specific answer isn't possible. Your post makes it sound
like you think it is just about feeding an ego. And if that is the case
he has no business holding his current job either.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan <damorgan@exxesolutions.com> wrote in message news:<3F01DA46.5ADE837D@exxesolutions.com>...
> scott wrote:
>
> > Our IS director is insisting that he needs sysadmin access to our
> > Oracle Applications instance, I however disagree. Is there a good
> > rule of thumb for who does and does not need sysadmin privs to the
> > DB/Apps? I need some ammo.

In my limited experience it is best practices to limit
administrative access to systems only to those that need to perform
day to day admin functions on them. DBAs don't get root. Sysadmins
don't have the SYS password and aren't in the dba group. Neither
sysadmins nor DBAs get admin accounts in applications. Developers and
managers don't get admin access to anything.

Anything else muddles the chain of accountability.

You WILL be the one to catch the blame when something goes wrong.


> >
> > thanks,
> >
> > Scott
>
> Why? Why does he think he needs access? If he just wants to look around
> CREATE SESSION and SELECT ANY TABLE are sufficient. If he wants to do
> something then it is a question of whether he is qualified. If he is
> qualified to do
> things he should have the privileges required to do those things. If not
> ... absolutely no privileges should be given.
>
> It is a question of security.
> It is a question of data integrity.
> It is a question of good business practices.
>
> And he bloody well be prepared to clean up his own messes or fall on his
> sword if he makes a mistake. Just like
> everyone else.
>
> Without knowing how much experience he has, or what he intends to do, I
> don't think a specific answer isn't possible. Your post makes it sound
> like you think it is just about feeding an ego. And if that is the case
> he has no business holding his current job either.

I've usually put it this way:

Those and only those who are responsible running a system should have
ability to alter it.
You can't really be responsible of any database when you don't know who else
might modify it.

It's harder case with Oracle Application's SYSADMIN user. You could offer
him System Administrator responsibility instead SYSADMINs password, then at
least it will be seen who has made any changes in case of problems. Or even
better, if your director requests the access because (s)he wants to see all
your companies financial etc.. data, then offer him other power-user
responsibilities for specific modules, then at least (s)he can't f*ck up the
whole system, only behaviour of few modules or processes.

Generally, with these kinds of issues with high-level bosses you ought to
pass your director and go one level higher from him and ask for a (security)
policy, stating which type of employees should have which type of access to
which type of data. But of course, you could get your ass burned that way as
well :\

Tanel.

"scott" <swordss@t-com.com> wrote in message
news:e13893d8.0307011015.6879a392@posting.google.c om...
> Our IS director is insisting that he needs sysadmin access to our
> Oracle Applications instance, I however disagree. Is there a good
> rule of thumb for who does and does not need sysadmin privs to the
> DB/Apps? I need some ammo.
>
> thanks,
>
> Scott

I just add one more word, "directly", to my sentence:

Those and only those who are _directly_ responsible running a system should
have ability to alter it.

Tanel.

yes : those who want it should not get it.

conversely, those who don't want it (support DBAs who will do anything to
avoid being on call ) should get it

What you could do is set up a dummy role called SYS_ADMIN_HIGH_AND_MIGHTY
and just grant it user privileges and give it to him; saves face all round.
"scott" <swordss@t-com.com> wrote in message
news:e13893d8.0307011015.6879a392@posting.google.c om...
> Our IS director is insisting that he needs sysadmin access to our
> Oracle Applications instance, I however disagree. Is there a good
> rule of thumb for who does and does not need sysadmin privs to the
> DB/Apps? I need some ammo.
>
> thanks,
>
> Scott

scott wrote:

> Our IS director is insisting that he needs sysadmin access to our
> Oracle Applications instance, I however disagree. Is there a good
> rule of thumb for who does and does not need sysadmin privs to the
> DB/Apps? I need some ammo.

Some base variants I can think of:

1) Fight the boss and risk your job. If he's serious about getting
access, he'll hire someone who'll give it to him;

2) Give him access, and start a CYA log of all you activity. My
experience is this kind of request at that level means there will be
some background data manipulation OR background security investigation;

3) Give him psuedo access through a specially tailored userid;

4) There may be a legitimate reason for this. Have a frank discussion
with him and ask for justification. Simply put, you have a position of
responsibility and you are now asking whether that responsibility is
being changed.

Hans Forbrich wrote:

> scott wrote:
>
> > Our IS director is insisting that he needs sysadmin access to our
> > Oracle Applications instance, I however disagree. Is there a good
> > rule of thumb for who does and does not need sysadmin privs to the
> > DB/Apps? I need some ammo.
>
> Some base variants I can think of:
>
> 1) Fight the boss and risk your job. If he's serious about getting
> access, he'll hire someone who'll give it to him;
>
> 2) Give him access, and start a CYA log of all you activity. My
> experience is this kind of request at that level means there will be
> some background data manipulation OR background security investigation;
>
> 3) Give him psuedo access through a specially tailored userid;
>
> 4) There may be a legitimate reason for this. Have a frank discussion
> with him and ask for justification. Simply put, you have a position of
> responsibility and you are now asking whether that responsibility is
> being changed.

I favor the 'Just Say No' point of view but that does likely risk one
losing their job. But I do like your #3.

How about the following:
1. Create a specific role.
2. Make sure that all transactions from the role's owner are audited using
DDL and AFTER LOGON triggers.
3. Write a DDL trigger that makes it impossible to CREATE, DROP, ALTER, or
TRUNCATE anything and code the
trigger such that it sends an email or logs whenever an attempt is made.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Hi!

> I favor the 'Just Say No' point of view but that does likely risk one
> losing their job. But I do like your #3.
>
> How about the following:
> 1. Create a specific role.
> 2. Make sure that all transactions from the role's owner are audited using
> DDL and AFTER LOGON triggers.
> 3. Write a DDL trigger that makes it impossible to CREATE, DROP, ALTER, or
> TRUNCATE anything and code the
> trigger such that it sends an email or logs whenever an attempt is made.

I completely agree with the principles you told here, but I think OP spoke
about Oracle Applications here (every user is APPS (or whatever APPS user
configured in apps). Thus, it's harder to do any monitoring in DB level -
but it can be done in apps responsibilities or apps users level.


Tanel.