× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm looking forward to reading THESE answers! We had the same problem with my prior employer - our auditors got around it by us having several user IDs, which was a pretty stupid resolution, in my opinion. Why have an ID for a programmer for him to do application development/maintenance, and a separate one that lets him run applications? And then the QSECOFR ID for other stuff. And the person knows all the passwords (obviously).

They also recommended establishing a "program librarian" position to have a non-IT person put the jobs into production. Of course, we didn't HAVE anyone for that position - they actually suggested having the receptionist do it! Which was a position spread among several people at various times of the day at that point. NOT!!!

After the audit (internal), we went back to the old way. I know it was wrong, but sometimes reality intrudes.

The 3rd party package route would have been the best way, but when they won't approve the expenditure...

Dale "Cork" Gindlesperger
Cell: 814-442-1291


We'll be undergoing an internal controls IT audit later this year and like a lot of small shops, our MIS staff has *ALLOBJ special authority in their user profiles. In addition, all our AMFLIBx files have authority for *PUBLIC as *CHANGE. Because our users don't have a command line and we control ODBC updates through an exit point package, *PUBLIC having *CHANGE to files isn't an issue. But the MIS staff having *ALLOBJ to production files and being able to DFU any one of them is an issue.

I believe there're at least 3 ways we can approach this:

1. Implement object level authority. (This is something management really doesn't want to consider).
2. Run a nightly program to GRTOBJAUT of *EXCLUDE for every object in our production libraries for every MIS user profile. In addition, remove *ALLOBJ special authority from the MIS user profiles.
3. Implement a third party package like Authority Broker from the PowerTech Group.

Have any of you had a similar security set-up as we have and had to comply with Sarbanes-Oxley regulations or something similar? If so, I'd like your input on the three approaches above or any other approach you might recommend.

Thanks in advance,


Bryan Burns
iSeries Specialist
ECHO, Incorporated
Lake Zurich, Illinois

_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
To post a message email: MAPICS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.