Encryption and Key Management: AWS KMS and Data Protection

This guide covers the critical aspects of data security on AWS, focusing on the AWS Key Management Service (KMS), the lifecycle of encryption keys, and service-specific implementation for S3 and EBS.

---

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between AWS-managed and Customer-managed KMS keys.
• Explain the mechanics of envelope encryption and how data keys are used.
• Compare the different S3 server-side encryption options (SSE-S3, SSE-KMS, SSE-C).
• Implement encryption for existing unencrypted EBS volumes using the snapshot/copy method.
• Configure key policies and explain the role of AWS CloudTrail in auditing key usage.

---

Key Terms & Glossary

• CMK (Customer Master Key): A logical representation of a key in KMS that includes metadata and the key material used to encrypt/decrypt data keys. It never leaves KMS unencrypted.
• HSM (Hardware Security Module): Secure hardware devices where KMS stores key material to ensure high physical and logical security.
• Envelope Encryption: The practice of encrypting data with a data key, and then encrypting the data key under another key (the CMK).
• Data Key: A cryptographic key generated by KMS used to encrypt large amounts of data locally within a service or application.
• Key Policy: A resource-based policy attached to a KMS key that defines who can use or manage that specific key.

---

The "Big Idea"

The central pillar of AWS security is Centralized Key Management. Instead of scattering keys across applications, AWS KMS provides a "Single Pane of Glass" to manage the entire lifecycle of cryptographic material. By integrating with virtually every AWS service and logging every action to CloudTrail, KMS ensures that encryption is not just a technical hurdle, but a manageable and auditable compliance tool.

---

Formula / Concept Box

S3 Encryption Comparison Table

---

Hierarchical Outline

1. AWS Key Management Service (KMS)
   • Architecture: Uses FIPS 140-2 Level 2 validated HSMs to protect key material.
   • Key Types:
     • AWS Managed: Created by AWS services; auto-rotated annually; cannot be deleted.
     • Customer Managed: Created by the user; full control over policies and rotation.
     • Imported Material: User provides the 256-bit symmetric key; user responsible for expiration.
2. Envelope Encryption Process
   • Generation: KMS generates a Plaintext Data Key and an Encrypted Data Key.
   • Encryption: Application uses Plaintext key to encrypt data, then discards the plaintext key.
   • Storage: The Encrypted Data Key is stored alongside the encrypted data.
3. Data At Rest Protection
   • S3: Objects are encrypted individually. Default bucket encryption only affects new objects.
   • EBS: Volumes and snapshots are encrypted. Encryption occurs on the host, ensuring data is encrypted in-flight to the storage.

---

Visual Anchors

The Envelope Encryption Flow

S3 Encryption Decision Logic

\begin{tikzpicture}[node distance=2cm] \draw[thick] (0,0) circle (1.5) node[align=center] {Do you want\KMS Audit?}; \draw[->, thick] (1.5,0) -- (3,0) node[right] {Yes $\rightarrow$ \textbf{SSE-KMS}}; \draw[->, thick] (0,-1.5) -- (0,-3) node[below] {No $\rightarrow$ \textbf{SSE-S3}}; \draw[dashed] (-2, -1) rectangle (5, 1); \node at (1.5, 1.2) {Server-Side Options}; \end{tikzpicture}

---

Definition-Example Pairs

• Automatic Key Rotation
  • Definition: The process where KMS generates new cryptographic material for a CMK every year without changing the Key ID.
  • Example: An enterprise policy requires keys to be changed every 12 months. Enabling rotation on a Customer-Managed CMK satisfies this without needing to re-encrypt existing data manually.
• Client-Side Encryption
  • Definition: Encrypting data on the local side of an application before it is sent to AWS.
  • Example: A healthcare company encrypts patient records on an on-premises server using the Amazon S3 encryption client before uploading to S3, ensuring AWS never sees the plaintext.

---

Worked Examples

Scenario: Encrypting an Unencrypted EBS Volume

You cannot "toggle" encryption on an existing EBS volume. To secure an unencrypted volume attached to an EC2 instance, follow these steps:

1. Stop the Instance: Ensure data consistency (though not always required, it is best practice).
2. Create Snapshot: Create a snapshot of the unencrypted volume.
   • Result: You now have an unencrypted snapshot.
3. Copy Snapshot: Use the Copy Snapshot command.
   • Key Action: Check the Encryption box and select your KMS CMK.
   • Result: You now have a NEW, encrypted snapshot.
4. Create Volume from Snapshot: Create a new EBS volume from the encrypted snapshot.
5. Swap Volumes: Detach the old volume and attach the new encrypted volume to the instance.

---

Checkpoint Questions

1. Which type of KMS key does not support automatic annual rotation?
   • Answer: External keys with imported key material.
2. True or False: If you enable default bucket encryption on S3, existing objects in that bucket are automatically encrypted.
   • Answer: False. Only objects uploaded after the setting is enabled are encrypted.
3. How are permissions managed for a KMS key?
   • Answer: Via Key Policies (required) and optionally IAM policies (if the key policy allows it).
4. What is the maximum number of CMKs you can create per region per account?
   • Answer: 10,000 keys.
5. Does EBS encryption protect data while it is moving from the EC2 instance to the EBS volume?
   • Answer: Yes, data is encrypted in-transit and at rest.

[!IMPORTANT] Always ensure that your IAM users or roles have the kms:GenerateDataKey and kms:Decrypt permissions in the key policy, or they will receive an "Access Denied" error even if they have full S3 or EBS permissions.