Cloud Misconfiguration Guide: Top Causes and Fixes

Many cloud data exposures are caused not by a clever exploit but by a setting someone changed, never changed, or did not know existed. An open bucket, a publicly shared snapshot, a security group admitting the internet to port 22, an access key left in a repository for years: each is a one-line error, and each has caused a public breach. This guide catalogues the misconfigurations that matter most across AWS, Microsoft Azure and Google Cloud, how to prevent them with organisation guardrails, infrastructure as code (IaC) scanning and policy as code, and how to detect the rest with posture management and drift detection. It is written for cloud security engineers, platform teams and architects; provider features are named only as documented examples.

Key takeaways

• Misconfiguration is the top-ranked cloud risk: the Cloud Security Alliance's Top Threats to Cloud Computing 2024 puts "misconfiguration and inadequate change control" first, ahead of identity and access management.
• The same short list recurs in breaches: public storage, snapshots and images, wildcard IAM, long-lived keys, open management ports, missing logs, unencrypted data, the old metadata service, broad shared links and default credentials.
• Prevent at the organisation layer first: AWS SCPs and RCPs, Azure Policy and Google Cloud organisation policy constraints stop the worst errors in every account, including ones nobody scans.
• Scan in the pipeline, confirm at runtime: IaC scanners catch errors before deployment; posture management and drift detection catch console changes and resources built outside code.
• Many misconfigurations are identity problems: static keys, wildcard permissions and instance credentials reachable through the metadata service turn one mistake into account-wide access.

Why cloud misconfiguration keeps causing breaches

NSA's Top Ten Cloud Security Mitigation Strategies (March 2024) states that "Many cloud breaches occur due to misconfigurations in cloud tenants." Under the shared responsibility model, every setting on a customer's storage, network rules, roles and keys is the customer's to get right.

• Self-service at speed: any engineer with API rights can create internet-facing resources in minutes, outside change control, which is why the CSA pairs misconfiguration with "inadequate change control".
• Defaults differ by service and age: newer storage blocks public access by default, older resources may not, and NSA notes that "Default logging policies vary greatly between cloud services".
• Expressive policy languages: one "Principal": "*" in a bucket policy or "Action": "*" on a role grants far more than intended.
• Sprawl and no owner: a control enabled in one region or account is absent in the next, and test resources outlive the people who built them.

The most common cloud misconfigurations

Default credentials on managed services and exposed Kubernetes dashboards complete the list; both are covered under network exposure below.

Storage, snapshots and shared links

Storage exposure leads directly to data loss (ATT&CK T1530 Data from Cloud Storage, often preceded by T1619 Cloud Storage Object Discovery).

• AWS S3: Block Public Access has four settings, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets, at organisation, account, bucket and access point level; the most restrictive combination wins. New buckets block public access by default, so the risk sits in older buckets and in teams that switch it off. Serve genuine public content through a CDN with origin access instead.
• Azure Blob Storage: set the account's AllowBlobPublicAccess property to false. If it is allowed, each container can be private, "Container" (anonymous listing and read) or "Blob" (anonymous read of blobs only). Before switching it off, Microsoft suggests querying StorageBlobLogs for AuthenticationType == "Anonymous" to find what still depends on it.
• Google Cloud Storage: enforce public access prevention and uniform bucket-level access, and use domain restricted sharing; Google notes that "By default, all user identities are allowed to be added to IAM policies."
• Snapshots and images: EBS block public access for snapshots is Regional. "Block all sharing" also makes already-public snapshots private; "block new sharing" leaves them public. It "does not prevent the public sharing of EBS-backed AMIs", so enable block public access for AMIs too, through an AWS Organizations declarative policy covering every account and Region. Images built from working servers carry keys and history files: build them from clean pipelines and scan for secrets.
• Write access matters too: the Twilio TaskRouter SDK Compromise 2020 came from a world-writable bucket serving JavaScript to customers.

SAS tokens and presigned URLs

Shared links are configuration, and they are credentials: AWS calls presigned URLs "bearer tokens that grant access to those who possess them."

In the Microsoft SAS Token Exposure 2023, one over-permissive account SAS link published in a public repository exposed 38TB of internal data. Add SAS strings and presigned URLs to secret scanning rules and prefer short, read-only, single-object links.

Where identity fits: keys, roles and the metadata service

The CSA ranks IAM second, and the two risks overlap: most cloud identity weaknesses are settings on non-human identities such as roles, service principals, service accounts and access keys.

• Wildcard and inherited permissions: flag policies granting * actions or resources, trust policies open to "Principal": "*" or whole external accounts, and default service accounts holding Editor (blocked by constraints/iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts). AWS IAM Access Analyzer reports unused roles, keys and permissions, the cheapest risk to remove. See the Cloud PAM and CIEM Guide.
• Long-lived access keys: static keys in code, images and .env files are a standing invitation (ATT&CK T1078.004 Cloud Accounts). The 230 Million AWS Cloud Environments Campaign 2024 harvested keys from exposed environment files, and in the Toyota T-Connect Key Exposure 2022 a key sat on public GitHub for five years. Move to roles, managed identities and workload identity federation, block key creation by policy, and alert on keys past your rotation limit. See the Cloud Workload Identity Guide and Secrets Management Guide.
• Instance metadata service: AWS instances accept IMDSv1 or IMDSv2 by default. IMDSv2 needs a session token from a PUT request, rejects token requests carrying X-Forwarded-For, and its default hop limit of 1 stops tokens being relayed through an extra network hop. Make "IMDSv2 only (token required)" the account default in each Region once no agent still uses v1, because enforcement breaks v1 clients. Azure and Google metadata endpoints require a Metadata: true or Metadata-Flavor: Google header. The Capital One Breach 2019 is the reference case: request forgery through a firewall returned role credentials that could read storage (T1552.005 Cloud Instance Metadata API).
• Keys left on hosts: the TeamTNT Worm 2020 stole AWS credential files from Docker hosts with an internet-facing API.

Network exposure, logging, encryption and defaults

Rules allowing 0.0.0.0/0 or ::/0 belong on ports 80 and 443 of a load balancer and almost nowhere else. Put the deny list in policy.

• Dashboards and consoles: the Tesla Kubernetes Cryptojacking 2018 began at an open Kubernetes console exposing AWS credentials, and the DeepSeek Database Exposure 2025 was an open ClickHouse database holding chat logs and API secrets. See the Kubernetes NHI Security Guide.
• Default credentials: marketplace images, self-hosted databases and admin panels can ship with known or empty passwords or authentication off. Require credentials in the template and scan for default logins after deployment.
• Logging: Google Cloud Data Access audit logs are disabled by default except for BigQuery, Azure resource logs need a diagnostic setting, and CloudTrail event history keeps only 90 days of management events. Run an organisation-level trail member accounts cannot stop, in a separate log account, and alert on changes to it (T1685 Disable or Modify Tools, Defense Impairment in ATT&CK v20). See the Log Management and Retention Guide.
• Encryption: S3 applies SSE-S3 default encryption to every bucket, and EBS encryption by default can be enabled per Region. Use customer-managed keys where you need key-level access control or crypto-shredding, and deny non-TLS requests with aws:SecureTransport or equivalents. See the Encryption Guide.

Prevention: guardrails, IaC scanning and policy as code

Organisation guardrails

• AWS: SCPs set the maximum permissions for principals in member accounts and grant nothing; RCPs cap what principals outside the organisation can do to your resources. Use them to deny disabling Block Public Access, stopping the organisation trail and launching instances that allow IMDSv1. They do not restrict the management account, so keep workloads out of it.
• Azure: Azure Policy evaluates disabled, then append and modify, then deny, then audit; layered assignments are "cumulative most restrictive". Assign at management group scope, start in audit or enforcement mode DoNotEnforce, and move to deny when compliance is clean.
• Google Cloud: constraints such as iam.managed.disableServiceAccountKeyCreation, iam.managed.disableServiceAccountKeyUpload, compute.managed.vmExternalIpAccess, compute.managed.requireOsLogin and sql.managed.restrictPublicIp enforce common controls at organisation or folder level.

IaC scanning and policy as code

• Scanners: Checkov scans Terraform, CloudFormation (including SAM), ARM, Serverless framework, Helm, Kubernetes and Dockerfiles with "more than 750 predefined policies" and graph-based checks across connected resources. Trivy's trivy config covers Terraform, CloudFormation, ARM, Helm, Kubernetes and Dockerfiles. tfsec's maintainers "encourage the tfsec community to transition over to Trivy", so do not start new pipelines on tfsec.
• Gate on a short list: fail builds on public storage, open management ports, wildcard IAM, unencrypted storage and IMDSv1; report the rest. Record suppressions in code with a reason and expiry.
• Protect Terraform state: state can hold generated passwords and keys in plain text. Keep it in an encrypted, locked remote backend readable only by the pipeline identity.
• Pipeline identity: the deployment role is the most privileged NHI in the estate; federate it from CI with short-lived tokens. See the CI/CD Pipeline Identity Security Guide.

Detection: posture management, drift and ownership

• Posture management: CSPM evaluates configuration continuously against benchmarks. CIS publishes "prescriptive configuration recommendations" as consensus-based, vendor-neutral benchmarks, including Foundations benchmarks for AWS, Azure, Google Cloud, Oracle, Alibaba and IBM clouds, service benchmarks, and EKS, AKS and GKE benchmarks. See the CNAPP Guide.
• Drift detection: NSA notes that "IaC allows organizations to quickly detect unauthorized changes to infrastructure." CloudFormation marks stacks DRIFTED, IN_SYNC or NOT_CHECKED and resources MODIFIED or DELETED, but only for properties set explicitly in the template, not nested stacks or unsupported types. Terraform users can schedule terraform plan -refresh-only. Treat security-relevant drift as an incident until explained, and fix it in code.
• External view: scan your own IP ranges and DNS names for open ports, dashboards and storage endpoints. See the Attack Surface Management Guide.
• Ownership: require owner and data-classification tags by policy at creation, and route each finding to the owning team with a due date by severity.
• Alert on: bucket and infrastructure enumeration (T1580 Cloud Infrastructure Discovery, T1619), storage made public, new public snapshot shares, rules opening management ports, and key use from new networks.

Metrics that show it is working

• Public exposure count: anonymously reachable storage, snapshots, images and databases outside the approved exception list.
• Guardrail coverage: share of accounts, subscriptions and projects under the baseline.
• Long-lived keys: active access and service account keys, and the share older than 90 days.
• Time to remediate: median days to fix critical misconfigurations.
• IaC coverage and drift: share of production resources deployed by pipeline, and drift findings per week.

Implementation roadmap

1. Baseline (weeks 1-4): enable native posture management in every account and region, run the CIS Foundations benchmark, and list public storage, public snapshots, open management ports and access keys by age.
2. Close public exposures: confirm intended public resources with owners using anonymous access logs, then enable public access blocks at account level, then organisation level.
3. Guardrails in audit mode: assign Azure Policy as audit or DoNotEnforce, attach SCPs and organisation policies to a test OU or folder, and review would-be blocks for two to four weeks.
4. Enforce in rings: sandbox, then non-production, then production. Roll back by detaching the policy or returning it to audit, and keep a documented break-glass path.
5. IaC gates: run Checkov or Trivy in report-only mode, then fail builds on the critical list.
6. Retire static keys: move workloads and pipelines to federation, then block key creation with a reviewed exception list.
7. Operate: schedule drift detection, route findings to owners and report metrics monthly.

Decision guidance

• Preventive or detective: deny outright what is almost never legitimate (public snapshots, IMDSv1, disabling the audit trail); detect and remediate where exceptions are common (public website buckets, partner sharing).
• Native or third-party: single-cloud organisations get most value from native posture services; multi-cloud estates benefit from one policy language and one findings queue.
• Small versus large: a small team can remove most risk with a landing zone template and a few organisation settings (public access blocks, IMDSv2 default, organisation trail, no key creation). Large estates need policy as code with version control, tests and staged rollout, because guardrails become production change.

Common failure patterns

• Fixing the console, not the code: a finding is closed by hand and the next deployment reintroduces it.
• Guardrails in one region only: snapshot and AMI blocks, IMDS defaults and EBS encryption by default are Regional; an unused region becomes the gap.
• Treating shared links as harmless: account-key SAS tokens and week-long presigned URLs end up in tickets and repositories, as in the Microsoft SAS Token Exposure 2023.
• Keys that never die: the Imperva Breach 2019 combined an exposed internal instance with an AWS API key that should not have been there.
• Logging assumed, not verified: data access logs were never enabled, so nobody can say what was read.
• Exceptions without expiry: suppressions and policy exemptions accumulate until the guardrail protects little.

Framework mapping

Practitioner checklist

• Enable storage public access blocks at organisation or account level in every cloud.
• Block public sharing of snapshots and machine images in every Region by organisation policy.
• Make "IMDSv2 only (token required)" the default and deny launches allowing IMDSv1.
• Deny 0.0.0.0/0 and ::/0 ingress to management and database ports.
• Run an organisation-level audit trail member accounts cannot stop, plus data access logs for sensitive stores.
• Replace static keys with federation, block new key creation and alert on keys older than 90 days.
• Use user delegation SAS, disallow Shared Key and cap presigned URL age with s3:signatureAge.
• Scan IaC in every pull request with a critical-only gate, and lock down Terraform state.
• Schedule drift detection and fix drift in code.
• Require owner tags and route every finding to an owner with a due date.

Standards and references

• NSA: Top Ten Cloud Security Mitigation Strategies
• Cloud Security Alliance: Top Threats to Cloud Computing 2024 Report
• Center for Internet Security: CIS Benchmarks
• Microsoft Learn: Grant limited access to Azure Storage resources using shared access signatures
• Microsoft Learn: Remediate anonymous read access to blob data
• AWS: Download and upload objects with presigned URLs
• AWS: Block public access for Amazon EBS snapshots
• Google Cloud: Organization policy constraints

Related NHI Mgmt Group resources: CNAPP Guide · Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · Secrets Management Guide · Attack Surface Management Guide