Again, just to make sure it's understood, what I am advocating does NOT require a change to what is set up in ESI.
What I am saying is you can change the access allocation of a single rule to a single mask in ACF2/Top Secret/RACF (not Endevor and not ESI). Then, when you're done maintenance, you change the ACF2/Top Secret/RACF access rule to that single mask back to general access. The "on/off" switch actually already exists today; it's just controlled in the security software and whether it's a single switch or a whole load of switches is a function of how well or over engineered the rules were created.
To be honest, it's really really simple. BUT, like I said, it requires a (re)examination of the security you THINK you need versus the security you ACTUALLY need. Many sites have never "gone back" and relooked at what they implemented "way back when" because "it works". What I discovered is, when you really look at what you really need and put the politics aside, the rules can be (and actually are) very simple.
To illustrate a truly basic example, the first entry in the Endevor provided NAMEQU entry reads:
NAMEQU ENVIRONMENT_ACCESS, +
L1=('C1'), +
L2=('ENVIRON'), +
L3=(ENVIRONMENT)
If I have a single rule in ACF2/RACF/Top Secret that allows READ access to rule "C1.ENVIRON.**", I allow access. If I temporarily change that rule to deny access, I temporarily suspend all activity in Endevor. On/off in the security software.
In reality, I can show you how you can even boil the rules down further to a mere handful, but I just want to make sure we aren't thinking its overly complex. It's really not.
But like I said, I'm not addressing the politics or egos involved!