Permissions never shrink on their own — shrinking them is a separate job

In one line

Permissions are added every time they are needed and stay as they are after the need ends. So "who can do what" is not a matter of people's memory but a value to be computed from account, role, and permission data, and reducing them is work that someone has to schedule and do separately.

Why this was needed

Permissions right after delivery are usually right. At that point everyone knows who does what, and there are only a few roles. The problem is what comes after. Permissions granted temporarily for overnight work remain, when a person changes departments the new role is attached but the old role does not come off, and departure processing happens only in the HR system while the account stays alive. After a year, nobody can describe the whole picture.

In an air-gapped network this is not a simple hygiene problem. In a place where there is originally no way out of the network, the only channel through which data can be moved outside is an account that has the permission to do so. So one of the first questions the audit asks about the deliverable is the account list and the permission list, and the second question is "why is that permission needed?" A permission that cannot answer the second question is a permission that should not exist.

Public standards point to the same place. The access control family of NIST SP 800-53 Rev 5 divides account management, least privilege, and separation of duties into separate controls, and NIST SP 800-171 Rev 3, which defense partners often check against, also puts access control as its first requirement family. The three are separate because none of them can stand in for another. Creating accounts well is useless if permissions are broad, and narrowing permissions is useless if one person combines approval and execution, because then approval becomes a formality.

How it works

The order of computation is always the same.

First, expand the effective permissions. Roles are attached to accounts, and roles inherit other roles. What shows on the screen is "two roles," but what is actually held is the union of permissions with all the inheritance expanded. The first thing you hit here is circular inheritance. If role A inherits B and B inherits A again, a naively written recursion does not end. You have to descend while remembering the roles you have visited, and when you expand it that way, it turns out that the two roles are effectively the same permission set. That fact itself is a finding.

Second, separate the permissions that are not used. If you compare the permissions held against the permissions actually used during the observation period, permissions that were never used remain. This is not the same as "permissions that can be deleted." A recovery permission used once a quarter may not show up in the observation period. So use the list not as a verdict but as a questionnaire.

Third, look at the account side. Accounts whose last login is far from the reference date, and accounts left marked as resigned in the HR records. There is one thing you must be sure to follow here. If you take the reference date as "today," the answer differs between yesterday and today from the same data. In audit response material this is fatal. Write the reference date in the data and use that value.

Fourth, look at combinations. Separation of duties is a rule about pairs, not about each permission one by one. Keep a list of pairs that neutralize control when held together, such as approval and execution, or reading and deleting audit records, and find those pairs in the effective permissions.

Fifth, look at what is reachable too. An account that holds a permission to grant permissions can do more than what it holds now. That is because it can attach one more role to itself. And if the role attached that way can grant yet another role, it goes one step further. If you stop after one step, you miss the most dangerous account. This is a problem of following a graph to the end.

What it looks like in the field

At one delivery site I once did an account reduction. What stood out was not an administrator account but an account named "migration account." The migration had ended long ago so nobody used it, and its last login was eight months ago. But the role attached to that account could grant other roles, and one of the roles that role could grant could delete audit records. The account nobody used was in effect the strongest account. What actually reduced risk in the reduction work was not trimming the administrator permissions but removing that one account.

Another thing I often see is duplicate assignment. This is when a person who already has a higher role also has a lower role attached separately. No permission is added, so the risk is the same, but it is constant noise for the person reading the list. If you can show by computation that the effective permissions stay the same even after revoking it, this cleanup ends without argument.

The third thing I often meet is believing the reduction is done once. Reducing permissions is not cleaning but periodic work. Even if you reduce once, after half a year the same list has swollen again. So the most valuable output of a reduction is not the number of permissions cut but the script that can rerun that judgment and the reference date data. If you run the same script next time and compare the numbers, a table comes out showing what grew in between. If you write only the result of the reduction in the delivery document and do not leave the computation, the person in charge half a year later starts over from scratch.

What you will do in the next lab

With 18 accounts, 9 roles, and three months of usage records, you expand the effective permissions and then find, in turn, unused permissions, dormant accounts, separation-of-duties violations, and privilege escalation paths. Next you build a reduction plan that decides revoke or keep for each assignment, then rerun the same judgment with it applied and confirm by numbers that the violations actually decreased. Circular inheritance and multi-step escalation paths are mixed in, so an implementation that looks at only one step gets stuck partway.