The most common cloud misconfigurations we find in client audits

01.Why the same mistakes keep appearing

Cloud platforms make it easy to create things and easy to forget them. A developer opens a port to debug an issue. A contractor gets broad access to finish a job. A backup job is set up in a hurry. Each decision was reasonable on the day. None was reviewed later.

Over time these small decisions pile up. The result is an environment where nobody can explain why a rule exists, but nobody dares remove it. That is where attackers find their way in.

02.1. Publicly accessible storage

A bucket or container is opened to test something, or to share a file with a partner. It is never closed. Months later it holds exports, backups or customer files that nobody meant to expose.

Check: list every storage resource that allows public or anonymous access. Turn on account-level blocks for public access. Ask owners to justify any exception in writing.

03.2. Over-privileged IAM roles

Roles with wildcard permissions are common, because they make things work on the first try. They also turn a small compromise into a large one. A single leaked token with broad rights can reach almost everything in the account.

Check: search for policies that allow all actions or all resources. Replace them with the specific actions the service needs. Use access analysis tools to see which permissions are actually used, and trim the rest.

04.3. Unused access keys that never expire

Long-lived keys sit in old scripts, laptops and chat messages. Employees leave. Projects end. The keys stay valid, and nobody is watching them.

Check: list keys by last-used date. Disable anything unused for a long period. Move to short-lived credentials wherever the platform supports it.

05.4. No multi-factor authentication on admin accounts

An admin password alone is a weak defence. It can be phished, reused or leaked. We still find privileged accounts, including the root or owner account, with no second factor.

Check: confirm MFA on every human account with admin rights, and on the root account. Keep emergency break-glass accounts under a documented process, with alerts when they are used.

06.5. Open management ports

SSH and RDP open to the whole internet are probed within minutes of appearing. Often the rule was added "temporarily" during an incident, and left.

Check: look for security groups or firewall rules that allow management ports from anywhere. Replace them with a bastion host, a VPN or a managed session service that logs who connected.

07.6. Logging switched off

Teams turn off audit logs to save cost or reduce noise. Then something goes wrong, and there is nothing to investigate. You cannot answer who did what, or when. For an auditor or an insurer, missing logs are a finding on their own.

Check: confirm audit logging is on for every account and region. Send logs to a separate, protected location. Set a retention period you can defend.

08.7. Unencrypted databases and backups

Encryption at rest is a checkbox on most platforms, yet we regularly find databases, snapshots and backups without it. Backups are the worst case, because they are copied around and forgotten.

Check: list databases, volumes and snapshots without encryption. Enable it on new resources by default. Plan a migration for the old ones, starting with anything that holds personal data.

09.A quick self-audit checklist

• Is any storage public? Is each case justified?
• Do any roles use wildcard permissions?
• Which keys have not been used recently?
• Does every admin account use MFA?
• Are SSH or RDP open to everyone?
• Is audit logging on everywhere?
• Is every database and backup encrypted?

10.Which one hurts most

If you can fix only a few things this month, fix in this order. Public storage and open management ports come first, because anyone on the internet can reach them without a password. Missing MFA on admin accounts comes next, because it protects the keys to everything else. Then wildcard roles and old keys, which limit what a stolen credential can do.

Logging and encryption matter, but they do not usually stop an attack. Logging helps you understand one. Encryption limits the damage from a lost disk or backup. Do them soon, but do not let them delay the items above.

11.How these mistakes combine

The real danger is in combinations. A server with an open management port is bad. If the same server has a role with wildcard permissions, an attacker who gets in can reach the rest of the account. If audit logging is also off, nobody finds out until the bill or a customer tells them.

For this reason, review findings together. Ask, "What could an attacker reach from here?" and not only, "Is this setting wrong?" A medium finding that sits on a path to sensitive data should move up the list.

12.Examples of safer defaults

• Block public access at account level, and allow exceptions by name.
• Give each service its own role with only the actions it needs.
• Use short-lived credentials and single sign-on for people.
• Reach servers through a managed session service, with no open management ports.
• Enable audit logs by default in every new account.
• Make encryption on by default in your infrastructure templates.

Defaults beat reminders. People forget. Templates do not.

13.Common mistakes when fixing these

• Fixing the finding by hand and not in code, so it returns at the next deploy.
• Closing a port or tightening a role without checking who uses it. Read the access logs first, then ask the owner.
• Trying to fix everything at once. Start with what is reachable from the internet.
• Skipping guardrails. Without a policy that blocks the mistake, it will come back.
• Declaring victory after one scan. Posture drifts every week.

14.Why audits find these again and again

Teams often fix a list once and call it done. Three months later, new accounts and new projects have brought the same mistakes back. The cause is not carelessness. It is the lack of a default. When the easy path in your templates is the unsafe one, people will take it.

Put the safe choice into templates and pipelines, and make the unsafe choice need a reason. Add a recurring scan, route findings to the owning team, and track the open count week by week. A falling trend tells you the habit has changed, and a flat one tells you it has not.

15.What to do next

Pick three items from the checklist and check them this week. Record what you find, assign an owner and fix the exposed items first. Then add guardrails so the same mistake cannot be shipped again. Put a recurring review in the calendar, even a short one.

Brandsmashers cloud security engineers run these checks and the fixes alongside your team. If you would like help turning a scan into a fix order, book a call and we will talk it through.