RE: Separation of Duties...

Well you should have 4 individuals performing the following roles:

1. DB Administrator - These profiles should have full access to the DB
under their administration. They do not need any special authorities.

2. System Administrator: This should be profiles such as QSYSOPR but not
use the QSYSOPR profile. They will perform the day to day job
administration and system monitoring. They should not have *ALLOBJ or
*AUDIT.

3. Security Officer: No one should have the QSECOFR password except the
Security Officer who should not use it unless necessary. This profile
will have *SECADM and handle setting permissions on all objects,
creating user profiles and authorization list. Any other security
related duties that you can think off. This profile, not QSECOFR,
should not have access to production application and data. This profile
should not have *AUDIT or any other special permission besides *SECADM.

4. System Auditor: This profile should have *AUDIT and control all
system audit journals and any application that manages/parses the audit
journals.


Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Graap, Kenneth
Sent: Wednesday, October 31, 2007 8:17 AM
To: Midrange Systems Technical Discussion
Subject: Separation of Duties...

We are in the middle of an IS Audit and the auditor is asking us why we
don't separate the duties of DB Administrator and System Administrator
on our System i platform.

.Historically we have always combined these duties on the System i but
we are now being pressured to come up with a way to separate them.

As anyone else had to do this and if so, how did you define these duties
and set up system security to enforce it?

or ... can anyone share a compelling argument for not separating these
duties?