Cloud Security

Cloud security fails in boring, predictable ways: an over-broad IAM policy, a public storage bucket, a long-lived access key in a repo, an unencrypted database, a missing egress control. This guide is organized around what a DevOps engineer actually implements to prevent each — not a compliance checklist to admire, but the controls you wire into IAM, IaC, and CI/CD. It stays cross-provider (AWS, Azure, GCP share the same shapes) and drops to concrete services where it helps.

The shared responsibility model

The provider secures the cloud of the infrastructure (physical hosts, hypervisor, managed-service internals); you secure what you run in it (identities, data, configuration, network rules, application code). The line moves with the service: on raw VMs you own OS patching; on a managed database the provider patches the engine but you still own access control, encryption settings, and network exposure. Most breaches happen squarely on the customer side of that line — misconfiguration, not provider failure.

Identity and access management

IAM is the control plane of cloud security. Get it wrong and nothing else matters; get it right and you’ve contained most blast radius.

Least privilege means grant the minimum actions on the minimum resources, and prefer roles assumed short-term over long-lived keys.

{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}

{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::app-uploads/*"
}

Core IAM practices, provider-agnostic:

• No long-lived keys. Use assumed roles (AWS IAM roles, GCP service accounts with workload identity, Azure managed identities). For CI/CD, use OIDC federation so the pipeline gets short-lived credentials — nothing to leak or rotate.
• MFA everywhere for human access; enforce it, don’t just enable it.
• Workload identity for services — a pod/function assumes an identity rather than reading a static key.
• Separate accounts/subscriptions/projects per environment (prod isolated from dev) so a dev compromise can’t reach prod.
• Audit and prune unused permissions and identities regularly — access analyzers flag what’s over-granted.

Secrets and encryption

• Secrets live in a managed store — AWS Secrets Manager / SSM Parameter Store, Azure Key Vault, GCP Secret Manager, or HashiCorp Vault — pulled at runtime, never in code, images, or plain env files. Enable automatic rotation where the store supports it.
• Encryption at rest should be default on for every data store, backed by a KMS key. Managed KMS handles the heavy lifting; your job is to enable it, control who can use the key (a second layer of access control), and rotate keys.
• Encryption in transit — TLS everywhere, including internal service-to-service traffic. Terminate with managed certificates and automate renewal.

Network segmentation

Flat networks let one foothold become total compromise. Segment by default:

• Private by default. Databases, caches, and internal services live in private subnets with no public IP; only load balancers and bastions are public.
• Security groups / firewall rules as allow-lists — open specific ports from specific sources, never 0.0.0.0/0 to a database.
• Default-deny egress. Most environments never restrict outbound traffic, which is exactly how data gets exfiltrated and how compromised workloads phone home. Restrict egress to known destinations.
• Zero-trust direction of travel — authenticate and authorize service-to-service calls (mTLS, identity-aware proxies) rather than trusting the network perimeter.

Infrastructure-as-code security

Your infrastructure is now code, so secure it like code — and catch misconfigurations before they’re deployed.

• Scan IaC in CI with Checkov, tfsec, or Terrascan — they flag public buckets, unencrypted volumes, over-broad security groups, and missing logging in the pull request, not in production.
• No secrets in state or code. Terraform state contains sensitive values — store it in an encrypted backend with locking and tight access.
• Policy as code — enforce guardrails (OPA/Conftest, Sentinel) so non-compliant infrastructure can’t be applied.
• Least-privilege IaC pipelines — the CI role that applies Terraform is itself a high-value target; scope it and use OIDC.

CI/CD and supply-chain security

The pipeline is production-adjacent and increasingly the target of choice:

• Scan dependencies (SCA) and code (SAST) on every PR; scan running apps (DAST) on a schedule.
• Scan container images (Trivy/Grype) before push; fail on critical CVEs.
• Generate SBOMs so you can answer “are we exposed to CVE-X?” fast.
• Sign artifacts (Cosign) and verify signatures at deploy, so only pipeline-built images run.
• Least-privilege pipelines, OIDC to the cloud, pinned third-party actions — see the GitHub Actions guide.

Logging, auditing, and posture management

You can’t respond to what you can’t see:

• Enable audit logs on every account — AWS CloudTrail, Azure Activity/Monitor logs, GCP Cloud Audit Logs — and centralize them in a SIEM with alerting on high-risk actions (root usage, IAM policy changes, security-group edits).
• CSPM (Cloud Security Posture Management) — a tool (or the provider’s Security Hub / Defender for Cloud / Security Command Center) that continuously scans for misconfigurations: public buckets, open ports, unencrypted volumes, unused credentials. This is how you catch drift at scale.
• Immutable, access-controlled log storage — logs an attacker can delete aren’t evidence.

Compliance, backups, and disaster recovery

• Map controls to your framework (SOC 2, ISO 27001, PCI, HIPAA) and let tooling produce evidence continuously rather than scrambling before an audit.
• Back up across accounts/regions and — critically — test restores. A backup you’ve never restored is a hope, not a control.
• Protect backups from ransomware with immutability/object-lock so they can’t be encrypted or deleted by a compromised identity.

Incident response

Have a runbook, and make sure the access to execute it is pre-provisioned (you don’t want to be granting break-glass permissions mid-incident):

1. Contain — isolate the affected resource (restrictive security group, revoke the identity’s sessions/keys).
2. Preserve — snapshot volumes and export logs before changing anything.
3. Eradicate & recover — rotate every credential the resource could reach, rebuild from known-good IaC/images, restore data from tested backups.
4. Learn — a blameless postmortem that produces concrete control changes (see DevOps Practices).

Cloud security checklist

Identity

• No long-lived access keys; roles + OIDC federation for CI/CD.
• MFA enforced for all human access.
• IAM policies scoped to specific actions/resources; no *:*.
• Prod isolated from non-prod at the account/subscription/project level.

Data

• Encryption at rest (KMS) default-on for every store; keys rotated.
• TLS in transit everywhere, including internal traffic.
• Secrets in a managed store with rotation; none in code/images/env.
• Public access blocked at the account level for object storage.

Network

• Data stores in private subnets, no public IP.
• Security groups are allow-lists; no 0.0.0.0/0 to data ports.
• Default-deny egress to known destinations.

Pipeline & posture

• IaC scanned (Checkov/tfsec) and images scanned (Trivy) in CI; fail on critical.
• Audit logs enabled and centralized; SIEM alerts on high-risk actions.
• CSPM continuously scanning for misconfiguration.
• Backups cross-region, immutable, and restore-tested.

Frequently asked questions

What is the shared responsibility model, concretely? The provider secures the underlying infrastructure; you secure your identities, data, configuration, and network rules. The boundary shifts by service (more yours on raw VMs, less on managed services), but configuration is always yours — and that’s where most breaches occur.

How do I stop leaked cloud credentials from causing breaches? Eliminate long-lived keys: use assumed roles/managed identities for workloads and OIDC federation for CI/CD, so credentials are short-lived and scoped. Enforce MFA and scope every policy to least privilege so even a leaked credential has minimal reach.

Are managed databases and buckets encrypted by default? Increasingly yes, but verify — and control who can use the KMS key, which is a second access-control layer. Never assume; make “encryption at rest, KMS-backed” an IaC-enforced default.

How do I catch misconfigurations before they’re exploited? Two layers: scan IaC in CI (Checkov/tfsec) to catch them pre-deploy, and run CSPM continuously to catch drift and manual changes in live accounts.

What’s the fastest win for a small team? Turn on account-level public-access blocking for storage, enforce MFA, remove static keys in favor of OIDC for CI/CD, and enable audit logging. Four changes that close the most common breach paths.

Related resources

• Guide: Kubernetes Security for cluster-level hardening, and GitHub Actions for keyless CI/CD deploys.
• Guide: DevOps Practices for secrets management, policy as code, and incident response as team practices.
• Free tools: the config validators check Terraform and YAML for issues client-side.