Securing Website Infrastructure on the Cloud: A Hardening Checklist

The website is only as safe as the account hosting it

Application code gets reviewed. The cloud account around it frequently does not. In assessment after assessment the highest-severity findings are not code bugs but configuration: a public storage bucket, an over-permissive IAM role, an unencrypted database reachable from the internet.

Identity and access

• No long-lived access keys — use workload identity or instance roles
• MFA enforced on every human account, without exception for admins
• Least-privilege IAM policies, reviewed quarterly; no wildcard * actions on production
• Separate accounts or subscriptions for production, staging and sandbox

Network exposure

• Databases and caches in private subnets only
• Security groups scoped to specific ports and source ranges
• All ingress terminated at a WAF or CDN with TLS 1.2+ and HSTS
• Administrative access via bastion or zero-trust proxy, never open SSH/RDP

Data protection

• Encryption at rest with customer-managed keys where regulation requires it
• Bucket policies default-deny public access; block public ACLs at the org level
• Automated backups with periodic restore tests — untested backups are not backups

Detection and response

• Centralised logging: cloud audit trail, application logs, WAF logs, all shipped off-account
• Alerts on IAM policy changes, root usage, security group opening, and mass data reads
• A written incident runbook with named owners and out-of-band communication

Continuous posture management

Point-in-time hardening decays. Wire CSPM checks and infrastructure-as-code scanning into CI so drift is caught at merge time, not during an audit. Pair that with quarterly configuration reviews against CIS Benchmarks.

Prioritisation

If you can only do five things this quarter: remove public data exposure, enforce MFA, cut wildcard IAM permissions, enable centralised logging with alerting, and test your restores.