Securing Sensitive S3 Data: The Problem & The Solution

Source: Dev.to

The Problem: Sensitive Data & Granular Access

Imagine your company stores customer call logs in an Amazon S3 bucket. This data contains PII (Personally Identifiable Information), so it must be encrypted at rest.

Standard encryption isn’t enough. Only specific employees (e.g., the Compliance Team) should be able to decrypt and read these logs. Even if a system administrator has access to the S3 bucket itself, they should not be able to read this sensitive data.

The Challenge

How do you enforce encryption while strictly limiting who can use the decryption keys, with the least amount of operational effort?

The Solution: SSE‑KMS with IAM Policies

The most effective solution is to use Server‑Side Encryption with AWS KMS keys (SSE‑KMS) combined with restrictive IAM policies.

How it works

• SSE‑KMS: Instead of letting S3 manage the keys transparently (SSE‑S3), you use AWS Key Management Service (KMS). This allows you to create a specific Customer Managed Key (CMK) for these call logs.
• Key Policies: Configure the key policy (or attach an IAM policy to users) to explicitly allow only the designated employees (e.g., the Compliance Team) to use kms:Decrypt for that key.

The Result

If a general admin tries to download the object, S3 may let them retrieve the file, but because they lack permission to use the KMS key, the data remains a garbled, encrypted mess.

Why this wins

• Separates storage access from data access.
• Satisfies the principle of Least Privilege.
• Requires no additional hardware (no CloudHSM) and no manual key management on your own servers (no SSE‑C).