Least-Privilege Failure in a Multi-Team Acquia Cloud Org
Agency A manages three client sites in one Acquia Cloud organization. Each client has its own application and Prod/Stage/Dev environments. A new contractor joins to work only on Client B's Stage environment. The org admin, under time pressure, adds the contractor to the organization with the 'Team member' role and grants access to Client B's application. Within a week, the contractor's tooling (using their personal API token) inadvertently triggers a cache clear on Client B's Prod environment, and a separate audit finds the contractor could view Client A's environment list. The contractor never needed Prod access. The org wants to fix access and pass a compliance review that requires demonstrable least privilege and auditable access.
1. Identify the access-control mistakes and explain the blast radius.
Read the worked answer
Two mistakes compounded. First, the contractor was added at the organization level with a broad role rather than being scoped to the specific environment they needed. Organization membership is the wrong granularity for a single-environment contractor; it grants visibility across applications in the org, which is why Client A's environment list was visible. Second, access was granted to the application (Client B) rather than to the Stage environment specifically, so the contractor's credentials could act on Prod.
The blast radius: an org-level role plus application access means the contractor's API token carries permissions beyond their task - including the ability to trigger operations on Prod (the cache clear) and to enumerate other clients' environments (a confidentiality issue across client boundaries). For an agency, cross-client visibility is a serious problem, not just an inconvenience.
2. Describe the corrected permission model and the steps to implement it.
Read the worked answer
Corrected model: scope access to the environment, not the organization or the whole application. Acquia Cloud supports per-environment team permissions; grant the contractor a role limited to Client B's Stage environment with only the permissions the task requires (e.g., code access and cache clear on Stage, no Prod).
Implementation steps:
- Remove the contractor from the organization-level team and from any application-wide grant.
- Add the contractor to Client B's Stage environment with a minimal role (e.g., a developer/limited role scoped to Stage).
- Revoke and reissue the contractor's API token after the change so the old token's broader scope cannot be reused; tokens inherit the user's current permissions, but rotating closes the window.
- Verify by having the contractor attempt the operations they should and should not be able to do: confirm Stage cache clear works and Prod cache clear and Client A environment listing are denied.
- Document the grant (who, what environment, what permission, expiry date) for the audit.
3. What evidence and controls satisfy the compliance requirement for least privilege and auditability?
Read the worked answer
Evidence: the access grant record showing environment-scoped permission, the role definition (what it allows), the removal of the org-level membership, and the token rotation record. Auditability: ensure access changes are logged and retained, and that the contractor's actions can be attributed to their identity. Controls: a joiner/mover/leaver process that provisions environment-scoped access with an expiry, a periodic access review that lists every user's effective permissions per environment and flags org-level grants, and a rule that contractors never receive organization-level roles. For cross-client isolation, verify that no contractor has visibility into applications they aren't assigned to, and re-test after any permission change. This combination demonstrates least privilege (minimal scope, time-bound) and auditability (logged, attributable, reviewable).