AWS KMS and Encryption Strategies

AWS Key Management Service (KMS) is a managed service that enables you to create, manage, and control cryptographic keys used to encrypt your data. It is integrated with most AWS services for server-side encryption (SSE) and provides an API for client-side encryption. KMS uses Hardware Security Modules (HSMs) validated under FIPS 140-2 Level 2 (or Level 3 for some regions) to protect key material.

Before KMS, customers had to manage their own encryption keys using third-party HSMs or software libraries, which was complex and error-prone. KMS simplifies key management by providing a centralized, auditable, and highly available key store. It also integrates with AWS CloudTrail for logging every key usage, enabling compliance and security auditing.

KMS operates on the principle of envelope encryption. When you encrypt data, you don't encrypt the entire data directly with your Customer Master Key (CMK). Instead, KMS generates a data key (a symmetric key) and returns two versions: a plaintext data key and an encrypted copy of that data key (encrypted under the CMK). You use the plaintext data key for local encryption, then discard it. The encrypted data key is stored alongside the encrypted data. To decrypt, you send the encrypted data key to KMS, which decrypts it using the CMK and returns the plaintext data key. This allows you to encrypt large amounts of data without sending it all to KMS.

For customer managed symmetric CMKs, you can enable automatic rotation. When enabled, KMS rotates the key material annually. The old key material remains available for decryption of existing data. AWS managed keys are rotated every 3 years. Asymmetric CMKs do not support automatic rotation.

Access to CMKs is governed by a combination of key policies and IAM policies. The key policy is a resource-based policy attached to the CMK. It can grant access to principals (users, roles) and AWS services. IAM policies can also grant access, but only if the key policy explicitly allows it (by setting a default statement that allows IAM policies to control access). This is known as the IAM policy delegation pattern.

Envelope encryption is the process of encrypting data with a data key and then encrypting that data key with a CMK. This provides several benefits:

KMS supports an encryption context — a set of key-value pairs that are cryptographically bound to the encrypted data. The same encryption context must be provided during decryption. This provides additional security by tying the encryption to specific metadata (e.g., bucket name, object key).

Key operations: - Encrypt: Encrypts up to 1 MB of data directly with a CMK. For larger data, use envelope encryption. - Decrypt: Decrypts ciphertext that was encrypted under a CMK. - GenerateDataKey: Returns a plaintext data key and an encrypted copy. Used for envelope encryption. - GenerateDataKeyWithoutPlaintext: Returns only the encrypted data key. Useful when you don't need the plaintext immediately. - ReEncrypt: Decrypts ciphertext and re-encrypts it under a different CMK.

KMS integrates with many AWS services for server-side encryption: - S3: SSE-KMS for encrypting objects. You can specify a CMK or use the default aws/s3 key. - EBS: EBS volumes can be encrypted using KMS. Snapshots and AMIs inherit the encryption. - RDS: RDS instances can be encrypted at rest using KMS. Read replicas and snapshots are also encrypted. - DynamoDB: Tables can be encrypted at rest using KMS. - Lambda: Environment variables can be encrypted with KMS. - SQS: Queues can be encrypted with KMS. - SNS: Topics can be encrypted with KMS.

Every KMS API call is logged in CloudTrail. This includes key creation, deletion, rotation, and usage. You can monitor for unauthorized access or misconfiguration.

Multi-Region keys are a type of CMK that can be replicated to other AWS regions. They have the same key ID and key material in each region, allowing you to encrypt data in one region and decrypt in another. This is useful for disaster recovery and global applications.

Asymmetric CMKs have a public and private key pair. The public key can be distributed, while the private key never leaves KMS. Use cases: digital signing (with RSA or ECC) and encryption where the public key is used externally (e.g., for encrypting data that only KMS can decrypt).

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

Create a CMK:

aws kms create-key --description "My key"

Enable automatic rotation:

aws kms enable-key-rotation --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

Generate a data key:

aws kms generate-data-key --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --key-spec AES_256

Encrypt data:

aws kms encrypt --key-id 1234abcd-12ab-34cd-56ef-1234567890ab --plaintext fileb://plaintext.txt --output text --query CiphertextBlob | base64 --decode > encrypted.txt

Decrypt data:

aws kms decrypt --ciphertext-blob fileb://encrypted.txt --output text --query Plaintext | base64 --decode > decrypted.txt

A healthcare company stores patient records in Amazon S3. They must comply with HIPAA, which requires encryption of protected health information (PHI). They create a customer managed CMK with automatic rotation enabled. The key policy restricts usage to a specific IAM role used by their application. They enable S3 default encryption with SSE-KMS, specifying their CMK. For additional security, they use an encryption context with the patient ID and bucket name. CloudTrail logs all KMS operations for auditing. Performance is not an issue because S3 handles envelope encryption transparently. A common misconfiguration is forgetting to allow the S3 service principal in the key policy, causing access denied errors. Another issue is using the same CMK for all buckets, which violates least privilege; they should use separate CMKs for different data classifications.

A financial services company runs an RDS MySQL database in us-east-1 encrypted with a customer managed CMK. For disaster recovery, they need a read replica in us-west-2. They use a multi-region CMK: they create the key in us-east-1 and replicate it to us-west-2. The replica has the same key ID and key material. When they create a cross-region read replica, RDS uses the replicated key to encrypt the replica. If a failover occurs, the application can decrypt data in the secondary region using the same key. They must ensure the key policy in the secondary region grants appropriate permissions. A common mistake is not replicating the key before creating the replica, causing the replica creation to fail. Cost is higher due to the additional CMK in the second region.

A SaaS company encrypts sensitive user data before storing it in DynamoDB. They use client-side encryption with the AWS Encryption SDK. The SDK uses KMS to generate data keys and performs envelope encryption locally. They use a CMK with a key policy that restricts usage to the application's IAM role. The encryption context includes the user ID and table name. This ensures that even if the DynamoDB table is compromised, the data remains encrypted. Performance is acceptable because the SDK caches data keys. A common issue is not rotating the CMK regularly; they enable automatic rotation. Another pitfall is using the same encryption context for all records, which reduces security; they should use unique context per record.