15.2 Cryptographic Controls & Key Management with AWS KMS & ACM

AWS KMS Cryptographic Architecture & Key Tiers

AWS Key Management Service (AWS KMS) provides centralized, hardware security module (HSM)-backed cryptographic key generation and management validated under FIPS 140-2 Cryptographic Module Validation Program (FIPS 140-3 Level 3 for modern HSMs). Understanding the operational tiers of KMS keys is vital for DevOps engineers designing data protection pipelines.

KMS Key Categories Comparison

---

KMS Key Policies, IAM Policies & Access Control

Unlike most AWS services where IAM policies alone can grant access, AWS KMS enforces a strict hierarchical authorization model: The Key Policy is the primary access control document. IAM policies are completely powerless unless the Key Policy explicitly delegates authority.

The Critical Root Principal Delegation Statement

For an IAM identity policy (attached to a role, user, or group) to grant permissions to a KMS key, the Key Policy must contain the following default delegation statement:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

[!WARNING] DOP-C02 Exam Critical Warning: In this context, arn:aws:iam::111122223333:root does not refer to the root user account credentials; it represents the AWS Account entity. This statement delegates access control to the account's IAM service. If this statement is removed or omitted and no other IAM principal is explicitly allowed in the Key Policy, the key becomes orphaned: no IAM policy in the account can grant access, and only the AWS account root user credentials can restore the Key Policy.

Key Policies vs. KMS Grants

While Key Policies provide static access definitions, KMS Grants offer dynamic, programmatic, and fine-grained access delegation without requiring updates to the JSON Key Policy.

• Use Cases for Grants: Used extensively by AWS services (e.g., Amazon EBS when attaching an encrypted volume to an EC2 instance, or Amazon RDS creating read replicas across regions). Grants can be scoped with an EncryptionContextEquals condition and revoked via kms:RevokeGrant or retired via kms:RetireGrant.
• Operational Advantage: Prevents hitting Key Policy character limits (maximum 32 KB) when dozens of microservices or automated deployment workers require temporary cryptographic rights.

---

Key Rotation Mechanics: Automatic vs. On-Demand

AWS KMS provides two mechanisms for rotating the backing cryptographic key material of Customer Managed Keys.

1. Automatic Key Rotation

When automatic rotation is enabled on a symmetric CMK:

• AWS KMS automatically creates a new version of the underlying cryptographic key material on the specified schedule (configurable between 90 and 2560 days; defaults to 365 days).
• The Key ID, Key ARN, Key Policy, and Aliases remain unchanged.
• KMS retains all historical backing key material indefinitely. When an application calls kms:Encrypt, KMS uses the latest key material version. When an application calls kms:Decrypt on legacy data encrypted years earlier, KMS detects the backing key version stored in the ciphertext metadata and transparently decrypts it.
• Zero operational overhead: No re-encryption pipelines, database migrations, or application configuration updates are needed.

2. Manual / On-Demand Key Rotation

• Used when automatic rotation is unsupported (e.g., asymmetric keys) or when an organization must rotate keys immediately following a security incident.
• The engineer generates a completely new CMK with a new Key ID and ARN.
• The engineer updates the Key Alias (alias/app-key) to point to the new Key ID.
• Previous CMKs must be preserved indefinitely to decrypt legacy ciphertext unless all historical datasets are re-encrypted using the new key.

---

Cross-Account KMS Key Sharing Pattern

Sharing KMS keys across AWS accounts is a standard requirement in multi-account enterprise architectures (e.g., CI/CD account deploying encrypted resources to production, or centralized S3 data lakes).

Two-Sided Authorization Architecture

Cross-account KMS access requires explicit permission on both sides of the trust boundary:

Account A (Key Owner: 111122223333)           Account B (Consumer: 444455556666)
┌──────────────────────────────────────┐     ┌──────────────────────────────────────┐
│ KMS Customer Managed Key             │     │ IAM Role: AppDeploymentRole          │
│                                      │     │                                      │
│ Key Policy:                          │     │ Attached IAM Policy:                 │
│ {                                    │     │ {                                    │
│   "Effect": "Allow",                 │     │   "Effect": "Allow",                 │
│   "Principal": {                     │◄────┼───│   "Action": [                    │
│     "AWS": "arn:aws:iam::4444..."    │     │   │     "kms:Encrypt",               │
│   },                                 │     │   │     "kms:Decrypt",               │
│   "Action": [                        │     │   │     "kms:GenerateDataKey"        │
│     "kms:Encrypt",                   │     │   │   ],                             │
│     "kms:Decrypt",                   │     │   │   "Resource": "arn:aws:kms:..."  │
│     "kms:GenerateDataKey"            │     │   │ }                                │
│   ],                                 │     │ }                                    │
│   "Resource": "*"                    │     └──────────────────────────────────────┘
│ }                                    │
└──────────────────────────────────────┘

1. Account A (KMS Owner): The KMS Key Policy must explicitly declare Account B (or the specific IAM role ARN in Account B) as a trusted principal for kms:Decrypt, kms:GenerateDataKey, and kms:DescribeKey.
2. Account B (Workload Account): The IAM Role executing the operation must have an attached identity policy explicitly allowing kms:Decrypt and kms:GenerateDataKey targeting the Key ARN in Account A.
3. S3 Bucket Considerations: If writing cross-account to S3 with KMS encryption, the writer needs kms:GenerateDataKey on the key and s3:PutObject on the bucket. The bucket policy must permit the upload, and object ownership must be set to BucketOwnerEnforced to ensure the bucket owner can read the uploaded objects.

---

Envelope Encryption Deep Dive

The KMS Encrypt API accepts plaintext of up to 4,096 bytes. For symmetric ciphertext, the Decrypt API accepts a ciphertext blob of up to 6,144 bytes because the blob includes KMS metadata in addition to the encrypted plaintext. To encrypt multi-megabyte or gigabyte files (e.g., EBS volumes, S3 objects, database snapshots), AWS uses Envelope Encryption.

The Envelope Encryption Lifecycle

1. Key Generation: The client application calls kms:GenerateDataKey specifying the Customer Master Key (CMK) ARN and desired key spec (AES_256).
2. KMS Response: KMS returns two representations of a newly generated symmetric key:
   • Plaintext Data Key: 256-bit symmetric key.
   • Encrypted Data Key (Ciphertext): The data key encrypted under the CMK.
3. Local Payload Encryption: The application uses the Plaintext Data Key to encrypt the payload locally using an algorithm like AES-GCM or AES-CBC in memory.
4. Memory Purge: The application immediately zeroes out and purges the Plaintext Data Key from memory.
5. Storage: The application stores the Encrypted Data Key adjacent to the ciphertext (e.g., in S3 object user metadata headers or a database metadata column).
6. Decryption Phase: To decrypt, the application extracts the Encrypted Data Key and passes it to kms:Decrypt. KMS decrypts the data key using the CMK and returns the Plaintext Data Key. The application decrypts the data locally, then immediately wipes the plaintext key from memory.

[ Application ] ──> kms:GenerateDataKey(CMK) ──> [ AWS KMS HSM ]
       │                                                │
       │◄── Plaintext Data Key + Encrypted Data Key ────┘
       ▼
[ Encrypt Payload Locally with Plaintext Data Key ]
       │
       ├──> [ Zero Out Plaintext Data Key from RAM ]
       ▼
[ Store: Payload Ciphertext + Encrypted Data Key in S3/EBS ]

---

AWS Certificate Manager (ACM) & AWS Private CA

Securing data in transit requires managing SSL/TLS certificates across microservices, load balancers, and public entry points.

ACM Public Certificates: DNS vs. Email Validation

ACM Regional Constraints

• CloudFront Distributions: To attach an ACM certificate to an Amazon CloudFront distribution, the certificate must be created in the us-east-1 (N. Virginia) region.
• Application Load Balancers & API Gateways: ACM certificates must be created in the same AWS Region as the load balancer or regional API Gateway.

AWS Private CA for Internal Microservices

Standard ACM public certificates are bound to integrated AWS services (ALB, CloudFront, API Gateway) and their private keys cannot be retrieved; ACM also offers an opt-in exportable public certificate option, selected at request time and separately priced, whose private key can be downloaded with a passphrase for use on EC2, on-premises, or multi-cloud hosts. For internal, non-public trust chains, AWS Private CA enables organizations to build a private hierarchical Public Key Infrastructure (PKI):

• Issues private certificates with exportable private keys for internal EC2 instances, containers running on Amazon ECS/EKS, and supported service meshes (for example, Istio).
• Supports mutual TLS (mTLS) authentication for zero-trust microservice architectures.
• Automates renewal via IAM roles and Systems Manager agents without exposing endpoints to public internet DNS validation.

---

AWS CloudHSM vs. AWS KMS

Both services protect cryptographic key material with hardware security modules, but they assign control and operations differently:

A KMS custom key store backed by CloudHSM combines KMS APIs and integrations with key material in a CloudHSM cluster that the customer controls. That extra control also adds failure modes: KMS cryptographic operations using the custom key store depend on a healthy, connected CloudHSM cluster. On the exam, do not choose CloudHSM merely because a question says “encryption”; identify a dedicated-HSM, direct-interface, or key-custody requirement that justifies its cost and operational burden.