Cloud Security
Intermediate 15 min read Cloud Security

Encryption at Rest & In Transit

Two states, two obligations

Encryption protects data in two states: at rest (storage encryption via KMS) and in transit (TLS between hops). Key management, algorithm choice, and rotation policies decide how much the encryption actually buys you.

KMSSSETLSin-transitat-restcustomer-managed keyrotation
Prerequisites: Security Basics & Services
Before we start

What you will learn

  • Encrypt data at rest with managed (and customer-managed) keys
  • Apply TLS everywhere data moves between layers
  • Manage key policy, rotation and audit
In 60 seconds

At rest: storage services encrypt bytes with a data key wrapped by a KMS key you (or the provider) control. In transit: TLS terminates between client/LB/service and origin; enforce versions, SNI, and no plaintext fallbacks.

Introduction

What is this?

At-rest options: provider-managed (default SSE), customer-managed KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS or CMEK), external keys (HYOK/EXTERNALLY). Mechanisms: envelope encryption (data key → KMS wrap), key hierarchy, per-object keys, hardware HSM-backed HSM. Lifecycle: creation, aliases, rotation (auto rotate CMK yearly; import rotations via re-import), deletion (grace period + plan), access policy limiting use (kms:Encrypt/Decrypt to specific roles). In-transit: TLS 1.2+/1.3 across LB, services, DB; enforce flexible/anywhere policies; mutual TLS for service-to-service (mTLS in mesh), EKS/HTTP client certs; SNI, certificate management (ACM automatic renewals), cipher/negotiation hardening (e.g., no TLS 1.0/1.1) and strict ALPN.

Motivation

Why do you need it?

  • Compliance and data protection start with 'bytes at rest are unreadable to disk-stealers'.
  • Customer-managed keys give revocation (kill-switch) and compliance audit for sensitive data.
  • TLS in transit is the difference between eavesdropeable network and a pipe.
  • Key policy is where 'encrypted but indirectly readable' mistakes get hunts expensive.
Think about it

Mental model

Imagine

A safe deposit box (at rest) plus armored trucking between banks (in transit)

Think of

Encryption everywhere

The box (KMS-encrypted storage) protects dormant wealth; the armored car (TLS) protects it in motion. A bank managing one badly — either — loses custody.

Mechanics

How it works

  • At rest: service requests a data key from KMS; encrypts with it; KMS-wrapped key stored alongside ciphertext.
  • Decryption unwraps with KMS — no raw keys ever touch application storage.
  • In transit: TLS handshake negotiates cipher+session; A/TLS protected from client all the way to origin (or ends at LB if backend plaintext inside VPC is an exception).
  • Rotation: provider rotates the key material behind a stable ARN or you rotate CMKs/aliases on schedule.
  • Audit: KMS use policy + access logs record every key usage to spot abuse.

Envelope encryption path.

Data
KMS
Ciphertext
Decrypt
TLS
Hands-on

Examples

KMS CMK policy essentials

KMS CMK policy essentials
{
  "Effect": "Allow",
  "Principal": { "AWS": ["arn:aws:iam::<app-account>:role/app"] },
  "Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey*"],
  "Resource": "*",
  "Condition": { "DateGreaterThan": { "aws:CurrentTime": "2026-01-01T00:00:00Z" } }
}
# rotation: auto-rotate on; audit kms:Decrypt usage via CloudTrail

Scoped to one role, gated by a kill date if needed, auditable — CMK policies are the actual data-navigate-gate.

Real world

In production

  • SSE-KMS on S3/GCS/Azure Blob for all production data; CMKs for PII.
  • mTLS inside service meshes for inter-service trust.
  • ACM-managed certs on every public endpoint (never self-signed in prod).
Guidelines

Best practices

  • Default to provider-managed encryption; use CMKs where custody/revocation matters.
  • Enforce TLS 1.2+/1.3; block legacy ciphers off public endpoints.
  • Never run plaintext HTTP inside or outside the cloud; internal LB still TLS.
  • Rotate CMKs on schedule with documented recovery; test decryption after rotation.
  • Keep key permission 'least scope' — encryption of a bucket isn't a right to read its objects.
Watch out

Common mistakes

  • Enabled encryption on paper (SSE) but key policy allows any role — the 'encrypted' fiction.
  • TLS terminates at the LB, plaintext HTTP to the origin 'inside the VPC' — still a sniffable LAN.
  • Storing the KMS alias/policy so broadly that cross-account decrypt looks normal.
  • Rotation misconfig: rotate the alias but keep old material so ciphertext breaks.
When things break

Debugging tips

  • 'Access denied' on decrypt → check both key policy AND caller's IAM, plus region of the key.
  • TLS handshake failing → version/cipher mismatch or the SNI hostname vs cert SANs.
  • Rotation broke decryption → old ciphertext needs old key material; rotate with grace or re-encrypt.
  • Vericode (mtls) auth 401 → hostname/CA trust mismatch between client and server.
Interviews

Interview checkpoint

Practice

Hands-on lab

Prove Envelope Encryption End-to-End
40 min · intermediate
In progress
Objectives
  • Create a customer-managed key
  • Encrypt an object with that key and decrypt via KMS
  • Show policy-scoped deny on the unwrap path

Prove Envelope Encryption End-to-End

40 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Envelope encryption ensures:

2

TLS 1.3 + ALPN enforcement protects:

Go deeper

Official documentation

AWS KMS concepts
docs
Azure Key Vault keys
docs
GCP Cloud KMS / CMEK
docs