Most cloud data breaches do not look like a break-in. There is no smashed window, no alarm bell, no stranger in the lobby. There is a storage bucket that stayed public after a rushed migration, an access key pasted into a script two years ago, a contractor account nobody remembered to close. The doors get opened from the inside, usually by people moving fast with the best intentions. The same handful of mistakes shows up in incident review after incident review, and every one of them has a fix you can start on this week.
1. Storage Buckets Left Open or Misconfigured
Object storage is where most cloud leaks begin, because making a bucket public takes one click and noticing that it is public takes a habit. The usual variations: a bucket policy that allows Principal: "*", legacy access control lists nobody has reviewed, static website hosting switched on for a bucket that also holds customer files, and listing enabled so anyone who guesses the name can browse the contents. Bucket names are easy to guess — company name, environment, "backups" — which makes an open bucket closer to publishing data than hiding it.
A separate problem is the presigned link. Someone generates one to share a file with a partner, sets the expiry to "never" for convenience, and never revokes it. The link outlives the project, the partnership, and sometimes the employee who created it.
- Switch on Block Public Access at the account or organisation level, then treat every exception as a documented decision with a named owner.
- Turn on default encryption and access logging for every bucket, including the ones your automation creates.
- Set short expiries on presigned URLs and review them the way you would review any other credential.
- Use infrastructure-as-code checks or a cloud security posture tool to catch drift, because manual settings decay quietly.
2. Identities With Far More Permission Than They Need
Wildcard permissions are convenient during a build and dangerous forever after. A role with Action: "*" on Resource: "*" can delete backups, read every database, and quietly create new admin users. It takes one compromised application, one leaked token, or one careless script to turn that role into a full breach.
Start from deny-by-default and add permissions per action and per resource. Give each workload its own role instead of sharing one across four services. Most providers now show which permissions an identity actually used, so you can strip out the ones that have gone untouched for months. Take standing admin rights away from humans and use just-in-time elevation instead: request it, use it, lose it.
3. Credentials That Never Expire
Long-lived access keys are the quietest risk in any cloud account. They end up in Git history, build logs, chat messages, container images, and on laptops that leave the building. Because they still work, nobody looks at them.
Where the platform allows it, replace keys with short-lived credentials issued to a role — instance profiles, workload identity federation, or your CI provider's native integration. Where a key genuinely cannot be removed, store it in a secrets manager rather than a config file, give it a narrow scope, rotate it on a schedule, and alert when a dormant key is suddenly used. Scan repositories and images for key patterns inside your pipeline; the scan that catches a key before it merges is worth ten that find it afterwards.
4. Audit Logs That Nobody Reads
Plenty of teams have logging switched on and nothing else. The logs sit in the same account as the workloads, with a retention window short enough to be useless by the time anyone investigates, and an intruder with admin rights can simply turn logging off.
Send audit logs from every account to a separate, tightly controlled account that workload admins cannot modify, and set retention to match your obligations. Then build a short list of alerts for the events that matter: a new identity created with admin rights, a policy changed to allow public access, logging disabled, an unusual spike in data egress, a sudden burst of object downloads. Data leaving your cloud costs money, and that bill is often the first honest signal of exfiltration.
5. The Human Layer: Accounts, MFA and Offboarding
Most cloud credentials are used by people, and people get phished. An account without multi-factor authentication, a shared login on a team wiki, a service account that somehow has console access — each is a way in that has nothing to do with your network configuration.
- Enforce MFA for everyone, and use hardware keys for administrators.
- Use single sign-on so that disabling one account closes every door at once.
- Automate offboarding: when someone leaves or changes team, their access goes the same day.
- Review access quarterly, with attention to contractors, vendors, and anyone holding a personal token.
6. Shadow Data and Unreviewed Third Parties
Data rarely stays where it was designed to live. A team exports a customer list to a spreadsheet on a personal drive, copies production records into a test environment, or hands a vendor a key with broad scope. None of that feels like a breach. All of it widens the blast radius.
Map where copies of sensitive data exist, and limit what can be moved into non-production environments — masked or synthetic data is usually enough for testing. Review the third-party apps your staff have connected through single sign-on and revoke the ones with broad scopes that nobody uses. When contracts, data processing terms, or breach notification duties are in play, bring in legal or compliance advice early: the technical fix is often simple, and the obligations around it are not.
A Practical Starting Point
You do not need a twelve-month programme to cut risk meaningfully. You need to close the obvious doors first.
- Turn on account-level Block Public Access and audit every existing bucket for public policies.
- List every identity holding admin or wildcard permissions, then cut the list down.
- Replace long-lived keys with short-lived roles wherever the platform supports it, and rotate the rest.
- Centralise audit logs in a locked account and alert on policy changes and logging being disabled.
- Enforce MFA, then automate offboarding so access disappears when someone does.
Pick one item and finish it before starting the next. Cloud breaches are rarely clever; they are usually one setting that nobody owned. Give it an owner, check it on a schedule, and most of the risk goes away.
Photo: 12019 / Pixabay
