Server-Side Encryption on Amazon S3: A Comprehensive Guide
If you are using Amazon S3, server-side encryption is worth understanding. It adds a layer of protection for your data at rest, and AWS makes it relatively painless to set up. This guide covers the basics: what it is, how to enable it, and a few things to keep in mind when managing encryption keys.
What server-side encryption is
Server-Side Encryption on Amazon S3
Server-side encryption is an extra security layer for data stored in Amazon S3 buckets. It works with two main key management options: keys managed by AWS (SSE-S3) or keys you manage yourself through AWS KMS (SSE-KMS). With SSE-S3, AWS handles the encryption keys. With SSE-KMS, you have more control over key rotation and access policies.
Server-Side Encryption on Amazon S3: Types of Server-Side Encryption
S3 supports three types of server-side encryption:
SSE-S3 uses keys that AWS manages. Every object gets encrypted with a unique key, and those keys are protected by AWS’s own security practices.
SSE-KMS gives you control over keys through AWS Key Management Service. You can create and rotate your own keys, set policies, and audit how keys are used. This is useful if you need strict control over who can decrypt your data.
SSE-C lets you provide your own encryption key for each object. AWS stores the encrypted data but cannot access the key. When you retrieve the object, you must provide the same key. This works if you need keys managed outside of AWS.
SSE-C is handy when you need strict key control and cannot store keys in AWS at all. Healthcare and financial organizations sometimes prefer this approach.
AWS-managed KMS key with S3
There is a known issue with cross-account access when using KMS-encrypted objects.
Here is the problem: AWS-managed KMS key policies are read-only. You cannot change them. This means you cannot grant cross-account permissions to objects encrypted with AWS-managed keys.
If you need Account Z to access a KMS-encrypted bucket in Account X, you must use a customer-managed key. Then you can adjust the key policy and bucket policy to allow the access.
The setup looks like this:
- Use a customer-managed key, not an AWS-managed key
- The bucket policy in Account X must allow explicit access from Account Z
- The KMS key policy must grant Account Z users permission to decrypt
- The IAM policy in Account Z must allow access to the bucket and key in Account X
New changes for 2023
In January 2023, AWS made SSE-S3 the default for all new S3 object uploads. This means new objects are automatically encrypted with SSE-S3 at no extra cost. You do not need to configure anything.
S3 has offered server-side encryption for years, but this change removed the step where you had to explicitly enable it.
Server-Side Encryption on Amazon S3: How to enable
For SSE-S3, you can set a bucket policy to enforce encryption on all uploads. You can also use the S3 console, AWS CLI, or SDKs.
For SSE-KMS, you first create a customer managed key in AWS KMS, then configure your bucket to use it. You can set this per-object or as a bucket default.
To set AES-256 as the default via CLI:
aws s3api put-bucket-encryption \
--bucket amzn-s3-demo-bucket \
--server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'
Best practices and Tips for Managing Encryption Keys
A few things that help when managing encryption keys:
Rotate your keys regularly. If a key is compromised, you want to limit what an attacker can decrypt. Most AWS-managed keys rotate automatically, but if you use customer-managed keys, you need a rotation strategy.
Store keys securely. Use AWS KMS, which is designed for this. Avoid hardcoding keys or storing them in code.
Monitor key usage. AWS CloudTrail logs KMS operations. Set up alerts for unusual activity, like decryption attempts from unfamiliar IPs.
Have a backup plan. If you lose your KMS key and do not have a backup, you lose access to everything encrypted with it. Use AWS KMS multi-region keys or back up key material outside AWS if your recovery requirements demand it.
The Need for Rotating Encryption Keys
Key rotation reduces the risk from a compromised key. The longer a key is in use, the more data it has encrypted, and the higher the potential impact if someone steals it.
With AWS KMS, you can enable automatic key rotation for customer managed keys. AWS rotates the key annually without you needing to re-encrypt existing data.
For SSE-C, you handle rotation yourself. You generate new keys and re-upload objects if you need fresh encryption on old data.
What are the benefits of using server-side encryption on Amazon S3?
Security is the main one. If someone gains access to your S3 bucket but objects are encrypted, they still cannot read your data. Encryption protects against both unauthorized access and physical theft of storage media.
Performance impact is minimal. AWS handles encryption in hardware optimized for this, and you will not notice latency differences in most workloads.
For SSE-KMS specifically, you get audit trails. CloudTrail records every encrypt and decrypt call, which helps with compliance and incident investigation.
Server-Side Encryption on Amazon S3
How to Monitor and Auditing Encryption Keys
With SSE-KMS, you can track who accessed your keys. CloudTrail captures kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey operations with timestamps, IAM users, and source IPs.
Set up a CloudTrail trail that sends logs to S3 and query them with Athena. You can also use AWS Config to monitor key policy changes.
For compliance, SSE-KMS gives you centralized control. You define key policies that specify who can use each key, and those policies are versioned. You always know who had access to what.
Important Considerations
SSE-KMS has costs. Each encrypt/decrypt operation incurs a small fee, and storing keys costs money too. For high-throughput workloads, this adds up. Estimate your KMS costs before committing to SSE-KMS for everything.
Example
To monitor key access:
- Create a CloudTrail trail that logs S3 and KMS events
- Send logs to an S3 bucket you control
- Query with Athena or a SIEM tool
- Set up CloudWatch alarms for failed decrypt attempts
Conclusion
Server-side encryption on S3 is a straightforward way to protect data at rest. SSE-S3 handles encryption automatically with no setup required. SSE-KMS gives you more control and auditability if you need it.
If you use SSE-KMS, keep track of your key policies, especially with cross-account access. Use customer-managed keys for that use case, since AWS-managed keys cannot have their policies modified.
Key management is ongoing work. Rotate keys, monitor access, and test your recovery procedures. Encryption only helps if the keys are secure and you can still access them when you need to.
Comments