Cloud Security - Learning Module

Loading content...

0/273

Encryption Services

The Last Line of Defense

In 2013, Edward Snowden revealed that the NSA was collecting data from major tech companies through a program called PRISM. One key takeaway for organizations worldwide: data that isn't encrypted can be read by anyone who gains access to it—whether through legal process, insider threat, or breach.

Encryption is the last line of defense. Even when all other security controls fail—when IAM is bypassed, when network perimeters are breached, when attackers gain access to storage systems—properly encrypted data remains protected. An encrypted database dump is just random bytes without the decryption keys.

Cloud providers offer sophisticated encryption services that make strong encryption accessible without requiring deep cryptographic expertise. Understanding these services—how they work, when to use them, and how to manage keys—is essential for building secure cloud architectures.

This page covers encryption at rest, encryption in transit, key management, and the architectural decisions that determine whether your encryption actually protects you.

What You Will Learn

By the end of this page, you will understand the difference between encryption at rest and in transit, cloud key management services (KMS) and their security models, envelope encryption and key hierarchies, customer-managed keys versus provider-managed keys, and encryption implementation patterns for different cloud services.

Encryption Fundamentals for Cloud Architects

Before diving into cloud-specific services, we must establish fundamental concepts that underpin all encryption implementations.

Symmetric vs. Asymmetric Encryption:

Symmetric encryption uses the same key for encryption and decryption. It's fast and efficient for encrypting large amounts of data. AES-256 is the standard.

Asymmetric encryption uses a key pair: public key for encryption, private key for decryption. It's slower but solves the key distribution problem—you can share the public key openly. RSA and ECC are common algorithms.

In practice, both are used together: asymmetric encryption protects symmetric keys, and symmetric keys encrypt the actual data. This is called hybrid encryption or envelope encryption.

Encryption Types Comparison
Characteristic	Symmetric (AES)	Asymmetric (RSA/ECC)
Key usage	Same key encrypts and decrypts	Different keys for each operation
Speed	Fast (hardware-accelerated)	Slow (computationally intensive)
Key distribution	Challenge: both parties need key	Easy: public key is shareable
Typical use	Data encryption at rest/transit	Key exchange, digital signatures
Key sizes	128, 192, or 256 bits	2048, 3072, 4096 bits (RSA)

Encryption at Rest vs. In Transit:

These terms describe the data's state when encryption is applied:

Encryption at Rest — Protecting stored data. When data is written to disk (EBS, S3, databases), it's encrypted before writing. When read, it's decrypted. This protects against:

Physical theft of storage media
Unauthorized access to storage systems
Data recovery from decommissioned hardware
Certain insider threats

Encryption in Transit — Protecting data as it moves. When data travels over a network (between services, between users and servers), it's encrypted during transmission. This protects against:

Network eavesdropping
Man-in-the-middle attacks
Wi-Fi sniffing
Backbone interception

Both are essential. A common mistake is implementing one but not the other. Data encrypted at rest but sent unencrypted over the network can be captured in transit. Data encrypted in transit but stored unencrypted can be stolen from storage.

Encryption Isn't Access Control

Encryption protects data from unauthorized access to storage or networks. It doesn't prevent authorized users from accessing data—anyone with decryption permissions can read encrypted data. Encryption supplements IAM, it doesn't replace it.

Cloud Key Management Services (KMS)

Key management is harder than encryption. Encryption algorithms are well-understood and implemented in standard libraries. The challenge is managing keys: generating them securely, storing them safely, controlling access to them, rotating them regularly, and ensuring they're available when needed.

Cloud providers offer Key Management Services (KMS) that handle this complexity:

AWS KMS — Managed service for creating and controlling encryption keys. Integrates with nearly all AWS services. Keys are stored in FIPS 140-2 validated hardware security modules (HSMs).

Azure Key Vault — Centralized cloud service for storing and managing secrets, keys, and certificates. Offers HSM-backed keys.

Google Cloud KMS — Key management service with HSM, software, and external key backing. Integrates with Google Cloud services.

KMS Core Capabilities

•Key generation — Create keys using cryptographically secure random number generators within HSMs.
•Key storage — Keys are stored encrypted within the service. Root keys never leave HSMs in plaintext.
•Access control — IAM policies determine who can use which keys for which operations.
•Key rotation — Automatic or manual rotation of keys. Old versions retained for decryption.
•Auditing — Every key usage is logged (CloudTrail, Cloud Audit Logs), enabling forensics and compliance.
•Multi-region — Replicate keys across regions for disaster recovery and latency.

Key Types and Hierarchy:

KMS implements a key hierarchy to balance security and usability:

┌─────────────────────────────────────────────────────────────────────────┐
│                          KEY HIERARCHY                                   │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   ┌─────────────────────────────────────────┐                           │
│   │         Root Keys / Master Keys          │  Level 0                 │
│   │   (Never leave HSM in plaintext)         │  (HSM-protected)         │
│   └─────────────────────────┬───────────────┘                           │
│                             │                                            │
│                             │ Encrypts                                   │
│                             ▼                                            │
│   ┌─────────────────────────────────────────┐                           │
│   │         Customer Master Keys (CMKs)      │  Level 1                 │
│   │   (Your KMS keys, managed by AWS)        │  (Customer-controlled)   │
│   └─────────────────────────┬───────────────┘                           │
│                             │                                            │
│                             │ Encrypts                                   │
│                             ▼                                            │
│   ┌─────────────────────────────────────────┐                           │
│   │         Data Encryption Keys (DEKs)      │  Level 2                 │
│   │   (Generated per object/volume)          │  (Envelope encryption)   │
│   └─────────────────────────┬───────────────┘                           │
│                             │                                            │
│                             │ Encrypts                                   │
│                             ▼                                            │
│   ┌─────────────────────────────────────────┐                           │
│   │              Your Data                   │  Level 3                 │
│   │   (Encrypted with DEK)                   │  (Protected)             │
│   └─────────────────────────────────────────┘                           │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Key Policy Example (AWS KMS):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM policies",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow encryption by app role",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/AppRole"},
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {"kms:ViaService": "s3.us-east-1.amazonaws.com"}
      }
    }
  ]
}

This policy allows encryption/decryption only when the request comes through S3—preventing direct key usage outside of the intended context.

HSM vs. Software Keys

Standard KMS keys are protected by HSMs but operations may involve software. For highest assurance, use dedicated HSM-backed keys (CloudHSM, Azure Dedicated HSM) or custom key stores where the HSMs are exclusively yours.

Envelope Encryption: The Core Pattern

Envelope encryption is the fundamental pattern used by cloud services to encrypt data efficiently while maintaining strong key protection. Understanding this pattern is essential for cloud security architects.

Why Not Encrypt Everything with KMS Directly?

You could send all your data to KMS for encryption, but this has problems:

Performance — KMS has rate limits and network latency. Encrypting gigabytes of data through API calls is slow.
Cost — KMS charges per API call. Encrypting every S3 object directly would be expensive.
Size limits — KMS can only encrypt up to 4KB directly.

The Envelope Encryption Solution:

Generate a random Data Encryption Key (DEK) locally
Encrypt your data with the DEK using AES-256 (fast, local operation)
Send the DEK to KMS to be encrypted with your CMK
Store the encrypted DEK alongside the encrypted data
Discard the plaintext DEK

For decryption:

Retrieve the encrypted DEK stored with the data
Send the encrypted DEK to KMS for decryption
Use the decrypted DEK to decrypt the data locally
Discard the plaintext DEK

Visual Representation:

                           ENCRYPTION FLOW
┌─────────────────────────────────────────────────────────────────────────┐
│                                                                          │
│   1. Generate DEK          2. Encrypt Data       3. Encrypt DEK         │
│   ┌───────────────┐        ┌───────────────┐    ┌───────────────┐       │
│   │   Random      │   ──▷  │   Your Data   │    │     KMS       │       │
│   │   DEK         │──────▷ │   + DEK       │    │  ┌─────────┐  │       │
│   │   (256-bit)   │        │   = Encrypted │    │  │   CMK   │  │       │
│   └───────────────┘        │     Data      │    │  └────┬────┘  │       │
│         │                  └───────────────┘    │       │       │       │
│         │                                       │       ▼       │       │
│         └───────────── DEK ────────────────────▷│  Encrypted    │       │
│                                                 │     DEK       │       │
│                                                 └───────┬───────┘       │
│                                                         │                │
│   4. Store Together                                     │                │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │                        Storage (S3, EBS, etc.)                  │   │
│   │   ┌─────────────────┐  ┌─────────────────────────────────────┐ │   │
│   │   │  Encrypted DEK  │  │         Encrypted Data              │ │   │
│   │   │  (Wrapped key)  │  │                                     │ │   │
│   │   └─────────────────┘  └─────────────────────────────────────┘ │   │
│   └────────────────────────────────────────────────────────────────┘   │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Why This Pattern Works:

Benefit	Explanation
Performance	Only the DEK (256 bits) goes to KMS; data encrypted locally at AES speed
Cost	One KMS call per object/volume, not per byte
Scalability	Generate unique DEK per object; compromise of one doesn't affect others
Key rotation	Rotate CMK without re-encrypting data; old DEKs still decryptable

Key Rotation Strategies

•Automatic CMK rotation — AWS KMS can rotate CMKs annually. Old versions are retained for decryption. Encryption uses the new version.
•Manual CMK rotation — Create a new CMK and update applications to use it. Provides more control but requires application changes.
•DEK rotation — Re-encrypt data with new DEKs. Necessary when compliance requires complete key replacement.
•Emergency rotation — If key compromise is suspected, immediately rotate and consider re-encrypting data.

AWS Services Handle This

When you enable encryption on S3, EBS, or RDS, the service implements envelope encryption automatically. You select the CMK; the service handles DEK generation, encryption, storage, and retrieval transparently.

Encryption at Rest: Storage Protection

Encryption at rest protects data stored in cloud services. Each service has its own encryption implementation, though the underlying concepts are consistent.

AWS Storage Encryption Options:

AWS Encryption at Rest by Service
Service	Encryption Method	Key Options	Default
S3	SSE-S3, SSE-KMS, SSE-C, Client-side	AWS-managed, CMK, Customer-provided	SSE-S3 (default since 2023)
EBS	XTS-AES-256	AWS-managed, CMK	Optional (can mandate)
RDS	AES-256	AWS-managed, CMK	Optional at creation
DynamoDB	AES-256	AWS-managed, CMK	Enabled by default
EFS	AES-256	AWS-managed, CMK	Optional at creation
Redshift	AES-256	AWS-managed, CMK, CloudHSM	Optional

S3 Server-Side Encryption Options Explained:

SSE-S3 (S3-Managed Keys):

Amazon manages the CMK
Simplest option, no additional cost
You can't audit key access separately from S3 access
Good for: general encryption needs without specific key control requirements

SSE-KMS (KMS-Managed Keys):

You specify a CMK in your KMS
Full control over key permissions via KMS key policies
Key usage logged in CloudTrail
Separation of duties: S3 admin can't decrypt without KMS permission
Good for: compliance requirements, audit trails, key access control

SSE-C (Customer-Provided Keys):

You provide the encryption key with each request
AWS uses the key, then discards it
You must manage key storage and delivery
Good for: requirements where you must control the actual key material

Client-Side Encryption:

You encrypt before uploading
AWS never sees plaintext
Complete control but more complex implementation
Good for: zero-trust scenarios, data that must be encrypted before leaving your environment

Encryption at Rest Best Practices

•Enable by default — Use SCPs or account-level settings to require encryption. Don't rely on individual resource configuration.
•Use CMKs for sensitive data — AWS-managed keys are convenient but CMKs provide better control and audit trails.
•Separate keys by data classification — Different CMKs for different sensitivity levels. This limits blast radius and enables different access policies.
•Monitor key usage — CloudTrail logs all KMS operations. Alert on unusual patterns or unauthorized access attempts.
•Consider performance — KMS has request limits. For high-throughput scenarios, use DEK caching or consider SSE-S3 for less sensitive data.

Encryption ≠ Access Control

Remember: encryption at rest protects against unauthorized access to storage. Anyone with S3:GetObject permission AND KMS:Decrypt permission can read encrypted objects. Encryption adds a layer, but IAM remains essential.

Encryption in Transit: Protecting Data in Motion

Encryption in transit protects data as it moves across networks. The standard mechanism is Transport Layer Security (TLS), the successor to SSL.

TLS Overview:

TLS provides three security properties:

Confidentiality — Data is encrypted; eavesdroppers see ciphertext
Integrity — Data cannot be modified without detection
Authentication — The server (and optionally client) prove their identity

TLS Handshake (simplified):

┌──────────────┐                          ┌──────────────┐
│    Client    │                          │    Server    │
└──────────────┘                          └──────────────┘
       │                                         │
       │──────── 1. ClientHello ────────────────▷│
       │         (Supported versions, ciphers)   │
       │                                         │
       │◁─────── 2. ServerHello + Certificate ───│
       │         (Selected version, cipher, cert)│
       │                                         │
       │──────── 3. Key Exchange ───────────────▷│
       │         (Verify cert, share key material)│
       │                                         │
       │◁─────── 4. Finished ────────────────────│
       │         (Confirm encryption working)    │
       │                                         │
       │◁═══════ 5. Encrypted Data ═════════════▷│
       │                                         │

TLS Best Practices

•Require TLS 1.2 or 1.3 — Older versions (SSL 3.0, TLS 1.0, TLS 1.1) have known vulnerabilities. Disable them.
•Use strong cipher suites — Prefer AEAD ciphers (AES-GCM, ChaCha20-Poly1305). Disable weak ciphers (RC4, 3DES, CBC mode without AEAD).
•Implement HSTS — HTTP Strict Transport Security tells browsers to always use HTTPS, preventing downgrade attacks.
•Certificate management — Use AWS Certificate Manager (ACM) for free, auto-renewing certificates. Never let certificates expire.
•Terminate at load balancer — Let ALB/NLB handle TLS termination with ACM certificates. This simplifies certificate management and offloads cryptographic work.

Internal Service-to-Service Encryption:

For traffic within your cloud environment (between microservices, to databases, etc.):

Approach	Implementation	Complexity	Use Case
TLS everywhere	Each service has certificates; all connections over HTTPS	Medium	Traditional web applications
mTLS (Mutual TLS)	Both client and server present certificates	High	Zero-trust, service mesh
Service mesh (Istio, Linkerd)	Sidecar proxies handle mTLS automatically	Medium (operational)	Kubernetes environments
VPN/PrivateLink	Encrypted at network layer	Low (application)	Hybrid cloud, cross-account

mTLS Deep Dive:

mTLS (mutual TLS) adds client authentication to standard TLS:

Standard TLS:                    mTLS:
┌────────┐    Verifies    ┌────────┐    ┌────────┐   Verifies    ┌────────┐
│ Client │ ─────────────▷ │ Server │    │ Client │ ◁──────────▷  │ Server │
└────────┘     Server     └────────┘    └────────┘   Both Certs  └────────┘
              Cert Only                             Verified

mTLS is essential for zero-trust architectures where network location doesn't confer trust. Service meshes like Istio automate mTLS between all services, making the implementation transparent to application code.

Don't Forget Database Connections

Database connections are often unencrypted by default. Ensure RDS, Aurora, and ElastiCache connections use TLS. Check that connection strings include SSL/TLS requirements and that certificate validation is enforced.

Advanced Key Management Patterns

For organizations with advanced security requirements, standard KMS may not be sufficient. Cloud providers offer additional key management options for higher assurance levels.

CloudHSM / Dedicated HSM:

For organizations requiring exclusive control over HSMs:

AWS CloudHSM

•Single-tenant HSMs in AWS data centers
•FIPS 140-2 Level 3 validated
•You manage keys; AWS manages hardware
•Use cases: regulatory requirements, legacy apps requiring PKCS#11

Custom Key Stores

•Use CloudHSM as KMS backend
•Get KMS API convenience with HSM security
•AWS services integrate via KMS
•Higher cost, more operational complexity

Bring Your Own Key (BYOK):

Some organizations must control key generation, often for compliance or to maintain consistency across multi-cloud:

BYOK Flow:
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  On-Premises    │     │   Wrapping      │     │   AWS KMS       │
│  Key Generation │────▷│   with AWS      │────▷│   Import Key    │
│  (Your HSM)     │     │   Public Key    │     │   Material      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                                               │
        │           Key material never                  │
        │           leaves your control                 │
        │           in plaintext                        │
        │                                               │
        └───────────────────────────────────────────────┘

BYOK Considerations:

You're responsible for key storage and backup outside AWS
Imported keys can't be auto-rotated by KMS
Key material must be re-imported after deletion
Adds operational complexity

External Key Stores (XKS):

The newest option allows KMS to use keys stored entirely outside AWS:

Feature	Standard KMS	Custom Key Store	External Key Store
Key location	AWS HSMs	Your CloudHSM	Your external HSM/KMS
Key material	AWS generates/stores	You control in CloudHSM	Entirely outside AWS
Integration	Native AWS services	Native AWS services	Native AWS services
Use case	Most workloads	Regulatory HSM requirements	Sovereignty, multi-cloud key management

Complexity vs. Security

Each level of additional control adds operational complexity. Standard KMS is secure enough for most workloads. Choose advanced options only when regulatory, contractual, or threat model requirements truly demand them.

Encryption Anti-Patterns and Pitfalls

Encryption is powerful but can be implemented incorrectly. These anti-patterns undermine the protection encryption should provide.

Common Encryption Mistakes

•Encryption without key management — Encrypting data but storing the key in the same place (e.g., encryption key in config file next to encrypted data). If attackers get the data, they get the key too.
•Overly broad KMS permissions — Granting kms:* to applications or roles. Any entity with decrypt permission for your CMK can decrypt your data.
•Not logging key usage — Without CloudTrail, you can't detect unauthorized key access or investigate incidents.
•Single key for everything — Using one CMK for all data means compromise of that key's access affects everything. Segment by data classification.
•Ignoring performance — KMS has rate limits. High-volume encryption without DEK caching or architectural consideration can hit throttling.
•Forgetting backups — Backups may not be encrypted or may use different keys. Attackers target backups because they're often less protected.
•Client-side encryption with lost keys — For client-side encryption, if you lose the key, the data is permanently lost. Ensure proper key backup.
•Encryption without integrity — Using encryption modes without authentication (e.g., AES-CBC without HMAC). Data can be modified without detection.

The 'Encrypted' False Sense of Security:

A common mistake is assuming encrypted data is protected regardless of IAM:

Scenario: S3 bucket with SSE-KMS encryption

❌ Misconfigured:
   - Bucket policy allows public access
   - CMK policy grants kms:Decrypt to "*"
   - Result: Anyone can download and decrypt

✓ Properly configured:
   - Bucket policy restricts to specific principals
   - CMK policy restricts kms:Decrypt to same principals
   - Result: Only authorized entities can access

Encryption amplifies your IAM decisions, but it doesn't replace them. If the same principals who can read encrypted data can also decrypt, encryption mainly protects against physical theft and some insider scenarios—not against IAM misconfigurations.

The Worst Anti-Pattern

The worst encryption mistake is 'security theater'—enabling encryption checkboxes for compliance without proper key management. Encryption with overly permissive key policies provides a false sense of security while adding no real protection against most attack scenarios.

Summary: Mastering Cloud Encryption

Encryption is the last line of defense—when all other controls fail, encrypted data remains protected. But encryption is only as strong as key management and access controls.

Key Takeaways

•Both at-rest and in-transit are essential — Data must be encrypted in storage and during transmission. Implementing only one leaves gaps.
•Key management is the hard part — Use KMS for key storage, rotation, and access control. Don't manage keys yourself unless you must.
•Envelope encryption is the pattern — Data keys encrypt data; master keys encrypt data keys. This provides security with performance.
•CMKs provide control — Customer-managed keys offer better auditing, access control, and separation of duties than AWS-managed keys.
•TLS 1.2+ everywhere — Disable older protocols. Require encryption for all database connections, not just external traffic.
•Encryption supplements IAM — It doesn't replace access control. Anyone with decrypt permission can read encrypted data.
•Advanced options exist — CloudHSM, BYOK, and XKS for organizations with specific regulatory or control requirements.

What's Next:

With encryption protecting data, our final topic addresses compliance in the cloud—how organizations meet regulatory requirements, achieve and maintain certifications, and demonstrate security to auditors and customers. Compliance ties together all the security controls we've discussed into a cohesive, verifiable framework.

Page Complete

You now understand cloud encryption architecture—from fundamental concepts through KMS, envelope encryption, and advanced key management. This knowledge enables you to design encryption strategies that truly protect data rather than just checking compliance boxes.