Encryption Types
By default there is no encryption. However, you can change this to use any of the following:
- SSE-S3 where S3 generates and manages the AES-256 keys. The master key is autogenerated and regularly rotated
- SSE-KMS where you provide the plaintext key on setup and it is stored in KMS for use on a particular bucket
- SSE-C where you provide the key on each read and write operation
- Client side encryption where the AWS S3 does no encryption or decryption
Setting Up Encryption
To set up default encryption on a bucket, you can use any of these methods:
- Use the Amazon S3 console.
- Use the REST API PUT Bucket encryption operation to enable default encryption and set the type of server-side encryption to use—SSE-S3 or SSE-KMS.
- Use the AWS CLI and AWS SDKs. For more information, see Using the AWS SDKs, CLI, and Explorers.
After you enable default encryption for a bucket, the following encryption behavior applies:
- There is no change to the encryption of the objects that existed in the bucket before default encryption was enabled.
- If your
PUT request headers don’t include encryption information, Amazon S3 uses the bucket’s default encryption settings to encrypt the objects.
- If your
PUT request headers include encryption information, Amazon S3 uses the encryption information from the PUT request to encrypt objects before storing them in Amazon S3.
Enforcing Encryption Using A Bucket Policy
The bucket policy ensure the PUT operation has an encryption header present with a valid encryption type.
{
"Version": "2012-10-17",
"Id": "PutObjectPolicy",
"Statement": [
{
"Sid": "DenyUnencryptedObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::awsexamplebucket1/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption": "true"
}}},
{
"Sid": "DenyIncorrectEncryptionHeader",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::awsexamplebucket1/*",
"Condition": {
"ForAllValues:StringNotEquals": {
"s3:x-amz-server-side-encryption": ["AES256", "aws:kms"]
}}}]}
SSE-KMS
With this approach S3 fetches the key from KMS which manages the key lifecycle.
- You can choose a customer managed CMK that you create and manage, or you can choose an AWS managed CMK that Amazon S3 creates in your AWS account and manages for you.
- Like a customer managed CMK, your AWS managed CMK is unique to your AWS account and Region. Only Amazon S3 has permission to use this CMK on your behalf.
- Amazon S3 only supports symmetric CMKs.
- You can create, rotate, and disable auditable customer managed CMKs from the AWS KMS console.
- The ETag in the response is not the MD5 of the object data.
- The data keys used to encrypt your data are also encrypted and stored alongside the data they protect.
- The security controls in AWS KMS can help you meet encryption-related compliance requirements.
- To request SSE-KMS in the object creation REST APIs, use the
x-amz-server-side-encryption request header. To specify the ID of the AWS KMS CMK that was used for the object, use x-amz-server-side-encryption-aws-kms-key-id. The Amazon S3 API also supports encryption context, with the x-amz-server-side-encryption-context header.
SSE-KMS Encryption Limits
- If you use the SSE-KMS option for your default encryption configuration, you are subject to the RPS (requests per second) limits of AWS KMS. Cryptographic operations (symmetric) request rates vary between 5000 and 30000 per second depending on the region
SSE-C
With this approach Amazon S3 does the encryption and decryption and client provides the correct key for each operation on each API call.
- You manage a mapping of which encryption key was used to encrypt which object. Amazon S3 does not store encryption keys. You are responsible for tracking which encryption key you provided for which object.
- Amazon S3 does not store the encryption key you provide. Instead, it stores a randomly salted HMAC value of the encryption key to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means if you lose the encryption key, you lose the object.
- If your bucket is versioning-enabled, each object version you upload using this feature can have its own encryption key. You are responsible for tracking which encryption key was used for which object version.
- Because you manage encryption keys on the client side, you manage any additional safeguards, such as key rotation, on the client side.
- Access must be over HTTPS.
- Amazon S3 rejects any requests made over HTTP when using SSE-C. For security considerations, we recommend that you consider any key you erroneously send using HTTP to be compromised. You should discard the key and rotate as appropriate.
- As with other server-side encryption methods, AWS only encrypts only the object data, not object metadata.
