Enforce Amazon S3 SSE-KMS Encryption with Bucket Policies – SAP-C02 Study Guide

Purpose of This Lesson

Amazon S3 automatically encrypts new objects at rest using server-side encryption, typically with S3-managed keys (SSE-S3). However, some security and compliance requirements require objects to use AWS Key Management Service keys (SSE-KMS) instead.

This lesson explains how to enforce SSE-KMS for object uploads with an S3 bucket policy and how to select the appropriate KMS key.

Key Concepts

S3 default encryption is not the same as enforced SSE-KMS

S3 default bucket encryption establishes what S3 should apply when an upload does not specify another encryption setting. It does not necessarily force every client to explicitly request SSE-KMS in its upload request.

A bucket policy can enforce the request header:

x-amz-server-side-encryption: aws:kms

Requests that do not include the required SSE-KMS value are denied.

SSE-S3 versus SSE-KMS

• SSE-S3: S3 encrypts objects with keys managed entirely by S3.
• SSE-KMS: S3 uses AWS KMS to generate and protect encryption keys.
• Customer managed KMS key: Provides more control over key policy, IAM permissions, rotation configuration, grants, auditing, and lifecycle management.
• AWS managed KMS key for S3: A key managed by AWS for the service, commonly represented by the aws/s3 alias. It reduces administration but offers less direct control than a customer managed key.

Object-level resource ARNs require /*

PutObject operates on objects, not on the bucket itself. Therefore, the policy resource must identify objects in the bucket:

arn:aws:s3:::example-bucket/*

The bucket ARN without /* is used for bucket-level actions such as s3:ListBucket.

The enforcement policy pattern

A concise policy statement denies uploads unless the request specifies SSE-KMS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedOrNonKMSUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

The explicit Deny is important. It overrides an otherwise permissive identity policy, making the requirement apply broadly to principals that access the bucket.

KMS key selection

When uploading through the S3 console or an API, the client can select either:

• An AWS managed KMS key for S3, or
• A customer managed KMS key identified by its key ARN or key ID.

A customer managed key is preferable when the organization needs direct control over key policy, cross-account access, auditability, or key deactivation. It also introduces more operational responsibility.

KMS permissions still apply

Using SSE-KMS does not eliminate authorization checks. The uploading principal and S3 must be able to use the selected KMS key according to the applicable IAM policy, KMS key policy, and grants.

For uploads, permissions commonly include kms:GenerateDataKey. Downloads and some object operations commonly require kms:Decrypt. Multipart uploads and copy operations may require additional KMS permissions depending on the operation and implementation.

Exam-Relevant Takeaways

• S3 default encryption is enabled by default, but a bucket policy is the stronger control when uploads must use a specific encryption type.
• Require SSE-KMS by denying s3:PutObject when s3:x-amz-server-side-encryption is not equal to aws:kms.
• Use arn:aws:s3:::bucket-name/* for object actions such as s3:PutObject.
• A bucket policy can enforce the encryption request header, but it does not by itself grant KMS key usage permissions.
• Customer managed KMS keys provide greater control than AWS managed keys, but require more administration.
• A failed upload may be caused by either the S3 bucket policy or missing KMS permissions.
• If the design requires one particular KMS key, checking only the encryption type may be insufficient. Add a condition such as s3:x-amz-server-side-encryption-aws-kms-key-id to restrict the key ARN or key ID.

Architecture Decision Guide

Requirement	Recommended approach	Main tradeoff
Encrypt objects at rest with minimal configuration	S3 default encryption using SSE-S3	Less control over key administration and usage policies
Require all uploads to use KMS-backed encryption	Bucket policy denying requests without aws:kms	Clients must send the correct encryption header and have KMS permissions
Control key policy, rotation, disabling, and audit events	Customer managed KMS key	Additional cost, policy design, quotas, and operational responsibility
Use a service-managed key with less administration	AWS managed aws/s3 KMS key	Limited direct control compared with a customer managed key
Require a specific customer managed key	Enforce both SSE-KMS and the KMS key ID condition	More restrictive; all clients must use the approved key
Permit uploads from multiple AWS accounts	Coordinate S3 bucket policy, IAM policies, and KMS key policy/grants	Cross-account KMS authorization is easy to misconfigure

Common Exam Traps

• Using the bucket ARN for s3:PutObject: The resource must end in /* because the action targets objects.
• Assuming default encryption is always a compliance control: Default encryption protects objects when no override is supplied, but a policy-based explicit deny is the reliable enforcement mechanism.
• Checking only for an encryption header: A request can specify an encryption mode that is not the required KMS mode. Check that the value is exactly aws:kms.
• Forgetting KMS authorization: S3 access and KMS key usage are separate authorization decisions.
• Confusing SSE-KMS with client-side encryption: SSE-KMS is performed by AWS after the request reaches S3. Client-side encryption occurs before the object is sent to AWS.
• Assuming aws:kms identifies a particular key: It identifies the encryption type, not necessarily the exact KMS key. Add a key-ID condition when key-level control is required.
• Ignoring existing objects: A new bucket policy controls future requests; it does not automatically re-encrypt objects already stored with SSE-S3.
• Overlooking non-PutObject upload paths: Multipart uploads, copy operations, replication, and service integrations may need separate validation and permissions.

Real-World Engineer Notes

• Test the policy with every upload path used by the application: SDK calls, CLI commands, console uploads, multipart uploads, and S3 copy operations.
• If using a customer managed key, define a clear KMS key policy and least-privilege IAM permissions. Avoid granting broad kms:* access.
• Consider adding a second condition to enforce the approved key:

"Condition": {
  "StringNotEquals": {
    "s3:x-amz-server-side-encryption": "aws:kms",
    "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:111122223333:key/example-key-id"
  }
}

In production, structure multiple conditions carefully so that the resulting deny logic matches the intended requirement. Test with policy simulation and controlled uploads.

• CloudTrail data events for S3 and KMS events can help identify which principal attempted an upload and where authorization failed.
• S3 Bucket Keys can reduce the number of KMS requests for SSE-KMS objects and potentially reduce KMS request costs, but they do not change the requirement for KMS-based encryption.
• For cross-account access, the caller’s IAM policy and the KMS key policy must both permit the required operation. An S3 bucket policy alone is not sufficient.
• Enforcing encryption at the bucket boundary is generally more reliable than relying on application developers to remember request parameters.

Quick Reference Summary

• Required header: x-amz-server-side-encryption: aws:kms
• S3 object resource pattern: arn:aws:s3:::bucket-name/*
• Enforcement mechanism: explicit Deny on s3:PutObject
• Default encryption: useful baseline, but not equivalent to a policy deny
• AWS managed S3 KMS key: less administration
• Customer managed KMS key: more control and more responsibility
• Common upload KMS permission: kms:GenerateDataKey
• Common download KMS permission: kms:Decrypt
• Specific-key enforcement: also evaluate s3:x-amz-server-side-encryption-aws-kms-key-id

Flashcards

1. Q: What S3 request header identifies SSE-KMS?

A: x-amz-server-side-encryption with the value aws:kms.

1. Q: Which policy effect is normally used to enforce SSE-KMS?

A: An explicit Deny for s3:PutObject requests that do not specify the required SSE-KMS value.

1. Q: Why does an object policy resource end with /*?

A: s3:PutObject is an object-level action, so the resource must represent objects inside the bucket.

1. Q: Does S3 default encryption guarantee that every request explicitly uses SSE-KMS?

A: No. A bucket policy can explicitly deny requests that do not provide the required SSE-KMS header.

1. Q: What is the main benefit of a customer managed KMS key?

A: Direct control over the key policy, permissions, rotation configuration, auditing, and lifecycle.

1. Q: What is a common KMS permission needed for an SSE-KMS upload?

A: kms:GenerateDataKey, subject to the exact operation and authorization configuration.

1. Q: What additional condition helps require one specific KMS key?

A: s3:x-amz-server-side-encryption-aws-kms-key-id.

1. Q: Does an S3 bucket policy grant access to the KMS key?

A: No. KMS authorization must also be allowed through IAM, the KMS key policy, or grants.

1. Q: What happens to existing SSE-S3 objects after adding an SSE-KMS enforcement policy?

A: They remain as they are; the policy does not automatically re-encrypt them.

1. Q: What is the difference between SSE-KMS and client-side encryption?

A: SSE-KMS encrypts the object within the S3 service, while client-side encryption encrypts data before it is uploaded.

Practice Questions

Question 1

A company requires every new object uploaded to an S3 bucket to use KMS-backed server-side encryption. Developers currently have s3:PutObject, but some applications upload objects without specifying encryption. Which control best enforces the requirement?

A. Enable S3 default encryption with SSE-S3
B. Add an explicit bucket-policy deny for s3:PutObject when s3:x-amz-server-side-encryption is not aws:kms
C. Add kms:Encrypt to the developers’ IAM policies
D. Enable S3 Versioning

Correct answer: B

Explanation: Default encryption is a baseline, but the explicit deny prevents uploads that do not request SSE-KMS. KMS permissions alone do not force clients to use KMS, and Versioning is unrelated.

Question 2

An architect writes a bucket policy for s3:PutObject with the resource arn:aws:s3:::finance-bucket. Uploads are not controlled as expected. What is the most likely problem?

A. s3:PutObject requires the AWS account ARN
B. The resource must use the object ARN pattern arn:aws:s3:::finance-bucket/*
C. s3:PutObject can only be used in an identity policy
D. S3 does not support KMS encryption

Correct answer: B

Explanation: PutObject is an object-level action, so the policy resource must identify objects with /*.

Question 3

An upload includes x-amz-server-side-encryption: aws:kms, but S3 returns an access-denied error. The bucket policy allows the upload when this header is present. Which additional issue should be investigated first?

A. Whether the caller or relevant key policy permits KMS key usage
B. Whether S3 Versioning is enabled
C. Whether the bucket has a lifecycle policy
D. Whether the object has a public ACL

Correct answer: A

Explanation: S3 authorization and KMS authorization are separate. The caller and key configuration must permit the required KMS operation, commonly including data-key generation for uploads.

Question 4

A regulated workload must use one customer managed KMS key for all objects in an S3 bucket. Which policy design best satisfies this requirement?

A. Check only that the request contains any encryption header
B. Require aws:kms and restrict s3:x-amz-server-side-encryption-aws-kms-key-id to the approved key
C. Enable public read access and rely on KMS encryption
D. Use SSE-S3 and store the key ARN in object metadata

Correct answer: B

Explanation: The encryption-type condition ensures KMS is used, while the key-ID condition ensures the approved customer managed key is selected.

Question 5

A team adds an SSE-KMS enforcement policy to a bucket containing existing SSE-S3 objects. What should the architect tell the team?

A. All existing objects are automatically re-encrypted with KMS
B. Existing objects are deleted because they do not satisfy the policy
C. The policy primarily controls new requests; existing objects require a separate re-encryption or copy process
D. The bucket policy is ignored for all objects created before the policy

Correct answer: C

Explanation: A bucket policy does not transform existing data. Existing objects must be copied or otherwise re-encrypted through a planned migration process if compliance requires SSE-KMS for them.