The Most Common Cloud Security Misconfigurations We See in Enterprise Environments

Image Source: iStock | The Most Common Cloud Security Misconfigurations We See in Enterprise Environments

The most expensive security incidents we see in enterprise cloud environments almost never start with a sophisticated attacker.

They start with an S3 bucket that was left publicly accessible six months ago during a testing sprint and never locked down. A service account with administrator privileges that was created for a one-off migration task and never deprovisioned. A security group rule that allows unrestricted inbound traffic on port 22 because someone needed SSH access quickly, and it was never revisited.

These are not edge cases. According to the Cloud Security Alliance, misconfiguration is the leading cause of cloud data breaches, responsible for over 65 percent of incidents in cloud environments. And the reason misconfiguration is so persistently dangerous is not that it is hard to fix. It is that it is easy to miss.

Here are the misconfigurations we encounter most consistently when we conduct security assessments on enterprise cloud environments, and exactly what to do about each one.

Overly Permissive IAM Policies

Identity and Access Management misconfiguration is the most common security issue we find in enterprise cloud environments, and the gap between what permissions exist and what permissions are actually needed is almost always larger than anyone realises.

The pattern we see most frequently is the progressive accumulation of permissions over time. A developer needs access to a specific S3 bucket. Rather than creating a policy scoped precisely to that bucket, a wildcard policy is applied because it is faster. Six months later, that principal has access to every S3 bucket in the account. Multiply that pattern across dozens of service accounts, IAM roles, and user accounts and the IAM configuration that exists in production is often dramatically more permissive than anyone intended or realised.

The fix starts with a rigorous audit of existing permissions against the principle of least privilege. Every principal should have precisely the permissions it needs to perform its function and nothing more. AWS IAM Access Analyzer, Azure AD Access Reviews, and GCP Policy Analyzer all provide tooling to identify where permissions exceed what is actually being used. Running these tools and acting on the results is one of the highest-value security activities a team can undertake.

The ongoing fix is enforcing least privilege at the point of policy creation rather than trying to remediate after the fact. That means policy templates, code review processes that include IAM policy review, and automated policy linting in CI/CD pipelines to catch overly permissive policies before they reach production.

Publicly Exposed Storage

Publicly accessible cloud storage remains a consistently prevalent misconfiguration despite years of high-profile incidents caused by it. The reason it persists is that the path to creating a public bucket is genuinely easy, and the process of auditing for public buckets across a large environment is genuinely tedious without the right tooling.

The immediate remediation is straightforward. On AWS, enable S3 Block Public Access at the account level, which prevents public ACLs and policies from being applied to any bucket, regardless of what individual bucket configurations say. On Azure, set the default storage account access to disabled at the subscription level. On GCP, enforce the uniformBucketLevelAccess constraint via organisation policy to prevent legacy ACLs from being used.

The ongoing control is preventative. Service Control Policies on AWS, Azure Policy, and GCP Organisation Policies can all enforce that no storage resource in the environment can be made public, regardless of what an individual developer does at the resource level. These controls should be applied at the organisation or management account level so they cannot be overridden by account-level configurations.

Unrestricted Security Group and Network ACL Rules

Security group rules that allow ingress from 0.0.0.0/0 on sensitive ports are almost universal in environments that have been running for more than a year. They accumulate because they are created quickly under time pressure, there is no automated alert when they are created, and there is no review process that catches them after the fact.

The ports that most frequently appear with unrestricted ingress in enterprise environments are 22 (SSH), 3389 (RDP), 1433 (SQL Server), 3306 (MySQL), 5432 (PostgreSQL), and 27017 (MongoDB).

Each of these represents a direct path to sensitive infrastructure if an attacker can reach the resource.

The fix for existing rules is an audit. AWS Config, Azure Security Center, and GCP Security Command Center all provide rules or findings that identify security groups with unrestricted ingress. Run these, export the results, and triage them by severity. Unrestricted access to management ports like 22 and 3389 should be treated as critical and remediated immediately, ideally by replacing direct SSH/RDP access with Session Manager or Azure Bastion.

The ongoing fix is automation. A Lambda function triggered by CloudTrail that alerts or automatically remediates when a security group rule with 0.0.0.0/0 ingress is created costs very little to build and prevents the problem from accumulating in the first place.

Logging and Monitoring Gaps

Environments without comprehensive logging are environments where the attacker has more time. Every minute between a security event occurring and your team being alerted is a minute of dwell time. And dwell time is directly correlated with breach severity.

The most common logging gaps we find are CloudTrail not enabled in all regions, S3 server access logging disabled, VPC Flow Logs not enabled on critical VPCs, and CloudWatch log groups without retention policies set, resulting in logs being automatically deleted before they can be used in an investigation.

The baseline logging configuration for an enterprise AWS environment should include CloudTrail with multi-region logging enabled and log file integrity validation turned on, logs delivered to a dedicated security account that the workload account cannot write to or delete from, VPC Flow Logs enabled on all VPCs with logs delivered to CloudWatch or S3, and S3 server access logging enabled on all buckets containing sensitive data.

Beyond the logging itself, the value comes from detection. AWS GuardDuty, Azure Sentinel, and GCP Security Command Center all provide ML-driven threat detection that operates against your logs and API calls. These services are not substitutes for a mature detection engineering practice but they provide a significant baseline of automated detection for common attack patterns at relatively low cost.

Secrets in Code and Configuration

Hardcoded credentials, API keys, and secrets in source code and configuration files are one of the most persistently embarrassing categories of security misconfiguration because every developer knows it is wrong, and it still happens constantly.

The reasons it happens are worth understanding because they inform the fix. Developers hardcode secrets during development because it is the path of least resistance. Those secrets make it into version control because there is no pre-commit hook catching them. They stay in version control because scanning the repository history is tedious, and the assumption is that the repository is private.

The fix has three components. Detection, using tools like AWS Secrets Manager secret detection, GitHub Secret Scanning, GitGuardian, or truffleHog to scan existing repositories and surface hardcoded secrets. Prevention, implementing pre-commit hooks using tools like detect-secrets or gitleaks that catch secrets before they reach the remote repository. And migration, replacing hardcoded secrets with references to a secrets management service such as AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.

The migration is the hardest part because it requires touching every piece of code that currently references a hardcoded secret. The most practical approach is to treat it as a progressive remediation, prioritising secrets with the broadest access or the highest sensitivity, and enforcing the use of secrets management for all new development immediately rather than waiting for the full migration to complete.

Unencrypted Data at Rest and in Transit

Unencrypted data at rest and in transit still appears in enterprise cloud environments more often than it should, usually as a result of older resources that were created before encryption was enforced as a standard, or newer resources where the encryption configuration was left at its default state without verifying what that default was.

The approach that works is policy enforcement rather than individual resource remediation. On AWS, AWS Config rules combined with AWS Config Remediation can automatically detect and remediate unencrypted EBS volumes, RDS instances, and S3 buckets. On Azure, Azure Policy can deny the creation of storage accounts and managed disks without encryption at rest enforced. Enforcing encryption at the policy level means new resources cannot be created without it, which addresses the ongoing problem, even if the historical remediation is incomplete.

For data in transit, enforcing TLS 1.2 as a minimum via resource policies on S3 buckets, requiring HTTPS for API endpoints, and using Network Policies or security groups to block unencrypted protocols on sensitive ports covers the majority of the exposure.

Building a Continuous Security Posture

The misconfigurations described in this article share a common characteristic. They are not hard to fix. They are hard to stay on top of in an environment that is changing continuously.

The organisations that maintain a strong cloud security posture are not the ones that run a quarterly audit and fix what they find. They are the ones that have built security controls into the infrastructure provisioning process so that compliant configurations are the default, automated detection so that non-compliant configurations are identified immediately rather than in the next audit cycle, and clear ownership so that identified issues are remediated within a defined SLA rather than sitting in a backlog indefinitely.

At Contivos, our security and compliance practice helps technical teams build exactly this kind of continuous posture management. We work across AWS, Azure, and GCP environments, embedding security controls in infrastructure-as-code templates, building detection and remediation automation, and providing the ongoing security operations support that keeps the posture from degrading as the environment evolves.

If your environment has any of the misconfigurations described in this article and you want support remediating them or building the controls to prevent them from recurring, visit contivos.com to start that conversation.

The misconfiguration that causes your next incident is probably already in your environment. The question is whether you find it first.