Least Privilege Meets a Deadline
A team is migrating an application to the cloud under a two-week deadline. To unblock progress, an engineer attaches an administrator-level policy to the application's service identity and says it will be tightened later. Six weeks later, the policy is still in place. A security review finds: the service identity's credentials are stored in a configuration file committed to a repository; the identity can read and delete data across all storage buckets in the account; and audit logs show the identity's credentials were used from an IP address outside the organization's range twice in the past month. The application legitimately needs to read one bucket and write to one queue.
1. What is the immediate containment sequence, and why in that order?
Read the worked answer
Containment order should follow stop the bleeding, then investigate, then fix root cause:
- Rotate/revoke the exposed credentials first. The out-of-range IP usage means the credential is likely compromised. Rotating invalidates the attacker's access immediately. Do this before anything that might tip them off or before lengthy analysis.
- Scope the identity down to its actual need - read one bucket, write one queue. This limits blast radius if a new credential leaks. Do it in the same change window as rotation.
- Preserve evidence. Snapshot audit logs and access records before they age out, so the investigation can determine what the credential accessed.
- Investigate the out-of-range usage: what was read, deleted, or exfiltrated; whether the repo is public; whether other secrets are in the same file/history.
- Remove secrets from the repo and its history, and move to a managed secret store with rotation.
Rotating first is the key judgment: analysis can wait minutes, but an active credential cannot.
2. The engineer argues that tightening permissions now risks breaking the app before the deadline. How do you evaluate and respond to that risk?
Read the worked answer
Treat it as a real but bounded risk that must be measured, not asserted.
- The application's stated needs are narrow: read one bucket, write one queue. Build the least-privilege policy from that, then test in a staging environment that mirrors production traffic. If it passes there, the breakage risk is low and the deadline argument weakens.
- Use access logs to derive the actual permission set rather than guessing: grant only actions the identity has exercised, plus a small margin, and monitor for denials after cutover.
- If a short bridge is truly needed, use a time-boxed, monitored elevated role with an expiration and an alert on use - not a permanent admin policy. The failure here was not the temporary grant; it was the absence of an expiration and a review.
Response to the engineer: the credential is already being used from outside the org, so the status quo carries a larger and less controllable risk than a tested permission change. The deadline argument has already been overtaken by events.