× 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.



We are at XAR6 and our MAPICS files are all *PUBLIC/EXCLUDE.



Thanx,

Nick



Nick Radich
Sr. Programmer/Analyst
EPC Molding, Inc.
Direct (320) 679-6683
Toll free (800) 388-2155 ext. 6683
Fax (320) 679-4516
nick_radich@xxxxxxxxxxxxxx



"Greg Wenzloff" <GWenzloff@xxxxxxxxxxx>
Sent by: mapics-l-bounces@xxxxxxxxxxxx
07/24/2008 09:23 AM
Please respond to
MAPICS ERP System Discussion <mapics-l@xxxxxxxxxxxx>


To
"MAPICS ERP System Discussion" <mapics-l@xxxxxxxxxxxx>
cc

Subject
Re: [MAPICS-L] Change Management






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.

_______________________________________________
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.