Multi-Cloud Guardrails at CloudScribe
CloudScribe is a SaaS provider running 280 AWS accounts and Azure subscriptions across two business units. It has 2,000 IAM roles and no central cloud security posture management. Twelve S3 buckets are publicly readable, even though a policy says public access is prohibited. A developer committed an API key to a public GitHub repository; four hours later, unauthorized EC2 instances were launched in a production account. CloudTrail is enabled per account but logs are not centralized, and the security team has no detection for IAM changes. The CISO wants a landing zone and guardrails, but engineering argues that central controls will slow delivery. The board wants a 90-day plan to prevent a repeat. There is no formal cloud incident response runbook.
1. Design an account structure and preventive guardrails for CloudScribe's AWS and Azure environments.
Read the worked answer
Use a multi-account landing zone with organizational units, service control policies, and centralized logging.
- Structure: Separate accounts for security (log archive, SIEM), shared services (networking, identity), production, non-production, and sandbox. Group under OUs by environment and data sensitivity. 280 accounts is too many to manage individually; consolidate where possible.
- Guardrails: AWS SCPs/Azure Policy to deny public S3 blobs, prohibit root account use, enforce encryption, and block unapproved regions. Use AWS Config/Azure Policy for detective controls.
- Centralized logging: Enable CloudTrail/Azure Activity Log to an immutable log archive account; alert on IAM changes and public bucket creation.
- Landing zone: Use Control Tower or equivalent to automate account vending with baseline controls.
Reasoning: The exposed key and public buckets show missing guardrails. Preventive controls stop the mistake; detective controls catch it fast.
2. How should CloudScribe enforce least privilege across 2,000 IAM roles in a multi-cloud environment?
Read the worked answer
Centralize identity and enforce least privilege through roles, permissions boundaries, and regular access reviews.
- Federate: Use an enterprise IdP (Okta/Entra) for AWS IAM Identity Center and Azure Entra ID; no long-lived IAM users. 2,000 roles is a symptom of role sprawl - consolidate using attribute-based access control (ABAC) where possible.
- Permissions boundaries: In AWS, use permissions boundaries to cap maximum privileges; in Azure, use Azure Policy and PIM for just-in-time role activation.
- Access reviews: Quarterly review of privileged roles and unused permissions. Automate removal of unused roles after 90 days.
- Guardrails: Deny creation of access keys; require MFA for privileged actions.
Reasoning: Least privilege at scale requires automation and federation, not manual IAM user management. Role sprawl increases the chance of an over-privileged identity.
3. Outline the incident response steps for the exposed API key and unauthorized EC2 instances.
Read the worked answer
Treat as a confirmed credential exposure: contain, investigate, eradicate, recover, and learn.
- Contain (first hour): Disable the exposed access key; revoke sessions; isolate the account or apply a deny-all SCP if unauthorized resources are found. Preserve logs.
- Investigate: Use CloudTrail to identify all API calls made with the key, including the unauthorized EC2 launches. Determine what data was accessed and whether persistence (new IAM users, roles) was created.
- Eradicate: Terminate unauthorized resources; rotate all related secrets; scan GitHub history and other repos for the key.
- Recover: Restore from known-good state if needed; validate no backdoors.
- Learn: Add secret scanning to CI/CD, pre-commit hooks, and automated revocation. Update the IR playbook.
Reasoning: A leaked key is a breach until proven otherwise; speed of containment limits blast radius. Four hours is enough for an attacker to launch resources and create persistence.