When cloud security breaches make headlines, the blame rarely falls on the major cloud providers themselves. More often, the vulnerability lies in how ops teams configure and manage their cloud environments. Misconfigured storage buckets, overly permissive IAM roles, and absent monitoring are recurring culprits. The good news: most of the controls needed to prevent these failures are standard offerings from every major cloud platform and cost little beyond the time to implement them correctly.
The following six cloud security policies form a layered baseline. They won’t cover every edge case, but they dramatically reduce the attack surface for the most common categories of cloud breach.
1. Secure Cloud Accounts and Use Groups for Access Control
Start with the basics: lock down your root or super-admin account. Use a strong, unique credential, enable multi-factor authentication on it, and avoid using it for day-to-day operations. Instead, create a dedicated administrative group and assign permissions to that group rather than to individual users. This makes auditing easier and reduces the risk of orphaned, over-privileged accounts.
Design additional groups around the principle of least privilege:
- Read-only group – for users and service accounts that run reports or query state.
- Operator group – for users who need to restart or manage workloads but should not be able to modify resource definitions.
- Administrator group – for fully trusted ops engineers, scoped to specific projects or regions where possible.
When you need to temporarily disable an account, apply a no-access policy to it rather than deleting it. Removing that policy later restores the account’s original permissions cleanly, without risk of unintended configuration drift.
One critical rule: never modify built-in or managed roles provided by the cloud platform. If you need a customised version, copy the role first, then edit the copy. Modifying a vendor-managed role can have unexpected side effects across all principals that inherit it.
2. Enable Two-Factor Authentication on Every Account
Every major cloud provider supports two-factor authentication (2FA), and most actively encourage it. There is no legitimate operational reason to skip it. 2FA significantly reduces the risk from stolen or guessed credentials, which remain one of the most common initial access vectors in cloud environments.
Add 2FA enforcement to your new-deployment checklist so it becomes a default, not an afterthought. For organisations managing large numbers of users, investigate identity provider (IdP) integrations that enforce 2FA centrally rather than relying on individual users to self-configure it.
3. Restrict Infrastructure Access with Firewall Rules
Many cloud migrations move previously internal workloads onto public-facing infrastructure without adequately tightening network access controls. The default posture for any new resource should be: all ports closed unless there is a specific, documented reason to open one.
Practical steps:
- Review security group and network ACL rules for every deployed resource. Remove any rule that permits broad ingress (for example,
0.0.0.0/0on SSH or RDP ports) unless it is genuinely required. - Use the cloud provider’s native firewall or web application firewall (WAF) capabilities where available to filter traffic to externally exposed services.
- Make “deny by default” an explicit part of your cloud security policy documentation, so new team members don’t open ports as a troubleshooting shortcut and forget to close them.
4. Limit Geographic and IP-Based Access Where Appropriate
If a workload serves customers or internal users in a defined geographic region, or from a known set of IP addresses, lock access down to that scope. Most cloud providers allow you to apply geo-based or CIDR-based access policies at the identity, network, or load balancer level.
This is a low-effort control that materially reduces exposure. Opportunistic bots, worms, and credential-stuffing attacks typically originate from outside an organisation’s expected network footprint. Restricting access to known ranges eliminates most of that noise without affecting legitimate users.
Review these restrictions periodically. As your team’s working locations or customer base evolves, outdated IP allowlists can become a support burden or a false sense of security.
5. Replace Passwords with Public Key Infrastructure (PKI)
Passwords are operationally expensive and cryptographically weak compared to key-based authentication. Public Key Infrastructure (PKI) authenticates users by verifying possession of a private key rather than a shared secret, which eliminates several entire categories of attack: credential phishing, brute-force login attempts, and password reuse across services.
All major public cloud providers support PKI for SSH access to compute instances, and many extend key-based authentication to API access as well. When migrating to PKI:
- Generate key pairs with a modern algorithm (consult your provider’s current recommendations).
- Protect private keys with a strong passphrase. If the storage medium holding the private key is lost, the passphrase buys time to rotate and revoke the compromised key.
- Do not store private keys on shared workstations or in unencrypted files in source repositories.
- Consider hardware security keys (such as those from YubiKey or similar vendors) for high-privilege accounts. These require physical interaction with the device to authenticate, providing a strong defence against remote compromise.
If you manage keys for multiple users or teams, use a dedicated secrets management solution rather than manually distributing key files. Cloud-native key management services can simplify rotation and auditing at scale.
6. Enable Auditing and Centralised Log Monitoring
Logs are only valuable if someone—or something—is actually reading them. Cloud environments generate logs in volume: API calls, authentication events, network flows, configuration changes, and more. Without a strategy to capture and analyse this data, you lose the ability to detect breaches in progress, investigate incidents after the fact, or demonstrate compliance during audits.
Steps to implement effective cloud monitoring:
- Enable the cloud provider’s native audit logging service (such as AWS CloudTrail, Azure Monitor, or GCP Cloud Audit Logs) across all accounts and regions from day one.
- Ship logs to a centralised, tamper-resistant store rather than leaving them scattered across individual service consoles.
- Set up alerting rules for high-priority events: root account logins, IAM policy changes, public exposure of storage buckets, and unusual API call volumes.
- Use a log analysis tool that can surface actionable signals from the noise—whether that’s a cloud-native SIEM, an open-source stack, or a commercial observability platform.
Monitoring is not purely a security function. The same log data supports capacity planning, cost attribution, performance troubleshooting, and change management. Investing in it early pays dividends across the entire operations lifecycle.
Putting It Together
None of these six policies requires specialist security expertise or significant budget. They are hygiene controls—the baseline that any cloud deployment should have before it carries production workloads. Skipping them doesn’t save time; it defers cost while compounding risk. A layered approach that combines strong identity controls, minimal network exposure, key-based authentication, and active monitoring makes it substantially harder for an attacker to gain and maintain access to your cloud environment.
Treat this list as a starting checklist, not a complete security programme. As your cloud footprint grows, build on these foundations with additional controls suited to your threat model, compliance requirements, and architecture.