Implementing Access Policies for AWS Encryption Keys

This guide explores the mechanisms and best practices for controlling access to encryption keys within AWS, focusing on the AWS Key Management Service (KMS) and its integration with Identity and Access Management (IAM) and Secrets Manager.

---

Learning Objectives

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

• Distinguish between AWS-managed and Customer-managed KMS keys (CMKs).
• Configure Key Policies and IAM Policies to enforce the principle of least privilege.
• Implement cross-account access for KMS keys using resource-based policies.
• Analyze the role of AWS CloudTrail in auditing key usage for compliance.
• Manage key lifecycles, including rotation, disabling, and deletion.

---

Key Terms & Glossary

• CMK (Customer Master Key): A logical representation of an encryption key. It includes metadata (key ID, creation date, description) and points to the key material used for encryption/decryption.
• Key Policy: A resource-based policy attached specifically to a KMS key. It is the primary way to control access to the key.
• Grant: A mechanism that allows an AWS principal to use a KMS key in cryptographic operations, often used for temporary permissions or integration with other AWS services.
• Envelope Encryption: The practice of encrypting data with a data key, and then encrypting the data key with a root key (the CMK).
• HSM (Hardware Security Module): FIPS 140-2 validated hardware where KMS key material is securely stored and used.

---

The "Big Idea"

Encryption is only as secure as the access control surrounding the keys. In AWS, KMS serves as the central "Trust Anchor." The core philosophy is decoupling: the service that stores the data (like S3 or EBS) does not hold the keys. Instead, it must prove it has permission to use a key managed by KMS. This separation of duties ensures that even if a storage layer is compromised, the data remains unreadable without specific KMS permissions.

---

Formula / Concept Box

[!IMPORTANT] For an IAM policy to grant access to a KMS key, the Key Policy must explicitly allow the account to use IAM policies for that key. This is known as "enabling IAM policies."

---

Hierarchical Outline

1. KMS Key Types
   • Symmetric Keys: 256-bit keys used for Encrypt/Decrypt (most common).
   • Asymmetric Keys: Public/Private key pairs used for signing/verifying or encryption.
2. Access Control Layers
   • Key Policies: The mandatory first layer of security.
   • IAM Policies: Used in conjunction with Key Policies for centralized management.
   • Grants: Programmatic, granular permissions for services.
3. The Lifecycle of a Key
   • Creation & Storage: Key material resides in HSMs.
   • Rotation: Prevents excessive data encryption under a single key.
   • Auditing: CloudTrail logs every API call (e.g., kms:Decrypt).

---

Visual Anchors

KMS Authorization Logic

This flowchart describes how AWS decides whether to allow a request to use a key.

Envelope Encryption Workflow

This TikZ diagram illustrates how KMS manages data keys for local encryption.

\begin{tikzpicture}[node distance=2cm, auto] \draw[thick, fill=blue!10] (0,4) rectangle (3,5) node[midway] {KMS CMK}; \draw[thick, fill=green!10] (0,2) rectangle (3,3) node[midway] {Data Key}; \draw[thick, fill=gray!10] (5,2) rectangle (8,3) node[midway] {Plaintext Data}; \draw[thick, fill=red!10] (5,0) rectangle (8,1) node[midway] {Encrypted Data};

\end{tikzpicture}

---

Definition-Example Pairs

• Resource-Based Policy (Key Policy): A JSON document attached directly to the key defining who can use it.
  • Example: Creating a key policy that allows the "Finance-Role" to kms:Decrypt but prevents the "Dev-Role" from doing so.
• Identity-Based Policy (IAM Policy): A policy attached to a user/group/role that grants permission to use KMS.
  • Example: Attaching an IAM policy to an EC2 Instance Profile so an application can retrieve and decrypt secrets from Secrets Manager.
• Automatic Key Rotation: A KMS feature where the service generates new cryptographic material for the CMK every year.
  • Example: Enabling rotation for a CMK used by a database to meet PCI-DSS compliance requirements without updating application code.

---

Worked Examples

Example 1: The "Separator of Duties" Policy

Scenario: A company wants to ensure that the administrator who manages the keys cannot actually use the keys to decrypt sensitive data.

The Solution: Split the Key Policy into two statements:

1. Key Administrator Statement: Allows kms:Create*, kms:Describe*, kms:Enable*, and kms:PutKeyPolicy. It specifically excludes kms:Decrypt.
2. Key User Statement: Allows kms:Encrypt and kms:Decrypt to a specific application role, but excludes management permissions.

Example 2: Cross-Account Access

Scenario: Account A has a KMS key that Account B needs to use to encrypt S3 objects.

Step-by-Step Breakdown:

1. Modify Key Policy in Account A: Add the ARN of the IAM user/role from Account B to the "Principal" section of the Key Policy.
2. Add IAM Policy in Account B: Create a policy for the user/role in Account B that grants kms:Encrypt on the ARN of the key in Account A.
3. Result: Account B can now successfully call the KMS service in Account A.

---

Checkpoint Questions

1. If a user has an IAM policy allowing kms:Decrypt but the Key Policy does not mention them (and does not enable IAM policies), can they decrypt data?
2. Which type of KMS key does NOT support automatic annual rotation?
3. Why is it best practice to use a private interface endpoint (PrivateLink) for Secrets Manager on EC2 instances in a VPC?
4. What AWS service provides the audit trail to see who used a specific CMK at 3:00 PM yesterday?

▶Click for Answers

1. No. The Key Policy is the primary authority; if it doesn't allow the account to use IAM or explicitly allow the user, the request is denied.
2. Imported Keys (External Key Material) do not support automatic rotation.
3. It ensures traffic stays on the AWS private network, improving security by not traversing the public internet.
4. AWS CloudTrail.