Cloud Misconfigurations to Fix First: An AWS, Azure and Google Cloud Checklist

Under the shared responsibility model, your cloud provider secures the data centres, hardware and core services. Everything you configure on top, from who can sign in to which storage is public, is your responsibility. That is where most cloud security problems start: not with an exotic exploit, but with a setting left open, a key never rotated or a permission granted “just for now”.

The good news is that defaults have improved. Since April 2023, new Amazon S3 buckets block public access and disable access control lists by default. Google Cloud organisations created on or after 3 May 2024 get secure-by-default policies that, among other things, stop default service accounts from receiving the broad Editor role and block persistent service account keys. The catch is that these defaults protect new resources. Accounts, subscriptions and projects created earlier keep their old settings, and that is where older risk tends to hide.

Fix first: the checklist

1. Identity and access

In the cloud, identity is the perimeter. One over-privileged identity can undo every other control.

• AWS: protect the root user with MFA, remove its access keys, and use IAM Identity Center or roles instead of long-lived IAM user keys
• Azure: require MFA through Conditional Access, block legacy authentication, and use Privileged Identity Management so Global Administrator is granted just in time rather than permanently
• Google Cloud: avoid the basic Owner and Editor roles, grant predefined or custom roles at the narrowest level, and disable service account key creation where workloads can use attached service accounts or workload identity federation
• Everywhere: review administrator accounts every quarter and keep two monitored break-glass accounts

2. Public exposure

• Storage: find every S3 bucket, Azure storage container and Cloud Storage bucket that allows anonymous access, and confirm each one is meant to be public
• Snapshots and images: check that disk snapshots, machine images and database backups are not shared publicly
• Network rules: remove security group, network security group and firewall rules that allow 0.0.0.0/0 to SSH (22), RDP (3389) or database ports, and use a bastion, VPN or identity-aware proxy instead
• Databases and management interfaces: make sure none has a public endpoint it does not need

3. Logging and monitoring

You cannot investigate what you did not record, and default retention is often short: AWS CloudTrail event history and the Azure activity log each keep 90 days.

• AWS: create an organisation-wide CloudTrail trail across all regions, with log file validation, delivered to a separate, locked-down account
• Azure: send activity logs and resource diagnostic logs to a Log Analytics workspace or storage account with the retention you need
• Google Cloud: Admin Activity audit logs are always on, but Data Access audit logs are off by default for most services, so enable them for services that hold sensitive data
• Everywhere: turn on the native threat detection service: Amazon GuardDuty, Microsoft Defender for Cloud or Security Command Center

4. Secrets and encryption

• Keep secrets in AWS Secrets Manager, Azure Key Vault or Google Secret Manager, never in code, container images, environment files or infrastructure-as-code repositories
• Scan repositories and CI pipelines for leaked keys, and rotate any you find
• Use customer-managed keys where regulation or contracts require them, and restrict who can use and delete those keys

5. Compute and workloads

• AWS: require IMDSv2 on EC2 instances, so the instance metadata service cannot be abused through server-side request forgery to steal role credentials
• Remove public IP addresses from instances that do not need them
• Patch images regularly, and rebuild rather than patch in place where you can
• Kubernetes: keep the API server private, enforce RBAC and apply Pod Security Standards; our container and Kubernetes security review covers this in depth

6. Guardrails and drift

• Use AWS service control policies, Azure Policy and Google Cloud organisation policies to prevent the risky settings above, not only detect them
• Scan Terraform and other infrastructure-as-code before deployment
• Measure each environment against the CIS Benchmarks for its provider and track the score over time

How to run a review that finds what matters

Automated posture tools are good at listing misconfigurations. They are less good at telling you which ones an attacker could chain together. A useful review does both:

1. Inventory every account, subscription and project, including the forgotten ones created for a pilot.
2. Run an automated benchmark check to find the known misconfigurations quickly.
3. Validate attack paths by hand: for example, a public instance with an over-privileged role that can read a bucket of customer data.
4. Prioritise by exploitability and business impact, not by the number of findings.
5. Fix through infrastructure-as-code and guardrails, so the issue cannot return with the next deployment.
6. Retest, and keep the evidence for auditors and customers.

Get an independent review

Our cloud security review covers AWS, Azure and Google Cloud, combining benchmark checks with manual attack-path testing, and our secure configuration review hardens the systems underneath. See the full range of cloud and infrastructure security services.

Sources

• AWS: Amazon S3 now applies two security best practices to all new buckets by default
• Google Cloud: Manage Google Cloud security baseline constraints
• Center for Internet Security: CIS Benchmarks