Amazon S3存储桶加密：KMS与AES256差异及访问疑问

Great question! Let's break this down clearly to explain the behavior you're seeing and the core differences between SSE-S3 AES256 and AWS KMS encryption (beyond just key policies).

Why End Users Can View SSE-S3 Encrypted Public Objects #

When you use SSE-S3 (AES256) encryption, AWS handles the entire key lifecycle behind the scenes:

• Each object is encrypted with a unique data key, which is then encrypted using a root AWS-managed master key (you never get direct access to this root key).
• When you mark an object as public, any anonymous user with the object's URL can send a retrieve request. AWS automatically decrypts the object on-the-fly before returning it—no explicit decryption permissions or key access is required for the user. The only check is whether the object's permissions allow public access; AWS takes care of decryption using its managed keys without exposing them to anyone.

Why KMS Encrypted Public Objects Throw the SigV4 Error #

With AWS KMS encryption, the workflow adds critical security layers that block anonymous access:

• The object's data key is encrypted using a KMS Customer Master Key (CMK) that you (or AWS, for managed CMKs) control. To retrieve the object, AWS must first call KMS to decrypt the data key.
• This KMS API call requires two things anonymous requests can't provide:
  1. AWS Signature Version 4 (SigV4): All KMS requests must be signed with valid AWS credentials, which anonymous users don't have.
  2. kms:Decrypt permission: Even if a user had credentials, they'd need explicit permission to use the CMK for decryption—something anonymous users can't be granted.

This is why public KMS-encrypted objects can't be accessed anonymously, while SSE-S3 ones work seamlessly.

Key Differences Between SSE-S3 AES256 and AWS KMS (Beyond Key Policies) #

• Key Ownership & Visibility:
  • SSE-S3: Keys are fully managed by AWS. You never see or interact with the root encryption keys; AWS handles rotation, storage, and security automatically.
  • KMS: You own (or can use AWS-managed) CMKs. You can view key metadata, configure rotation schedules, enable/disable keys, and even bring your own keys (BYOK) for full control.
• Decryption Workflow:
  • SSE-S3: Decryption is transparent and tied directly to object access permissions. AWS handles it automatically when a valid access request is made—no extra API calls or permissions needed.
  • KMS: Decryption requires an additional KMS API call, which needs SigV4 signing and explicit kms:Decrypt permissions. This blocks anonymous access but adds security for restricted content.
• Audit & Logging:
  • SSE-S3: You can only log object-level access (via CloudTrail or S3 access logs), but there's no visibility into how the underlying SSE-S3 keys are used—AWS keeps those details internal.
  • KMS: Every CMK operation (encrypt, decrypt, rotate, etc.) is logged in CloudTrail, giving you full auditability of key usage—critical for compliance and security monitoring.
• Cost Structure:
  • SSE-S3: Completely free to use—no extra charges for encryption/decryption operations.
  • KMS: Has associated costs: monthly fees for storing CMKs, plus per-call charges for KMS API operations (encrypt/decrypt counts towards this).
• Flexibility:
  • SSE-S3: A one-size-fits-all solution—all objects in a bucket use AWS-managed SSE-S3 keys by default, with limited per-object customization.
  • KMS: You can use different CMKs for different objects/buckets, allowing you to isolate keys across projects, teams, or compliance domains. You can also use multi-region CMKs for cross-region replication.

内容的提问来源于stack exchange，提问作者lft93ryt