Cloud security: the 5 configuration mistakes we see most often
Most cloud breaches don't come from the provider's flaws, but from the customer's misconfiguration. Here are the five most common traps.
Moving to the cloud does not shift responsibility for security onto the provider. The shared responsibility model applies: AWS, Azure or GCP secure the infrastructure, but the configuration of services, access and data stays on your side. Gartner estimated that through 2025, 99% of cloud security failures stem from the customer’s side, not the provider’s — the vast majority of high-profile “cloud” breaches are in fact customer misconfigurations. Here are five we encounter most often.
1. Publicly accessible object storage
An S3 bucket, an Azure Blob container or a GCS bucket accidentally set to public is a classic. It usually happens when someone opens access “just for a moment” for testing and forgets to revoke it. The result: customer data, backups and logs accessible to anyone who knows or can guess the address.
The fix: enable public access blocking at the level of the whole account, not just individual resources. Regularly scan your environment for publicly exposed resources — this can be fully automated.
2. Excessive IAM privileges
The most common and most dangerous mistake. Policies like Action: * on Resource: *, granted “to make it work”, mean that compromising one account or key gives the attacker control over the whole environment.
The principle of least privilege is not a slogan — it’s the foundation of cloud security. Every identity (user, role, service) should have exactly as many privileges as it needs. Tools that analyse actually used permissions and suggest reducing them are helpful here.
3. Access keys in code and repositories
Long-lived access keys stored in code, configuration files or repository history are a gift to attackers. Bots constantly scan public repositories for such credentials — the time from publication to abuse is measured in minutes.
The solution: use roles and temporary identities instead of static keys, store secrets in dedicated managers (Secrets Manager, Key Vault) and add credential-leak scanning to your CI/CD pipeline.
4. No monitoring and logging
You cannot detect an incident you cannot see. Disabled or unconfigured logs (CloudTrail, Azure Monitor, Cloud Audit Logs) mean that after an attack you cannot establish what happened or the scope of the breach.
Enable API-level audit logging across all regions, route logs to a separate, secured account and set alerts on high-risk events: IAM policy changes, disabling logging, creating new high-privilege accounts.
5. Default and unsecured data services
Databases and services launched with their default configuration are sometimes accessible from a wider network than they should be, occasionally without strong authentication or encryption. This applies to both managed databases and services run on virtual machines yourself.
The rule: no data service should be accessible from the internet without an explicit need. Enforce encryption at rest and in transit, restrict network access to the necessary minimum, and regularly review security group rules.
Automation over a one-off review
A cloud environment changes daily — new resources appear, permissions are modified. A one-off audit gives a snapshot for a given day but goes stale within a week. That’s why it’s worth deploying continuous configuration monitoring (CSPM), which detects deviations from agreed standards on an ongoing basis.
Summary
Cloud security rests on configuration discipline: blocking public access, least privilege, eliminating static keys, full logging and securing data services. If you’d like to check whether your AWS, Azure or GCP environment contains these mistakes, book a cloud configuration audit.
