Common Cloud Misconfigurations

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Cloud breaches are rarely the result of a clever attack on the cloud provider’s infrastructure. Overwhelmingly, they are the result of the customer configuring something wrong — an exposed data store, an over-permissioned identity, a setting left open. The cloud gives you enormous power to configure resources through software, and that same power makes it easy to configure them insecurely. This page is the catalogue of what goes wrong, and the discipline of preventing it.

Part 1: The Problem

Page 5C.1 established the shared responsibility model: the cloud provider secures the underlying infrastructure to a high standard, and the customer secures their own configuration, identity, data, and access. It also stated the consequence bluntly — the customer’s side is where cloud breaches happen.

Now we get specific. How exactly does the customer side go wrong? The answer, in the overwhelming majority of cases, is cloud misconfiguration: a cloud resource set up insecurely. Not a sophisticated exploit, not a zero-day — a setting left open, a permission too broad, a data store exposed.

You already met this idea in 2.9 (Security Misconfiguration) — the OWASP category of insecurity-by-setup. In the cloud, misconfiguration is not just a category of risk; it is the dominant one. This page is the cloud-specific deep dive: the common misconfigurations, why they happen so much, and how to prevent them.

Part 2: The Concept — Why Cloud Misconfiguration Is So Common

Before the catalogue, understand why cloud misconfiguration is so pervasive — because the causes point to the cures.

• Everything is configured through software. In the cloud, every resource has configuration — often a lot of it. The power to configure anything through software is also the power to *mis*configure anything. There is simply far more configuration surface than in a traditional environment.
• Defaults are not always secure. Cloud services have default settings, and those defaults are not always the most secure option (the 2.9 lesson — insecure defaults). A resource created without careful configuration may be insecure by default.
• Speed and scale. The cloud is built for rapid, large-scale creation of resources. Things get created fast, by many people, often under pressure — and “configure it properly later” frequently never happens (again, the 2.9 dynamic).
• Complexity. Cloud environments are large and intricate — many services, many resources, many permissions, many interconnections. Complexity breeds mistakes (the recurring 2.9 / 3.5 lesson). It is genuinely hard to keep a complex cloud environment fully, correctly configured.
• Knowledge gaps. Cloud platforms are deep and evolve constantly. People configure services they do not fully understand the security implications of.
• Drift. Cloud environments change constantly (5C.1); a correctly-configured resource can drift into an insecure state as things around it change (the configuration drift idea from 4.4).

The takeaway: cloud misconfiguration is not a sign of careless individuals — it is a structural consequence of how the cloud works. Which means the cure is not “be more careful”; it is systematic, automated prevention (Parts 5 and 6, and the DevSecOps half of this track).

Part 3: The Concept — Exposed Storage and Data

The most notorious category of cloud misconfiguration — responsible for a great many well-known cloud data breaches — is exposed storage.

Cloud providers offer storage services — places to store files, data, backups. These are enormously useful and heavily used. They are also, misconfigured, a leading cause of breaches.

The classic failure: a cloud storage resource that should be private — accessible only to specific authorized identities — is instead configured so that it is publicly accessible to anyone on the internet. The data inside — which may be sensitive customer data, internal files, backups, secrets — is then readable by anyone who finds it. And attackers actively scan for exposed cloud storage; finding it requires no skill, just looking.

Related data-exposure misconfigurations:

• Storage exposed more broadly than intended — not necessarily fully public, but accessible to far more identities than it should be.
• Unencrypted data — sensitive data stored without encryption (recall encryption at rest, 1.3) — so that any exposure is immediately a full data leak.
• Databases and data services exposed — cloud databases or data services configured to be reachable when they should be tightly restricted (the cloud version of the exposed-database problem from 3.2).
• Backups left exposed — backups are data too, and an exposed backup is an exposed copy of everything.

The principle running through all of it: data is the crown jewel, and in the cloud the most common way it is lost is through a storage or data resource configured to be more accessible than it should be. The defense is disciplined: data resources private by default, access restricted to the specific identities that genuinely need it (least privilege, identity-based — 5C.1), and sensitive data encrypted.

Part 4: The Concept — Identity and Access Misconfigurations

The other dominant category — flowing directly from 5C.1’s “identity is the new perimeter” — is identity and access misconfiguration. If identity is the primary security boundary, then misconfigured identity is the primary way that boundary fails.

The common identity/access misconfigurations:

Over-permissioned identities. The biggest one. An identity — a user, or a service/machine identity — granted far more permissions than it needs. This violates least privilege (5C.1, and the principle since 0.2), and the consequence is severe: if that identity is ever compromised, the attacker inherits all its excessive permissions. An over-permissioned identity turns a small compromise into a large one. (This is the cloud, identity-level version of the privilege-escalation lesson from 3.4 — except here the excessive privilege was simply granted, not escalated to.)

Overly broad access policies. Access rules written too permissively — granting access to more resources, or more actions, or more identities than intended. The cloud’s access-policy systems are powerful and detailed; written carelessly, they grant far too much.

Weak authentication on cloud accounts. Cloud accounts — especially powerful administrative ones — without strong authentication and MFA (1.4, 4.2). A compromised cloud admin account can mean compromise of the entire environment.

Unused and forgotten identities. Identities (especially old user accounts, or service identities for things no longer used) left active. Each is an unnecessary, often unmonitored, way in (the attack-surface and unused-account lesson from 4.4).

Exposed credentials and keys. Cloud access credentials and keys — the things that authenticate identities — leaked or exposed: hard-coded in code, committed to repositories (the leaked-secrets finding from 2.1, 2.10, 4.2), or otherwise mishandled. An exposed credential is a handed-over identity.

Excessive use of highly-privileged identities. Using powerful administrative identities for routine work, rather than reserving them and using minimally-privileged identities for everyday tasks (the “don’t operate as root” lesson from 0.2, at cloud scale).

The defense for all of it is identity discipline built on least privilege: every identity (human and machine) granted the minimum permissions needed; access policies written tightly; strong authentication and MFA, especially on privileged accounts; unused identities removed; credentials managed properly and never exposed.

Part 5: The Concept — The Other Misconfigurations, and a Unifying View

Beyond exposed data and identity issues, cloud misconfiguration spans more ground. The other notable categories — and then the unifying principle:

Network misconfigurations. Even though identity is the new perimeter, cloud environments still have network-level controls — virtual networks, and firewall-like rules controlling what can reach what. Misconfigured, these expose resources that should be restricted: a resource open to the whole internet when it should be reachable only internally (the cloud version of 3.2’s improper exposure and 4.4’s firewall discipline).

Logging and monitoring not enabled. Cloud providers offer logging and monitoring capabilities — but they are not always on by default, or not configured comprehensively. A cloud environment without proper logging is one where attacks cannot be detected (the entire 4.6 lesson — “an attack you cannot see is an attack you cannot stop” — and you cannot configure detection on logs that were never enabled).

Insecure service-specific settings. The cloud has a vast array of services, and each has its own security-relevant configuration. Misconfiguring any of them — leaving a service’s settings in an insecure state — creates risk. There is no shortcut around this: each service used must be configured securely.

Unencrypted data and traffic. Beyond exposed storage (Part 3), encryption — of data at rest and in transit (1.3) — is something the customer must configure, and failing to is a misconfiguration.

The unifying view. Step back, and every category here — exposed data, identity issues, network exposure, missing logging, insecure settings — is the same root pattern you learned in 2.9: insecure by setup. The cloud did not invent misconfiguration; it amplified it, because the cloud is configured entirely through software, at speed, at scale, in complex environments. Cloud security, in large part, is the discipline of getting and keeping configuration right. Which is why the cure (Part 6) is systematic and automated, not manual and hopeful.

Part 6: The Concept — Preventing Cloud Misconfiguration

Knowing what goes wrong is half of it; preventing it is the rest. Because cloud misconfiguration is structural (Part 2), the defenses must be systematic.

Secure configuration discipline. Configure resources securely deliberately, not by accepting defaults: data private, identities least-privileged, access tight, encryption on, logging on, network access restricted. This is the cloud version of hardening (4.4).

Use security baselines and benchmarks. Just as 4.4 used recognized hardening baselines, the cloud has recognized secure-configuration benchmarks for cloud environments. Configure against a benchmark rather than improvising — it makes secure configuration thorough and consistent.

Cloud security posture scanning. There are tools — broadly, cloud security posture management — that automatically and continuously scan a cloud environment for misconfigurations and flag them. This is essential: because cloud environments are large, complex, and constantly changing (drift), continuous automated scanning is the only realistic way to find misconfigurations across the whole environment. This is the cloud equivalent of the vulnerability scanning from 4.8 — turned toward configuration.

Continuous monitoring for drift. Because environments drift (Part 2), misconfiguration detection cannot be one-time. It must be continuous — catching the resource that became insecure as things changed.

Least privilege, relentlessly. Given how central over-permissioning is (Part 4), least privilege applied relentlessly to every identity is one of the highest-value preventive measures.

Prevent misconfiguration at the source — the DevSecOps move. The most powerful prevention: rather than creating cloud resources and then scanning them for misconfiguration, define cloud infrastructure as code (5C.4) and check that code for misconfiguration before the resources are ever created. This is “shift left” (5B.1) applied to cloud configuration — and it is exactly what 5C.4 (Infrastructure as Code security) and 5C.5 (DevSecOps pipelines) build. The best fix for misconfiguration is to never deploy it.

🔑 The deep lesson: cloud breaches are overwhelmingly customer-side misconfiguration — exposed storage and data, over-permissioned identities, network exposure, missing logging, insecure settings. It is the 2.9 “insecure by setup” pattern, amplified because the cloud is configured through software at speed, scale, and complexity. Because the cause is structural, the cure is structural: secure-configuration discipline against benchmarks, continuous automated posture scanning to find misconfiguration across the whole environment, relentless least privilege — and, best of all, preventing misconfiguration at the source by checking infrastructure-as-code before it deploys.

📓 Key Terms

🧪 Hands-On Lab

Use your free-tier cloud account from 5C.1. Create, examine, and secure resources you own — never test cloud resources you do not own.

Task 1 — Examine storage configuration. In your cloud account, create a storage resource. Examine its access configuration carefully — what determines whether it is private or public? Configure it correctly as private, accessible only to a specific identity. Understand exactly how the exposed-storage breach happens — and how to prevent it.

Task 2 — Practice identity least privilege. Create an identity that needs to do one specific thing. Configure its permissions to allow only that — the minimum. Then look at how easy it would be to instead grant broad permissions, and reflect on why over-permissioning is so common.

Task 3 — Examine an access policy. Look at how access policies work in your cloud environment. Write a tightly-scoped one and a deliberately over-broad one. See concretely how an access policy can grant far more than intended.

Task 4 — Check network configuration. Create a resource and examine its network access configuration. Configure it so it is reachable only as intended — not open to the whole internet. The cloud version of firewall discipline (4.4).

Task 5 — Enable logging. Find the logging and monitoring capabilities in your cloud account. Enable logging for your resources. Note that it was not necessarily on by default — and connect this to 4.6 (no logs, no detection).

Task 6 — Run a posture scan. Use a cloud security posture / misconfiguration scanning tool (free/open-source options exist) against your own cloud environment. Read what it flags. This is the cloud equivalent of vulnerability scanning — turned toward configuration.

Task 7 — Study a benchmark. Find a recognized cloud security benchmark for your provider. Walk a section of it against your environment. See how systematic, recognized secure configuration compares to ad-hoc configuration.

Task 8 — Write a cloud misconfiguration note. In Notion, create a “Cloud Misconfigurations” page — why misconfiguration is so common, the main categories (exposed data, identity, network, logging, settings), and how to prevent it. Reference material for the track.

⚠️ Common Mistakes

• Accepting defaults. Cloud service defaults are not always secure. Configure deliberately and securely; do not assume the default is safe.
• Leaving storage exposed. Exposed cloud storage is a leading breach cause. Data resources private by default; access restricted to specific identities.
• Over-permissioning identities. Granting more permissions than needed turns any compromise into a large one. Relentless least privilege on every identity, human and machine.
• Writing over-broad access policies. Powerful policy systems, written carelessly, grant far too much. Scope policies tightly.
• Not enabling logging. Cloud logging is not always on by default. Without it, attacks cannot be detected (4.6). Enable it.
• Treating misconfiguration as a one-time fix. Environments drift constantly. Misconfiguration detection must be continuous — automated posture scanning.
• Manual, hopeful configuration. Cloud environments are too large and complex for “be careful” to work. Prevention must be systematic — benchmarks, scanning, and ideally checking infrastructure-as-code before deployment (5C.4).

✅ Recap & What’s Next

• Cloud breaches are overwhelmingly customer-side misconfiguration — the 2.9 “insecure by setup” pattern, amplified by software-defined configuration at speed, scale, and complexity.
• The dominant categories: exposed storage and data, over-permissioned identities and weak access, plus network exposure, missing logging, and insecure service settings.
• Because the cause is structural, the cure is structural — secure-configuration discipline against benchmarks, continuous automated posture scanning, relentless least privilege, and best of all, preventing misconfiguration at the source (5C.4).

Next (5C.3): Cloud environments do not just store data — they run things, increasingly in containers and orchestrated by Kubernetes. Page 5C.3 secures that layer — and connects directly to the container content of your On-Prem/DevOps module.