Using server-side encryption with AWS KMS keys (SSE-KMS)
Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket in Amazon S3. Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted at no additional cost and with no impact on performance. The automatic encryption status for S3 bucket default encryption configuration and for new object uploads is available in AWS CloudTrail logs, S3 Inventory, S3 Storage Lens, the Amazon S3 console, and as an additional Amazon S3 API response header in the AWS Command Line Interface and AWS SDKs. For more information, seeDefault encryption FAQ.
Server-side encryption is the encryption of data at its destination by the application or service that receives it.
Amazon S3 automatically enables server-side encryption with Amazon S3 managed keys (SSE-S3) for new object uploads.
Unless you specify otherwise, buckets use SSE-S3 by default to encrypt objects. However, you can choose to configure buckets to use server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS) instead. For more information, seeSpecifying server-side encryption with AWS KMS (SSE-KMS).
AWS KMS is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. Amazon S3 uses server-side encryption with AWS KMS (SSE-KMS) to encrypt your S3 object data. Also, when SSE-KMS is requested for the object, the S3 checksum (as part of the object's metadata) is stored in encrypted form. For more information about checksum, seeChecking object integrity in Amazon S3.
If you use KMS keys, you can use AWS KMS through theAWS Management Console or theAWS KMS API to do the following:
Centrally create, view, edit, monitor, enable or disable, rotate, and schedule deletion of KMS keys.
Define the policies that control how and by whom KMS keys can be used.
Audit KMS key usage for correct use. Auditing is supported by theAWS KMS API but not by theAWS KMS Console;.
The security controls in AWS KMS can help you meet encryption-related compliance requirements. You can use these KMS keys to protect your data in Amazon S3 buckets. When you use SSE-KMS encryption with an S3 bucket, the AWS KMS keys must be in the same Region as the bucket.
There are additional charges for using AWS KMS keys. For more information, seeAWS KMS key concepts in theAWS Key Management Service Developer Guide andAWS KMS pricing.
For instructions on allowing IAM users to access KMS-encrypted buckets seeMy Amazon S3 bucket has default encryption using a custom AWSAWS KMS key. How can I allow users to download from and upload to the bucket? in the AWS re:Post Knowledge Center.
Permissions
To successfully make aPutObject request to encrypt an object with an AWS KMS key to Amazon S3, you needkms:GenerateDataKey permissions on the key. To download an object encrypted with an AWS KMS key, you needkms:Decrypt permissions for the key. Toperform a multipart upload to encrypt an object with an AWS KMS key, you must have thekms:GenerateDataKey andkms:Decrypt permissions for the key.
Carefully review the permissions that are granted in your KMS key policies. Always restrict customer-managed KMS key policy permissions only to the IAM principals and AWS services that must access the relevant AWS KMS key action. For more information, seeKey policies in AWS KMS.
Topics
AWS KMS keys
When you use server-side encryption with AWS KMS (SSE-KMS), you can use the defaultAWS managed key, or you can specify acustomer managed key that you have already created. AWS KMS supportsenvelope encryption. S3 uses the AWS KMS features forenvelope encryption to further protect your data. Envelope encryption is the practice of encrypting your plain text data with a data key, and then encrypting that data key with a KMS key. For more information about envelope encryption, seeEnvelope encryption in theAWS Key Management Service Developer Guide.
If you don't specify a customer managed key, Amazon S3 automatically creates an AWS managed key in your AWS account the first time that you add an object encrypted with SSE-KMS to a bucket. By default, Amazon S3 uses this KMS key for SSE-KMS.
Objects encrypted using SSE-KMS withAWS managed keys can't be shared cross-account. If you need to share SSE-KMS data cross-account, you must use acustomer managed key from AWS KMS.
If you want to use a customer managed key for SSE-KMS, create a symmetric encryption customer managed key before you configure SSE-KMS. Then, when you configure SSE-KMS for your bucket, specify the existing customer managed key. For more information about symmetric encryption key, seeSymmetric encryption KMS keys in theAWS Key Management Service Developer Guide.
Creating a customer managed key gives you more flexibility and control. For example, you can create, rotate, and disable customer managed keys. You can also define access controls and audit the customer managed key that you use to protect your data. For more information about customer managed and AWS managed keys, seeCustomer keys and AWS keys in theAWS Key Management Service Developer Guide.
When you use server-side encryption with a customer managed key that's stored in an external key store, unlike standard KMS keys, you are responsible for ensuring the availability and durability of your key material. For more information about external key stores and how they shift the shared responsibility model, seeExternal key stores in theAWS Key Management Service Developer Guide.
Using SSE-KMS encryption for cross-account operations
When using encryption for cross-account operations, be aware of the following:
If an AWS KMS key Amazon Resource Name (ARN) or alias is not provided at request time or through the bucket's default encryption configuration, the AWS managed key (
aws/s3) is used.If you're uploading or accessing S3 objects by using AWS Identity and Access Management (IAM) principals that are in the same AWS account as your KMS key, you can use the AWS managed key (
aws/s3).If you want to grant cross-account access to your S3 objects, use a customer managed key. You can configure the policy of a customer managed key to allow access from another account.
If you're specifying a customer managed KMS key, we recommend using a fully qualified KMS key ARN. If you use a KMS key alias instead, AWS KMS resolves the key within the requester’s account. This behavior can result in data that's encrypted with a KMS key that belongs to the requester, and not the bucket owner.
You must specify a key that you (the requester) have been granted
Encryptpermission to. For more information, seeAllow key users to use a KMS key for cryptographic operations in theAWS Key Management Service Developer Guide.
For more information about when to use customer managed keys and AWS managed KMS keys, seeShould I use an AWS managed key or a customer managed key to encrypt my objects in Amazon S3?
SSE-KMS encryption workflow
If you choose to encrypt your data using an AWS managed key or a customer managed key, AWS KMS and Amazon S3 perform the following envelope encryption actions:
Amazon S3 requests a plaintext data key and a copy of the key encrypted under the specified KMS key.
AWS KMS generates a data key, encrypts it under the KMS key, and sends both the plaintext data key and the encrypted data key to Amazon S3.
Amazon S3 encrypts the data using the data key and removes the plaintext key from memory as soon as possible after use.
Amazon S3 stores the encrypted data key as metadata with the encrypted data.
When you request that your data be decrypted, Amazon S3 and AWS KMS perform the following actions:
Amazon S3 sends the encrypted data key to AWS KMS in a
Decryptrequest.AWS KMS decrypts the encrypted data key by using the same KMS key and returns the plaintext data key to Amazon S3.
Amazon S3 decrypts the encrypted data, using the plaintext data key, and removes the plaintext data key from memory as soon as possible.
When you use an AWS KMS key for server-side encryption in Amazon S3, you must choose a symmetric encryption KMS key. Amazon S3 supports only symmetric encryption KMS keys. For more information about these keys, seeSymmetric encryption KMS keys in theAWS Key Management Service Developer Guide.
Auditing SSE-KMS encryption
To identify requests that specify SSE-KMS, you can use theAll SSE-KMS requests and% all SSE-KMS requests metrics in Amazon S3 Storage Lens metrics. S3 Storage Lens is a cloud-storage analytics feature that you can use to gain organization-wide visibility into object-storage usage and activity. You can also use the SSE-KMS enabled bucket count and % SSE-KMS enabled buckets to understand the count of buckets that (SSE-KMS) fordefault bucket encryption. For more information, see Assessing your storage activity and usage with S3 Storage Lens. For a complete list of metrics, see S3 Storage Lens metrics glossary.
To audit the usage of your AWS KMS keys for your SSE-KMS encrypted data, you can use AWS CloudTrail logs. You can get insight into yourcryptographic operations, such asGenerateDataKey andDecrypt. CloudTrail supports numerousattribute values for filtering your search, including event name, user name, and event source.
Amazon S3 Bucket Keys
When you configure server-side encryption using AWS KMS (SSE-KMS), you can configure your buckets to use S3 Bucket Keys for SSE-KMS. Using a bucket-level key for SSE-KMS can reduce your AWS KMS request costs by up to 99 percent by decreasing the request traffic from Amazon S3 to AWS KMS.
When you configure a bucket to use an S3 Bucket Key for SSE-KMS on new objects, AWS KMS generates a bucket-level key that is used to create uniquedata keys for objects in the bucket. This S3 Bucket Key is used for a time-limited period within Amazon S3, further reducing the need for Amazon S3 to make requests to AWS KMS to complete encryption operations. For more information about using S3 Bucket Keys, seeReducing the cost of SSE-KMS with Amazon S3 Bucket Keys.
Requiring server-side encryption
To require server-side encryption of all objects in a particular Amazon S3 bucket, you can use a bucket policy. For example, the following bucket policy denies the upload object (s3:PutObject) permission to everyone if the request does not include anx-amz-server-side-encryption-aws-kms-key-id header that requests server-side encryption with SSE-KMS.
{ "Version":"2012-10-17", "Id":"PutObjectPolicy", "Statement":[{ "Sid":"DenyObjectsThatAreNotSSEKMS", "Effect":"Deny", "Principal":"*", "Action":"s3:PutObject", "Resource":"arn:aws:s3:::amzn-s3-demo-bucket1/*", "Condition":{ "Null":{ "s3:x-amz-server-side-encryption-aws-kms-key-id":"true" } } } ]}To require that a particular AWS KMS key be used to encrypt the objects in a bucket, you can use thes3:x-amz-server-side-encryption-aws-kms-key-id condition key. To specify the KMS key, you must use a key Amazon Resource Name (ARN) that is in thearn:aws:kms: format. AWS Identity and Access Management does not validate if the string forregion:acct-id:key/key-ids3:x-amz-server-side-encryption-aws-kms-key-id exists.
When you upload an object, you can specify the KMS key by using thex-amz-server-side-encryption-aws-kms-key-id header or rely on yourdefault bucket encryption configuration. If your PutObject request specifiesaws:kms in thex-amz-server-side-encryption header, but does not specify thex-amz-server-side-encryption-aws-kms-key-id header, then Amazon S3 assumes that you want to use the AWS managed key. Regardless, the AWS KMS key ID that Amazon S3 uses for object encryption must match the AWS KMS key ID in the policy, otherwise Amazon S3 denies the request.
For a complete list of Amazon S3 specific condition keys, see Condition keys for Amazon S3 in theService Authorization Reference.
Encryption context
Anencryption context is a set of key-value pairs that contains additional contextual information about the data. The encryption context is not encrypted. When an encryption context is specified for an encryption operation, Amazon S3 must specify the same encryption context for the decryption operation. Otherwise, the decryption fails. AWS KMS uses the encryption context asadditional authenticated data (AAD) to supportauthenticated encryption. For more information about the encryption context, seeEncryption context in theAWS Key Management Service Developer Guide.
By default, Amazon S3 uses the object or bucket Amazon Resource Name (ARN) as the encryption context pair:
If you use SSE-KMS without enabling an S3 Bucket Key, the object ARN is used as the encryption context.
arn:aws:s3:::object_ARNIf you use SSE-KMS and enable an S3 Bucket Key, the bucket ARN is used as the encryption context. For more information about S3 Bucket Keys, seeReducing the cost of SSE-KMS with Amazon S3 Bucket Keys.
arn:aws:s3:::bucket_ARN
You can optionally provide an additional encryption context pair by using thex-amz-server-side-encryption-context header in an s3:PutObject request. However, because the encryption context is not encrypted, make sure it does not include sensitive information. Amazon S3 stores this additional key pair alongside the default encryption context. When it processes yourPUT request, Amazon S3 appends the default encryption context ofaws:s3:arn to the one that you provide.
You can use the encryption context to identify and categorize your cryptographic operations. You can also use the default encryption context ARN value to track relevant requests in AWS CloudTrail by viewing which Amazon S3 ARN was used with which encryption key.
In therequestParameters field of a CloudTrail log file, the encryption context looks similar to the following one.
"encryptionContext":{ "aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket1/file_nameWhen you use SSE-KMS with the optional S3 Bucket Keys feature, the encryption context value is the ARN of the bucket.
"encryptionContext":{ "aws:s3:arn": "arn:aws:s3:::amzn-s3-demo-bucket1Sending requests for AWS KMS encrypted objects
AllGET andPUT requests for AWS KMS encrypted objects must be made using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Requests must also be signed using valid credentials, such as AWS Signature Version 4 (or AWS Signature Version 2).
AWS Signature Version 4 is the process of adding authentication information to AWS requests sent by HTTP. For security, most requests to AWS must be signed with an access key, which consists of an access key ID and secret access key. These two keys are commonly referred to as your security credentials. For more information, seeAuthenticating Requests (AWS Signature Version 4) andSignature Version 4 signing process.
If your object uses SSE-KMS, don't send encryption request headers forGET requests andHEAD requests. Otherwise, you’ll get anHTTP 400 Bad Request error.
