Cloud Security Checklist: Protecting Your Data in the Cloud

Cloud providers secure the underlying platform. You secure what you put on it and how you configure it. Misconfiguration and weak access control are common causes of cloud incidents, and both sit on the customer’s side of the line. The split of responsibility moves depending on the service model.

Identity, access and data are your responsibility in every model. That is where this checklist spends most of its effort. Each item below is written as a statement you can confirm. Mark it yes, no or not applicable, and give every no an owner and a date.

• Every human account uses multi-factor authentication, with administrators using the strongest method available.
• The account owner or root login is protected with multi-factor authentication, has no access keys, and is used only for tasks that require it.
• A break-glass account exists, is stored securely, is alarmed on use, and has been tested.
• Single sign-on connects the cloud to your central identity provider, so leavers lose access when their directory account is disabled.
• Roles grant least privilege. No one has broad administrator rights for daily work.
• Administrators use separate accounts for administration and for email and browsing.
• Long-lived access keys are avoided. Where they exist, each is documented, scoped and rotated.
• Service accounts and application identities have only the permissions the application needs.
• Access is reviewed on a schedule and unused accounts and permissions are removed.

• Networks are segmented, with production separated from non-production and sensitive tiers separated from public-facing ones.
• Security groups and network rules default to deny and open only the ports and sources a service requires.
• No remote administration ports, such as SSH or RDP, are open to the whole internet. Administrators connect through a controlled access path.
• Databases and internal services have no public addresses.
• Private endpoints or private connectivity are used to reach sensitive services without crossing the public internet.
• Public web applications sit behind a web application firewall, and denial of service protection is enabled.
• Network flow logs are enabled and retained.
• Outbound traffic is restricted for sensitive workloads, so a compromised system cannot freely send data out.

• Data is encrypted at rest on every storage service, with the setting enforced by policy.
• Data is encrypted in transit, using current versions of TLS, and legacy protocols are disabled.
• Encryption keys are managed in a key management service, with rotation enabled and key administration separated from data administration.
• Public access to storage is blocked at the account level, and any exception is documented and approved.
• Data is classified, and the most sensitive classes have extra controls and monitoring.
• Secrets such as passwords and API keys live in a secrets manager, not in code, scripts or configuration files.
• Backups are encrypted, kept in a separate account or location, protected from deletion, and restore-tested.
• Retention and deletion rules exist and are applied.

• Infrastructure is defined as code and changes go through review.
• A posture management tool or built-in checks compare your configuration against a recognized baseline, and findings have owners and due dates.
• Server images are hardened and patched, and patching is automated or scheduled.
• Container images and code dependencies are scanned for known vulnerabilities before deployment.
• Unused services, regions and resources are disabled.

• Audit logging is enabled in every account and region, including administrator and API activity.
• Logs go to a central location that administrators of the monitored accounts cannot alter or delete.
• Alerts exist for high-risk events: use of the root login, changes to access policies, creation of new keys, disabled logging and storage made public.
• A security monitoring function reviews alerts. This may be your own team or a provider’s, with response times written down.
• An incident response plan covers cloud scenarios such as leaked keys and a compromised account, and names who decides what.
• The plan has been exercised at least once, and contact details are current.

• Applicable obligations are identified, such as PIPEDA, provincial privacy laws, sector rules and contractual requirements.
• Data residency requirements are met, including where backups, logs and support access are located.
• The provider’s independent assurance, such as SOC 2 reports or ISO/IEC 27001 certificates, has been reviewed and its scope confirmed to cover the services you use.
• Required tags, approved regions and approved services are enforced as policy.
• Workloads are spread across zones where availability requires it, and recovery time and recovery point objectives are written down and tested.
• A breach notification process exists. Under PIPEDA, organizations must report breaches of security safeguards that create a real risk of significant harm, and Quebec has its own incident requirements for private-sector organizations.

Start with the items that close the most common paths to compromise.

1. Turn on multi-factor authentication for every human account, starting with administrators and the account owner.
2. Block public access to storage at the account level.
3. Close any remote administration ports that are open to the internet.
4. Enable audit logging in every account and region, and send it to protected central storage.
5. Check that backups exist, are separate from production, and have been restored at least once.

Then work through the rest in priority order. For the broader picture beyond the cloud, the enterprise security assessment checklist covers endpoints, email, people and third parties, and the zero trust guide explains the access model that ties many of these controls together.

• Assuming the provider handles configuration and access.
• Using shared administrator accounts with no multi-factor authentication.
• Leaving access keys in code repositories.
• Enabling logging but never reviewing it, or letting administrators delete it.
• Checking security once at launch instead of continuously.
• Keeping backups in the same account as production, where one compromise reaches both.
• Treating compliance paperwork as proof of security.

Ask these of the cloud provider, or of a managed service provider who operates the account for you.

• Which independent audit reports cover the services we use, and what do they exclude?
• Where is our data stored, including backups and logs, and who at the provider can access it?
• Who holds the administrator credentials and the account owner login, and how is their use recorded?
• How are security alerts monitored, by whom, and within what response time?
• What is the process and timeline for notifying us of a security incident?
• Can we obtain our logs and configuration if we end the relationship?

Is the cloud less secure than on-premises?

Not by nature. Providers invest heavily in physical and platform security, but the customer still configures access, networks and data protection. Cloud environments are secure or insecure mainly because of how they are configured and managed.

What is the shared responsibility model?

It is the division of security duties between provider and customer. The provider secures the facilities, hardware and platform. The customer secures identity, data and the configuration of what it deploys, and the exact split depends on whether the service is infrastructure, platform or software.

How often should we run through this checklist?

Automate the checks that can be automated and run them continuously. Review the rest, such as access reviews and incident exercises, on a fixed schedule, and again after any major change.

Do we need a separate tool to monitor cloud security?

Native monitoring covers many needs, particularly with one account. Organizations with several accounts or clouds often add a central tool so findings and logs are viewed in one place. Choose by what you need to see, and not by the product category.