Your Cloud Infrastructure

The defaults are not secure. Every major cloud breach in the last five years — Capital One, Twitch, Samsung, Toyota — traced back to a misconfiguration that the cloud provider’s default settings didn’t prevent. AWS, Azure, and GCP give you the tools to build Fort Knox or a house of cards. The platform doesn’t care which one you pick. And the usual suspects know exactly which default settings to probe first.

This is the checklist. Not theory, not architecture diagrams — the specific settings and configurations that would have prevented most of the breaches you’ve read about. Go through it. Check every item. The cloud provider’s shared responsibility model means everything above the hypervisor is your problem.

DO / DON’T

DO:

• Treat cloud defaults as insecure until proven otherwise
• Enable MFA on every account, especially root/owner accounts
• Enable logging before you do anything else
• Block public access to storage by default
• Review IAM policies quarterly at minimum
• Use infrastructure-as-code so your security posture is version-controlled

DON’T:

• Use the root account for daily operations — ever
• Create IAM policies with "Effect": "Allow" on "Resource": "*" unless you absolutely must
• Leave default security group rules in place
• Assume the cloud provider secures your workloads — that’s your job
• Store secrets in environment variables, code, or config files
• Open 0.0.0.0/0 on any port “temporarily” — temporary becomes permanent

Identity and Access Management

IAM is where most cloud breaches begin. One overly permissive policy, one set of leaked credentials, one forgotten service account — and the whole environment is compromised.

Root / Owner Account Lockdown

• Enable MFA immediately. Hardware key preferred (YubiKey), TOTP app as fallback. The root account can do everything, including deleting all other accounts. Protect it accordingly.
• Never use the root account for daily work. Create individual IAM accounts with specific permissions. The root account should be used only for the handful of tasks that require it (billing changes, account closure).
• Store root credentials offline. Print the password and MFA recovery codes. Store them in a physical safe. Not a password manager — those can be compromised too.
• Enable alerts on root account usage. Any root login should trigger an immediate notification. If you get one and it wasn’t you, that’s a five-alarm fire.

IAM Policies

• Least privilege, enforced programmatically. Every policy should grant the minimum permissions needed. AWS IAM Access Analyzer, Azure AD Access Reviews, and GCP IAM Recommender all identify overly permissive policies — use them.
• No inline policies. Use managed policies attached to groups or roles. Inline policies are harder to audit and easier to lose track of.
• Require MFA for sensitive operations. IAM policy conditions can require MFA for actions like deleting resources, modifying security groups, or accessing production data.
• Service accounts get service-specific permissions. A CI/CD pipeline doesn’t need AdministratorAccess. A Lambda function doesn’t need s3:*. Scope it tight.
• Rotate credentials. Access keys should be rotated every 90 days. Better yet, use IAM roles with temporary credentials instead of long-lived access keys.

CISA’s Cloud Security Technical Reference Architecture provides the baseline framework for federal cloud deployments, but the principles apply to everyone.

Logging and Monitoring

If you can’t see what’s happening, you can’t detect a breach. Enable logging before you deploy a single workload.

Centralized Logging

• AWS: Enable CloudTrail in all regions, including regions you don’t use. Attackers love spinning up resources in regions you’re not watching. Enable S3 server access logging and VPC Flow Logs.
• Azure: Enable Activity Log, Azure Monitor, and NSG Flow Logs. Forward everything to a Log Analytics workspace.
• GCP: Enable Cloud Audit Logs (Admin Activity, Data Access, System Event). Export to BigQuery or Cloud Storage for retention.

Log Integrity

• Immutable storage. Write logs to a bucket with object lock / immutable retention. If an attacker compromises your environment, the first thing they’ll try to do is delete the evidence.
• Cross-account log storage. Send logs to a separate account that your production environment can write to but not delete from. NIST SP 800-92 covers log management guidance.

Alerting

• Unauthorized API calls. Alert on AccessDenied events — they indicate someone probing for permissions.
• Root account usage. Any activity on the root account should fire an alert.
• Security group changes. Any modification to firewall rules should be reviewed.
• New IAM accounts or policies. Unauthorized creation of access is a classic persistence technique — MITRE ATT&CK T1136 (Create Account).

Network Controls

VPC / VNet Design

• Separate production from development. Different VPCs/VNets, different accounts if possible. A compromised dev environment shouldn’t provide a path to production.
• Private subnets for everything that doesn’t need direct internet access. Databases, application servers, and internal services belong in private subnets. Use NAT gateways for outbound access only.
• No 0.0.0.0/0 ingress rules. If a security group allows all traffic from any IP on any port, you’ve left the front door open. Audit for this regularly — it’s the single most common misconfiguration.

Security Groups / NSGs

• Default deny. Start with no inbound rules and add only what’s needed.
• Scope to specific IPs or CIDR ranges. SSH (port 22) and RDP (port 3389) should never be open to the internet. Use bastion hosts, VPN, or session managers (AWS Systems Manager Session Manager).
• Separate security groups by function. Web servers, application servers, and databases should each have their own security group with rules scoped to the minimum required communication between tiers.

Storage Security

Block Public Access

• AWS S3: Enable “Block Public Access” at the account level. This overrides bucket-level policies and prevents accidental public exposure. This single setting would have prevented dozens of headline breaches.
• Azure Blob: Disable anonymous access at the storage account level.
• GCP Cloud Storage: Use uniform bucket-level access and disable object ACLs.

Encryption at Rest

• Enable server-side encryption on all storage. Use customer-managed keys where the data warrants it.
• For S3: enable default encryption with SSE-S3 (minimum) or SSE-KMS (better control, audit trail of key usage).
• Encrypt EBS volumes, RDS instances, and any other persistent storage.

Secrets Management

Hardcoded secrets are the cockroaches of cloud security — they’re everywhere and nearly impossible to fully eliminate.

• Use a secrets manager. AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or HashiCorp Vault. Secrets belong in dedicated, audited, access-controlled stores — not in code, not in environment variables, not in config files.
• Rotate secrets automatically. Secrets Manager and Vault can rotate database passwords, API keys, and certificates on a schedule without downtime.
• Scan for exposed secrets. Tools like truffleHog, GitLeaks, and GitHub’s built-in secret scanning catch credentials committed to repos. Run them in CI/CD. Every commit, no exceptions.

CIS Benchmarks

The Center for Internet Security (CIS) publishes detailed hardening benchmarks for AWS, Azure, and GCP. These are consensus-based, independently audited checklists that cover everything on this page and more.

• AWS: CIS Amazon Web Services Foundations Benchmark
• Azure: CIS Microsoft Azure Foundations Benchmark
• GCP: CIS Google Cloud Platform Foundation Benchmark

Run the benchmarks against your environment. Tools like Prowler (AWS), ScoutSuite, and cloud-native services (AWS Security Hub, Azure Defender, GCP Security Command Center) can automate the assessment.

Fix everything flagged as Critical or High. Review everything flagged as Medium. This isn’t optional — it’s the bare minimum.

The cloud gives you power. It also gives you the power to misconfigure yourself into a headline. Go through this list. Check every item. The shared responsibility model means everything above the foundation is yours to secure — or yours to lose.