Cloud incidents are rarely clever. More often, someone left a door open: a storage bucket readable by anyone, a database reachable from the whole internet, an administrator role handed out because it made a deployment error disappear. The platforms are generally solid. The settings around them are where teams get hurt.

This guide walks through the misconfigurations that show up again and again, and how to find them before somebody else does.

Why Misconfiguration Is So Common

Cloud makes creating resources trivially easy and makes undoing exposure no easier. Defaults change over time, console wizards hide options, and infrastructure gets copied from old examples. Add deadline pressure, and “just open it up so it works” becomes the path of least resistance. The mistake is usually small and made once; it persists because nothing reminds anyone to revisit it.

The Usual Suspects

Public or overly open storage. Object storage and file shares set to public access, or shared via links that never expire. Look for any storage that serves content to anonymous users and ask whether that was deliberate.

Wide-open network rules. Security groups or firewall rules that allow administrative ports, databases or internal services from anywhere. Remote management ports reachable from the whole internet are a frequent entry point.

Excessive permissions. Roles with broad administrative rights granted to people, applications or automation that needed only a narrow capability.

Credentials in the wrong places. Access keys in source repositories, in container images, or in documents. Long-lived keys that nobody rotates.

Missing logging. Audit logs turned off or not retained, which means you cannot reconstruct what happened later.

No multi-factor authentication on privileged accounts. Especially the account that owns the whole cloud subscription.

Forgotten resources. Old test environments, snapshots and unattached disks that still hold real data and sit outside anyone’s patching or review.

Unencrypted data stores. Encryption options that were available but never switched on, or key management left as an afterthought.

A Review Table You Can Reuse

Area	Question to ask	Evidence to collect
Storage	Is anything readable without authentication?	Public-access settings per bucket or share
Network	Which ports are open to all addresses?	Exported firewall or security group rules
Identity	Who holds administrative roles?	Role assignments, last-used dates
Keys	Which long-lived credentials exist?	Key list with age and owner
Logging	Are audit logs on, centralized and retained?	Log configuration per account
MFA	Do all privileged users require it?	Policy settings and user report
Data	Is stored data encrypted?	Encryption settings per data store
Inventory	What exists that nobody owns?	Resources lacking an owner tag

Run this as a recurring checklist rather than a one-time cleanup. Cloud environments change daily.

A Hypothetical Example

A small team builds a prototype and creates a storage bucket for file uploads. To avoid permission errors during the demo, a developer sets it to public. The demo succeeds. The prototype evolves into a real product, uploads begin to include customer documents, and the bucket’s setting is never revisited.

Nothing about this required a skilled attacker. Automated scanners continuously look for openly readable storage. The fix is simple: block public access at the account level, serve legitimate public files through a content delivery setup you control, and give the application a narrowly scoped role to read and write only what it needs.

Put Guardrails Ahead of Reviews

Reviews catch problems after they exist. Guardrails stop many from existing at all:

• Account-level controls that prevent public storage access unless explicitly overridden.
• Policy-as-code or built-in policy services that reject or flag non-compliant resources at creation.
• Infrastructure as code with peer review, so settings are visible in a change request instead of buried in a console.
• Separate accounts or projects for production and experimentation, so test sloppiness can’t reach real data.
• Mandatory tags, especially owner, so every resource has someone to ask.

Most major providers offer a posture-assessment feature that scans for these issues. Check your provider’s current documentation for what is available and how it is configured; the specifics change often.

Triage What You Find

Expect a long list the first time. Don’t try to fix everything at once. Order by exposure and impact:

1. Anything exposing sensitive data to the internet
2. Privileged accounts without MFA
3. Overbroad roles and long-lived credentials
4. Missing logging
5. Hygiene items such as untagged resources

If you find something that might already have been exposed, treat it as a possible incident rather than a cleanup task: preserve logs, check access history, and follow your response plan.

Frequently Asked Questions

Is cloud less secure than on-premises? Not inherently. The provider secures the underlying platform, while you secure configuration, identities and data. Most cloud breaches trace back to the customer-controlled side.

What is the first thing to check in a new cloud account? Enable MFA on the root or owner account, turn on audit logging, and block public storage access. Those three steps close a large share of common exposure.

How often should we review configurations? Continuously through automated checks if possible, plus a deliberate manual review on a regular schedule such as quarterly.

Do we need a paid security tool? Start with the native posture and policy features of your provider. Consider third-party tools when you run multiple clouds or outgrow native reporting.

Who is responsible when something is misconfigured? Under the shared responsibility model, configuration of your resources is generally yours. Read your provider’s documentation on where the line sits.

Next Step

Pick one cloud account and run the table above against it this week, starting with a list of every storage location that allows anonymous access. Fix the first item you find before you look for the second.