Re: User Security Advice -- MIDRANGE-L

I suggest expanding the PF design to house some code representingapplication such as General Accounting, or specific areas of Accounting,such as General Ledger, that the relevant dept head may want to limitdifferent people different kinds of access different areas. So you have acode like A* for Accounting, AG for General Ledger. Develop this for allapplications. Include IT dept e.g. accessing Security itself. Instead ofa set of flags for ALL programs, you have ALL application areas, with roomfor some growth.

So basically for an application like General Ledger, you'd have some codesrepresenting major activities ... is this person allowed to delete oldjournals, are they allowed to update journals, can they see criticalaccounts like owner's equity. You come up with a set of access rules byapplication manager desires, and recognize the software may not bestructured to permit this set of rules to be implemented immediately, butwhat you are doing is designing the security file to support reasonable needs.

In the comments in the front of each program source code you have areminder to the programmer about its security classification. If ANYONEasks you to modify this program to support activities outside this securityclassification, identify relevant department heads who should be notifiedwhat is going on here.

In front of EVERY program you'd have a CL to call the security checkingroutine. It have parameter saying "I am accounting or whatever granulararea" and to run me people need whatever security classification. Thisroutine returns a YES GO or NO STOP flag to the calling program. If theresult is NO, it might also send a MESSAGE to a security message queue ...such and such a user tried to run whatever software but did not have theproper clearance. This would be reviewed by the relevant dept managers tosay whose security and what programs ought to be adjusted to differentsecurity settings.

Can people access this stuff without going thru the front door menus,particularly the security file itself? Does this stuff need to be encrypted?

Hi All,



Does anyone have any advice on protecting home-grown programs and user
security?  Right now we have a very rudimentary security system that
protects programs based on the users "level".  This level has nothing to
do with the built-in security used by the AS/400.  Instead, there's an
additional PF that houses the username, a security category (ie: "A" for
all programs, "S" for only scanning programs, etc.). and a security
level (3 - can do everything, 0 - can do very little).



We're looking at revamping our entire security system to make it more
granular.  Instead of having a broad security level such as "A3", I'm
looking to go right down to the menu items and restrict on that.  So if
we have "001 - Production Control, 002 - Trailer Control, 003 - User
Profiles", I would have the user maintenance program allow access to
001, and 003 for a user, but restrict them from using 002.



However, we have almost 275 programs spread across 15 menus, so a user's
profile may be large because in addition to their name and password,
they will have an extra 275 fields that will have a "Y" or "N" in them
to restrict their access to the programs.  Furthermore, when new menu
items are added, I will need to go into the user profile program and
update all records.  So I'm not sure if this is a viable solution.



I thought I'd consult the group for some advice, since I'm sure there
are others who have done this before.  If not, are there any good
Redbooks that cover this issue or has everyone rolled out their own
security solutions?



Thanks!



/b;



-=-=-=-=-=-=-=-=-=-=-=-=-=-

Brian Piotrowski

Assistant Mgr. - I.T.

Simcoe Parts Service, Inc.

Ph: 705-435-7814 x343

Fx: 705-435-6746

-=-=-=-=-=-=-=-=-=-=-=-=-=-



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