BetterIAM
Governance

Governance

The loop that keeps access correct over time, from measuring usage and mining roles to reviews, guardrails, terms of use, and self-service.

@better-iam/servergovernance.mdpolicies.md

and say who may do what on the day you set them up. Then people change teams, projects end, roles grow, and exceptions pile up. A year later nobody can say whether the access is still right, and auditors ask anyway.

Governance is the loop that keeps access right over time. You measure which access is actually used, simplify how it is granted, have the people who know certify it, check each change before making it, hold lines no change may cross, get people to agree to the rules, and help them get what they need without an administrator.

Questions and the features that answer them

Each governance feature answers one question an administrator or auditor asks. Start from the question you have:

QuestionFeatureAPI
Which grants are redundant or could be simpler?Role miningroleMining.suggest / apply
Who holds access unlike their peers?Peer outliersroleMining.outliers
Which access is actually used?Access usage and right-sizingaccessUsage option, roleMining.usage / rightSize
Should this person keep this role?Review recommendationsroleMining.reviewRecommendations
What happens if I edit this role?Change impact previewimpact.preview
What must never (or always) be possible?Access invariantsinvariants.*, iam.checkInvariants()
Have people accepted the rules?Terms of useagreements.*, principal.pendingAgreements
How can I get access myself?Self-service access pathsaccessPaths.find, useAccessPaths

The administrator reads above each need a permission: iam:analysis:read (role mining, usage, recommendations), iam:policies:simulate (impact), iam:invariants:read, or iam:agreements:read. Access paths and a member's own agreements need only that person's session. The console's Organization section has a page for each feature.

The loop

Measure

You cannot remove unused access until you know what is used. Turn on access usage once and let it run for a review period. Every allowed check is counted per person and action, so roleMining.rightSize can later show which grants nobody touched.

Simplify

Access granted one person at a time becomes hard to reason about. Role mining reads who holds what and proposes simpler grants: redundant bindings to remove, roles to bind to a group once, duplicate roles, and bundles of roles to grant together as an . Peer outliers show people whose access differs from their colleagues', often access that outlived a move.

Review

Auditors want proof that someone checks access regularly. A is that check: it asks named reviewers, or each person's manager, to keep or revoke every role binding, and applies the decisions when it closes. Certifications also suggest a decision for each item from usage evidence.

Change safely

A role edit can give or take access from many people at once. An shows who gains and loses what before you make the change. An is a rule that must hold whatever roles say, such as "contractors never approve payments"; enforced invariants refuse any change that would break them. See change safety.

Agree

Some access should depend on people accepting rules first, such as an acceptable-use policy. Terms of use are versioned that members accept; an ordinary policy statement holds back access until they do.

Help people help themselves

"Access denied" sends people to an administrator even when they could fix it themselves. When your application refuses something, access paths tell the person what they could do about it: step up to MFA, accept terms, activate an , or request a package.

Two related tools live with authorization: rules, which name roles nobody may hold together, and the access analysis, a scan of a tenant's configuration for risky grants. See separation of duties and access reviews.

In this section

Was this page helpful?

Last updated on

On this page