Yes, we have around 30 BPCS/LX environments. Each environment has a 2 character code assigned. NH for North Haven, TM for Tampa etc. All objects within the environment are owned by xxSSA, where xx is the 2 character code.
Users adopt authority from BPCSMENU to the data. *PUBLIC is *EXCLUDE.
All file objects in every environment also have group profile LXDTAUSE assigned with *USE access. Support staff and Super Users have this as a Supplemental Group on the user profile to give read access to all data (from either within or outside BPCS/LX).
All file objects in every environment also have group profile LXSSAALL assigned with *ALL access. This can be used for automated jobs, interfaces etc.
-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: 11 October 2017 12:18
To: bpcs-l@xxxxxxxxxxxx
Subject: [EXTERNAL] [BPCS-L] Implementing "Application Only Access" in LX
We've gotten a lot more concerned about security on our data. In general everyone who has access to this lpar has need to get into Infor LX.
Something that really hasn't been true for 25+years is that if you change their user profile to LMTCPB(*YES) they no longer have access to the command line and cannot get to the data outside of the programs.
Well longer ago than some people working on IBM i and it's predecessors have been alive there have been ways around that. For example:
- "IBM Navigator for i" which is loaded on every IBM i and is available at
http://youribmi:2001
- IBM Access Client Solutions "Run SQL scripts".
- Excel
and really a rather unlimited number of other possibilities.
And while the auditors are still concerned with securing some commands like STRSQL (and forget about newer ones like RUNSQL, etc), and some people push Exit Point programs, it's still like playing "Whack-a-mole".
Quite some time ago Wayne Evans coined a phrase called "Application Only Access". In this model the users do not have access to the data. *PUBLIC is *EXCLUDE and the users are NOT part of some group, authorization list or any other method to gain direct access to the data.
Suppose your data is owned by SSA. And SSA is the only user with access to that data.
Now, suppose you have a program named BPCSMENU. And that program is owned by SSA. And, that program is set with "User profile" = *OWNER and not *USER. Then that user could call BPCSMENU and if that program accesses the data the user could see that data.
Now let's say the rest of the programs do not have "User profile" set to *OWNER but have it set to *USER. And all those programs (such as ACR100)
have "Use adopted authority . . . . . . . . . . . . : *YES". What this
means is that the user could not call ACR100 directly and get access to the data since the "User profile" is set to *USER. However if they called it from an unbroken call stack in which every program between BPCSMENU and
ACR100 have "Use adopted authority . . . . . . . . . . . . : *YES" then
they would have access to that data.
This is the difference between Use adopted authority" and "User profile"
and why you do not just make them both *OWNER and *YES. They do different things.
Infor ships their programs out of the box with "User profile" set to *USER
and Use adopted authority . . . . . . . . . . . . : *YES. Which is
what you want. Except for the initial BPCSMENU type program.
So in theory this should work for us, providing the users have *USE (aka read only) access to the programs.
Has anyone done this? Have you set *PUBLIC to *EXCLUDE and try this? How did it work out for you?
How do you handle those "super users" who have a business need to query certain files with either 5250 based tools or with client server or web based tools? Do you give them *USE (aka read only) capability to certain files? Do you limit them only to 5250 based queries which you write and call from a menu (which our users will not accept since it limits "what if" stuff).
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/bpcs-l.
[CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser:
http://emaildisclaimer.medtronic.com
midrange.com
