Re: Authority Collection -- MIDRANGE-L

<snip>

> Basically my goal is to secure the data with *public *exclude. Most users should have no access to the end data but instead should use programs which adopt authority to get to the data. For example, if JOHN is enrolled in our ERP application then he can perform any task authorized for him. However if JOHN tries to query the data directly outside of the applications he cannot.

<snip>

THIS is the goal indeed. John as a standalone profile even with command line access shouldn't even be able to DSPPFM the dadgum file. If he has access to a reporting application through app level security then the application adopts the needed level of access and accesses the data. Same with update etc.

ODBC = Nope.
Query = Nope.
SQL = Nope.
FTP = Nope.
SCP = Nope.
Nope Nope Nope Nope Nope.

Yes some query users exist but that's where a well planned Authorization List works well. Files which need to be queried are secured by it. Users who need query access are added to it. Works well. BUT it then also allows access via ODBC, SQL, FTP, SCP ... for downloads anyway. This doesn't put your application at risk but your DATA, yes.

As to the Original Question I have not yet gone through an authority collection to figure this out but I have seen Carol Woodbury discussing Authority Collections and it very clearly thrilled her that these capabilities exist. She spoke glowingly of them!

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 5/20/2020 3:47 PM, Rob Berendt wrote:

How many of you have ran the authority collection tasks and have actually taken steps to secure your applications based on the results?

First, I tried going around them with other steps.
I used IBM i Services to analyze job schedule entries.
I used IBM i Services to find that a lot of our applications submit jobs for the end users. For example, fill out a prompt screen then it submits off the job.
I used IBM i Services to analyze all of our programs. All but 7 of our programs (and those are being looked at) are set up with Use Adopted Authority of *YES. This basically allows adopted authority to pass down the call stack. For example, if you have a program called ERPMENU and that is owned by owner ERP with USER(*OWNER) then when JOHN logs in and starts out with ERPMENU and does order entry he will be able to use that data from the programs as long as they all do the Use Adopted Authority. The problems start arising when JOHN takes an option which submits a program to batch. If that program has the Use Adopted Authority set right but doesn't have a previous program in the call stack which had USER(*OWNER) (which it won't since it was submitted to batch) we'll have issues.

Basically my goal is to secure the data with *public *exclude. Most users should have no access to the end data but instead should use programs which adopt authority to get to the data. For example, if JOHN is enrolled in our ERP application then he can perform any task authorized for him. However if JOHN tries to query the data directly outside of the applications he cannot. I have ZERO interest in playing whack-a-mole by concerning myself with things like command line capability, exit point programs and any of that rot. A few users who are more of your "query monger" types may have read access to some tables.

I am leaning towards firing off the authority collection tasks now. Seems there are two schools of thought. One is to run it on the objects and the other is to run it against a user or set of users. Which did you use, and performed actions based on the results?

I believe we may end up not relying upon USEADPAUT(*YES) but end up switching the programs to USER(*OWNER). Especially with as many jobs submitted that we have. This, though, probably opens up another can of worms as then any user could submit a job, providing the program called has the USER(*OWNER) and get to the data. But better than total unfettered access to the data.

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