The most surprising thing about how cloud providers encrypt data at rest is that they don’t encrypt your data with your keys by default, but rather with keys they manage, which they then encrypt with other keys.
Imagine you’ve uploaded a crucial database backup to a cloud storage bucket. You want to be sure it’s safe, so you enable "encryption at rest." What happens under the hood is a multi-layered dance of keys. The cloud provider uses a data encryption key (DEK) to encrypt your actual data. This DEK is unique per object or a group of objects. Then, this DEK itself is encrypted by a key encryption key (KEK). The KEK is where the "at rest" part gets interesting.
Here’s a simplified look at how it might work in a typical object storage service like AWS S3 with Server-Side Encryption (SSE-S3):
- Data Encryption Key (DEK): When you upload
my-backup.sql, S3 generates a unique DEK. - Data Encryption:
my-backup.sqlis encrypted using this DEK. The encrypted data is stored. - Key Encryption Key (KEK): S3 then takes that DEK and encrypts it using a master KEK managed by AWS. This is often referred to as a "customer master key" (CMK) in AWS terminology, though for SSE-S3, it’s a master key managed by AWS itself.
- Storage: The encrypted DEK is stored alongside the encrypted data.
When you request my-backup.sql, the process reverses:
- S3 retrieves the encrypted data and the encrypted DEK.
- S3 uses its master KEK to decrypt the DEK.
- S3 uses the now-decrypted DEK to decrypt your
my-backup.sql.
This is all handled transparently by the cloud provider. Your data is encrypted, and the key used to decrypt it is itself encrypted and managed by the provider.
This model, often called "envelope encryption," is standard. It offers a good balance between security and performance. Encrypting every single byte of data with a unique DEK is efficient. Managing and rotating those DEKs becomes simpler because you only need to manage the KEKs.
You, as the user, have options to control this. The primary lever is selecting who manages the KEK.
-
SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys): This is the default. AWS manages both the DEK and the KEK. You don’t see or interact with any keys directly. It’s the simplest to enable – just a checkbox.
- Config: In the AWS CLI, when uploading:
aws s3 cp my-backup.sql s3://my-bucket/ --sse 'AES256' - Why it works: AWS handles all key generation, encryption, decryption, and rotation behind the scenes. Your responsibility is minimal.
- Config: In the AWS CLI, when uploading:
-
SSE-KMS (Server-Side Encryption with AWS KMS-Managed Keys): Here, you still let AWS handle the encryption/decryption of your data at rest, but you choose or create the KEK residing in AWS Key Management Service (KMS). You can control access to this KEK and audit its usage.
- Config: When uploading:
aws s3 cp my-backup.sql s3://my-bucket/ --sse 'aws:kms' --sse-kms-key-id arn:aws:kms:us-east-1:111122223333:key/your-kms-key-id - Why it works: AWS KMS provides a secure, auditable vault for your KEK. You can grant or revoke permissions to use this KEK, giving you granular control over who can access the keys that decrypt your data.
- Config: When uploading:
-
SSE-C (Server-Side Encryption with Customer-Provided Keys): This is the closest you get to managing your own keys for server-side encryption. You generate and manage the DEK yourself. When you upload data, you provide the DEK. When you download, you must provide the exact same DEK. The cloud provider uses it to encrypt/decrypt your data but never stores your DEK.
- Config: When uploading:
aws s3 cp my-backup.sql s3://my-bucket/ --sse-c 'AES256' --sse-c-key 'your-base64-encoded-256-bit-key' --sse-c-key-md5 'your-base64-encoded-md5-of-the-key' - Why it works: The cloud provider performs the encryption/decryption using your key, but since they don’t store the key, it’s your sole responsibility to manage its lifecycle, availability, and security. If you lose the key, your data is irrecoverable.
- Config: When uploading:
The nuance most people miss is that even with SSE-KMS, the KEK itself is protected. AWS KMS uses a root master key (often called a "backing key" or "primary key") to protect the KEKs you create. This adds another layer of defense, ensuring that your KEKs are not directly exposed even within the KMS service.
The next step in securing data is often understanding how these encryption mechanisms interact with data in transit.