Background - I am trying to set up Cross-Region Replication for one of our buckets. Our bucket is currently encrypted via a KMS CMK(customer-managed key). We know that AWS KMS is region-specific.
I have been able to replicate the unencrypted objects without any issues.
Question - Will the objects in the destination bucket will be de-encrypted when the objects(which are encrypted) are replicated across to the destination bucket which at the moment is not encrypted. Because we know the CMK key is not going to be available in the destination region?
The S3 service where you are replicating from will need to decrypt the datakey using the CMK for that region and then construct a new envelope using the CMK of the destination region. There is no need to decrypt the actual data.
If you are replicating across accounts, then the source account needs access to encrypt using the destination account's CMK but the destination account doesn't require access to decrypt using the source account's CMK. This shows that the S3 service where the source bucket is located is the one constructing the new envelope prior to replication - which is both the logical and the secure way of doing it. (https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-config-for-kms-objects.html#replication-kms-cross-acct-scenario)
So in transit, the replicated objects are encrypted using both TLS and KMS.
(Disclosure: I am employed by AWS)
Related
I have a multi-region trail defined with Terraform that I'm trying to encrypt with KMS. My trail covers four AWS regions: us-east-1, us-west-2, eu-west-2, and eu-central-1 and I'm creating a KMS key for encrypting the log files and adding the appropriate permissions per the AWS docs. However, it's not clear whether or not this needs to be a multi-region key. If the KMS key I use needs to be multi-region, do I need to make a replica key for each additional region that my trail covers?
The docs say CloudTrail supports KMS multi-region keys, but the appropriate situation(s) to use MRKs w/ CloudTrail isn't straightforward. If I could get that far, then I do know that related MRKs do not share key policies and that I would need to define a specific policy for each should I need them.
It is not mandatory to use multi region keys with CloudTrail. When you configure a trail and want to encrypt the CloudTrail log files, you can use a single KMS key to encrypt the files. Just make sure the KMS key is in the same region as the S3 bucket where you're sending the log files to.
I like to share the image across accounts but the image is encrypted with an AWS managed key and I was wondering how I can transfer this image to another account.
I gather an image encrypted with custome keys is transferrable, and is it the same with the image with an AWS key?
KMS
With KMS you have AWS Managed Key and Customer Managed Key (CMK).
To allow another account to use your key it needs to be a CMK, because you need to allow it on your key police.
https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
You can't change police on AWS Managed Key. Which means you can't allow other accounts to use an AWS Managed Key.
So you can't share your encrypted AMI with another account when it is using AWS Managed Key.
AMI
An AMI can't be transferred, but you share it with another account. When it is encrypted you need to share the key as well. See documentation below.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html
As your current AMI is encrypted with AWS Managed Key, what you can do is create a new AMI without encryption or encrypted with CMK and share it. See documentation below.
https://aws.amazon.com/premiumsupport/knowledge-center/account-transfer-ec2-instance/
I'm using the tool created by aws at https://github.com/awslabs/aurora-snapshot-tool to copy aurora snapshots from one account to another account. However, I just don't understand what to enter for KmsKeySource & KmsKeyDestination while creating a destination account. I have checked the CMK pages mentioned on the site but still unable to understand. Could anyone give a clear explanation?
For KmsKeySource I have entered the CMK which my DB cluster is using in the Source account. Is it correct?
For aurora snapshot to be able to copy between accounts, you cannot use default AWS managed keys in KMS for at rest encryption, you need to create customer managed CMKs in KMS and use that CMK in your Aurora db at rest encryption. The KmsKeySource here means the kms cmk key id you use for source db, thats correct.
The KmsKeyDestination is only required if you are copying the snapshot between different AWS regions, as KMS CMKs are regional resources, you need to provide the destination region CMK key id if your source and target region are different. In such case AWS handling the copying of encrypted snapshot from region A to B, and re-encrypt it using region B's CMK.
If the source and target region are the same, then KmsKeyDestination is optional, as the target db can simply use the same CMK key as source, which is specified in KmsKeySource.
I want to enable default encryption for the existing buckets (Amazon S3-managed encryption keys (SSE-S3)). The future objects will be encrypted but to encrypt the existing objects either I need to copy them or re-upload them.
I am wondering as I am using SSE-S3 for default encryption on the buckets, do I need to make any IAM changes to allow bucket users for accessing both the existing objects and future objects? Or enabling default encryption (SSE-S3) on buckets does not require any IAM changes as the encryption applied before storing data at rest?
Thank you for your help.
If you are using SSE-S3 (Amazon S3-managed encryption keys) then you don't have to do anything. You may just enforce this encryption through bucket policy, as a default SSE-S3 bucket encryption can be overwritten by your users on per-object basis.
But if you were to choose SSE-KMS as default with your own CMK (not AWS one), then your users/inctances/lambdas would need to have permissions to access the CMK as well.
When I SSE-S3 encrypt the bucket (objects) with AES256 and make it public. The contents of the bucket are visible. However, this is not the case with AWS KMS which throws the following error:
Requests specifying Server Side Encryption with AWS KMS managed keys require AWS Signature Version 4.
How is the end-user able to view the object in AES256 encrypted?
Use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) – Each
object is encrypted with a unique key employing strong multi-factor
encryption. As an additional safeguard, it encrypts the key itself
with a master key that it regularly rotates. Amazon S3 server-side
encryption uses one of the strongest block ciphers available, 256-bit
Advanced Encryption Standard (AES-256), to encrypt your data.
According to this, my understanding is, if an object is encrypted it requires the decryption keys or in AWS world access to the key that is decrypting it. Please explain how AES256 is different from KMS. (Other than key policies provided by AWS on KMS)
Server-Side Encryption in S3 is always AES256, whether you are using SSE-S3 or SSE-KMS.
In both cases, S3 uses a key to transparently encrypt the object for storage and decrypt the object on request. The user accessing the object does not see the encrypted object in either case.
With SSE-S3, S3 owns and controls the keys, so permission to upload or download includes implicit permission for S3 to access the keys that it needs in order to access the object.
The level of encryption is the same whether you use SSE-S3 or SSE-KMS, but SSE-KMS imposes more stringent security constraints on accessing the objects, including mandatory use of HTTPS and Signature Version 4.