Cloud Security Misconfiguration Checklist: 10 Things to Fix in AWS, GCP and Azure

Most cloud breaches aren’t sophisticated. They’re misconfigurations: a bucket left public, a database open to the internet, an access key that should have been rotated two years ago. Attackers scan for these constantly because they work.

The fixes are almost always simple. The hard part is knowing what to check and doing it consistently across every account and region. Here’s a checklist of the ten misconfigurations worth auditing first, with the equivalent on each major cloud.

1. Public object storage

The single most common cause of cloud data leaks. A bucket made public “temporarily” for a demo, never locked back down.

• AWS: S3 buckets with public ACLs or bucket policies allowing *. Turn on S3 Block Public Access at the account level.
• GCP: Cloud Storage buckets granting allUsers or allAuthenticatedUsers.
• Azure: Storage accounts or blob containers with anonymous public read access.

Unless a bucket is deliberately serving a public website, it should be private.

2. Security groups and firewalls open to the world

Management ports exposed to 0.0.0.0/0 are an open invitation. SSH (22), RDP (3389), and database ports (3306, 5432, 27017) should never be reachable from the entire internet.

• AWS: security group rules allowing 0.0.0.0/0 on sensitive ports.
• GCP: VPC firewall rules with a 0.0.0.0/0 source range.
• Azure: Network Security Group rules allowing Any source on management ports.

Restrict to known IP ranges, or front access with a bastion / VPN / Identity-Aware Proxy.

3. Unused and stale access keys

Long-lived credentials are a liability. The longer a key exists, the more places it’s been copied to: laptops, CI configs, that one Slack message.

• AWS: IAM users with access keys older than 90 days, or keys that haven’t been used in months.
• GCP: user-managed service account keys (prefer short-lived credentials and workload identity).
• Azure: service principal secrets nearing or past expiry.

Rotate regularly, delete what’s unused, and prefer role-based, short-lived credentials over static keys.

4. Unencrypted storage and databases

Encryption at rest is free and on by default in most services now, but older resources and manual setups often missed it.

• AWS: unencrypted EBS volumes, RDS instances, and S3 buckets.
• GCP: while Google encrypts by default, check for resources not using customer-managed keys where policy requires them.
• Azure: managed disks or SQL databases without encryption enabled.

5. Overly permissive IAM

The principle of least privilege is easy to state and hard to enforce. Watch for:

• Policies granting *:* (full admin) to users or roles that don’t need it.
• Wildcard resource permissions where a specific ARN would do.
• Service accounts with project-wide Owner or Editor in GCP.
• Azure role assignments at subscription scope that should be resource-group scoped.

6. Disabled logging and audit trails

You can’t investigate what you didn’t record. Audit logging should be on everywhere.

• AWS: CloudTrail enabled in all regions, logs delivered to a locked-down bucket.
• GCP: Cloud Audit Logs enabled for admin and data access.
• Azure: Activity Logs and diagnostic settings exporting to a Log Analytics workspace.

7. No MFA on privileged accounts

Multi-factor authentication on the root/owner account and any admin user is non-negotiable. Check that the AWS root account has MFA and no active access keys, that GCP super-admins use MFA, and that Azure global admins are covered by Conditional Access requiring MFA.

8. Publicly exposed databases and management endpoints

Beyond open ports, look for managed services with public endpoints enabled by default:

• AWS: RDS or Redshift instances with Publicly Accessible set to yes.
• GCP: Cloud SQL instances with a public IP and no authorized network restriction.
• Azure: SQL servers with “Allow Azure services and resources to access this server” left broadly open.

Keep data tiers on private networks.

9. Missing TLS and weak transport settings

Data in transit deserves the same care as data at rest. Check for load balancers and storage allowing plaintext HTTP, outdated TLS versions, and S3 buckets without a policy enforcing aws:SecureTransport.

10. Default VPCs, secrets in plaintext, and forgotten resources

The long tail: default VPCs nobody hardened, secrets hard-coded in environment variables or user-data scripts instead of a secrets manager, and old resources from departed projects that still hold access. These don’t fit a single rule, but they’re where real incidents start.

Why a checklist isn’t enough

A checklist tells you what to look for. It doesn’t scale to every resource, in every region, across three clouds, every week. Doing this by hand, you’ll check the obvious accounts and miss the forgotten ones, which is exactly where the risk lives.

That’s the gap automated scanning fills. Graymole runs 473 read-only checks across AWS, GCP, and Azure in a single pass (every item on this checklist and far more) using only a read-only role with no agents and no write access. It flags public buckets, open security groups, stale keys, unencrypted storage, and over-broad IAM, then traces each finding back to the raw cloud API response so you can verify it yourself.

Because it’s read-only and runs in minutes, you can scan on a schedule and catch misconfigurations as they appear instead of discovering them after an incident. Run your first scan free and see where you stand.