Cloud environments fail in predictable ways. After reviewing dozens of AWS, Azure, and GCP environments across industries and company sizes, the same misconfigurations appear again and again — regardless of how sophisticated the organisation looks from the outside.
This is not a criticism of the teams involved. Cloud platforms are complex, move fast, and are operated under constant pressure to ship. Misconfiguration is the norm, not the exception. What matters is knowing where to look and how to fix what you find.
Here are the five issues that come up in almost every cloud security assessment we run.
Overly Permissive IAM Roles and Policies
This is the single most common and most dangerous finding across cloud environments. IAM misconfigurations come in several forms, but the most damaging are wildcard permissions (`"Action": "*"`), administrator roles attached to workloads that do not need them, and long-lived access keys assigned to service accounts that were "temporary" and never rotated.
The impact is severe: a compromised application or container with an overly permissive IAM role can be used to enumerate the environment, exfiltrate data, escalate privileges, and move laterally across the account — all without breaking any network controls, because the permissions were granted legitimately.
Apply least privilege consistently. Every role and policy should grant only the permissions required for a specific task, on specific resources, for a limited time where possible. Audit IAM regularly with tools like AWS IAM Access Analyzer or ScoutSuite. Eliminate unused roles, unused keys, and any use of `"Resource": "*"` that cannot be justified.
❌ "Action": "*", "Resource": "*" ← Never acceptable in production ✓ "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-specific-bucket/*"
Publicly Accessible Storage Buckets
S3 buckets, Azure Blob containers, and GCS buckets with public read access remain a persistent source of major data breaches. The configurations that cause this are often made without full awareness — a developer enables public access to share a file quickly, or a misconfigured Terraform module defaults to public ACLs, and the change is never reviewed or reverted.
The consequences are well-documented. Publicly accessible storage buckets have exposed customer records, financial data, healthcare information, internal source code, and credentials in incidents affecting organisations of every size. This is one of the highest-likelihood, highest-impact risks in cloud environments.
Enable "Block All Public Access" at the account level in AWS — this prevents any bucket in the account from being made public, even by accident. For legitimate use cases requiring public content (static websites, CDN assets), use CloudFront or a dedicated CDN rather than direct bucket access. Audit existing buckets regularly with automated tooling.
Secrets in Environment Variables and Source Code
API keys, database passwords, and cloud provider credentials committed to source code or stored in plaintext environment variables are found in the majority of cloud environments we assess. They appear in `.env` files checked into repositories, in EC2 instance user data, in Lambda environment variables, in Kubernetes ConfigMaps, and in container images.
The risk is amplified by the fact that secrets in version control have a permanent history — even if a secret is removed from the current codebase, it remains accessible in the git history unless the history is actively scrubbed.
Use native secrets management: AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Retrieve secrets at runtime, never store them in code or static configuration. Implement pre-commit hooks with tools like GitLeaks or detect-secrets to catch secrets before they are committed. Rotate any secret that has ever touched source control, regardless of current exposure status.
Security Groups and Firewalls Open to 0.0.0.0/0
Overly permissive network access rules — particularly inbound rules allowing traffic from any source on sensitive ports — are routine findings in cloud assessments. Common patterns include SSH (port 22) open to the internet "for convenience," RDP (3389) accessible externally, and database ports (5432, 3306, 1433) reachable from outside the VPC.
The attack surface this creates is significant: internet-facing SSH and RDP are constantly scanned and targeted by credential stuffing and brute force attacks. An open database port with weak credentials or an unpatched service is a direct path to data exfiltration.
No management ports (SSH, RDP) should be open to the internet. Use AWS Systems Manager Session Manager, Azure Bastion, or a VPN for administrative access. Database services should be in private subnets with no direct internet access. Apply the principle of least-privilege networking: restrict inbound rules to the specific IP ranges and ports required, and audit security groups regularly for drift.
Logging and Monitoring Gaps
Inadequate logging is not a misconfiguration that enables initial compromise — but it is the misconfiguration that turns a contained incident into an undetected breach. In environments where CloudTrail is disabled, where logs are not forwarded to a central SIEM, or where alerting on critical events (root account usage, IAM changes, security group modifications) is absent, attacks proceed undetected for weeks or months.
We regularly find environments where CloudTrail logging was never enabled in all regions, where S3 access logs were disabled, where VPC flow logs were not collected, and where there was no alert configured for root account login — one of the highest-signal security events in any AWS environment.
Enable CloudTrail in all regions with log file validation. Enable S3 access logging on sensitive buckets. Enable VPC flow logs. Configure GuardDuty. Set up alerts for: root account usage, IAM policy changes, security group modifications, and failed authentication events. Send all logs to a centralised, tamper-resistant destination with appropriate retention periods.
The Pattern Behind All Five
These five misconfigurations share a common root cause: they are the result of prioritising speed over security at the point of configuration, without a mechanism to catch and correct the drift over time.
The organisations that manage cloud security well are not the ones with the strictest policies — they are the ones with automated controls that make secure configuration the default, and automated monitoring that surfaces deviations quickly. Cloud security is not a one-time audit. It is a continuous process.
Quick self-check: Can you answer yes to all of these? No IAM wildcard permissions on production roles. No public storage buckets. No secrets in source control. No management ports open to the internet. CloudTrail enabled in all regions with alerting. If not — you know where to start.
Want to know what's in your cloud environment?
Our cloud security review covers IAM, network exposure, data security, logging, and architecture risks — across AWS, Azure, and GCP. Clear findings, practical remediation.
Book a Free Consultation →