Cloud Security in Plain English: The Three Mistakes Behind Most Cloud Mess-ups

Most cloud mess-ups are not some genius zero-day nobody saw coming. They are three boring mistakes, made by good people who were busy. Too many people can do too much. Some storage got left open. And nobody is keeping the logs. This post walks through all three in plain English, across AWS, Azure and Google Cloud without picking a side, and tells you what to actually do about each one.

Quick definition before we start, because I promised plain English. A cloud misconfiguration is just a setting that got left in a state that lets someone in who should not be in. Not a bug. Not a hack, really. A setting. Keep that in mind, because it is the whole theme here: the danger is almost never the cloud being the cloud. It is a choice somebody made, often months ago, that nobody circled back on.

Mistake 1: everyone can do everything

Here is how it happens, and I want to be fair about it because I have done it too. You are small. Someone needs access to ship a thing by Friday. You give them admin because admin is the box that definitely works and you do not have time to figure out the narrower box. Multiply that by two years and a few hires, and now half your team can touch production and you could not say who actually needs to.

Security people call this least privilege, or the lack of it. The idea is simple: every person, app and service account gets access to exactly what it needs, and nothing else. The failure mode has a name too. The NSA and CISA, in their joint advisory on the ten most common misconfigurations they find in the wild, call it privilege creep, “the granting of excessive access and unnecessary account privileges.” They note that when privileges are overly permissive, users “can see and/or do things they should not be able to,” which widens your attack surface. In one of their assessments, a team that got in through a single account with admin permissions compromised the whole domain in under a business day. One account. Before lunch, basically.

And this is not a Windows-only story, even though their report leans on Active Directory examples. The exact same pattern lives in your cloud console. An over-broad IAM role in AWS, an owner assignment in Azure, a primitive role in Google Cloud. Same mistake, different logo.

What to do, roughly in order:

1. Pull a list of who has admin or owner-level access to your cloud account. Just look at it. Most people are surprised.

2. For anything that is a person, ask “do they still need this, today.” For anything that is an app or a service account, ask “what is the smallest role that still lets it work.”

3. Turn on multifactor authentication for every privileged account, no exceptions, especially the root or global admin.

4. Make this a recurring thing, a calendar event, not a someday. Access that was right in March is wrong by September because people and projects move.

You do not need to buy anything to start. You need an afternoon and the willingness to tell someone their access is getting trimmed. The second part is harder than the first, which is a people problem wearing a security costume.

Mistake 2: the storage got left open

This is the one that ends up in the news. A storage bucket full of customer data, readable by anyone on the internet who knew the URL, discovered by a researcher who was just poking around. It feels like negligence from the outside. From the inside it is usually one person flipping one setting to unblock one task, and then forgetting.

Here is the part worth internalizing: the defaults are on your side. Amazon’s own documentation says it plainly. “By default, new buckets, access points, and objects don’t allow public access.” Then the important next sentence: “However, users can modify bucket policies, access point policies, or object permissions to allow public access.” Azure blob storage and Google Cloud Storage behave the same way out of the box. Private by default. The risk is not the default. The risk is the change someone made later, for a reason that made sense that day, and the open door nobody closed.

So the fix is less about locking things down from scratch and more about catching the drift:

1. Find your storage. Buckets, blob containers, whatever your provider calls them. You cannot protect what you have not inventoried, which is a theme on this blog for a reason.

2. Turn on the account-wide guardrail. On AWS it is called Block Public Access, and AWS recommends enabling all four of its settings at the account level so one stray policy cannot quietly make a bucket public. Azure and Google Cloud have their own versions of “do not allow public access, account-wide.” Turn the equivalent on.

3. For the handful of things that genuinely need to be public, a marketing site’s images, say, serve them deliberately through the front door your provider gives you for that, not by flipping a whole bucket open.

4. Set up an alert for when a bucket does go public. Every major provider can tell you. Most people just never asked it to.

If you take one thing from this section: public storage is almost never a default you inherited. It is a decision, and decisions can be found, reviewed and reversed.

Mistake 3: nobody is keeping the logs

This one is the quietest and, honestly, the one that haunts people most after something goes wrong. Something happens. A file is gone, or a record was changed, or a customer swears they never agreed to a thing. You go to figure out who did what, and when, and you discover the answer is a shrug. There is no record. Or there is a record of some things and not the thing you need.

The NSA and CISA advisory lists “insufficient internal network monitoring” as one of its top ten, and warns it “could lead to undetected adversarial compromise.” Which is the polite way of saying: if you are not watching, someone can be inside for a long time and you will not know. Their own red teams used exactly this gap to move around networks unseen.

Cloud makes this trap especially easy to fall into, because of a default that surprises people. On AWS, the audit service CloudTrail is on for the big administrative actions, the “someone changed a setting” events. But AWS’s documentation is explicit: “By default, trails and event data stores log management events, but not data or Insights events.” Data events are the ones that record who read, wrote or deleted the actual objects in your storage. In other words, out of the box you often get a log of who changed the locks, but not a log of who opened the door and walked through. Azure and Google Cloud draw a similar line: the control-plane changes get logged, the data-access events usually need to be turned on.

The fix is not glamorous and that is the point:

1. Turn on audit logging across every region and account, not just the one you log into most. On AWS that is CloudTrail with a trail covering all regions; use the equivalent on Azure and Google Cloud.

2. Decide where the logs go and make sure that place is not writable by the same people whose actions you are logging. Logs you can quietly delete are a diary, not evidence.

3. Turn on data-event logging for the storage that actually matters. You do not need to log every read of every object in the company. You need the sensitive stuff covered.

4. Keep the logs long enough to be useful. A breach is often found months after it started, so a two-week window is a window that closes before you look through it.

If you cannot answer “who did what, and when,” you cannot prove what was touched, and you cannot tell a customer, a regulator or your own board anything better than “we think it’s fine.” That is a bad sentence to have to say out loud. I have heard people say it. Their faces do a thing.

Why these three, and why now

You might notice none of these is cloud-specific in spirit. Least privilege, not leaving the door open, keeping records: your grandmother’s accountant knew all three. What the cloud changed is the speed and the blast radius. One over-broad role, one public bucket, one gap in the logs, and the damage is instant and global instead of slow and local. The mistakes got older and the consequences got faster.

This is also the deeper reason the perimeter model stopped working, which we dug into in our piece on zero trust architecture. When there is no wall anymore, each of these three mistakes is a door standing open on the open internet, not a door inside a building you locked at night. Zero trust is really just these habits made into a system: assume nobody is trusted by default, give everything the least it needs, and watch everything.

The takeaway

You do not have a cloud problem. You have three settings worth checking. Who can do what. What is open to the internet. Whether anyone is writing down what happens. Pull those three lists this week, and you will have done more for your security than most companies do in a quarter.

If your cloud setup has grown faster than anyone’s been able to keep up with, and you are not sure which of these three doors is standing open right now, that is exactly the kind of thing our cloud security architecture work exists to figure out.