Encryption and key management

Exam tasks: 1.2 (encryption strategies for data at rest and in transit, central key management across accounts), 2.3 (security controls for new solutions)

The decision: who must control the key (AWS, you, or hardware only you can touch), where must it be usable (one account, many accounts, many Regions), and how much operational work will you accept for that control?

Choosing where keys liveCopy Anchor Link

KMS key typesCopy Anchor Link

Other key flavours on a customer managed key:

• Symmetric (the default and what AWS services use), asymmetric (RSA and ECC for signing or public-key encryption outside AWS) and HMAC.
• Imported key material (BYOK): you generate the key material and import it. You can set it to expire and delete it immediately, but you're responsible for keeping a copy, and it doesn't rotate automatically.
• Deleting a key has a waiting period of 7 to 30 days. Disable the key first if you're unsure: disabled keys can be re-enabled, deleted ones can't.

Key policies and grantsCopy Anchor Link

• Every KMS key has exactly one key policy, and it is the primary control. IAM policies only work for a key if its key policy allows it, usually through the default statement that trusts the account root.
• Split key administrators (manage, rotate, schedule deletion) from key users (Encrypt, Decrypt, GenerateDataKey) in the key policy.
• Grants give a principal specific operations on one key, can be created and retired through the API, and don't need a key policy edit. AWS services such as EBS, RDS and Secrets Manager use grants behind the scenes. Grants are eventually consistent, so use a grant token for immediate use.
• Condition keys narrow use: kms:ViaService (only through S3 in a given Region), kms:EncryptionContext:..., kms:CallerAccount.

Cross-account key useCopy Anchor Link

1. The key policy in account K allows account A (or a role in A) to use the key.
2. An IAM policy in account A allows its principal the KMS actions on the key's ARN. Aliases don't work across accounts.
3. Many services resolve the key when they encrypt, so cross-account sharing works best with a single customer managed key per data domain in a central security account.

Multi-Region keysCopy Anchor Link

• A set of keys in different Regions with the same key ID and key material. Their IDs start with mrk-.
• Data encrypted in one Region can be decrypted in another without a cross-Region KMS call and without re-encrypting.
• Each replica is its own resource with its own key policy, grants and aliases. It isn't a global key.
• Use them for client-side encryption of data that moves between Regions (DynamoDB global tables, S3 replication of client-encrypted objects, signing in several Regions) and for DR. Don't use them by default: a single-Region key keeps data in one Region by design.

Envelope encryptionCopy Anchor Link

KMS itself encrypts only small payloads, up to 4 KB. For anything larger:

• The KMS key never leaves KMS. Only data keys travel, and the stored one is encrypted.
• This is how S3, EBS and every other integrated service work, and what the AWS Encryption SDK does for you.
• Pass an encryption context (non-secret key-value pairs) so ciphertext can only be decrypted with the same context, and so CloudTrail records what was decrypted.

CloudHSM and external key storesCopy Anchor Link

KMS already uses FIPS-validated HSMs, so "FIPS" alone doesn't demand CloudHSM. Look for these signals:

• CloudHSM is a cluster you run. Put at least two HSMs in different AZs, since a lost single HSM means lost keys unless you have backups.
• An external key store adds latency and makes your availability depend on your own HSM and proxy. Only choose it when a regulation requires it.

ACM and TLS certificatesCopy Anchor Link

• ACM certificates are regional. A certificate for an ALB must be in the ALB's Region.
• CloudFront (and edge-optimized API Gateway) needs the certificate in us-east-1, whatever Region the origin is in.
• ACM renews DNS-validated certificates automatically. Email-validated ones need someone to approve each renewal, so prefer DNS validation.
• By default you can't export the private key of an ACM public certificate. For TLS on EC2 itself, use an exportable certificate or AWS Private CA.

Encryption in transitCopy Anchor Link

S3 encryption optionsCopy Anchor Link

• S3 Bucket Keys make S3 derive a bucket-level key from the KMS key, which cuts KMS requests (and their cost and throttling risk) sharply for SSE-KMS. Turn it on for busy buckets.
• Changing the bucket's default encryption only affects new objects. Re-encrypt existing ones with S3 Batch Operations copy.
• To enforce a specific key, deny s3:PutObject in the bucket policy unless the encryption headers name that key, or set the default and block other options.
• Client-side encryption (for example with the Encryption SDK) means S3 only ever sees ciphertext.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• AWS KMS concepts
• Multi-Region keys in AWS KMS
• Protecting data with server-side encryption in S3
• ACM supported Regions