Configuring Encryption Across AWS Account Boundaries

This guide focuses on the secure implementation of cross-account data access using AWS Key Management Service (AWS KMS). In a multi-account AWS environment, sharing encrypted data requires a coordinated "handshake" of permissions between the account that owns the encryption key and the account that needs to access the data.

Learning Objectives

After studying this guide, you should be able to:

• Identify the two mandatory policy configurations required for cross-account KMS access.
• Distinguish between AWS-managed keys and Customer Managed Keys (CMKs) in the context of cross-account sharing.
• Configure S3 Server-Side Encryption (SSE-KMS) to allow external account principals to decrypt objects.
• Explain the role of Envelope Encryption when dealing with datasets larger than 4 KB.

Key Terms & Glossary

• KMS Key (CMK): A logical representation of an encryption key. It contains metadata such as the key ID, creation date, and the key material used to encrypt/decrypt data.
• Key Policy: A resource-based policy attached to a KMS key that determines who can use or manage the key. This is the primary way to control access to a KMS key.
• Principal: An entity (user, role, or account) that is allowed or denied access to a resource.
• SSE-KMS: Server-Side Encryption using KMS keys stored in AWS KMS. It provides an audit trail of key usage via CloudTrail.
• Envelope Encryption: The practice of encrypting plaintext data with a data key, and then encrypting that data key with a root key (the KMS key).

The "Big Idea"

[!IMPORTANT] The Cross-Account Handshake: For a user in Account B to use a key in Account A, both accounts must "opt-in." Account A must delegate authority to Account B via a Key Policy, and Account B must grant its users permission to use that external key via an IAM Policy.

Formula / Concept Box

Hierarchical Outline

1. KMS Key Types
   • AWS Managed Keys: Created by AWS services; cannot be shared across accounts.
   • Customer Managed Keys (CMK): Created by you; support full policy control and cross-account sharing.
2. The Sharing Process
   • Trust Establishment: Account A adds Account B to the Key Policy.
   • Identity Permission: Account B creates an IAM policy targeting the Key ARN in Account A.
3. Service Integration (S3 Example)
   • S3 uses SSE-KMS for cross-account scenarios.
   • Bucket policies may also need to grant s3:GetObject to Account B.
4. Security Best Practices
   • Enable Key Rotation (Automatic for symmetric CMKs).
   • Use Key Aliases for application code (though ARNs are required for cross-account policy definitions).

Visual Anchors

The Cross-Account Permission Flow

The Envelope Encryption Mechanism

Definition-Example Pairs

• Key Policy Delegation: Granting another AWS account the right to use a key.
  • Example: Account 111122223333 adds "Principal": {"AWS": "arn:aws:iam::444455556666:root"} to its KMS policy. This allows the administrator of Account 444455556666 to further delegate that key to their own users.
• SSE-KMS: Using a specific CMK to encrypt S3 objects.
  • Example: A financial firm requires that all PII data in S3 be encrypted with a key they control and rotate annually, rather than using the default S3 managed key.

Worked Examples

Scenario: Sharing an S3 Bucket Across Accounts

Problem: You have data in Account A (Resource Account) encrypted with a KMS CMK. A Lambda function in Account B (Processing Account) needs to read this data.

Step-by-Step Solution:

1. In Account A: Open the KMS Console. Select the CMK. Edit the Key Policy to include Account B's ARN as a user.
   jsonCopy

   { "Sid": "Allow cross-account use", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:root" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }
2. In Account B: Create an IAM Policy for the Lambda execution role.
   jsonCopy

   { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms:region:AccountA-ID:key/key-uuid" }
3. Result: The Lambda can now call s3:GetObject. S3 will automatically pass the kms:Decrypt request to Account A, which will be approved because of the policy handshake.

Checkpoint Questions

1. Can you share an AWS Managed Key (e.g., aws/ebs) with another account? (Answer: No, only Customer Managed Keys).
2. If Account A grants Account B access in the Key Policy, but Account B does not give its users an IAM policy for that key, can the users access the data? (Answer: No, both policies must allow it).
3. Which API action is required by a user to upload an encrypted file to S3 using a KMS key? (Answer: kms:GenerateDataKey).

Comparison Tables

Muddy Points & Cross-Refs

• Key Aliases: You cannot use a Key Alias (e.g., alias/mykey) in a cross-account IAM policy. You must use the full Key ARN.
• S3 Bucket Policies: Don't forget that even if KMS is configured, the S3 bucket policy in Account A must also allow Account B to perform s3:GetObject.
• Encryption In-Transit: While KMS handles data at rest, cross-account transfers should always enforce TLS using aws:SecureTransport in the bucket policy.