Skip to main content
Back to module
Security Operations & Defense · Hardening and Vulnerability Management

Cloud security posture

Reading45mLesson 3 of 3 in this module

Understand shared responsibility and fix the classic cloud misconfigurations: a public storage bucket and an open management port.

Why it matters

In the cloud, a single setting can expose a whole data set to the internet. Many of the best-known cloud breaches were not clever exploits: they were storage buckets left public, databases with no password, or management ports open to everyone. Cloud security posture management (CSPM) is the practice, and the tooling, of continuously checking cloud configuration for exactly these mistakes and fixing them.

The shared responsibility model

Cloud providers secure the cloud itself: data centres, hardware, the hypervisor and their managed services. You secure what you put in it and how you configure it: identities and permissions, network rules, storage access, encryption settings, and your operating systems and applications. The line moves depending on the service (you manage more on a virtual machine than on a managed database), but configuration is always your job.

The usual suspects

MisconfigurationWhy it is dangerousTypical fix
Public storage bucketAnyone with the URL can list or download filesBlock public access; share with signed URLs or specific identities
Security group allowing 0.0.0.0/0 on port 22 or 3389Every bot on the internet can try to log inRestrict to known IPs, or use a bastion, VPN or the provider's session manager
Overly broad IAM permissions ("Action": "*")One leaked key can do anythingLeast privilege; role-based access; short-lived credentials
Root or owner account without MFAAccount takeover is totalMFA on the root account, then stop using it day to day
Audit logging offNo record of who changed whatTurn on CloudTrail / Activity Log / Cloud Audit Logs for all regions
Unencrypted storage or databasesData readable if copiedTurn on default encryption

Worked example: a public bucket

A storage bucket with this AWS bucket policy is readable by the whole internet:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::acme-reports-2026/*"
  }]
}

"Principal": "*" means everyone, including people who are not logged in. Anyone can fetch an object with a plain request:

curl -I https://acme-reports-2026.s3.amazonaws.com/q3-customers.csv
# HTTP/1.1 200 OK   <- exposed

Fix: remove the statement and turn on S3 Block Public Access, ideally at the account level so a single bucket policy cannot undo it. New buckets have it on by default, so a public bucket today usually means someone turned it off. After the fix, the same request returns 403 Forbidden. Then answer the incident question too: was the file downloaded while it was public? Check server access logs or CloudTrail data events if they were enabled, and involve your IR process if sensitive data was exposed.

Worked example: an open management port

A security group rule lets SSH in from anywhere:

Inbound: TCP 22  source 0.0.0.0/0

Fix: change the source to the admin's public IP as a /32 (for example 198.51.100.24/32), or remove the rule entirely and connect through the provider's session manager, which needs no open inbound port. Azure network security groups and Google Cloud firewall rules work the same way.

How CSPM tools work

CSPM tools read your cloud configuration through the provider's APIs and compare it with rules, often mapped to CIS Benchmarks for AWS, Azure and Google Cloud. Examples:

  • Built in: AWS Security Hub and AWS Config, Microsoft Defender for Cloud, Google Security Command Center.
  • Open source: Prowler (AWS, Azure, Google Cloud, Kubernetes) and ScoutSuite.
  • Commercial platforms that add attack-path analysis and workload protection (often sold as CNAPP).

The output is a list of findings with severity, the affected resource and a fix. As with vulnerability management, prioritise by exposure and data sensitivity: a public bucket of website images is a different problem from a public bucket of customer records.

The best place to catch misconfiguration is before deployment. If infrastructure is defined as code (Terraform, CloudFormation, Bicep), scanners such as Checkov or tfsec flag a public bucket in a pull request, before it ever exists.

Cost and safety in your own account

Practising in a real cloud account is valuable, but treat it carefully:

  • Use the provider's free tier, set a budget alert first, and delete everything when you finish.
  • Never put real or personal data in a practice resource, especially one you are about to make public.
  • Only scan and change accounts you own. Probing other people's buckets or ports is unauthorised access, even if they are misconfigured.

Common mistakes

  • Fixing the console and not the code. If the bucket came from Terraform, the next deploy reverts your manual fix.
  • Opening a port "just for a minute". Bots scan the whole IPv4 internet constantly; exposure is found in minutes.
  • Ignoring identities. Broad IAM permissions and long-lived access keys cause as many incidents as network rules.

Quick recap

  • Under shared responsibility, the provider secures the cloud and you secure your configuration.
  • Public buckets, open management ports, broad IAM, missing MFA and disabled audit logs are the usual problems.
  • Fix a public bucket with Block Public Access and specific grants; fix an open port by restricting the source or using a session manager.
  • CSPM tools (Security Hub, Defender for Cloud, Prowler) find misconfigurations continuously; IaC scanners catch them before deployment.

Try it

Open the Do tab to create, find and fix both misconfigurations in your own free-tier account.

Also in this lesson: