Cloud Security Basics: 7 Configuration Mistakes That Quietly Expose Your Data

Monday, 9:20 a.m. The application is running, customers are logging in, and monitoring shows no outages. And yet a company bucket in the cloud is publicly accessible, an account created a few months ago still has administrator privileges, and a database port responds directly from the internet.

Nothing has broken, so the problem can go unnoticed for months. The cloud works exactly as it was configured. It just shares data more widely than the company intended.

This is the fundamental challenge of cloud security. AWS, Microsoft Azure and Google Cloud secure their own infrastructure. Service configuration, permissions, data access and network settings remain largely the customer’s responsibility. Gartner predicted that through 2025, 99% of cloud security failures would be the result of customers’ actions, not the providers’. This is a prediction, not a measurement of incidents, but it shows well how much configuration matters.

In short, the most common cloud configuration mistakes are public resources, overly broad permissions, keys stored in code, open ports, poorly protected administrator accounts, lack of control over encryption keys, and uncontrolled configuration changes. All of them can be detected and fixed before someone exploits them.

A public bucket that was never meant to be public

Amazon S3, Azure Blob Storage and Google Cloud Storage are used to store files, backups, logs and application data. The problem begins when an internal resource is made publicly available.

This usually happens during testing. Someone quickly shares a file, finishes the task and forgets about it. A few months later, the same location holds reports, data exports and customer documents. The application works, so no one notices that the public bucket is exposing data.

Start by checking which resources allow public or anonymous access, and disable it wherever it is not needed. Separate public files from company data, restrict access to specific users and services, and monitor changes to settings. That way, an accidentally opened resource will not slip through with the next deployment.

IAM permissions broader than the job requires

In the cloud, almost everything is based on identity and permissions. The problem arises when access is granted “just in case”. A developer needs one operation, so they get full permissions. The project ends, but the access remains.

Broader access means worse consequences when an account is compromised. If a user who should only read logs can also delete resources and change policies, a single stolen credential opens up the entire environment.

Apply the principle of least privilege: give users and services only the IAM permissions they actually need. Regularly review administrator accounts, broad roles, unused accounts, temporary access and service accounts. Teams and projects change, so this review is repeated on a regular cycle.

Access keys and passwords in code

An application needs a connection to a database or an API, so someone types a password or key directly into a configuration file. It works, so the temporary solution ends up in production. Later, the secret sits in the repository, deployment scripts, container images and documentation.

Whoever obtains such a key can use resources with that account’s permissions. If the key does not expire, the risk lasts for months.

To fix this, store credentials in a secrets management tool, not in code. Where possible, use short-lived credentials instead of permanent keys. Remove unused keys, rotate them and scan repositories for secrets. An exposed key must be revoked and replaced; simply removing it from the code is not enough.

Ports and admin panels open to the entire internet

An administrator briefly opens access to a server or database to fix a problem. After the work is done, the rule stays, because nothing prompts anyone to close it. As a result, SSH, RDP, a database or an internal panel can be reached from any IP address.

This is not yet a breach, but it is a much larger attack surface. Security groups, firewalls and network rules are therefore part of application protection, not a technical detail.

Check which services are reachable from the internet, especially administrative ports, databases, panels and internal APIs. Narrow access to specific networks, people or services, and use a VPN or another controlled path for administrative tasks.

Privileged accounts without proper protection

An administrator who can create accounts, change access rules and delete resources is a different risk than an ordinary user. Even so, such an account is often protected the same way: without MFA, alongside active unused accounts, and with full privileges in day-to-day work.

Taking over such an account gives the attacker control of the entire environment.

Therefore, enable MFA (multi-factor authentication) on all administrative accounts. Then remove unnecessary privileged accounts, and log and monitor the use of the remaining ones. Separate day-to-day work from administrative tasks so that the account used for email and documents does not have permanent access to critical infrastructure.

Data is encrypted, but no one has checked access to the keys

“The data is encrypted” sounds reassuring. However, encryption is only as good as the control over the keys. If a user can see the data and can freely use the key, encryption does nothing to limit excessive access. The same applies when keys are available to too many accounts or the policies for their use are too broad.

Establish not only whether the data is encrypted, but also who manages the keys and who can use them. Permissions to keys should follow from the role of the user or application. While you are at it, check encryption in transit, key rotation and the protection of backups. A ticked “encryption enabled” option does not replace access management.

The environment was secure six months ago

An audit was completed successfully: public resources closed, unnecessary permissions removed, rules corrected. Afterwards, your team deployed new services, test environments appeared, someone opened a port, and another team launched a resource outside the agreed process.

Such a gradual departure from secure settings established during an audit is called configuration drift.

Any audit captures a single day. New mistakes are only caught by monitoring changes: automated settings checks, alerts on risky changes, periodic IAM reviews, an up-to-date inventory of resources, and CSPM (Cloud Security Posture Management) tools that compare your environment against adopted rules. CIS Benchmarks, recommendations for securely configuring cloud services, can serve as a reference point.

AWS, Azure and GCP secure the cloud. You are responsible for how you use it

Moving an application to a large provider does not take care of security. This is how the shared responsibility model works: the provider secures data centers, hardware and the underlying infrastructure, while the customer is responsible for, among other things, access, data, identities and the network.

The exact split depends on the service. With a virtual machine, the customer is responsible for more than with a fully managed service.

But the provider will give you a mechanism for blocking public access, but it will not decide whether a given resource should be public. It will give you an IAM system, but it does not know whether an employee still needs administrator privileges.

How to check what is actually exposed in the cloud?

A few applications and one team can be reviewed manually. The problem grows with the environment: more AWS accounts, Azure subscriptions, GCP projects, teams, and test environments that were meant to exist for a few days.

At that point, you need to establish which resources exist, which are accessible from the internet, who has permissions, and whether the configuration meets the adopted security level.

This is where cloud and infrastructure security stops being a one-off task and becomes a process: find public resources and excessive permissions, restrict them, and then make sure the environment does not slip back to its previous state after subsequent changes.

One-off audit or continuous monitoring?

A cloud security audit tells you what is misconfigured today. It is a good start, especially when a company has no up-to-date picture of its environment. But the cloud changes every day, so audit results quickly become outdated.

One does not exclude the other. The audit sets the starting point, and monitoring makes sure the environment does not slip back into risky settings.

7 questions for your IT team

You do not need to know the configuration of AWS or Azure to start a conversation about cloud security. These questions are enough:

1. Which of our resources are publicly accessible from the internet?
2. Who has administrator privileges, and do they still need them?
3. Are there permanent access keys in our code, repositories or scripts?
4. Which ports and admin panels are accessible from outside our network?
5. Do all privileged accounts have MFA?
6. Who can use the encryption keys and read sensitive data?
7. Will we find out if a secure configuration changes to a risky one tomorrow?

The lack of a clear answer does not mean an incident. It does, however, show where to start the review.

Summary: the cloud can be secure, but it will not configure itself

Configuration mistakes that pose the greatest danger do not look like incidents. A public bucket keeps storing files, an open port lets your application run, and an account with excessive permissions does nothing wrong for months. Trouble only comes to light when someone who should not have access takes advantage of it.

Cloud security rests on knowing your own environment: what is public, who has access, which accounts have high privileges, where your data is, and whether its configuration has changed since your last review. A one-off fix is a good start. Yet staying secure also requires control over what happens after your next deployment.