Mastering AWS Encryption and Certificate Management (SAP-C02)

This guide covers the critical aspects of data protection within the AWS ecosystem, focusing on AWS Key Management Service (KMS), AWS CloudHSM, and AWS Certificate Manager (ACM) as required for the Solutions Architect Professional certification.

Learning Objectives

By the end of this module, you should be able to:

• Evaluate and implement encryption strategies for data at rest and data in transit across multi-account environments.
• Distinguish between AWS KMS and AWS CloudHSM based on compliance and control requirements.
• Design automated certificate management lifecycles using AWS Certificate Manager (ACM).
• Configure cross-account access for encryption keys using IAM and KMS Key Policies.

Key Terms & Glossary

• CMK (Customer Master Key): A logical representation of a key in KMS that includes metadata and the key material used to derive data keys.
• DEK (Data Encryption Key): A cryptographic key used by a service or application to encrypt a specific set of data; it is itself encrypted by a CMK.
• Envelope Encryption: The practice of encrypting data with a data key, and then encrypting the data key with a master key.
• FIPS 140-2 Level 3: A US government security standard for hardware security modules (HSMs). KMS is validated at Level 3 for the underlying HSMs.
• Perfect Forward Secrecy (PFS): A feature of specific key agreement protocols that ensures session keys are not compromised even if the private key of the server is compromised.

The "Big Idea"

In the AWS Shared Responsibility Model, Security in the Cloud is the customer's responsibility. Encryption acts as the "last line of defense." Even if physical or logical access controls fail, properly managed encryption ensures that data remains unreadable and useless to unauthorized parties. AWS simplifies this through managed services like KMS and ACM, which automate the heavy lifting of key rotation and certificate renewal.

Formula / Concept Box

Hierarchical Outline

1. Data at Rest Protection
   • AWS KMS
     • Symmetric vs. Asymmetric Keys
     • Key Policies (Resource-based) vs. IAM Policies
     • Granting cross-account access
   • AWS CloudHSM
     • Single-tenant, dedicated hardware
     • Custom Key Stores for KMS
     • Compliance (FIPS 140-2 Level 3 control)
2. Data in Transit Protection
   • TLS/SSL
     • Enforcing HTTPS via CloudFront/ALB
     • Perfect Forward Secrecy (PFS) support
3. Certificate Management
   • AWS Certificate Manager (ACM)
     • Public vs. Private CA
     • DNS vs. Email Validation
     • Automated Renewal (ACM-managed certificates)

Visual Anchors

KMS Envelope Encryption Flow

Certificate Lifecycle Management

\begin{tikzpicture}[node distance=2.5cm, auto] \draw[thick, ->] (0,0) -- (2,0) node[midway, above] {Request}; \draw (3,0) circle (1) node {ACM}; \draw[thick, ->] (4,0) -- (6,0) node[midway, above] {Validate}; \draw (7,0) rectangle (9,1) node[midway] {DNS/Email}; \draw[thick, ->] (8,0) -- (8,-1.5) -- (3,-1.5) node[midway, below] {Issued & Deployed}; \draw[thick, dashed, ->] (2,-1.5) -- (2,-0.5) node[midway, left] {Auto-Renew}; \end{tikzpicture}

Definition-Example Pairs

• Symmetric Encryption: Using the same key for encryption and decryption.
  • Example: Using a KMS Symmetric CMK to encrypt an Amazon EBS volume. It is fast and natively integrated with most AWS services.
• Asymmetric Encryption: Using a public key to encrypt and a private key to decrypt.
  • Example: Generating a key pair in KMS to sign a digital document or to allow external users to encrypt data that only your internal application can decrypt.
• Custom Key Store: An AWS KMS feature that allows you to store your KMS keys in an AWS CloudHSM cluster instead of the standard KMS storage.
  • Example: A financial institution required by law to have physical control over the HSM hardware while still wanting to use the KMS API for S3 encryption.

Worked Examples

Scenario: Cross-Account S3 Access with KMS

Goal: Account A wants to allow an IAM role in Account B to upload and encrypt objects to an S3 bucket in Account A using a KMS key located in Account A.

Step 1: The KMS Key Policy (in Account A) You must modify the Key Policy to grant the external account permission to use the key.

Step 2: The IAM Policy (in Account B) The user or role in Account B needs permission to access both the S3 bucket and the KMS key.

Checkpoint Questions

1. What is the main benefit of using a "Custom Key Store" for AWS KMS?
2. Why does ACM require DNS or Email validation before issuing a certificate?
3. True or False: AWS KMS keys can be exported out of the service to be used on-premises.
4. Which service would you choose if you need to perform high-throughput cryptographic operations using the PKCS#11 standard?

Muddy Points & Cross-Refs

• KMS vs. CloudHSM: This is the most common point of confusion. Remember: KMS is multi-tenant, managed, and easy to integrate; CloudHSM is single-tenant, customer-managed, and used for specialized compliance (FIPS 140-2 Level 3 full control) or legacy API support.
• ACM Renewal: ACM can only auto-renew certificates if they are validated via DNS or if the domain is correctly configured for email validation and the certificate is currently associated with an AWS resource (like an ALB).
• Cross-Ref: For more on how these keys are used in high-availability scenarios, see the Disaster Recovery (RTO/RPO) section.

Comparison Tables