Securing a Cloud Estate You Didn't Build

You just got handed the keys to a cloud account that's been growing untended for three years. Nobody left documentation. IAM has 40 roles with wildcard permissions, there are S3 buckets nobody remembers creating, and the last person who understood the network topology left the company in 2022. This is more common than most job postings admit, and the first month sets the tone for everything after.

Get an inventory before you touch anything

Resist the urge to start locking things down immediately. You need a map first. Run aws resourcegroupstaggingapi get-resources across every region, not just us-east-1 — teams love spinning up test resources in ap-southeast-2 and forgetting about them. Pair that with AWS Config if it's already enabled, or turn it on now if it isn't. On Azure, az resource list --output table piped into a spreadsheet works fine for a first pass. On GCP, Cloud Asset Inventory's gcloud asset search-all-resources gives you the same view.

Cross-reference against billing. Anything costing money should show up in your resource inventory; anything in the inventory with zero recent activity is a candidate for archival. Discrepancies here are usually where the scary stuff hides — orphaned EC2 instances with public IPs, forgotten RDS snapshots sitting unencrypted, load balancers pointing at nothing.

Audit IAM like it's a crime scene

Pull every IAM policy and look for "Action": "*" combined with "Resource": "*". That combination should not exist outside of a handful of break-glass admin roles, and even those should have MFA enforcement and CloudTrail alerting attached. Use IAM Access Analyzer to find roles that grant access to external accounts — this catches both intentional cross-account trust relationships and mistakes from someone testing a Terraform module against the wrong account ID.

Check access keys older than 90 days with aws iam generate-credential-report. Inherited estates almost always have long-lived keys attached to service accounts, sometimes hardcoded in a Lambda environment variable or a Jenkins job. Rotate them, but stage it — killing a key that a nightly batch job depends on at 2 AM is how you get paged during your first week.

Find the public exposure before an attacker does

Run a network reachability check across your VPCs. Security groups with 0.0.0.0/0 on anything other than 80/443 need justification, not assumption. Tools like ScoutSuite or Prowler will chew through an account in minutes and spit out a report ranked by severity — start there instead of building your own checklist from scratch.

S3 buckets deserve special attention because they're the classic inherited-estate landmine. Check both bucket policies and account-level Block Public Access settings; someone may have disabled the account default years ago for a one-off static site and never turned it back on. aws s3api list-buckets combined with a loop checking get-bucket-acl and get-bucket-policy-status on each one gives you a clean picture in under ten minutes for most accounts.

Establish logging before you establish trust

If CloudTrail, VPC Flow Logs, or GuardDuty aren't already running everywhere, turn them on now, before you make any other changes. You want a record of what happens from this point forward, and you want it before you start deleting things, because deletion is exactly when mistakes get made and blamed on the new person. Ship logs to a separate account or subscription if at all possible, so a compromised workload can't also erase its own evidence.

Set up GuardDuty or Azure Defender for Cloud with alerting routed somewhere a human actually checks — not a Slack channel with 400 unread messages. The value of detection tooling is close to zero if the alerts land in a void.

Fix the loudest problems first, document everything

You won't fix an inherited estate in a sprint. Triage by blast radius: public data exposure first, then overprivileged identities, then network segmentation, then everything else. Write down what you find and what you changed, even in a plain Google Doc, because the next person who inherits this from you deserves better than what you got.

Expect pushback when you tighten a security group and a dev's integration test starts failing. That's normal — it means the audit is working. Talk to the team that owns the workload before you flip anything in production, and keep a rollback plan ready for the first two weeks.

For more on the tools and reasoning behind cloud audits, check out Korra Studio's segments on IAM hardening and cloud detection engineering — both pair well with the workflow above.