According to Gartner, through 2025, 99% of cloud security failures will be the customer's fault. Not the cloud provider's. The customer's.
That's not a criticism. It's the nature of the shared responsibility model. AWS, Azure, and GCP secure the underlying infrastructure. What you build on top of it — the configuration, the access controls, the data — is your responsibility.
And most organisations get this wrong in predictable, fixable ways.
The most common misconfigurations we see
1. Publicly accessible S3 buckets (or Azure Blob containers)
This one has caused some of the most high-profile breaches of the past five years. A storage bucket intended for internal use is accidentally left public. It's indexed by search engines or scanners. Data is exposed.
AWS now blocks public access to new S3 buckets by default. But legacy buckets created before these defaults changed may still be public. If you haven't audited this recently, do it now.
Check: AWS Console → S3 → Block Public Access (account settings). Verify each bucket individually.
2. Overpermissive IAM roles
IAM (Identity and Access Management) controls who and what can access your cloud resources. The most common problem: roles with * permissions (full access) given to Lambda functions, EC2 instances, or services that only need to read one specific resource.
If one of those services is compromised, an attacker has full access to your AWS account.
Fix: Apply least privilege. Every IAM role should have only the permissions it needs to perform its specific function. Use AWS IAM Access Analyzer to identify unused permissions.
3. Security groups with 0.0.0.0/0 inbound rules
A security group rule that allows inbound traffic from 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) means your server is accessible from the entire internet.
This is fine during initial setup. It becomes a critical vulnerability when left in production indefinitely.
Fix: Restrict SSH/RDP access to specific IP ranges (your office, your VPN). Use AWS Systems Manager Session Manager instead of SSH where possible.
4. Disabled CloudTrail (or equivalent logging)
CloudTrail is AWS's audit log. Every API call, every action, logged. If you don't have it enabled, you have no visibility into what's happening in your environment — and no forensic capability if something goes wrong.
Fix: Enable CloudTrail in all regions. Send logs to a separate S3 bucket with write-once policies to prevent tampering.
5. Root account without MFA
The AWS root account has unrestricted access to everything. If it's compromised, everything is compromised.
Fix: Enable MFA on the root account immediately. Then don't use it. Create IAM users with appropriate permissions for day-to-day work.
A quick cloud security posture check
If you're not sure where to start, these free tools will give you an immediate picture:
- AWS Security Hub — aggregates security findings across your AWS account
- ScoutSuite — open-source multi-cloud security auditing tool
- Prowler — AWS-specific security assessment tool
- Azure Security Centre / Microsoft Defender for Cloud — equivalent for Azure
Running any of these will surface your most critical misconfigurations within an hour.
The DevSecOps angle
Cloud misconfigurations often originate not in operations, but in development. Infrastructure-as-Code (Terraform, CloudFormation) templates with insecure defaults get committed to repos and deployed to production.
Catching this at the pipeline stage — before deployment — is far more effective than fixing it afterwards. Tools like Checkov, tfsec, and Trivy can scan IaC files as part of your CI/CD pipeline.
This is the shift-left principle applied to cloud security: find misconfigurations where they're cheapest to fix, before they become production problems.
If you want a structured cloud security review of your AWS or Azure environment, Xcevia offers cloud security assessments starting from £2,000. We identify your critical misconfigurations and provide a clear remediation plan.