Cloud Security

Cloud providers secure the platform, but customers configure it, and most cloud breaches come from customer misconfiguration and leaked credentials, not from the provider's data centres being hacked. Cloud security is therefore mainly about identity, configuration, data and visibility. Examples here are AWS-first but the ideas are the same everywhere; a mapping table follows.

Shared Responsibility Model

The provider secures the cloud; the customer secures what they put in it. The more managed the service, the more the provider takes on.

Data, identity and configuration are always the customer's problem. Read each service's responsibility documentation; the line moves per service.

Cloud IAM

Identity is the new perimeter (see Identity and Access Management).

• Roles over users: workloads and humans assume roles that issue short-lived credentials; avoid long-lived access keys, which leak into repos, laptops and logs.
• Least privilege: policies list specific actions and resources; avoid "Action": "" and "Resource": "". Start narrow, widen on evidence (access analysis tools can generate policies from usage).
• MFA on all human users, mandatory for the root/owner account, which should be locked away and unused day to day.
• Separation: multiple accounts/subscriptions/projects per environment and workload; organisation-wide guardrail policies (service control policies) that even admins cannot override.
• Federation / SSO with the corporate identity provider; remove people centrally when they leave.
• Review unused users, keys and roles regularly; rotate what must remain.
• Watch for privilege escalation paths: permissions to create policies, pass roles or modify trust relationships are as powerful as admin.

Concept: a policy has who (principal), what (action), on which (resource) and when (conditions). The IAM users/groups/roles/policies walkthrough is in the lab notes below.

Common Misconfigurations

Most of these are found by automated posture tools (CSPM, below) and prevented with infrastructure-as-code review and guardrails. Treat configuration as code under Change Management and harden baselines per System Hardening.

Network Controls

Internet
   |
[ Load balancer / WAF ]        public subnet
   |
[ App servers ]  <- security group: only LB may connect     private subnet
   |
[ Database ]     <- security group: only app tier on 5432   private subnet, no route to internet
   |
 Private endpoint to storage / services (traffic never crosses the internet)

• VPC/VNet: your isolated virtual network; split into public and private subnets by tier (see Network Segmentation).
• Security groups: stateful, allow-only rules attached to instances; reference other groups instead of IP ranges. Network ACLs are stateless subnet-level filters.
• Private endpoints (PrivateLink, Private Endpoint, Private Service Connect): reach provider services over the private network, not the public internet.
• Egress control and NAT: databases and app tiers rarely need direct outbound internet.
• WAF, DDoS protection, VPN/Direct Connect at the edge. See Firewalls and IDS/IPS and VPN and Tunneling.
• Zero-trust thinking: do not trust a workload merely because it is inside the VPC; authenticate and authorise every call.

Data Protection

• In transit: TLS everywhere, including internal service-to-service traffic.
• At rest: enable default encryption on storage, databases and snapshots. See Cryptographic Solutions.
• KMS (key management service): central creation, rotation, access policy and audit of keys.
• Key ownership options: provider-managed keys (simplest), customer-managed keys in KMS (you control policy, rotation and can disable), customer-supplied or external/HSM-held keys (BYOK/HYOK, maximum control, more operational burden).
• Separate key administrators from key users; a key policy is itself an access control.
• Classify data and apply retention and deletion (Data Lifecycle); enable versioning and immutable copies for recovery (Backup and Disaster Recovery).

Logging and Monitoring

Practices: enable in every account and region, send to a separate, write-restricted log account, enable log file integrity validation, retain per policy, and forward to the SIEM. Alert on root login, console login without MFA, IAM policy changes, disabled logging, security group changes and large data downloads. See Logs Fundamentals for log basics.

CSPM, CWPP, CASB

Containers and Kubernetes Basics

A container packages an app and its dependencies, sharing the host kernel (lighter than a VM, weaker isolation).

• Images: build from minimal, trusted base images; scan images for vulnerabilities and secrets in CI; pin versions/digests; sign images; use a private registry. Remember image layers keep anything ever added, including a secret deleted in a later layer.
• Least-privilege containers: run as non-root, read-only root filesystem, drop Linux capabilities, no --privileged, do not mount the container runtime socket (docker.sock) or host paths; this is the classic escape route.
• Secrets: not in images or plain environment variables baked at build; use Kubernetes Secrets with encryption at rest, or an external secrets manager.
• Kubernetes: RBAC with least privilege (avoid cluster-admin), secure the API server and kubelet, enable audit logs, use NetworkPolicy for default-deny pod traffic, namespaces for separation, pod security standards (restricted profile), admission controllers to enforce policy.
• Runtime: detect abnormal behaviour (shell in a container, unexpected outbound connections, file changes) with runtime security tooling; keep nodes patched.
• Supply-chain controls apply: see Secure Software Development.

Serverless Considerations

• No servers to patch, but function code, dependencies and permissions remain yours.
• Give each function its own least-privilege role; shared broad roles are the usual flaw.
• Event data (queue messages, uploads, API payloads) is untrusted input: injection still applies.
• Secrets via a secrets manager, not environment plain text; limit timeout and concurrency to contain abuse and cost.
• Short-lived and ephemeral, so logging must be built in; there is nothing to forensically image afterwards.

Multi-Cloud and Equivalents

Multiple providers multiply identities, consoles and skills needed; standardise on a central identity provider, infrastructure-as-code, common tagging and one logging/monitoring pipeline.

Compliance and Governance

• Providers publish audit reports and certifications (e.g. ISO 27001, SOC 2); these cover their part, not your configuration.
• Map your workloads to requirements such as GDPR (data location, processors, breach notification) and sector rules; use region restrictions and data residency controls.
• Use benchmarks (CIS Foundations) and the frameworks in Security Frameworks; automate evidence collection.
• Tag assets with owner and data classification so accountability exists.
• Design with Security Architecture Principles: least privilege, defence in depth, secure defaults, separation of duties.

Key Points

• Customer always owns data, identity and configuration, whatever the service model.
• Prefer roles and short-lived credentials; enforce MFA and least privilege; guard the root account.
• Block public storage, restrict security groups, keep secrets out of code.
• Encrypt in transit and at rest with managed keys, and log control-plane and network activity to a protected, central place.
• Use CSPM for posture, CWPP for workloads, CASB for SaaS.
• Containers: scan images, run non-root, never expose the runtime socket, default-deny network policy.

Related

• Identity and Access Management, Cryptographic Solutions, Security Architecture Principles
• SIEM and Log Management, Backup and Disaster Recovery, Secure Software Development

Hands-on

• AOC: AWS Security - S3cret Santa: IAM users, groups, roles and policies, enumerating permissions, assuming a role, and reading from S3.
• AOC: Containers - DoorDasher's Demise: Docker images and layers, the Docker socket, container escape and privilege escalation.