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
| Misconfiguration | Why it is dangerous | Typical fix |
|---|---|---|
| Public storage bucket | Anyone with the URL can list or download files | Block public access; share with signed URLs or specific identities |
Security group allowing 0.0.0.0/0 on port 22 or 3389 | Every bot on the internet can try to log in | Restrict to known IPs, or use a bastion, VPN or the provider's session manager |
Overly broad IAM permissions ("Action": "*") | One leaked key can do anything | Least privilege; role-based access; short-lived credentials |
| Root or owner account without MFA | Account takeover is total | MFA on the root account, then stop using it day to day |
| Audit logging off | No record of who changed what | Turn on CloudTrail / Activity Log / Cloud Audit Logs for all regions |
| Unencrypted storage or databases | Data readable if copied | Turn 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.