Three IAM Models, and One Engineer With Standing Access to All of Them

Three reviews, three passes, one person

The cycle runs the way it was designed to. Each cloud's owner exports entitlements for the accounts, subscriptions or projects they operate. Managers attest. The sign-offs are filed and the control reads green in all three places.

Every one of those reviews is correct. An access review run inside a provider covers the estate that provider operates, which is what it is for. Grants held elsewhere fall outside the question it was built to ask, so they never surface as a gap or an exclusion.

The reviewer sees one row. A manager approving read access and a deployment role in one cloud is approving something reasonable. The other two rows sit in other reports, produced by other teams, in other weeks.

Four properties of the three-review shape do the damage:

• The person appears in each export as a different account, so no line anywhere states that these are one human.
• The three reviews run on three schedules, so even laid side by side they describe three different days.
• Each reviewer is asked whether a grant suits the person's role, and that question can be answered yes in three places at once.
• Contractors, shared operational accounts and credentials issued to a person for a pipeline sit outside the employee roster the reviews are built from.

Three reviews that each pass do not add up to a person whose access has been reviewed.

The review is scoped to an estate, the privilege is held by a person

That mismatch is the whole of it. A review is scoped to an estate because an estate is the unit somebody can be made to own and attest to. Privilege accumulates against a person, because a person receives it, carries it between teams and uses it. Reviewing the first object and drawing conclusions about the second is where the aggregate goes missing.

Held together, ordinary grants compose. Someone who can change a pipeline definition in one cloud and approve what it deploys into another holds an unreviewed capability built out of two approved ones. Someone who can read a regulated dataset in one cloud and write to storage they control in another can move it, with granted rights at both ends of the move.

Reachability does the rest of the work. The clouds are joined already, by federation for humans and workload identity for machines, and those trust relationships were built by separate teams to make specific things work. Rights over the identity configuration on one side of a trust are rights over what the other side accepts. The path runs through a named individual, and it exists whether or not anyone has drawn it.

The compositions worth finding first all have one shape, a grant in one cloud multiplied by a grant in another:

• Change the deployment definition in one cloud, approve or trigger what it deploys into a second.
• Read sensitive data in one cloud, write to a location you control in another.
• Administer a directory or a trust relationship in one cloud that a second cloud accepts identities from.

Standing access outlives the work it was granted for

A grant made for a piece of work carries an end condition, and the end condition lives in a conversation: the migration finishes in March, the incident closes, the certification cycle ends. The system holding the grant records the grant, and the end condition stays in the conversation, so the date passes in silence.

Deprovisioning is built around leaving the company, and it works. The event with no trigger behind it is the one where the work ended and the person stayed. An internal transfer moves someone's responsibilities and leaves their access exactly where it was, because a leaver process fires on departures and a transfer is a move.

Where the platforms in use support time-bound elevation, the stronger answer is to stop the grant standing at all: it gets requested for a task, approved, used, and it lapses. That capability sits in the identity platforms and in the privileged access products layered on them, and turning it on shrinks the population a review has to cover. What remains standing is what the review still owes an answer for: grants issued before the capability arrived, grants in systems outside its reach, and the permanent access a job genuinely needs every day.

This is also why the per-cloud review renews it. In an export, a grant made for a project that has since closed looks identical to a grant the role requires, because the reason it was made is not carried in the record. The reviewer can only ask whether the access looks plausible for that job, and it does.

The grants that survive their own reason have recognizable origins:

• Elevated rights issued during an incident, when raising them quickly was the correct call.
• Migration access to the old environment and its replacement, held until the old one is retired, which slips.
• Read access issued to someone supporting an audit or a certification cycle.
• Everything carried through an internal transfer, sitting underneath whatever the new role required.
• Long-lived credentials issued to a person and then embedded in a pipeline, where revoking the person breaks a build.

An internal transfer moves a person's work and leaves their access where it was. Nothing in the leaver process fires, because nobody left.

What a person-scoped review needs

Changing the object under review is a larger change than it sounds, and most of the difficulty arrives before any judgment is made. The output is one page per person covering the whole estate. Three things stand between you and that page.

The first is the join. The same human holds accounts in three directories under three naming conventions, and after an acquisition some were created by a company that no longer exists. Somebody has to state that these accounts belong to one person, and to arbitrate where the evidence is a similar name and a shared manager. An account that attaches to no name on the employment roster is a finding of its own.

The second is resolving what a grant means. What a person can do arrives through group membership, nested groups, roles they are permitted to assume, and permissions written onto a resource that name them. A list of direct assignments describes less than the person holds.

The third is the reviewer. A per-cloud review is answered by whoever owns that cloud, and they know exactly what a grant permits there. A union has to be answered by the person's manager, with an estate owner beside them to translate.

One page per person carries:

• Every account across every provider, joined to one named human, with the directory each came from.
• Effective permission per cloud, resolved through groups and assumable roles.
• Why each grant exists and when it was made, carried forward from the request that created it.
• An expiry or a re-justification date on anything granted for a piece of work.
• The machine identities and long-lived credentials issued to that person, listed beside the human accounts.
• A decision against every line: keep, reduce, or remove, with a name and a date.

Running it without reviewing everybody

A person-scoped review across three clouds is heavy, and the cost scales with the population you point it at, so the population is the first decision. Start where the union is most likely to matter: platform and reliability engineers, security staff carrying investigative access everywhere, anyone who has changed teams since the last review, and the few people holding rights over a trust relationship between two clouds. Report where you started beside the findings.

CWS runs tool agnostic posture assessment across AWS, Azure and Google Cloud, scored against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework, and the entitlement data a cross-cloud privilege picture needs is what that work reads. Each provider console reviews the estate it operates, correctly and completely, and the platforms that aggregate across providers resolve effective permissions for every customer they cover at once, which is what a platform is built to do. Deciding which of those grants your organization intends one named person to hold, and standing behind that decision in writing, is work that lives inside your organization.

Moving the unit of access review from the estate to the person, the join that makes it possible, and the sequencing by population are CWS positions. The Cloud Controls Matrix carries an identity and access management domain and the Cybersecurity Framework reports identity management and access control inside its protect function. Neither settles what object the review runs against.

The number that says whether the cycle worked is the count of grants removed. A review ending in signatures and no revocations has described the estate you already had, and a description was available before the cycle started.

Whether your own team runs this or you bring someone in, settle these in the first week, because each of them settles itself by default when nobody raises it:

• How two accounts are proved to belong to one person, and who decides when the evidence is thin.
• Which role name grants read only access at each provider, settled before the first export is requested.
• Whether contractors, shared operational accounts and credentials issued to people are in scope.
• Who signs a removal, and how quickly it executes once signed.
• What happens to a grant nobody can justify and nobody will remove, including who accepts that risk by name.

Count the revocations. A cycle that ends in signatures has produced a description of your estate, and the estate is the one you started with.