Cloud Entitlements
Cloud permission models are enormous, granted broadly and used narrowly. Where standing privilege now concentrates, and how to reduce it.
Analysis
Traditional PAM was designed for a world of servers and directories. Most standing privilege now sits in cloud platforms, with a different permission model and a different failure mode.
Why cloud is different
The permission model is enormous. Thousands of individual actions, granted through policies most people cannot read.
Roles are granted broadly because working out the minimum takes effort and broad works immediately.
Actual usage is a tiny fraction of what is granted, consistently, across every organisation that measures it.
Identities are not only people. Workloads, functions, pipelines and services all hold permissions, and they outnumber humans.
Cross-account and cross-tenant trust creates paths that are invisible from within one account.
Everything is an API, so there is no console session to broker in the traditional sense.
The permission gap
The central measurement.
Compare permissions granted against permissions used, over a representative period.
Cloud platforms provide this data, through access analysis and usage logs.
The ratio is usually stark: a small proportion of granted permissions are exercised at all.
The unused remainder is pure exposure, available to anyone who compromises the identity and useful for nothing else.
Reducing it
Right-size from observed usage. Generate a policy from what was actually used, review it, and apply it. This is the highest-return activity available in cloud security and it is mechanical.
Remove unused identities, which accumulate faster than in traditional estates.
Remove long-lived access keys in favour of federated, short-lived credentials.
Scope by resource and condition, not only by action.
Separate environments so that a development identity cannot reach production.
Watch the permission-modifying permissions, which are the cloud tier zero: anything that can alter policies, roles or trust relationships.
Just-in-time in cloud
Elevation on request rather than standing role assignment, which most platforms support natively or through a broker.
Short expiry, measured in hours.
Approval proportionate to the tier.
The grant recorded as the audit event.
This is more achievable in cloud than on-premises because the platforms were built with programmable role assignment, and it is frequently deployed later because the traditional estate got attention first.
What session recording means here
There is no interactive session in the traditional sense for API activity.
The platform's own audit log is the record — every API call, with the identity, source and parameters.
Ensure it is enabled everywhere, including in regions and accounts nobody uses, which is where an attacker will operate.
Ship it out of the account to a destination the account's administrators cannot alter, which is the control that makes it evidence.
Console sessions can be recorded where a broker is used, and the value is lower than the API log.
Where it fits in the programme
If your estate is mostly cloud, do this before traditional vaulting.
If it is mixed, run both, and accept that they are different projects with different tooling.
The common ground is the inventory and the ownership model, which should cover both rather than existing twice.
Generating a right-sized policy
The highest-return mechanical activity available in cloud security.
Collect actual API usage for the identity over a representative period, which must include monthly and quarterly processes.
Generate a policy from observed usage, which the major platforms support.
Review it rather than applying blindly, because absence of use is not proof of no need.
Apply in audit mode where available, then enforce.
Watch for denials for a period afterwards.
Repeat annually, and after any significant workload change.
The permissions that grant permissions
Cloud tier zero, and it is not always obvious which permissions belong to it.
Anything that can modify policies, roles or their attachments.
Anything that can create identities.
Anything that can alter trust relationships between accounts or tenants.
Anything that can modify or disable audit logging.
Anything that can assume other roles broadly.
Treat these as tier zero regardless of what else the identity does, grant them just-in-time, and alert on every use. An identity holding them can grant itself everything else.