“We moved to the cloud, so we’re secure now.” It is the most common sentence in boardroom security briefings. It is also, almost always, wrong.
Cloud providers give you tools to be secure. They do not give you security. The same misconfigurations that broke on-premise systems break in the cloud, plus a few new ones that are unique to the model. Here is what they are and how to fix them.
The misconfigurations that keep causing breaches
These five categories account for the majority of cloud security incidents. None of them require a sophisticated attacker. All of them are exposed by automated scanning within hours of going live.
1. Public storage
S3 buckets, Azure Blob containers, Google Cloud Storage buckets, Elasticsearch indices, MongoDB instances, and the long tail of “I spun this up to test something and forgot.”
Default permissions on these often mean “the entire internet can read this.” Sometimes “the entire internet can write to this.” It is the cloud equivalent of leaving a file cabinet open on the sidewalk.
Fix: Default to private. Use the principle of least privilege. Enable block public access at the account level so it is the floor, not the ceiling. Scan your environment for public buckets continuously, not just at audit time.
2. Over-permissioned identities
IAM roles with AdministratorAccess. Service accounts with *. Resource policies that allow “any authenticated user.” The classic “I just need this to work for the demo” permissions that get left in production for years.
Cloud identity is powerful, and most teams do not have a good handle on it. A developer grants a role to fix a bug. The role is too broad. The role is never scoped down. Three years later, a compromised credential has admin across the environment.
Fix: Use the principle of least privilege, but really. Audit IAM roles quarterly. Use permission boundaries to cap what even admin roles can do. Require MFA on every human identity. Use temporary credentials over long-lived access keys.
3. Secrets in repositories
API keys, database passwords, and cloud credentials committed to Git. Sometimes for years. Sometimes on a public repository. Almost always picked up by automated scanners within minutes of being pushed.
The pattern is the same in every incident: a developer was rushing, hardcoded a credential to make a test work, committed it, and forgot.
Fix: Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password). Pre-commit hooks that block secrets. Continuous scanning with tools like GitGuardian, TruffleHog, or GitHub’s built-in secret scanning. Treat every leaked secret as compromised, even if you “removed it” from the repo.
4. Misconfigured firewalls and network rules
Security groups with 0.0.0.0/0 on SSH, RDP, or database ports. Network ACLs that look locked down but allow the world on port 443 to a system that should not be public. Load balancers forwarding traffic to backends that have no business being on the public internet.
The cloud makes it very easy to open a port to the world with a single click. It does not make it easy to remember that you did.
Fix: Default-deny on all network rules. Use bastion hosts or SSM Session Manager instead of exposing SSH. Audit security group rules for any 0.0.0.0/0 entries. Use VPC flow logs to see what is actually happening on the network.
5. Weak or missing logging and monitoring
CloudTrail, GuardDuty, CloudWatch, Azure Monitor, Cloud Logging, all of it. Often turned off. Or turned on, but nobody reading the alerts. Or reading the alerts, but the alerts are tuned so loose that the real signal is buried in noise.
The cloud gives you world-class logging. It does not give you monitoring for free. Most cloud compromises are detected weeks or months after the fact, often by an external party, because the organization was not watching what was happening in their own environment.
Fix: Turn on CloudTrail (or equivalent) in every region, not just your primary one. Enable GuardDuty / Defender for Cloud / Security Command Center. Pipe logs to a SIEM or a centralized log store. Alert on the things that matter: new IAM users, policy changes, console logins from new geographies, data exfiltration patterns.
The deeper issue: shared responsibility, misunderstood
Cloud providers love the phrase “shared responsibility model.” It means: the cloud provider secures the cloud itself (the physical data centers, the hypervisors, the managed services), and you secure what you put in it (your data, your applications, your access controls, your configuration).
Customers hear: “we moved to the cloud, so we are secure.”
What they should hear: “we moved to the cloud, so we traded managing physical infrastructure for managing a more complex and faster-moving configuration surface area, with similar or higher security responsibility.”
The companies that understand this spend real effort on cloud security posture management, least-privilege IAM, and centralized logging. The companies that do not, end up in the news.
What to do this week
You do not need a new tool. You need to go through the list above and check whether any of the five misconfigurations exist in your environment. Here is a 4-hour audit you can do with one person.
- Search your cloud account for public storage. Every major provider has a one-click report for this. Set up an alert so it pings you when a new public bucket appears.
- List all IAM users and roles with AdministratorAccess. If the list is longer than 5, you have work to do.
- Search your source code for hardcoded secrets. GitHub, GitLab, and Bitbucket all have built-in scanning. Turn it on.
- Check security groups for 0.0.0.0/0 on management ports. Anything that says “0.0.0.0/0” and “port 22” or “port 3389” is a finding.
- Confirm CloudTrail (or equivalent) is on, in every region, with logs going somewhere durable. Confirm the alerts are routing somewhere a human sees them.
Do this. The cloud will still be there on Monday. The misconfigurations will be gone.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
