One of the most persistent misunderstandings about the cloud is that moving to AWS, Azure or Google Cloud makes security "their problem". It does not. Every major provider works under a shared responsibility model: they secure the cloud itself, and you secure what you put in it. Most cloud security incidents that make the news involve the customer's half, such as an open storage bucket, a leaked access key or an unpatched server, not a failure of the provider's data centre.
The shared responsibility model in one line
AWS summarises it neatly as security "of" the cloud versus security "in" the cloud. The provider is responsible for the physical buildings, hardware, network backbone and the virtualisation layer. You are responsible for how you configure and use the services on top.
Where exactly the line falls depends on the service type:
| Responsibility | IaaS (virtual machines) | PaaS (managed DB, app platform) | SaaS (email, CRM) |
|---|---|---|---|
| Physical security, hardware, hypervisor | Provider | Provider | Provider |
| Operating system patching | You | Provider | Provider |
| Network controls (firewall rules, security groups) | You | Mostly you | Provider |
| Application code and configuration | You | You | Provider (you configure settings) |
| Identity and access management | You | You | You |
| Your data and who can see it | You | You | You |
Notice the bottom two rows. Whatever service you use, identity and data are always yours. The official descriptions are worth a read: AWS, Microsoft Azure.
Your half: the essential controls
1. Lock down the root or owner account
The account you used to sign up has unlimited power, including the ability to delete everything and change billing. Enable multi-factor authentication (MFA) on it, store its credentials securely, and stop using it for daily work. Create individual administrator accounts instead.
2. Use individual identities and least privilege
Every person gets their own login; shared accounts make it impossible to know who did what. Grant only the permissions each role needs. A developer deploying to one project should not be able to delete production databases in another. Review permissions when people change roles or leave.
3. Avoid long-lived access keys
Static API keys pasted into scripts, CI pipelines or, worst of all, committed to Git repositories are a frequent cause of breaches. Prefer temporary credentials: IAM roles for servers, workload identity for containers, and single sign-on for people. Where keys are unavoidable, rotate them and scope them narrowly. Tools such as git-secrets or gitleaks can scan repositories for accidentally committed secrets.
4. Control network exposure
Security groups and network firewall rules decide what the internet can reach. A frequent mistake is opening SSH (port 22), RDP (3389) or database ports (3306 for MySQL, 5432 for PostgreSQL) to 0.0.0.0/0, meaning everyone. Restrict administrative ports to known IP addresses or a VPN, keep databases in private subnets, and expose only ports 80 and 443 for web traffic. You can confirm what is reachable from outside with our port checker.
5. Keep storage private by default
Object storage buckets are private when created on the major platforms today, but someone can still make them public. Turn on account-level settings that block public access (for example S3 Block Public Access), and grant access to specific files through signed, time-limited URLs instead of public buckets.
6. Encrypt data
Enable encryption at rest for disks, databases and storage; on most services this is a setting or already the default. Use TLS for data in transit, including connections between your application and its database. Check public endpoints with an SSL checker to confirm certificates are valid and current.
7. Patch what you run
On IaaS, the operating system and every package on it are your responsibility. Enable automatic security updates where suitable. On Ubuntu and Debian:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgradesOn RHEL-based systems, dnf-automatic serves the same purpose.
8. Turn on logging and alerts
Enable the provider's audit log (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) in every region and account, and keep the logs somewhere attackers cannot easily delete them. Add alerts for high-risk events: root account logins, changes to IAM policies, security groups opened to the world, and unusual spending, which can indicate stolen credentials being used for cryptocurrency mining.
9. Back up independently
The provider keeps its infrastructure available, not your data recoverable from your own mistakes. Keep backups with separate credentials, ideally in a separate account, and test restores.
10. Use the provider's built-in posture tools
AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center scan your configuration for common mistakes against recognised benchmarks such as those from the Center for Internet Security (CIS). Start with their free or basic tiers and fix the high-severity findings first.
Where businesses commonly slip
- Assuming a managed service is configured securely by default for their use case.
- Test environments with real customer data and weaker controls.
- Former employees or contractors whose access was never removed.
- No one assigned to review security alerts, so they pile up unread.
Good cloud security is mostly consistent basics rather than exotic tools. If you would like help reviewing an existing setup, see our cloud solutions page.
Key takeaways
- Under the shared responsibility model, the provider secures the infrastructure; you secure your configuration, identities and data.
- The more managed the service, the less you patch, but access control and data are always yours.
- Protect the root account with MFA, use least privilege, and avoid long-lived keys.
- Restrict open ports, keep storage private, encrypt, log, back up and act on alerts.