Dave - I think you may be wrong about *PUBLIC *EXCLUDE.
At least on an old version...
My MAPICS system is at XA Release 4 and it is all *PUBLIC *CHANGE.
When we started working on SOX we tried changing it to *EXCLUDE.....
MAPICS would not work at all.
Greg
-----Original Message-----
From: Dave Shaw [mailto:daveshaw@xxxxxxxxxxxxx]
Sent: Thursday, July 24, 2008 10:10 AM
To: MAPICS ERP System Discussion
Subject: Re: [MAPICS-L] Change Management
Bryan,
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!
Dave Shaw
MAPICS-L moderator
----- Original Message -----
From: "Burns, Bryan" <Bryan_Burns@xxxxxxxxxxxx>
To: <MAPICS-L@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
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.
_______________________________________________
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.
midrange.com
