Cloud: design privilege boundaries

Cloud permissions should reflect functions, sensitivity and accountability. Architecture must address both day-to-day operation and recovery when a dependency fails.

Cloud authentication does not define access scope

When I review cloud access, I want to know what each identity can actually do. A valid session may allow someone to read a resource, administer a subscription or change policies granting access to other people. The consequences differ and must remain visible.

We also need to consider how permissions combine. A seemingly limited assignment may gain additional privileges through groups, inheritance or the ability to assume another identity. I would review effective access, not just the role listed in a request. The scope should include affected resources, permitted actions and limiting conditions. Without that context, a role inventory can look correct while hiding administrative capabilities nobody intended or explicitly reviewed. We need evidence of the resulting permissions, not just their labels.

Separate the paths

Distinguish user access, human administration and workload operations. Each path needs conditions and evidence appropriate to its impact.

Separate human and automated access paths

A person administering a service and an application consuming its data need different models. For human access, we can define temporary activation linked to a task. For a continuous integration, we must understand which identity represents the workload and how it obtains credentials.

I would also review who can configure that integration or act as its identity. Otherwise, someone could indirectly obtain capabilities absent from their own role. AWS guidance on temporary credentials and least privilege is useful for its platform, but must be checked against the specific services and mechanisms we use. Across several clouds, I would not assume an equivalent implementation exists or behaves identically. Each design needs to explain and test its own constraints.

Reduce exposure

Evaluate temporary privileges for administrative tasks. Document permitted scope, approval where appropriate and individual traceability.

Example: an administrative intervention

An administrator needs to change a production network configuration. Architecture can separate read access from modification privileges and associate the latter with a task and a duration. Before automating this, check which actions the platform supports, how access is revoked and what happens if an operation is still running when permission expires.

A JIT test must reach the end

Being able to activate a temporary permission is the start of the test. I need to check what happens at expiry, how existing sessions are affected, and whether keys, tokens or derived permissions remain usable. Behavior depends on the service and must be validated.

I would also test approval, denial and early removal. Who can change scope during an intervention? Can we distinguish the requester from the person authorizing a sensitive task? Do logs connect the activity to the individual? I would not demand one workflow for every action. Impact and urgency should guide the design, while preserving response mechanisms that do not require permanent privileges for convenience. The result should be usable by the teams carrying out legitimate work.

Questions before selecting a solution

Declared compatibility does not replace an end-to-end workflow test. Verify authentication, authorization, logging and revocation for the actual clouds and services. Also review access outside the usual path: local accounts, automation keys and emergency mechanisms.

Include the routes we do not normally use

Local accounts, old keys and supplier access can remain outside the usual workflow. We need to find them and explain their purpose. Federation does not mean every local identity has disappeared or that its permissions are controlled by the identity provider.

My review would include portals, APIs, command-line tools and access between accounts or projects. It would also cover identities administering policies and those able to change logging. The ability to alter who has access or which evidence is retained deserves particular attention. Each path needs an owner and a treatment: bring it into the model, retire it, or document an exception with clear conditions and an agreed review. That includes paths kept for occasional maintenance, not just daily administration.

Prepare for emergencies

Define emergency access, custody, alerts and testing. Avoid making recovery depend solely on the component whose failure it must resolve.

Onboarding needs completion criteria

Bringing a cloud into the privileged access model requires more than enabling a connector. I would select representative tasks and check how teams work through portals, APIs and their usual tools. Commercial product support must become evidence of the workflow we need.

I would define acceptance criteria for identity, authorization, removal and traceability. If a function is excluded, record its scope and treatment. Success in one service does not validate every other service: network, database, platform and identity administration may behave differently.

I would also agree when previous routes are removed and how incidents are handled. Transition must allow work to continue without indefinitely retaining parallel paths that undermine control. Necessary exceptions should remain visible and be reviewed with the service owner.

After deployment, I would check actual activity, failures and requests for broader access. If the team avoids the new workflow, investigate why: a capability may be missing, an operational issue may exist, or a simpler alternative may remain available. That analysis should guide adjustments. Adoption is more meaningful when we can demonstrate that privileged tasks use the intended mechanism and permissions are removed as expected. Completion therefore needs evidence from real operating tasks as well as a successful technical connection, with clear ownership for every outstanding limitation.

Operate access without an impossible dependency

The model must be usable during an incident. Emergency access needs protection, owners and tests, together with a design that can recover the failing component. If every route relies on the same unavailable authentication service, the alternative may exist on paper but fail in practice.

I would measure coverage by cloud and service, administrative activities using the model and outstanding routes. I would also measure access mechanism availability and the time needed to obtain legitimate authorization. Better adoption alone does not prove that privileges are removed correctly. I would therefore combine operating metrics with permission and revocation tests. The aim is for the business to administer its services through access that is explainable, limited and operationally viable.

Further reading

Official sources for checking and exploring these concepts. This article presents a practical approach; it does not reproduce the references’ full requirements.

• NIST Cybersecurity Framework 2.0
• AWS — IAM security best practices

Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.