Encryption is the most fundamental technical control for data protection. At rest, it ensures that unauthorized access to storage media — a stolen disk, a leaked backup, a misconfigured cloud bucket — does not expose plaintext data. In transit, it ensures that network interception, man-in-the-middle attacks, or misconfigured routing cannot read or tamper with data moving between components.

The two complement each other: encrypting only in transit leaves data vulnerable on disk; encrypting only at rest leaves it vulnerable on the wire. A complete data-protection posture requires both, managed through a consistent key-management lifecycle.

How It Works

  • Classify data by sensitivity and regulatory requirements to determine encryption scope and key-management rigor.
  • Encrypt at rest with mechanisms appropriate to the layer: application-level field or object encryption, database or tablespace encryption, or full-disk / volume encryption, each with current, approved algorithms and key sizes. Understand what each layer actually protects against: full-disk and volume encryption (e.g., AWS EBS, S3-SSE) primarily guards against physical media theft or unauthorized storage access, but does nothing once an attacker has a valid instance session or service account; application-level encryption protects data even from compromised infrastructure, at the cost of query and indexing complexity.
  • Manage encryption keys through a dedicated key-management system (KMS) — never store keys alongside the data they protect.
  • Use envelope encryption for large datasets: encrypt data with a data-encryption key (DEK), then encrypt the DEK with a key-encryption key (KEK) held in the KMS.
  • Encrypt in transit using TLS 1.2 or 1.3 with strong cipher suites; disable legacy protocols (SSL, TLS 1.0/1.1) and weak ciphers.
  • Rotate keys on a defined schedule and support re-encryption of stored data during rotation without downtime.
  • Secret Management provides the infrastructure for storing and distributing encryption keys and TLS certificates securely.

Failure Modes

  • Keys stored alongside encrypted data (for example in the same database or the same cloud storage bucket) — a single breach exposes both.
  • TLS termination at a load balancer with plaintext traffic on the internal network, exposing data to internal attackers or misconfigured logging.
  • Key rotation deferred indefinitely because re-encryption is seen as too expensive or risky, leaving long-lived keys that accumulate exposure.
  • Deprecated or weak transport settings remain enabled for compatibility, allowing downgrade or legacy-protocol exposure.
  • Encryption applied selectively (for example database columns but not backups, or API traffic but not internal service-to-service calls) leaves gaps in coverage.
  • Application-level field encryption breaks database indexes and query predicates — a WHERE email = '...' on ciphertext returns nothing, forcing teams to fall back to infrastructure-only encryption or adopt specialized techniques (blind indexes, searchable encryption) that add significant complexity.
  • KMS key policies that are overly broad (for example granting decrypt to an entire account or role) make encryption cosmetic — any compromised principal with that role reads plaintext without ever touching the raw key.

Verification

  • At-rest verification: inspect raw storage artifacts (backup file, disk image, object-store dump) and confirm that primary sensitive payloads are unreadable without decryption keys, while explicitly checking for residual plaintext exposure in metadata, file names, indexes, or logs.
  • In-transit verification: capture network traffic between components and confirm all service-to-service and client-to-service communication uses TLS 1.2+ with no fallback to plaintext.
  • Key isolation: verify that encryption keys are not accessible from the same credentials or storage path as the encrypted data.
  • Rotation test: trigger a key rotation and verify that new writes use the new key, existing data remains readable during the transition, and any required re-encryption completes within the defined window.
  • TLS configuration audit: scan all TLS endpoints and verify no deprecated protocols (TLS 1.0/1.1) or broken/legacy cipher suites such as RC4 or 3DES are negotiable; if older CBC-based suites remain for compatibility, document and justify them explicitly with a retirement plan.
  • Client-Side Encryption: Customer-managed keys move key custody to the data owner, enabling zero-knowledge architectures but shifting key-management burden to the client.
  • Mutual TLS (mTLS): Adds certificate-based peer authentication to transport encryption, ensuring both sides of the connection prove their identity.
  • Transparent Data Encryption (TDE): Database-level encryption protects storage media but not data after decryption in the database engine — an attacker with a valid database session reads plaintext.
  • Secret Management handles key and certificate distribution and rotation.
  • Least Privilege restricts access to decryption keys through KMS policies.
  • Strong Authentication (MFA / OIDC) ensures that only verified identities can request decryption keys from the KMS.

References