Skip to content

Intermediate · Cloud security basics · topic 30 of 43 · 35 min

Common cloud misconfigurations

Explanation

Most cloud breaches come from settings, not clever hacking: storage open to the public, management ports open to the whole internet, unencrypted disks and snapshots, logging turned off, and secrets left in places anyone can read. Cloud security posture management (CSPM) tools scan accounts for these mistakes automatically.

Why misconfigurations dominate

Cloud makes it easy to create things in seconds, often by people who are not security experts. One wrong click can make data public to the world. Attackers run automated scans of the whole internet that find open storage and open ports within hours.

The usual suspects

MisconfigurationWhy it is dangerousFix
Public storage bucket or blob containerAnyone with the URL, or a scanner, can list and download filesBlock public access at account level; share files with short-lived signed links
Security group / network rule allowing 0.0.0.0/0 on SSH, RDP or databasesBrute force and exploits from the whole internetAllow only specific IPs, use a VPN, bastion or the provider's session manager
Unencrypted disks, databases or snapshotsA copied snapshot leaks everythingTurn on encryption at rest (usually one setting, often default now)
Public snapshots or machine imagesOthers can copy your disksKeep them private; audit sharing
Logging disabledNo evidence after an incidentTurn on audit logs in every account and region
Secrets in VM user data, environment files or codeAnyone with read access gets the keysUse a secrets manager
Old instance metadata settingsAn SSRF bug in an app can steal the server's cloud credentialsOn AWS, require IMDSv2 (session-based metadata)
Default passwords on managed services or dashboardsEasy takeoverChange on creation; use SSO

Public buckets in detail

Object storage (AWS S3 buckets, Azure Blob containers, Google Cloud Storage buckets) holds files. It can be made public through access settings or policies. Since April 2023, AWS turns on S3 Block Public Access and disables ACLs by default for new buckets, which helps, but older buckets and deliberate changes still cause leaks.

bash
$ aws s3api get-public-access-block --bucket invoices-bucket
{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}
All four settings true: this bucket cannot be made public by mistake.

Infrastructure as code and scanning

Many teams define cloud resources in code (Terraform, CloudFormation, Bicep). That lets security checks run before anything is created. CSPM (cloud security posture management) tools, built into providers (like AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center) or from vendors, scan live accounts and list misconfigurations against benchmarks such as the CIS Benchmarks.

python
buckets = [
    {"name": "invoices", "public": False, "encrypted": True},
    {"name": "test-upload", "public": True, "encrypted": False},
]
for b in buckets:
    problems = []
    if b["public"]:
        problems.append("PUBLIC")
    if not b["encrypted"]:
        problems.append("NOT ENCRYPTED")
    print(b["name"], problems or "ok")
A tiny posture check over exported settings. Shows invoices ok, then test-upload ['PUBLIC', 'NOT ENCRYPTED'].

Detection

  • Alert when a bucket policy or ACL changes to public.
  • Alert when a network rule opens a sensitive port to 0.0.0.0/0.
  • Alert when logging is stopped or deleted.
  • Watch for large downloads from storage by unusual identities or IPs.

Common mistakes

  • "Temporary" public access for testing that is never removed.
  • Fixing a finding by hand but not in the infrastructure code, so the next deployment brings it back.
  • Scanning only the main region; attackers use the regions nobody watches.
Tip: Turn on account-level guardrails (like S3 Block Public Access for the whole account, or organisation policies) so that one person's mistake cannot make data public.

Need help?

Stuck on a word or an idea? Search this course, or every course, and jump straight to the explanation or a worked question.

Try:

Watch the lesson

Common cloud misconfigurations · 1/7

Misconfiguration > hacking

Most cloud breaches come from settings, not clever hacking.

Prefer a video by a teacher? Find free videos on “common cloud security misconfigurations public S3 bucket security groups” on YouTube ↗

In real life: KYC documents in an open bucket

A lending app stored customers' Aadhaar and PAN card scans in a storage bucket. A developer made the bucket public to test an image viewer and forgot to undo it. A security researcher found it with a simple search and reported it responsibly. The company blocked public access at account level, moved to short-lived signed links for viewing documents, turned on alerts for any public bucket, and, as personal data was exposed, followed its breach reporting duties.

Practice (0/3 done)

Task 1 · Question

Which setting most directly prevents an S3 bucket from being made public by mistake?

Task 2 · Code · Python

Write findings(buckets) where each bucket is a dict with "name", "public" (bool), "encrypted" (bool) and "logging" (bool). Return a list of strings "NAME: PROBLEM" for every problem, in bucket order, with problems checked in this order: "public", "not encrypted", "no logging".

Task 3 · Practice

Create a free-tier account on one cloud provider (use MFA and a billing alert). Create a private storage bucket, confirm public access is blocked, try to open a file by its public URL (it should fail), then delete the bucket. Write down each setting you checked.

Quick quiz

Question 1

1.What does CSPM stand for?

Question 2

2.Why require IMDSv2 on AWS servers?

Question 3

3.A finding is fixed by hand in the console but returns after the next deployment. Why?

Question 4

4.Which is the best way to let a customer download one private document?

Question 5

5.Why should you scan all regions, not just the main one?

Read more (free)

Open a question to see the answer and why. The first ones are this topic's own quiz, so try the quiz above before you peek.

What does CSPM stand for?

Answer: Cloud security posture management

CSPM tools scan cloud accounts for risky settings.

Why require IMDSv2 on AWS servers?

Answer: It makes it much harder for an SSRF bug to steal the server's credentials

IMDSv2 needs a session token, which typical SSRF requests cannot get.

A finding is fixed by hand in the console but returns after the next deployment. Why?

Answer: The infrastructure code still has the bad setting

Fix the source (infrastructure as code), not just the live resource.

Which is the best way to let a customer download one private document?

Answer: A short-lived signed URL

Signed URLs give temporary access to one object only.

Why should you scan all regions, not just the main one?

Answer: Attackers and forgotten resources can be in regions nobody watches

Unused regions are a classic blind spot.

A company's storage bucket of invoices was left public and was downloaded by strangers. Whose responsibility was that setting?Related

Answer: The customer's

Bucket access settings are configuration, which is security IN the cloud.

From The shared responsibility model

Which bucket policy statement makes data public?Related

Answer: Allow, Principal "*", s3:GetObject, no Condition

Allow to Principal "*" without a limiting condition grants access to anyone on the internet.

From Securing and sharing S3 data

In every cloud model, who is responsible for the customer's data and user access?Related

Answer: The customer

Data and identities are always on the customer side.

From The shared responsibility model

Which service finds credit card numbers stored in S3 buckets?Related

Answer: Amazon Macie

Macie discovers and reports sensitive data in S3.

From Logging, threat detection and incident response

Pass the quiz (60% or more) or mark this topic as done when you are ready.

Your progress is saved on this device only.

Next steps

  1. 1 more topic in “Cloud security basics” before its exam: Logging and monitoring in the cloud.
  2. Module 7 exam: Cloud security basics · 12 questions · 20 min, without help. 4 topics of this module still to finish first.
  3. Then the next module, Governance, risk and compliance. 43 topics left in the course before the final exam.

← Previous: Cloud identity and access management