AS/400 security auditing and *ALLOBJ access |
 |
EXPERT RESPONSE FROM: Carol Woodbury
|
|
|
|
| > |
QUESTION POSED ON: 03 February 2008
I've been auditing AS/400 security for nearly a year, so I am still new. When I asked one client why their programmers have *ALLOBJ, their response was that *ALLOBJ gives them read-only access. This threw me off guard. From all the training, articles and reference manuals to which I have access, I know that this is not true. I also learned that the programmers migrate their changes into production after development/testing. The client's explanation is that programmers also serve as support to security officers and administrators and that is why they need so much access and special authority. What type of monitoring should be done to mitigate the risk that programmers will be able to do anything without management's knowledge since they have so much access?
|
|
|
To continue reading for free, register below or login
To read more you must become a member of Search400.com
The client's answer is obviously wrong. *ALLOBJ gives them the ability to do whatever they want to to an object. There are numerous issues with the scenario you described. First, programmers should not be promoting their own objects (no separation of duties there!). Second, programmers should not permanently need *ALLOBJ assigned to their profiles. If it is a small shop, there are occasions when programmers may need more capabilities, such as during a system or application update. I would audit the commands the programmers run by using the CHGUSRAUD command, specifying *CMD for the AUDLVL parameter. Then monitor this activity in the audit journal by looking for CD entries.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
