Roles, attributes, and why sprawl happens

Strip the vocabulary away and every access system answers one question at the moment somebody runs a query: given who is asking, what they are asking for, and what they intend to do with it, is the answer yes? The models differ only in how much of that question they are willing to look at.

• Look at one thing. Read the person's role, check whether that role holds the privilege, answer. Fast, cheap, and it forces every distinction you care about to become a separate role.
• Look at everything. Read attributes of the person, the object, the operation and sometimes the surrounding conditions, and evaluate a rule over all of them. Expressive, and it moves the difficulty somewhere less visible.

The reason this matters to an approver rather than an engineer is that the model decides what a request even looks like. Under the first, every request is "add me to a role", and the role list absorbs every distinction anybody ever needed. Under the second, requests become "my attributes are wrong", which is a very different conversation and often a shorter one.

• Role - a named bundle of permissions that people are put into. In the strict model it is the only thing the decision looks at.
• Attribute - a fact about the person, the data, the action or the moment. Region, tenure, contract status, sensitivity class, whether the operation is a read or an export.
• Policy - a rule that combines attributes and returns allowed or denied. Written once, evaluated on every request, which is what lets its answer change without anybody editing anything.
• Group - usually an identity-provider construct, often mapped one to one onto a role. Two lists that must agree, held by two teams, which is a durable source of drift.
• Entitlement - what an auditor calls the end state: this named human can read this column. It is what gets certified, and it is downstream of all of the above.
• Sprawl - not a technical failure. A list that grew one reasonable exception at a time until nobody could hold it in their head or safely remove anything from it.

Role-based access control works on the single attribute of role, and that role is usually assigned from a fairly static organizational position. Somebody joins the analytics team, they get the analytics role, and the decision at query time is a lookup: does this role hold this privilege on this object.

The strength is not performance, it is legibility. You can print the whole list. You can walk into a review with it. You can tell a person exactly what they hold and they can check it. Every access model that replaced it has struggled to reproduce that one property, and it is the property an auditor cares about most.

The weakness is that every distinction has to become a role. The moment access depends on something that varies within a job - which region, how long they have been here, whether they are staff or contract - the list starts multiplying, because a list is the only place the model can put that information.

NIST SP 800-162 defines attribute-based access control as determining authorization by evaluating attributes of the subject, attributes of the object, the requested operations and, in some cases, environment conditions against a policy. Four groups, one Boolean rule set, one answer.

The consequence people underestimate is the second half: a decision can change between requests as attribute values change. Nobody has to edit a role, run a script or approve anything. A contractor's end date passes and the same query that worked yesterday returns nothing today, because the rule was written against the attribute rather than against a membership somebody has to remember to remove.

That self-correcting property is the honest case for attributes, and it is a strong one. It only holds while the attribute is accurate, which is why the real prerequisite is not a policy engine but a system of record that people trust.

The pitch is that attributes replace a sprawling role list with a handful of elegant rules. What actually happens is a transfer: complexity leaves a list you can enumerate and arrives in a policy set you have to reason about. Both are complexity. Only one of them can be printed and read aloud in a review.

• A role list fails visibly. Three hundred and forty rows is obviously bad. Everybody in the room agrees on the diagnosis even if nobody agrees on the fix.
• A policy set fails quietly. Twelve rules, each defensible, whose interaction nobody has traced. It looks tidy right up until somebody asks which rule granted a particular read, and the honest answer takes an afternoon.
• Attributes have owners you do not control. The region, the tenure and the contract flag live in HR systems. Access becomes only as correct as a field somebody else maintains for a different purpose.
• The failure mode is inverted. A missing role blocks somebody and they complain within the hour. A stale attribute silently grants, and nobody complains at all.

None of that is an argument for staying on roles. It is an argument for choosing where you want your difficulty to live, and for being able to say out loud which control is holding which part of the decision.

Warehouses in practice run a split, and it is a good split even though most teams arrived at it by accident rather than design. Roles carry the coarse decision, which is whether a job touches this table at all. Row and column policies carry the attribute-shaped part, which is which rows and which values that job is allowed to resolve.

The test for whether your split is right is simple. Point at any rule and ask which mechanism enforces it. If the answer is "both, sort of", you have a rule implemented twice, and the two copies will disagree at the worst possible moment.

An attribute model is a data quality commitment wearing a security badge. Before promising a policy that reads region and contract status, find out three things about each attribute you intend to rely on.

• Who owns it, by name. Not a system, a person. If the region field is maintained by whoever last did the onboarding paperwork, the policy is only as good as that afternoon.
• How fast it updates. A leaver flag that lands in the warehouse the following Monday leaves a four-day window where a policy reads true and should read false. That window is the actual control gap, and it is worth writing down as a number.
• What happens when it is missing. Null is the case nobody specifies and the case that decides your exposure. A rule that grants when the attribute is absent will grant to every record created before the field existed.

One further trap: attributes read at query time can be gamed by whoever controls them. If a person can edit their own profile field, that field cannot be the thing standing between them and the national ID column. Attributes used for access decisions need the same change control as the grants they replaced.

Sprawl is not carelessness. It is what happens when three ordinary conditions hold at once, and they hold almost everywhere.

• Every exception becomes a role. There is nowhere else to put it. Somebody needs one extra column for one project, and the mechanism available for expressing that is a new role, so a new role is created.
• No role is ever deleted. Not because anybody defends it, but because nobody can say who would break. Deletion carries all the downside and none of the credit, so the rational individual choice is always to leave it.
• The fastest path to unblocking somebody is a new grant. Understanding whether an existing role already covers the need takes an hour. Creating something new takes four minutes and the person is unblocked before the standup ends.

Notice that nobody in that loop is behaving badly. The platform engineer helped, the manager approved, the analyst got back to work. The cost is entirely deferred and lands on a person who was not in the room, usually the one preparing next year's access review.

The pattern is remarkably consistent across organisations. A long tail of roles with one or two members each, created for a project that ended, and one broad role that half the company holds. The tail is embarrassing. The broad role is the actual problem.

The shared role wins because it is the only one anybody trusts to work. A new joiner needs access on their first morning. Somebody could work out which of the 340 fits, or they could add them to the one that definitely covers everything, and the second option ships. Six months later the shared role is the de facto standard and the 340 are decoration.

At Saltbox this is exactly the opening state: one shared analyst role that everybody in data holds, scoring 109 leaks, 0 over-blocks and 30 standing privileges against 150 concrete access requests. Zero over-blocks is not a compliment. It is the signature of a role that grants everything to everybody, and it is why nobody ever complained about it.

Saltbox's policy ladder is scored the same way at every step, against a written design over 150 requests. Two of those steps are masking policies, which is where attention usually goes. One of them is the role split, which is where the value actually is.

Read the last row against the one above it. Two masking policies, both of them real work with a review and a deployment, moved leaks from 109 to 70. Splitting one shared role into the five jobs that actually exist moved leaks from 70 to 22 and standing privileges from 17 to 1, in a single step.

That is the highest-value control available, and it is the one that reads on a plan as administration rather than security. Nobody presents a role-modelling workstream to a board. It is worth learning to, because the alternative is spending the year on policies that are individually correct and collectively worth a third as much.

Before any migration, there is a cheap diagnostic. Go down your role list and look for families: three roles that differ only by region, four that differ only by seniority, two that differ only by whether somebody is staff or contract. Each family is one attribute-shaped rule being emulated by a list of values.

Those families are where a policy genuinely helps, because they are the rules that go stale. A role per region has to be maintained by hand every time somebody relocates. A rule against the region attribute maintains itself, and the two people who moved country stop being an incident waiting to be discovered.

The second one is longer and it is the short version of the work. A role you can define in those terms is a role somebody can safely delete when the job disappears, which is the property the 340 are missing.

Cleaning the list once achieves nothing durable, because the loop that produced it is untouched. Three interruptions, in rough order of how much they cost you.

• Give an exception somewhere to live that is not a role. Time-bound elevation with a recorded reason handles the genuine one-off, and it expires. That is session 3, and it is the single change that stops the tail growing.
• Make deletion safe rather than brave. Nobody removes a role because nobody knows who breaks. Query history against grants turns that into a fact, and the answer is usually that the role has not been used in eleven months.
• Require a job sentence before a role exists. One sentence saying what the role is for, and if two roles share a sentence they are one role. It is a small piece of friction placed exactly where the loop starts.

There is also a sequencing point worth holding on to. Role modelling before masking gives you a smaller, clearer surface to write policies against. Masking before role modelling means writing exception lists for roles you are about to delete, which is a fortnight of work you will discard.