Except for perhaps at the hyper-scalers where delegated permissions are granted to thousands of support staff, techs, engineers, developers, etc... this kind of fine-grained permission model is a no-go.
It's hard to explain, but it reminds me of the Semantic Web, this totally artificial theoretical construct of how Things Should Be, but... it never worked out like that, and never will. Market forces just don't align with these ivory tower approaches of how things Ought To Be Done.
On the contrary, all too often worse is better, because it scales effortlessly, is faster, and much more importantly: cheaper.
This applies to priviliged identity management (PIM) and its variations.
What I see in most organisations is that the "least trusted" person, the outsourced subcontractor to the contractor, some below-minimum-wage person working out of Chennai is the "Global Admin" (or equivalent) and the CEO, CIO, CTO, and the CISO all have... no special rights. The same as a random secretary.
I see this pattern over and over, organisation after organisation. The exceptions are few and far between, so there must be a reason!
My best guess is that this is because as permissions delegation get finer and finer grained, then the manager delegating the permissions needs better and better knowledge of the technical task to be done in the future to properly and accurately delegate all -- not just some(!) -- of the permissions required to execute that task.
How would you delegate the permissions to fix an "error" (unspecified!) "somewhere" in the tangled network of servers and other equipment?
Remember: No gaps! No missing permissions! This has to be one hundred percent coverage, no edits on the fly, because this troubleshooting could be at 3am on a Sunday after a disaster that could stop the business operating on Monday morning.
No, getting woken up at 3:30am to delegate more permissions is not something most senior managers will accept. Even if they're forced to at gunpoint, what exactly are they going to do? The clock is ticking, the system is down, they don't even know where the problem is! If the +1 permission they just granted is not sufficient, they'll have to grant one more at 4:00am, then 4:30am, then 5:00am and so forth until the business is back up.
This means that with sufficiently fine-grained permissions, eventually the "delegator" has to be 100% involved throughout the entire time complex ad-hoc tasks are performed. This isn't just troubleshooting, it's consultants, it's new deployments, migrations, mergers, splits, role changes, reshuffles, or anything that wasn't 100% perfectly foreseen by the original security delegation architects.
Not to mention that "security architect" is a specialisation with very little overlap with any specific product or business system. The "person in charge" of some database, platform, or product is very unlikely to fully grok delegated ACLs, ZSP, PIM, etc...
This just doesn't scale. Managers overseeing, say, five staff can't be 100% involved in all five staff doing ad-hoc work. Even if they can make this work, what about the next level management, the level from which this manager gets their delegated permissions (which they can further delegate)? Run this up to the level of CIO and with a sufficiently specific access control design you'll have the CIO doing nothing else other than mashing buttons in the some security delegation system such as Active Directory!
It's just soooo much easier to give the lowly tech "Domain Admin" and be done with it.
The alternative with ZSP or whatever is Ivory Tower stuff that only works in "tech organisations" like FAANGs at a huge scale, and nowhere else. You need techs at every layer of management, sufficient scale to justify the effort and not be swamped in overhead.
PS: For comparison, I see a similar effect with ex-FAANG engineers recommending metrics for everything. That's great. I have apps that get 1 real transaction... per month. The other 99.999% of hits in the metric are GoogleBot and random drive-by hackers.
Except for perhaps at the hyper-scalers where delegated permissions are granted to thousands of support staff, techs, engineers, developers, etc... this kind of fine-grained permission model is a no-go.
It's hard to explain, but it reminds me of the Semantic Web, this totally artificial theoretical construct of how Things Should Be, but... it never worked out like that, and never will. Market forces just don't align with these ivory tower approaches of how things Ought To Be Done.
On the contrary, all too often worse is better, because it scales effortlessly, is faster, and much more importantly: cheaper.
This applies to priviliged identity management (PIM) and its variations.
What I see in most organisations is that the "least trusted" person, the outsourced subcontractor to the contractor, some below-minimum-wage person working out of Chennai is the "Global Admin" (or equivalent) and the CEO, CIO, CTO, and the CISO all have... no special rights. The same as a random secretary.
I see this pattern over and over, organisation after organisation. The exceptions are few and far between, so there must be a reason!
My best guess is that this is because as permissions delegation get finer and finer grained, then the manager delegating the permissions needs better and better knowledge of the technical task to be done in the future to properly and accurately delegate all -- not just some(!) -- of the permissions required to execute that task.
How would you delegate the permissions to fix an "error" (unspecified!) "somewhere" in the tangled network of servers and other equipment?
Remember: No gaps! No missing permissions! This has to be one hundred percent coverage, no edits on the fly, because this troubleshooting could be at 3am on a Sunday after a disaster that could stop the business operating on Monday morning.
No, getting woken up at 3:30am to delegate more permissions is not something most senior managers will accept. Even if they're forced to at gunpoint, what exactly are they going to do? The clock is ticking, the system is down, they don't even know where the problem is! If the +1 permission they just granted is not sufficient, they'll have to grant one more at 4:00am, then 4:30am, then 5:00am and so forth until the business is back up.
This means that with sufficiently fine-grained permissions, eventually the "delegator" has to be 100% involved throughout the entire time complex ad-hoc tasks are performed. This isn't just troubleshooting, it's consultants, it's new deployments, migrations, mergers, splits, role changes, reshuffles, or anything that wasn't 100% perfectly foreseen by the original security delegation architects.
Not to mention that "security architect" is a specialisation with very little overlap with any specific product or business system. The "person in charge" of some database, platform, or product is very unlikely to fully grok delegated ACLs, ZSP, PIM, etc...
This just doesn't scale. Managers overseeing, say, five staff can't be 100% involved in all five staff doing ad-hoc work. Even if they can make this work, what about the next level management, the level from which this manager gets their delegated permissions (which they can further delegate)? Run this up to the level of CIO and with a sufficiently specific access control design you'll have the CIO doing nothing else other than mashing buttons in the some security delegation system such as Active Directory!
It's just soooo much easier to give the lowly tech "Domain Admin" and be done with it.
The alternative with ZSP or whatever is Ivory Tower stuff that only works in "tech organisations" like FAANGs at a huge scale, and nowhere else. You need techs at every layer of management, sufficient scale to justify the effort and not be swamped in overhead.
PS: For comparison, I see a similar effect with ex-FAANG engineers recommending metrics for everything. That's great. I have apps that get 1 real transaction... per month. The other 99.999% of hits in the metric are GoogleBot and random drive-by hackers.