The Over-Permissive Analyst and the Audit Finding
A mid-sized SaaS company runs a customer-support analytics workload in one cloud account. An auditor found that a support analyst's identity has an attached policy granting Action: "*" on Resource: "*", inherited from a hurried migration two years ago. The analyst only needs to read objects in one bucket and query one managed data warehouse. Separately, the security team discovered that the account root user has no MFA and that access keys for a service account were committed to a public repository six months ago and never rotated. The company must pass a compliance review in 45 days and cannot take downtime during business hours.
1. Prioritize the three findings. Which is the most urgent and why?
Read the worked answer
The exposed long-lived access keys are the most urgent. An over-permissive policy is dangerous only if that identity is compromised, and missing root MFA is dangerous only if the root password is guessed or phished - both are latent. The leaked keys are an active exposure: anyone who found them has had six months to use them, and the auditor's discovery does not mean the attacker has not already acted. The correct order is: (1) rotate/disable the leaked keys and review logs for use from unexpected locations, (2) enable root MFA and remove root access keys, (3) scope down the analyst policy. The reasoning is about likelihood of active exploitation, not about which finding sounds worst in a report.
2. Rewrite the analyst's access to least privilege and explain how you would verify it without breaking their work.
Read the worked answer
Replace the wildcard policy with two statements: one allowing the specific read actions needed on the one bucket's objects (and listing the bucket if the tool requires it), and one allowing the specific query/connect actions on the one data warehouse resource. Deny everything else by default - do not attach broader managed policies. Verification should be evidence-based, not hopeful: use the provider's policy simulator or access analyzer to test the exact API calls the analyst's tooling makes, then run the analyst's real workflow in a staging identity before switching production. Because there is no downtime allowed, do the change during a maintenance window with the old policy version retained for quick rollback. Also enable access logging so the next review can show which permissions were actually exercised, and check for unused permissions after 30 days.
3. The company wants to prevent a repeat of the leaked-key incident. Which controls address root cause rather than symptom?
Read the worked answer
Rotating the key is the symptom fix. Root-cause controls are: (1) eliminate long-lived static credentials in favor of short-lived role-based credentials assumed by workloads, so there is no key to commit; (2) add automated secret scanning in CI that blocks merges containing credential patterns; (3) enforce MFA on privileged identities and remove root access keys entirely; (4) add anomaly detection and alerting on credential use from new geographies or unusual API patterns, so exposure is caught in hours, not months. The judgement point is that a policy saying "do not commit secrets" is not a control - the control is the pipeline gate plus the removal of the secret's existence. Each of these should be mapped to the compliance framework's access-control and monitoring requirements so the 45-day review has evidence, not promises.