Moving an application to the cloud removes a surprising amount of work: no data-centre lease, no failed disk to replace, no hypervisor patch at three in the morning. It does not remove responsibility. Someone still decides who can read the data, which port is public, how a key is used, and whether a deleted database can be restored.
Cloud security begins with that hand-off. The provider secures infrastructure and managed services within a defined boundary; the customer secures identities, data, configuration, and application use above it. The cloud is not automatically safer or less safe—it makes some controls easier to automate and some mistakes much faster to spread.
Shared Responsibility
The exact boundary differs by provider and service, but the general pattern is:
| Area | IaaS | PaaS | SaaS |
|---|---|---|---|
| Facilities, hardware, core network | Provider | Provider | Provider |
| Hypervisor or managed service platform | Provider | Provider | Provider |
| Guest operating system | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider for the SaaS product |
| Identities and access | Shared | Shared | Shared |
| Customer data and classification | Customer | Customer | Customer |
| Customer configuration | Customer | Customer | Customer |
| End-user devices and use of the service | Customer | Customer | Customer |
An IaaS customer does not secure the provider’s physical data center or underlying hypervisor. A SaaS provider does not manage every aspect of customer security: the customer still controls users, sharing, data, integrations, endpoint access, and many configuration choices.
Read the provider’s service-specific documentation. A managed database, object store, serverless function, and virtual machine have different boundaries even within the same cloud.
Deployment Models
- Public cloud: infrastructure and managed services operated by a provider for many customers with logical isolation.
- Private cloud: cloud-style infrastructure dedicated to one organization or hosted environment.
- Hybrid cloud: connected private or on-premises systems and public-cloud services.
- Multi-cloud: services from more than one cloud provider.
Private cloud is not inherently more secure. Isolation may simplify one threat while increasing the organization’s responsibility for patching, hardware, capacity, and operations. Multi-cloud can reduce dependence on one provider, but it often multiplies identities, policies, logs, and skills.
The Cloud Control Plane
Cloud APIs can create networks, copy data, change logging, and assign administrator access. A stolen control-plane credential may have more impact than access to one server.
Protect the control plane with:
- federation from a managed identity provider;
- phishing-resistant MFA for administrators;
- separate administrative accounts;
- least-privilege roles and short-lived sessions;
- just-in-time elevation for rare tasks;
- organization-level guardrails;
- alerts on high-risk changes;
- protected emergency accounts with tested procedures.
Avoid long-lived access keys. Use workload identity or instance roles so applications receive short-lived credentials without storing a secret in code.
Configuration and Exposure
Common cloud incidents involve ordinary configuration mistakes: public storage, broad security groups, anonymous endpoints, exposed snapshots, disabled logs, or cross-account trust that is wider than intended.
Useful practices include:
- infrastructure as code reviewed like application code;
- policy checks before deployment;
- separate accounts or projects for environments;
- default-deny network and identity policies;
- continuous inventory and configuration monitoring;
- ownership and expiry for exceptions;
- independent checks from outside the trusted network.
Cloud Security Posture Management (CSPM) tools can find known misconfigurations. They do not prove that every workload is secure or that a flagged setting is exploitable in context.
Data Protection
Start with classification and minimization. Knowing that a bucket is encrypted is less useful if no one knows what it contains or whether it should exist.
Encryption
Cloud services commonly encrypt storage by default and use TLS for network transport. Customer-managed keys may improve separation of duties, revocation control, or compliance evidence, but they add availability and operational risk.
Define:
- which service or application performs encryption;
- who can use and administer each key;
- how keys are rotated and recovered;
- what happens to old ciphertext;
- whether logs reveal plaintext or secrets;
- how deletion and retention are enforced.
TLS has replaced SSL. Current guidance should not recommend “SSL encryption.”
Backups and deletion
Backups need separate access, tested restoration, retention, and protection from the identities that administer production. Replication is not a backup if corruption or deletion immediately propagates.
Deletion may involve live objects, versions, snapshots, replicas, caches, and provider backup cycles. Document the actual lifecycle rather than assuming one API call erases every copy immediately.
Network Security
Virtual networks, subnets, security groups, route tables, private endpoints, load balancers, and web application firewalls provide different controls.
Keep management interfaces private where possible. Restrict outbound traffic for sensitive workloads, because an attacker may use egress for command-and-control or data theft. Network controls should support identity and application authorization, not replace them.
A web application firewall can reduce common HTTP attacks and absorb known patterns. It cannot understand every business rule or repair insecure code.
Logging and Detection
Enable and centralize logs before an incident:
- identity and token events;
- organization and control-plane activity;
- storage access for sensitive data;
- network flows where useful;
- workload and application logs;
- key-management operations;
- configuration and policy changes.
Protect the logging destination from the same administrators and workloads it records. Normalize identities, preserve timestamps, and test alerts with real scenarios such as a new access key, public storage change, or disabled audit trail.
Resilience
High availability across zones does not automatically provide regional disaster recovery. Define recovery time objective (RTO) and recovery point objective (RPO), then design data replication, backups, dependencies, DNS, credentials, and infrastructure code around them.
Run restoration exercises. A diagram of a second region is not evidence that the application can start there or that operators can obtain emergency access.
Compliance
Provider reports and certifications are evidence about the provider’s scoped controls. They do not certify the customer’s application or configuration.
ISO/IEC 27017 gives cloud-specific information-security guidance. ISO/IEC 27018 addresses protection of personally identifiable information in public-cloud processing. PCI DSS is an industry standard, not a government regulator. Customers still need to determine their own scope, responsibilities, and evidence.
Conclusion
Cloud security begins with an accurate responsibility map. The provider secures the service beneath a documented boundary; the customer secures identities, data, configuration, and use above it. Once that boundary is clear, automation can make controls more consistent instead of making mistakes faster.