October 5 Article in "in-approval" - Are your Endevor ESI rules complicated and hard to maintain or keep track of? Maybe it's time to optimize....

[John Dueckman]

A new article has been published in "in approval". Are your security rules for Endevor a rat's nest of complexity? Here's some ideas on optimizing a necessary component of securing one of your enterprise's most valuable asset.

 

 

You can find the blog at https://johndconsulting.wordpress.com

[Philip Gineo]

Thanks John for this article and all the other "in approval" publications!  Each one is well written!  I really appreciate you sharing your knowledge!

[Mathew Goldstein]

Our entry stages do not require packages so relying on package approvals will not restrict entry stage actions.  We need to restrict access by subsystem.  There are people who need to have display only access to almost all program elements in almost all systems of most stages.  And our emergency path package approvals are sometimes reduced to the point where ESI restrictions are probably a good idea.  Given this combination it seems to me that we either need to define single stage entry stage environments, or add the stage to the action profile definitions, and then specify ESI profiles for the ADD, UPDATE, GENERATE, RETRIEVE, DELETE, TRANSFER actions (at a minimum) for the entry environment or stage action profiles for every subsystem so that we can restrict those actions in the entry stages by subsystem while still allowing other people display authority.  I do not think we are going to start requiring packages for our entry stages.

[John Dueckman]

I certainly hope you weren't under the impression that I advocated the use of packages for entry into Endevor! And based on your comments, I would say what you want to do is very do-able.

 

Let me know if you want to explore options; I have other articles/presentations I've written that help shed light on better understanding and exploiting the ESI as well as a principal I refer to as APE (Ask-Permit-Execute).... APE will appear in a future "in-approval" article (scheduled for next year) but I can provide you an advance copy...

 

You can reach me at [e-mail].

[Mathew Goldstein]

You recommend using MENUAUTH instead of MENUITEM to cover SIGNOVR for the action profiles.  TRANSFER potentially allows users to break the migration path, therefore we also want to restrict use of TRANSFER.  Only MENUITEM covers TRANSFER.  We do not want to use both MENUAUTH and MENUITEM, that is mostly redundant and too complicated.  We want ti restrict use of both SIGNOVR and TRANSFER without restricting anything else (in accordance with the APE principle of relying mostly on package approvals to grant permissions) using either MENUAUTH or MENUITEM if possible.

 

Question:  if we use MENUITEM, require UPDATE access for SIGNOVR but READ access for the other actions, and selectively grant some people UPDATE access for the various actions that support SIGNOVR such as ADD, SIGNIN, etc., then would only those users with the UPDATE access be able to execute sign out override?

[John Dueckman]

Sounds like you've got the principles down correctly, Mathew. Experiment... but you are totally on the right track! And obviously you can extend the same concepts to the TRANSFER action. I applaud your efforts!