RE: MAPICS - need info on the AMAPICS user profile

[Kevin Fox <kdfox@xxxxxxxxxxxxx>]

Greg,

Your right, I did not provide very good advice.  Criticism is not the same as 
constructive criticism.

Ann, thanks for your input, its very good advice.

I guess the first advice I would have is to ensure that before you do anything, 
you understand MAPICS security.  One of the problems with providing "generic" 
advice in this forum is that I'm never sure what release / ptf level anyone is 
at.  Suffice it to say, Green Screen application security changes between 
releases and is dependent upon which combination of appliations you have.   
Here then is a breif summary of MAPICS security options.  Your requirements 
depend upon your produciton environment  MAPICS Release, PTF level and 
application set.

1. CAS Security (including personal menus)
2. COM Data Groups
3. IFM Security
4. Client Architecture (Power Architecture) Security

This does not include 3rd party applications such as MC2 or Web applicatons 
that may be integrated in some way.  Nor does it include any custom code 
developed in house.

Each area is unique and has it's own set of "rules" that assist you in applying 
the level of security depending upon your requirements.

Second, you need to fully understand security within your AS/400/iseries 
operating system.  Don't forget to include Auxillary Storage Partitions (ASP) 
in your education.

Third, in most environments a full understanding of security includes the 
network and access to the Internet.  This especially true if your at or 
planning to go to R7.

Once you understand MAPICS security, then you can begin to assess your 
particular environment.  In general, I would start with any custom code and or 
database changes (especially triggers).  If you are reviewing your system for 
Sarbanes Oxley (SOX) then you need to also include downloading programs that 
create offline files such as MS Excel Spreadsheets, MS Access, etc. etc.   The 
objective of the assessment is to create a plan of action.  What needs to 
change in order to create a secure system?  In other words, what is the delta 
between where you are today and where you want to be tomorrow?

In most MAPICS shops, whether they have been running MAPICS for 2 months or 20 
years, this is not a trivial task.  It needs to be approached with caution.  
And now it needs to be carefully documented for SOX.  What ever you do, do not 
just "wing it" in your production environment.  There are so many different 
threads to the security blanket, that once it begins to unravel it is almost 
impossible to sew back together.

Ann is absolutely correct, create a good test environment.  Understand, if the 
test environment and the production environment are on the same CPU/ASP,  that 
you can't use "real" users to do your testing as it will affect the production 
environment.  (note: this may affect licensing requirements)

Create groups of users by security requirements. 

Create a security template using MAPICS security for each group.

Then begin testing.  Pay particular attention to the groups that work "outside" 
of MAPICS with MAPICS data, especially programmers.   As I stated before; many, 
many shops give programmers QSECOFR level authority just to "bypass" all the 
security that is in place.  This will most definently fail a SOX audit.

Finally, and just as importantly, you need to re-eduate the user community as 
to why you are going to change their working lives.  Involve the users in your 
security design plan.  Those users working in a public company that have 
financial reporting requirements will not appreciate not having access to the 
data they use to create their reports.

I realize that this is pretty general advice, and definently not "technical".   
Realize that security is a big issue with every company, and that "generic 
adivce" taken at face value without a good understanding of your systems can do 
more harm than good.

Don't know if this helps much, but there it is.

Kevin Fox
kdfox@xxxxxxxxxxxxx

Greg,

IF you do not have any modified or custom programs,  removing AMAPICS group
from your users profiles should not cause any problems.  Your MAPICS
programs and files should be correct as they were installed via MAPICS
procedures (but you should check this out).  A few of the MAPICS programs
are owned by QSECOFR, but 99% should be owned by AMAPICS.  In fact I just
displayed all the program objects to a file and all but 2 are owned by
AMAPICS.  The MAPICS command in QGPL should have *use for public.  That is
how users get into MAPICS with no authority, then the cross applcation
security you grant inside MAPICS takes over.

If you do have a lot of custom, trigger, or modified MAPICS programs, you
can create user modified option(s) (1 for ownership, 1 to use *owner
authority)  and with a subsetted list in wrkobjpdm change ownership, etc. in
mass.  If you need to change many programs and/or files, be sure to test
your user modified option on one or two before applying to all.  After you
get the authority in place, you can remove the AMAPICS group profile from
the user profiles.  (a program can be written to do this, too, if you have
many users).  And of course you should do one or two manually first and let
those users test before removing all...  14 years of loose security could
have some gotchas.  Do you have a test environment?

-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx
Behalf Of Greg Wenzloff
Sent: Thursday, December 30, 2004 8:03 AM
To: 'MAPICS ERP System Discussion'
Subject: RE: MAPICS - need info on the AMAPICS user profile

Thanks Ann, Michael, and Ted for your suggestions on how to correct our
problem.

Dave and Kevin: You put a lot of energy into your replies but no suggestions
on what to do about it.

Once MAPICS is tightened down, what is a good technique that allows Query to
be used against MAPICS file?    Any other methods for securing MAPICS?

Greg