Idea Details

Access rule parameter for non-cncl users

Last activity 09-29-2017 04:57 PM
Fletch1's profile image
01-13-2017 08:25 AM

To create an access rule parameter ($nononcncl) to force non-cncl user to abide by the rules set.  The problem we are seeing is that certain users need non-cncl to do their job, but this also gives them access to everything.  There are certain areas the non-cncl user should not have access to.  We have CICS transaction that these non-cncl user have access to and the auditor frown against it. For example, these non-cncl users can get it to unemployment, state police, motor vehicle,  taxation records that they should not be allowed to access. By creating this new access rule parameter we can force the non-cncl users only to have access to these area if a rule is written for them.


09-29-2017 04:57 PM

Robert -


It's dirty, but you could write a RULE-PRE (I think, it's been a while since I was on an ACF2 system) EXIT that checks the DSNAME and the contents $DATA (I forgot the name of the comment field) and then set the non-cncl flag off in the in-memory LIDREC.  We actually had a vendor program that did that before making an ACF2 call.  It took me a while to figure out why I couldn't get to the dataset even with my non-cncl ID.


Also, why not just generate a report of all NON-CNCL loggings and then run it through SORT or SAS, etc., to pick out those accesses of interest.  Auditor like reports. 


- Don

09-21-2017 03:28 PM

I agree, the system programmer rarely needs NONCNCL when they have proper authority.  Setup a firecall type LID that the user can check out when and only when needed.  Make sure all actions are logged

01-19-2017 10:50 AM

What I am suggesting is that certain System Programmers need non-cncl to do their job if there is a problem on the system and they need access to if there is no rule written for them, and yes they will be logged.  But there are still certain areas that non-cncl user should not have access unless there is a rule written to allow them.. We just had an audit and we found out our non-cncl system programmers had access to FTI, HIPAA, PCI data and transactions (CICS) they should never have access to even if they are non-cncl.

01-19-2017 10:24 AM

I agree, that would be the proper best practice protocol for any security / audit function.

01-19-2017 10:17 AM

Why not provide the user with the proper authority they need and remove the non-cancel?  It doesn't make sense to make a non-cancel ID cancelable.