Cloud Security in Depth

Introduction

The provider secures the cloud. You secure what you build in it. Because everything is reachable through APIs, one mistake can expose a lot, so security must be designed in layers, where a failure of one does not mean disaster. This is defence in depth.

Layer 1: Identity is the new perimeter

In the cloud, identity is often the main boundary.

• MFA everywhere, with phishing-resistant methods for administrators.
• Least privilege with narrowly scoped roles, and short-lived credentials.
• Central sign-in (single sign-on) and automatic removal of access when people leave.
• Guard rails: organisation-wide policies that stop dangerous actions, such as making storage public or disabling logging, even for administrators.
• Separate accounts or projects for production, development and security tooling, to limit the blast radius.

Layer 2: Network

• Private subnets for data and internal services, and deny by default security groups
• No public management ports such as SSH or remote desktop open to the internet. Use bastion hosts, session managers or VPNs.
• A web application firewall and DDoS protection in front of public apps
• Private connectivity to cloud services where available, so traffic does not cross the public internet

Layer 3: Data protection

• Encryption in transit: TLS for all traffic, including internal.
• Encryption at rest: turn it on for storage and databases. It is usually one setting.
• Key management: use the provider's key management service, or a hardware security module for the highest assurance. Control who can use each key, rotate keys, and log their use. Consider customer-managed keys for sensitive data.
• Classify data, and apply stronger controls to sensitive data.
• Backups that are encrypted and protected from deletion.

Secrets

Never place secrets in code, images or logs. Use a secrets manager, give each service access only to what it needs, rotate secrets, and scan repositories for leaks.

Layer 4: Workloads

• Keep operating systems, containers and dependencies patched and scanned.
• Use hardened, minimal images and run as non-root.
• Infrastructure as code scanning finds insecure settings before deployment.
• Posture management tools watch continuously for misconfigurations, such as open buckets or overly broad roles.

Layer 5: Logging and detection

• Turn on audit logs of every API action (who did what, when, from where), and send them to a separate, protected account.
• Collect network, application and security logs centrally.
• Create alerts for high-risk events: root login, policy changes, large data downloads, disabled logging.
• Use threat detection services, and rehearse your incident response plan.

Zero trust

Zero trust assumes no user, device or network location is automatically trusted. Every request is verified for identity, device health and context, and given only the access needed, with continuous checks. It replaces "castle and moat" thinking, which fails when attackers get inside or when staff work from anywhere.

Compliance and shared responsibility

Rules such as privacy laws and industry standards may require specific controls, audit trails and data location. Providers publish compliance reports for their part, but you remain responsible for your configuration. Use frameworks, automate evidence collection, and involve legal and security experts for regulated data.

A quick review list

1. Root accounts locked away with MFA
2. No long-lived keys in code
3. Storage not public unless intended
4. Encryption on, keys controlled
5. Audit logs on and protected
6. Patching and scanning in place
7. A tested incident response plan

Try it yourself

Review a cloud setup you know against the list. Find the three weakest points, rank them by risk, and write what you would change first.

Summary

• Layer controls across identity, network, data, workloads and logging, so no single failure is fatal.
• Encrypt data, manage keys and secrets properly, and never expose management ports.
• Zero trust verifies every request, and you stay responsible for your own configuration and compliance.