Sorry didn't mean to be short here but most on this forum run into the situation where auditors pitch crap over the wall to see if it will stick all the time.
My general sugestion would be for IT Auditors to more a little more about IT other than just the "system process" or "general controls" or "master data protection" or "segregation of duties". How about learning networking, SQL or even a little bit about the application being audited?
My ideal auditor would suggest the high level issue, some possible courses of action and not LASER BEAM on one silly item.
In this specific case the target is the F9312. The ideal auditor would suggest "A method to ensure that the Security Administrator is restricted from altering the security audit table within the system. Another individual would have access to the history table for maintenance purposes and thus collusion would have to occur between the Security Administrator and this other individual".
Now the fact that you've pointed out that you can't do this in JDE is not a short coming of the product but merely a lack of insight. Since each auditor or firm will general recommend opposite things depending on which way the wind is blowing that day there is no system that can account for all of this.
So since this can't be done in JDE........well don't do it in JDE.
We have a few fundamental items in play here: (1) Network, (2) Database, (3) Application. So we have 3 areas to layer security to gain the desired effect.
In this case I think the issue can be solved at the database level with a few statements:
REVOKE ALTER, DELETE ON sy812.F9312 FROM *PUBLIC;
GRANT ALTER, DELETE, INSERT, SELECT, UPDATE ON sy812.F9312 TO PROXYID1;
GRANT ALTER, DELETE, INSERT, SELECT, UPDATE ON sy812.F9312 TO PROXYID2;
GRANT ALTER, DELETE, INSERT, SELECT, UPDATE ON sy812.F9312 TO PROXYID3;
etc, etc.
So the simple answer would be to revoke the ALTER and DELETE permissions on the table to all database userids.
Just my $0.02 US, $0.0197 CDN
Colin
