My recommendations would be the following:
1) Analyze which specific tasks your staff needs *ALLOBJ for. Create
specific programs (you'll probably only need CLPs) that adopt *ALLOBJ to do
ONLY these functions and secure the programs so that only the relevant staff
members can run them. Document the rules for granting authorities to the
programs and for using them.
2) Analyze why your files have *PUBLIC *CHANGE. MAPICS ships with *PUBLIC
*EXCLUDE, after all, and all MAPICS programs adopt AMAPICS authority so that
they can work with them. If you have programs of your own that use MAPICS
files, why not use the same scheme? Be sure to document whatever you do.
3) If you have files that users need *READ access to (for queries or other
things where adoptive authority is difficult to use), consider using
authorization lists for them. Yes, there's a (very small) performance
impact at file open, but it's negligible for any decently-sized modern
system. Use the same authorization list for each file group and maintaining
access takes very little work. Make sure you document whatever you do.
Third-party tools can make managing access easier. In addition to security
tools, you might also want to consider change management tools like TurnOver
or Implementer. My suggestion, though, is to decide how you want to manage
your system first, and then look at tools to support that. Systems that are
well-thought-out and capable of being managed manually are much easier to
automate with tools.
Ultimately, though, if you want to satisfy SOx auditors, documentation is
everything. Well defined, well documented, sensible processes will almost
always pass audit; poorly documented practices based on expediency will not.
Good luck with whatever you do!
----- Original Message -----
From: "Burns, Bryan" <Bryan_Burns@xxxxxxxxxxxx>
Sent: Thursday, July 24, 2008 9:03 AM
Subject: [MAPICS-L] Change Management
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
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