Cloud Security for Startups: IAM, Buckets and the Mistakes Everyone Makes First

When a startup's cloud account gets compromised, the story is rarely a clever attack. It is a root credential in a repository, a storage bucket set to public "just for the demo", or a key created two years ago by someone who no longer works there. Cloud providers publish a shared responsibility model for exactly this reason: they secure the data centre, the hardware and the underlying services; you secure what you build on top and, above all, who can do what in your account.

That "who can do what" is called IAM — identity and access management — and it is where almost all cloud security lives. Here are the mistakes I see first at nearly every early-stage company, on AWS, Google Cloud and Azure alike, and what to do instead.

Mistake 1: using the root account for daily work

Every cloud account has a root or owner identity that can do anything, including delete the account. It should be used exactly once — to create the first administrator — and then locked away.

Fix: put a hardware security key or authenticator app on the root account, store its password in the company password manager with restricted access, and never use it again. Create individual user identities for people (ideally through single sign-on with your Google Workspace or Microsoft 365) and give the administrators their own role. If you see root logins in your audit log, something is wrong.

Mistake 2: long-lived access keys everywhere

Access keys are passwords for programs. They end up in .env files, CI configuration, laptops, chat messages and — far too often — in a public code repository, where automated scanners find them within minutes of a push. Leaked keys are the most common route to the surprise cloud bill and the exfiltrated database.

Fix:

• Prefer roles over keys. Servers, containers and serverless functions can be given an identity by the platform; no key needs to exist.
• For CI/CD, use the provider's short-lived credential exchange (OIDC federation) rather than a stored key.
• Where a key is genuinely unavoidable, give it the narrowest possible permissions, rotate it on a schedule, and add a secret scanner to your repositories so a leaked key is caught before it is pushed.
• Turn on the provider's own leaked-credential detection and billing alerts. A cost alarm at twice your normal spend has caught more crypto-mining compromises than any intrusion system.

Mistake 3: "AdministratorAccess" for everything

The quickest way to make a deployment work is to give it every permission. Then it stays that way. When that service is compromised, the attacker has every permission too.

Fix: the principle of least privilege. Each identity — human or machine — gets only the permissions it needs to do its job. Start from the provider's managed read-only or task-specific policies and add rather than subtract. Review who has admin quarterly; the list should be short and everyone on it should be able to say why.

Mistake 4: public storage buckets

Object storage (S3, Cloud Storage, Blob Storage) is where files live, and it has been the source of a decade of headline breaches for one reason: a bucket that was made public. Sometimes deliberately for a website, sometimes accidentally for a test, and then forgotten while customer records were uploaded to it.

Fix:

• Turn on the account-wide block public access setting. All three major providers have one. Then make exceptions only for buckets that genuinely serve public content, and put those behind a CDN rather than exposing the bucket directly.
• Enable encryption at rest by default (it is one checkbox) and versioning on buckets that hold anything you would hate to lose.
• Run the provider's storage-permissions audit — Access Analyzer on AWS, the equivalent on the others — and read the output.

Mistake 5: no logging, no alerts, no idea

Cloud platforms will record every API call, every login and every configuration change. Most startups never turn it on, and discover a breach only when a customer or a bill tells them.

Fix: enable the audit log (CloudTrail, Cloud Audit Logs, Activity Log) for the whole organisation, send it to a bucket in a separate account that ordinary admins cannot delete from, and keep it for at least a year. Then set five alerts:

1. Root or owner account login.
2. A new administrator or a change to an IAM policy.
3. A security group or firewall rule opened to the world.
4. Logging turned off.
5. Spend above a threshold.

That is an afternoon of work and it is the difference between finding out in an hour and finding out in a quarter.

The next five, once the first five are done

• Separate accounts for production and everything else. A mistake in a test environment should not be able to touch customer data. The providers' organisation features make this cheap.
• Network defaults. Databases and internal services should not have public IP addresses. Put them in private subnets and reach them through a bastion or a VPN.
• Secrets in a secrets manager, not in environment files copied between machines.
• Patching as a routine. Managed services patch themselves; virtual machines do not. If you run VMs, you own their updates.
• Backups with immutability, in a second region — see the backups post for the full rule.

A note on the shared responsibility model

It is worth reading your provider's version once, because it decides what you are on the hook for. The short version: they are responsible for the security of the cloud; you are responsible for security in the cloud — your identities, your data, your configuration, your code. When something goes wrong in the second column, the provider's incident is that they will send you a very polite email.

None of the fixes above require a security team or expensive tooling; every one is a setting or a habit. Do the first five this month. They are the same five that, unfixed, will be in the post-mortem.