AWS Security: Data Protection at Rest and in Transit

This guide covers the core cryptographic services within AWS, focusing on AWS Key Management Service (KMS), AWS CloudHSM, and AWS Certificate Manager (ACM). Understanding the distinction between managed and dedicated hardware solutions, as well as the mechanics of envelope encryption, is critical for the DevOps Engineer Professional exam.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between AWS KMS (multi-tenant) and AWS CloudHSM (single-tenant) based on compliance and architectural needs.
• Explain the process of Envelope Encryption using KMS Keys and Data Keys.
• Identify the appropriate encryption type (at rest vs. in transit) for various AWS services like S3, RDS, and ELB.
• Select the correct KMS Key type (Customer managed, AWS managed, or AWS owned) for specific administrative requirements.
• Describe how ACM manages the lifecycle of SSL/TLS certificates for data in transit.

Key Terms & Glossary

• KMS Key: The primary resource in AWS KMS. It is a logical representation of a master key (256-bit) used to generate and encrypt Data Keys.
• Data Key: An encryption key generated by KMS used to encrypt large volumes of data outside of the KMS service.
• Envelope Encryption: The practice of encrypting plaintext data with a data key, and then encrypting that data key under another key (the KMS Key).
• Hardware Security Module (HSM): A physical computing device that safeguards and manages digital keys and performs cryptographic operations.
• FIPS 140-2: A US government computer security standard used to approve cryptographic modules. CloudHSM provides Level 3, while KMS provides Level 2.
• Perfect Forward Secrecy (PFS): A feature of specific key agreement protocols that ensures that session keys are not compromised even if the private key of the server is compromised (often managed via ACM/ALB).

The "Big Idea"

In the AWS ecosystem, data protection is a shared responsibility. While AWS secures the infrastructure, the user is responsible for classifying data and applying the correct encryption. AWS KMS is the "glue" for data at rest, integrating with nearly every service (S3, EBS, RDS) to provide a seamless encryption experience. AWS CloudHSM is the "specialist" for high-compliance or legacy requirements, giving the user full control over the hardware. Finally, ACM handles the identity and encryption of data moving over the network (transit), ensuring that "who you are talking to" is verified and the conversation is private.

Formula / Concept Box

Hierarchical Outline

1. AWS Key Management Service (KMS)
   • Managed Service: Highly available, multi-tenant HSMs.
   • KMS Key Types:
     • Customer Managed: Created by you; full control over policies and rotation.
     • AWS Managed: Created by AWS services; you can view but not manage.
     • AWS Owned: Not in your account; used by AWS for internal service protection.
   • Envelope Encryption Workflow:
     1. Request Data Key from KMS.
     2. KMS returns Plaintext Data Key + Encrypted Data Key.
     3. App uses Plaintext Data Key to encrypt data, then discards it.
     4. App stores Encrypted Data Key alongside the encrypted data.
2. AWS CloudHSM
   • Dedicated Hardware: Single-tenant, resides within your VPC.
   • Control: You manage users and keys; AWS has no access to your key material.
   • Use Cases: Oracle TDE, SSL Offloading, Issuing Certificate Authorities.
3. AWS Certificate Manager (ACM)
   • Provisioning: Request public/private certificates.
   • Automation: Automatic renewal of certificates validated via DNS or Email.
   • Deployment: Integrated with ALB, CloudFront, and API Gateway.

Visual Anchors

KMS Envelope Encryption Flow

CloudHSM Network Architecture

Definition-Example Pairs

• Customer Managed Key (CMK)

  • Definition: A KMS key in your account that you create and manage, including the key policy and rotation settings.
  • Example: An organization creates a specific CMK for their "Finance" department to ensure that only members of the Finance-Admin IAM role can decrypt S3 buckets containing tax records.

• SSL Offloading

  • Definition: The process of moving the resource-intensive decryption of HTTPS traffic from the web server to a specialized device.
  • Example: Using CloudHSM to handle the RSA handshakes for a high-traffic web application, freeing up EC2 CPU cycles for application logic.

• KMS Grants

  • Definition: A mechanism to delegate subset of permissions on a KMS key, often used for temporary or programmatic access.
  • Example: An EC2 Auto Scaling group is given a "grant" to use a KMS key to decrypt an EBS volume during the instance launch process.

Worked Examples

Scenario: Encrypting an S3 Bucket with SSE-KMS

Goal: Ensure all objects uploaded to my-secure-data-bucket are encrypted at rest using a key that can be audited via CloudTrail.

1. Step 1: Create a Customer Managed Key (CMK).
   • Navigate to KMS Console -> Create Key -> Symmetric.
   • Define Alias: s3-data-key.
2. Step 2: Define Key Policy.
   • Grant kms:GenerateDataKey and kms:Decrypt to the IAM roles responsible for the application.
3. Step 3: Enable Default Encryption on S3.
   • Go to S3 Bucket Properties -> Default Encryption.
   • Select "Server-side encryption with AWS Key Management Service keys (SSE-KMS)".
   • Choose the s3-data-key created in Step 1.
4. Step 4: Verify in CloudTrail.
   • Perform a PutObject operation. Check CloudTrail logs for a GenerateDataKey event originating from S3 on your behalf.

Checkpoint Questions

1. What is the maximum data size that can be encrypted directly by a KMS Key without using envelope encryption? (Answer: 4 KB)
2. True or False: AWS has the ability to recover your keys in CloudHSM if you lose your credentials. (Answer: False - CloudHSM is single-tenant and user-managed).
3. How often does AWS automatically rotate AWS Managed Keys? (Answer: Every 3 years/1095 days; Customer Managed Keys can be rotated every 1 year).
4. Which service would you use to manage SSL certificates for a CloudFront distribution? (Answer: AWS Certificate Manager - ACM).

Muddy Points & Cross-Refs

• KMS vs. CloudHSM: The most common point of confusion. Remember: KMS is Shared Hardware/Managed Software. CloudHSM is Dedicated Hardware/Your Software. Choose CloudHSM ONLY if you need FIPS 140-2 Level 3 or need to use non-standard APIs like PKCS#11.
• Deleting Keys: You cannot delete a KMS key immediately. There is a mandatory waiting period of 7 to 30 days. This is a safety mechanism to prevent accidental data loss.
• Cross-Region Encryption: KMS keys are Region-specific. To move encrypted data between regions, you must either use Multi-Region Keys or re-encrypt the data in the destination region.

Comparison Tables

KMS Key Type Comparison

KMS vs. CloudHSM