Cloud Encryption — Explain encryption at rest and in transit in cloud services (conceptual) - Cyber Security

SECTION 1

Historical Context & Motivation

The challenge of protecting sensitive information during storage and transmission predates cloud computing by decades. When organizations began migrating workloads from on-premises data centers to third-party cloud service providers (CSPs) in the late 2000s, a fundamental trust problem emerged: how can an enterprise ensure the confidentiality and integrity of its data when the underlying hardware, network fabric, and administrative access belong to another entity? Encryption — the mathematical transformation of plaintext into ciphertext using a secret key — became the primary control for addressing this concern, evolving from a military and diplomatic tool into a ubiquitous infrastructure layer embedded in every major cloud platform.

1976 • Diffie–Hellman Key Exchange

Whitfield Diffie and Martin Hellman publish their landmark paper introducing public-key cryptography, enabling two parties to establish a shared secret over an insecure channel — a prerequisite for modern encryption in transit.

2001 • AES Standardized by NIST

The Advanced Encryption Standard (AES) replaces DES as the federal symmetric cipher standard, becoming the de facto algorithm for encrypting data at rest in virtually all storage systems and cloud services.

2006 • Launch of AWS S3 & EC2

Amazon Web Services launches its first major cloud storage and compute services, catalyzing the shift to public cloud. Early adopters immediately question how data is protected on shared infrastructure, driving demand for server-side and client-side encryption options.

2014 • Google Encrypts Inter-Datacenter Traffic

Following the Snowden revelations, Google announces encryption of all data moving between its data centers by default, raising the industry bar for encryption in transit and prompting other CSPs to follow.

2018–Present • Default Encryption & Zero-Trust Architectures

All three major CSPs (AWS, Azure, GCP) enable encryption at rest by default for most storage services. Regulations such as GDPR and CCPA codify encryption expectations, and zero-trust models mandate encryption even within the provider's internal network.

This historical trajectory reveals a recurring pattern: every expansion of the attack surface — from local disks to network links to shared multi-tenant infrastructure — has been met with a corresponding expansion of cryptographic controls. The central question that this lesson addresses is: what are the distinct threat models, mechanisms, and trade-offs of encrypting data at rest versus data in transit within cloud environments?

SECTION 2

Core Principles & Definitions

Before examining encryption at rest and in transit individually, it is essential to establish the foundational concepts that underlie both. Cloud encryption is not a single monolithic feature but rather a layered architecture involving multiple actors — the data owner, the cloud service provider, and potentially third-party key management services — each playing a distinct role in key generation, storage, rotation, and access control. The following principles form the conceptual bedrock of the entire domain.

Symmetric Encryption

A single secret key is used for both encryption and decryption. AES-256 is the dominant symmetric cipher in cloud environments. It is fast and efficient for bulk data, making it ideal for encrypting stored objects (at rest) and payload data within established TLS sessions (in transit).

Asymmetric Encryption

Uses a mathematically linked key pair — a public key for encryption and a private key for decryption (or vice versa for signatures). RSA and elliptic-curve algorithms (ECDHE) are used primarily during the TLS handshake to negotiate symmetric session keys securely.

Key Management

Encryption is only as strong as the protection of its keys. Cloud providers offer managed services such as AWS KMS, Azure Key Vault, and Google Cloud KMS that generate, store, rotate, and audit keys within hardware security modules (HSMs).

Envelope Encryption

A hierarchical key scheme where a data encryption key (DEK) encrypts the actual data, and a key encryption key (KEK) wraps (encrypts) the DEK. This pattern limits the exposure of the master key and enables efficient key rotation without re-encrypting large datasets.

Defense in Depth

Encrypting data at rest and in transit are complementary layers in a defense-in-depth strategy. Neither alone is sufficient: encryption at rest does not protect data intercepted on the wire, and encryption in transit does not protect data after it is written to disk on a compromised server.

✦

KEY TAKEAWAY

Think of cloud encryption like securing a valuable letter. Encryption at rest is the locked safe in which you store the letter at your destination — it protects the letter while it sits in storage. Encryption in transit is the armored courier who carries the letter through public streets — it protects the letter while it is moving. Even if the courier is trustworthy, you still want a safe at home, and even if the safe is impregnable, you still need a secure courier. Both layers must coexist.

SECTION 3

Visual Explanation — Data Lifecycle in the Cloud

The following diagram illustrates the two primary encryption domains within a typical cloud architecture. On the left, a client application communicates with the cloud over a public network secured by TLS (encryption in transit). On the right, the cloud storage subsystem protects persisted data with AES-256 encryption at rest. The key management service sits centrally, issuing and managing keys for both domains. Observe how data transitions from plaintext inside the client, to ciphertext on the wire, back to plaintext in the application tier, and finally to ciphertext on disk — each transition represents a potential vulnerability that encryption addresses.

The diagram shows data flowing from the client application (left) through a TLS 1.3 tunnel into the cloud provider's application tier, where it is decrypted in memory. The data is then re-encrypted using AES-256-GCM before being written to persistent storage. The KMS/HSM component supplies both data encryption keys (DEKs) and key encryption keys (KEKs) via envelope encryption.

Notice the critical gap between the in-transit and at-rest encryption zones: the application tier processes data in plaintext in memory. This is by design — the application must be able to read and manipulate the data to perform its function. However, this gap is precisely why encryption in use (sometimes called confidential computing) is an active research area. Technologies like Intel SGX and AMD SEV attempt to protect data even while it is being processed, but they remain outside the mainstream scope of most cloud encryption discussions today.

SECTION 4

How Cloud Encryption Works — Mechanisms in Depth

Encryption at Rest

When a cloud service encrypts data at rest, the goal is to render stored data unintelligible to anyone who gains physical or logical access to the storage medium without possessing the corresponding decryption key. This includes scenarios such as a stolen hard drive, an unauthorized database administrator, or a government subpoena served to the cloud provider. The dominant algorithm is AES-256 operating in Galois/Counter Mode (GCM), which provides both confidentiality and integrity through authenticated encryption. The CSP typically implements encryption at one or more layers: the storage controller (full-disk encryption), the object/block storage service (server-side encryption), or the client SDK (client-side encryption before data leaves the tenant's application).

SYMMETRIC ENCRYPTION (AES)

C = E(K, P) and P = D(K, C)

Where C is the ciphertext, P is the plaintext, K is the symmetric key (256 bits for AES-256), E is the encryption function, and D is the decryption function. The same key K is used in both directions, which is why secure key storage is paramount.

Envelope Encryption in Detail

Rather than encrypting every stored object directly with a master key, cloud providers employ envelope encryption. A unique data encryption key (DEK) is generated per object (or per chunk), and the DEK itself is then encrypted ("wrapped") by a key encryption key (KEK) stored in the KMS. The wrapped DEK is stored alongside the ciphertext. To decrypt, the application first sends the wrapped DEK to the KMS for unwrapping, receives the plaintext DEK, and then uses it locally to decrypt the data. This architecture means the master key (KEK) never leaves the HSM, limiting its exposure surface dramatically.

ENVELOPE ENCRYPTION

Stored = { E(DEK, Plaintext), E(KEK, DEK) }

The stored artifact consists of two components: the ciphertext produced by encrypting the plaintext with the DEK, and the wrapped DEK produced by encrypting the DEK with the KEK. Key rotation involves re-wrapping DEKs with a new KEK without re-encrypting the bulk data.

Encryption in Transit

Encryption in transit protects data as it moves between the client and the cloud service, between microservices within the cloud, or between data centers in a multi-region deployment. The foundational protocol is Transport Layer Security (TLS), currently at version 1.3 (RFC 8446). A TLS connection is established via a handshake that combines asymmetric and symmetric cryptography: the client and server use asymmetric algorithms (e.g., ECDHE for key agreement, RSA or ECDSA for authentication) to securely negotiate a shared symmetric session key, which is then used to encrypt the application-layer payload using AES-GCM or ChaCha20-Poly1305. This hybrid approach leverages the strengths of both families — asymmetric for key exchange, symmetric for bulk throughput.

TLS 1.3 HANDSHAKE (SIMPLIFIED)

SessionKey = HKDF(ECDHE(clientPriv, serverPub))

The session key is derived from the shared secret produced by Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) key exchange, then expanded using HKDF (HMAC-based Key Derivation Function). Ephemeral keys ensure forward secrecy: even if the server's long-term private key is compromised later, past sessions remain secure.

ℹ

Mutual TLS (mTLS)

In standard TLS, only the server presents a certificate. In mutual TLS (mTLS), both client and server authenticate each other with X.509 certificates. This is increasingly used for service-to-service communication within cloud environments (e.g., via service meshes like Istio) to enforce zero-trust principles at the transport layer.

SECTION 5

Encryption Models — Who Holds the Keys?

A crucial dimension of cloud encryption is not just which algorithm is used, but who controls the encryption keys. The key custodian determines the trust boundary: if the CSP holds all the keys, the CSP can technically access your plaintext data. Conversely, if the customer holds all the keys, the CSP cannot offer value-added services that require reading the data (e.g., indexing, compression, deduplication). Cloud providers typically offer multiple models along this spectrum, each with distinct security, usability, and cost trade-offs.

The key custody spectrum ranges from CSP-managed keys (least customer control, least effort) through customer-managed keys (balanced) to client-side encryption (full customer control, highest operational burden). Regulatory requirements often dictate the minimum acceptable position on this spectrum.

Model	Key Generation	Key Storage	Encryption Location	CSP Access to Plaintext?
SSE – Provider Keys	CSP	CSP KMS	Server-side	Yes
SSE – Customer-Managed Keys	Customer (in CSP KMS)	CSP KMS (customer's key ring)	Server-side	Technically, during processing
SSE – Customer-Provided Keys	Customer (external)	Customer's infrastructure	Server-side (key in memory only)	Briefly, during operation
Client-Side Encryption	Customer (external)	Customer's infrastructure	Client-side	No

Comparison of cloud encryption key custody models

SECTION 6

Worked Example — Designing an Encryption Architecture

Consider a healthcare startup building a patient records application on AWS. The application stores protected health information (PHI) in Amazon S3 and communicates with a React front-end via an API Gateway. Federal regulations (HIPAA) require encryption of PHI both at rest and in transit. The security team must choose appropriate encryption models and document the architecture.

Healthcare Cloud Encryption Architecture

1
Step 1 — Identify Regulatory Requirements

HIPAA's Security Rule (§ 164.312(a)(2)(iv) and § 164.312(e)(2)(ii)) specifies encryption as an addressable implementation specification for data at rest and in transit. The startup's risk assessment determines that encryption is a reasonable and appropriate safeguard for PHI stored in S3 and transmitted over the internet. This means both encryption at rest and encryption in transit are required.

Both at-rest and in-transit encryption required by HIPAA
2
Step 2 — Select Encryption at Rest Model

Given the sensitivity of PHI, the team selects SSE-KMS (customer-managed keys) for S3. They create a customer master key (CMK) in AWS KMS with a key policy that restricts decrypt permissions to the application's IAM role only. They enable automatic key rotation (every 365 days) and configure CloudTrail to log all KMS API calls for audit purposes.

S3 bucket policy: "x-amz-server-side-encryption": "aws:kms" with customer CMK ARN
3
Step 3 — Implement Envelope Encryption Flow

When the application uploads a patient record to S3, the following occurs automatically: (1) S3 calls KMS to generate a unique DEK; (2) KMS returns both the plaintext DEK and a copy encrypted (wrapped) with the CMK; (3) S3 uses the plaintext DEK to encrypt the object with AES-256-GCM; (4) S3 stores the ciphertext alongside the wrapped DEK; (5) S3 discards the plaintext DEK from memory. On retrieval, S3 sends the wrapped DEK back to KMS for unwrapping, receives the plaintext DEK, decrypts the object, and returns the plaintext to the authorized caller.

Envelope encryption ensures the CMK never leaves the HSM boundary
4
Step 4 — Configure Encryption in Transit

The team configures AWS API Gateway with a custom domain and an ACM (AWS Certificate Manager) TLS certificate. They enforce TLS 1.2 as the minimum protocol version on the API Gateway's security policy, disabling all older cipher suites. For S3 access, they apply a bucket policy that denies any request where aws:SecureTransport is false, ensuring all API calls to S3 must use HTTPS. Internal communication between the API service and the database uses TLS with certificates managed by AWS Private CA.

S3 bucket policy condition: "Condition": {"Bool": {"aws:SecureTransport": "false"}} → Deny
5
Step 5 — Validate and Document

The team validates the architecture by: (a) using openssl s_client to confirm TLS 1.2+ negotiation on the API endpoint; (b) checking S3 object metadata to verify the x-amz-server-side-encryption header is present with value aws:kms; and (c) reviewing CloudTrail logs to confirm KMS Decrypt events correlate with authorized application reads. They document these controls in the HIPAA Security Risk Assessment as evidence of compliance.

Architecture achieves defense in depth: TLS on the wire, AES-256-KMS on disk, customer-controlled keys, full audit trail

SECTION 7

Strengths, Limitations & Trade-offs

Cloud encryption is a powerful control, but it is not a panacea. Understanding its limitations is as important as understanding its strengths, because overestimating what encryption provides can lead to dangerous false confidence. The following table contrasts the two primary encryption domains across several dimensions.

Dimension	Encryption at Rest	Encryption in Transit
Primary Threat Mitigated	Physical theft of storage media, unauthorized disk access, insider threats at the storage layer	Network eavesdropping, man-in-the-middle attacks, packet sniffing on shared infrastructure
Primary Algorithm	AES-256-GCM (symmetric)	TLS 1.3 (hybrid: ECDHE + AES-GCM / ChaCha20)
Performance Impact	Minimal — AES-NI hardware acceleration in modern CPUs reduces overhead to < 2%	Handshake latency (1 RTT for TLS 1.3); negligible symmetric encryption overhead after handshake
What It Does NOT Protect	Data in memory, data accessible via authorized application queries, metadata (file names, sizes)	Data after arrival at the endpoint, traffic analysis (packet sizes/timing), compromised endpoints
Key Risk	Key loss = permanent data loss; key compromise = full exposure	Certificate mismanagement, expired certs, failure to enforce minimum TLS version
Operational Complexity	Key rotation, access policy management, cross-region key replication	Certificate lifecycle management, cipher suite configuration, mTLS rollout

Comparative analysis of encryption at rest vs. encryption in transit

✦

KEY TAKEAWAY

Encryption does not equal access control. Even with AES-256 encryption at rest enabled, any user or service with the IAM permission to call kms:Decrypt can still read the plaintext. Think of encryption as a locked door: the lock is important, but the real security question is who has the key and under what conditions can they use it. Encryption must always be paired with robust identity management, least-privilege policies, and continuous monitoring to be effective.

SECTION 8

Connection to Advanced Topics — Beyond At-Rest and In-Transit

The at-rest/in-transit dichotomy, while foundational, leaves an important gap: data that is being actively processed in memory is typically unencrypted. This has driven the emergence of confidential computing, a paradigm that uses hardware-based Trusted Execution Environments (TEEs) such as Intel SGX, AMD SEV-SNP, and ARM TrustZone to protect data even during computation. Additionally, advances in homomorphic encryption (FHE) promise the ability to perform computations on ciphertext directly, though current schemes remain orders of magnitude slower than plaintext operations and are not yet practical for general workloads. The table below positions the concepts covered in this lesson relative to these advanced approaches.

Data State	This Lesson's Scope	Advanced Approach	Maturity
At Rest (on disk)	AES-256-GCM via SSE/CSE with KMS	Searchable encryption, format-preserving encryption (FPE)	Production-ready (standard); niche (advanced)
In Transit (on wire)	TLS 1.3 / mTLS	Post-quantum key exchange (ML-KEM / Kyber)	Production-ready (standard); standardizing (advanced)
In Use (in memory)	Not covered — plaintext gap	TEEs (Intel SGX, AMD SEV-SNP), Fully Homomorphic Encryption (FHE)	TEEs: GA on major CSPs; FHE: research/early adoption

Mapping data states to current and advanced encryption approaches

⚠

Post-Quantum Readiness

Quantum computers threaten asymmetric algorithms (RSA, ECDHE) used in TLS key exchange. NIST finalized its first post-quantum cryptography standards in 2024, including ML-KEM (Kyber) for key encapsulation. Major CSPs are already piloting hybrid key exchange modes (e.g., X25519Kyber768) in their TLS stacks. Cloud architects should begin inventory of cryptographic dependencies and plan migration paths.

As you advance in cloud security, consider how encryption in use completes the triad and how the shift toward zero-trust architectures — where every network segment is treated as hostile — further blurs the traditional at-rest/in-transit boundary. Service meshes, for example, apply mTLS between every microservice, effectively making all internal communication encrypted in transit by default, while confidential computing extends the at-rest guarantee into the CPU cache and registers.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

A cloud storage service advertises that all data is "encrypted at rest with AES-256." A security analyst claims this alone does not protect against a malicious database administrator at the CSP who has legitimate query access. Is the analyst correct? Explain why or why not, referencing the distinction between encryption and access control.

Show answer

The analyst is correct. Encryption at rest protects against physical media theft and unauthorized low-level disk access, but a database administrator with legitimate query access would interact with the data through the application or storage service, which decrypts data transparently for authorized queries. The encryption key (or the permission to invoke the KMS Decrypt API) is effectively available to the query path. Therefore, encryption at rest does not substitute for proper access control policies (IAM, database ACLs) that restrict who can query the data. The correct mitigation is defense in depth: encryption at rest combined with least-privilege access policies, audit logging, and potentially client-side encryption if the CSP itself must be excluded from the trust boundary.

Question 2: BASIC CALCULATION

An organization stores 10 TB of data in S3 using SSE-KMS with a unique DEK per object. If the average object size is 5 MB, approximately how many DEKs are generated? If each DEK is 256 bits (32 bytes) and the wrapped DEK stored alongside each object is 184 bytes (due to KMS wrapping overhead), what is the total storage overhead from wrapped DEKs?

Show answer

The number of objects is 10 TB ÷ 5 MB = 10 × 10¹² bytes ÷ 5 × 10⁶ bytes = 2 × 10⁶ = 2,000,000 objects, hence 2,000,000 DEKs. The total wrapped DEK overhead is 2,000,000 × 184 bytes = 368,000,000 bytes ≈ 368 MB. Relative to the 10 TB total, this is approximately 368 MB ÷ 10,485,760 MB ≈ 0.0035%, which is negligible. This illustrates why envelope encryption is practical: the per-object key overhead is trivially small compared to the data itself, while providing the security benefit of key isolation per object.

Question 3: INTERMEDIATE

An architect is comparing two approaches for a microservices application running on Kubernetes in GCP: (A) relying solely on Google's default encryption of inter-node traffic within the VPC, or (B) deploying Istio service mesh with mTLS enforced between all pods. Analyze the threat models that each approach addresses and does not address. Under what organizational or regulatory conditions would approach (B) be necessary despite approach (A) being in place?

Show answer

Approach (A) — Google's default VPC encryption — protects against eavesdropping by external entities tapping the physical network between nodes. However, it operates at the infrastructure layer and does not authenticate individual services; any pod on the same node or VPC can potentially intercept plaintext traffic. Approach (B) — Istio mTLS — provides both encryption and mutual authentication at the application (L7) layer. Each service has its own X.509 identity, so a compromised pod cannot impersonate another service, and all inter-service traffic is encrypted independently of the infrastructure layer. Approach (B) is necessary when the organization follows a zero-trust architecture model, when regulatory frameworks (e.g., PCI DSS 4.0 requirement 4) mandate encryption of sensitive data on internal networks, or when multi-tenancy within the cluster means that pods from different trust domains coexist on shared nodes. In essence, (A) is a network-layer control while (B) is a workload-identity-level control — they complement each other in a defense-in-depth posture.

Question 4: APPLIED

A fintech company must comply with PCI DSS and stores credit card numbers in an Azure SQL Database. Design an encryption strategy that addresses both at-rest and in-transit requirements. Specify: (1) the Azure feature for encryption at rest and key custody model, (2) the TLS configuration for client-to-database connections, (3) how you would handle key rotation without downtime, and (4) one limitation of your design that encryption alone cannot address.

Show answer

(1) Azure SQL supports Transparent Data Encryption (TDE) with customer-managed keys stored in Azure Key Vault. The company should create a Key Vault with soft-delete and purge protection enabled, generate an RSA 2048+ key, and configure TDE to use this key as the TDE protector. (2) Azure SQL enforces TLS for all connections by default; the company should set the minimum TLS version to 1.2 in the server configuration and reject unencrypted connections. Application connection strings should specify Encrypt=True and TrustServerCertificate=False. (3) Key rotation is accomplished by creating a new key version in Key Vault and setting it as the new TDE protector. Azure SQL will re-wrap the internal DEK with the new key version without re-encrypting the underlying data — this is a metadata operation and causes no downtime. (4) A major limitation is that TDE does not protect against SQL injection attacks or application-level data exfiltration by an authorized user. If an attacker compromises the application's database credentials, they can execute queries and receive plaintext results, because TDE decryption is transparent to the query engine. Column-level encryption (Always Encrypted) or application-level tokenization would be needed to address this gap.

Question 5: CRITICAL THINKING

A government agency is evaluating whether to adopt a "Hold Your Own Key" (HYOK) model where encryption keys never leave the agency's on-premises HSMs, versus a cloud-native KMS approach where keys reside in the CSP's HSM infrastructure. Construct a rigorous argument for each side, considering: threat model coverage, operational resilience, disaster recovery, key ceremony complexity, and the impact of a future quantum computing threat. Which approach would you recommend for a classified workload, and why?

Show answer

HYOK argument: Keys never entering the CSP's domain eliminates the CSP from the trust chain, protecting against CSP insider threats, government subpoenas to the CSP, and CSP-side key management vulnerabilities. This is the strongest posture for sovereignty and regulatory compliance in classified contexts. However, HYOK introduces operational complexity: every encryption/decryption operation requires a network call to the on-premises HSM, adding latency and creating a single point of failure. Disaster recovery requires HSM replication across geographically separated secure facilities, and key ceremonies require physical presence of multiple key custodians. Cloud-native KMS argument: Keys reside in FIPS 140-2 Level 3 validated HSMs managed by the CSP, which has dedicated cryptographic engineering teams, automated key rotation, built-in high availability across regions, and integrated audit logging. Operational resilience is superior because the KMS scales with the cloud workload. The trade-off is that the CSP technically has the capability (though not necessarily the authorization) to access the key material. Regarding quantum threats: both approaches face the same fundamental risk to asymmetric algorithms used in TLS key exchange, but symmetric keys (AES-256) stored in either HYOK or cloud KMS remain quantum-resistant (Grover's algorithm reduces effective strength to 128 bits, still considered secure). The migration challenge is in the transport layer, not the key storage layer. Recommendation for classified workloads: HYOK with a cloud-based external key manager (EKM) integration (e.g., Google Cloud EKM or AWS XKS). This preserves sovereignty while reducing latency through caching and local proxying. The operational overhead is justified by the threat model requirements of classified data, where the CSP must be excluded from the trust boundary by policy, not just by technical controls.

SUMMARY

Lesson Summary

Summary

Cloud encryption addresses the fundamental trust challenge of storing and transmitting data on infrastructure controlled by a third party. Encryption at rest uses AES-256-GCM to render stored data unintelligible without the decryption key, protecting against physical media theft, unauthorized disk access, and storage-layer insider threats. Envelope encryption structures the key hierarchy into data encryption keys (DEKs) and key encryption keys (KEKs), enabling efficient key rotation and limiting master key exposure. Encryption in transit relies on TLS 1.3 to protect data from network eavesdropping and man-in-the-middle attacks, using a hybrid of asymmetric key exchange (ECDHE) and symmetric bulk encryption with forward secrecy.

The choice of key custody model — CSP-managed, customer-managed, or client-side — determines the trust boundary and the operational burden on the data owner. Neither encryption at rest nor encryption in transit protects data in use, which remains an active frontier addressed by confidential computing and homomorphic encryption. Effective cloud security requires treating encryption as one layer in a defense-in-depth strategy, always paired with robust identity and access management, audit logging, and continuous monitoring.