Question # 0: AWS console displays AWS managed keys and Customer Managed Keys; it doesn't display AWS owned CMKs as an item in the list. As per documentation, customers cannot view or manage AWS-owned CMKs. However, under AWS managed keys, I see keys that were not created by me either implicitly or explicitly. Particularly I see this key with the alias aws/dynamodb. When I created DynamoDB tables, I used default settings which means, it will use AWS-owned CMKs for encryption at rest. Does this mean, "aws/dynamodb" is an AWS-owned CMK? It is a bit ambiguous. Is there a field in aws kms describe-key that displays the type?
The default option in us-east-1 is AWS owned CMK
Question # 1: Other than rotation policy, ownership, and the cost, is there a fundamental difference in the way AWS-owned CMKs encrypt/decrypt data when compared to AWS-managed CMKs?
Question # 2: As per the documentation, AWS-owned CMK usage is not limited to one particular account, this means there is a possibility that AWS uses the same CMK across multiple different accounts Is this understanding correct?
Question # 3: What services besides DynamoDB use AWS-owned CMKs for encryption at rest? In the picture, I see some more keys, and those are corresponding services that I tried.
Appreciate any help. Thanks in advance.
Does this mean, "aws/dynamodb" is an AWS-owned CMK?
No. AWS-owned CMKs don't show in your KMS console. The aws/dynamodb is AWS-managed CMK which is not free. It is the second option in DynamoDB table creation:
Q1. From the cryptographic point of view there is not difference, at least I'm not aware of any. But practical difference is that you can't use AWS-owned CMKs on your own. You can't use it to decrypt/encrypt your own data using AWS CLI or SDK, as the CMK is only used by AWS. The other difference is that it can be easier to move encrypted data between accounts, as AWS will use same AWS owned key on both accounts, rather then you managing different keys on different accounts.
Q2. Yes, that's correct. AWS can re-use the same key for multiple customers.
Q3. I think S3 is the most common service using AWS-owned key SSE-S3.
Related
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.
Given already deployed AWS resources that use the default AWS managed keys, is it possible to change the default encryption key from AWS managed to a Customer Managed Key (CMK)?
Resources in question:
EFS
FSx
Thanks!
I don't think you can change it, at least the API documentation don't have this options.
EFS:
https://docs.aws.amazon.com/efs/latest/ug/API_UpdateFileSystem.html
FSx:
https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateFileSystem.html
I'm working on a Slack app which will have to store access token per each customer using the app (ex. 1000 teams using it = 1000 tokens). Token enables the app to access Slack API for customers workspace and will be used frequently every day.
App will be running on AWS, using Lambda's and DynamoDB.
What would be the best practice to store those access tokens securly?
I cannot find any strict recomendation for this scenario. Was thinking initially to put those in DynamoDB in a dedicated table but thinking now if I should use other AWS services for that use case. I've checked Secrets Manager but looks like a rather expensive option and not sure if it applies to my scenario.
Appreciate any suggestions.
I would probably use a dedicated DynamoDB table for this purpose. At a minimum, I would configure it to use a KMS CMK to encrypt the data at-rest, and also restrict access to the table through fairly granular IAM permissions in your AWS account. If you also wanted to encrypt each value separately you could look into client-side encryption.
Your findings on the Secrets Manager costs are a good point. You could also look at Systems Manager Parameter Store as an alternative that is generally cheaper than Secrets Manager. Secrets Manager does have the added security of being able to set an IAM resource policy on the secret itself.
Ultimately it's up to you to determine how secure your solution needs to be, and how much you are willing to pay for that. You could even spin up an AWS HSM to encrypt the values, but that would increase the cost by quite a bit.
In AWS S3 encryption - which technique provides rotation policy for encryption keys?
I am reading recommended is SSE-KMS, but in some places questions where asked like "How does Amazon SSE-S3 key rotation work?"
So which one supports key rotation and if both are supporting key rotation which is recommended?
There are several ways of encrypting S3 objects (or putting default encryption on a bucket). Below I only mention server-side encryption (i.e. that performed on the AWS side, not client side):
SSE-S3 - is free and uses AWS owned CMKs (CMK = Customer Master Key). The encryption key is owned and managed by AWS, and is shared among many accounts. Its rotation is automatic with time that varies as shown in the table here. The time is not explicitly defined.
SSE-KMS - has two flavors:
AWS managed CMK. This is free CMK generated only for your account. You can only view it policies and audit usage, but not manage it. Rotation is automatic - once per 1095 days (3 years),
Customer managed CMK. This uses your own key that you create and can manage. Rotation is not enabled by default. But if you enable it, it will be automatically rotated every 1 year. This variant can also use an imported key material by you. If you create such key with an imported material, there is no automated rotation. Only manual rotation.
SSE-C - customer provided key. The encryption key is fully managed by you outside of AWS. AWS will not rotate it.
which is recommended?
It depends. I would say that generally SSE-S3 is sufficient and it simplifies a lot of operations, e.g. cross-account access to encrypted objects. But due to some external requirements (regulatory issues), other encryption options must be used.
For example, you may be required to rotate encryption key every 6 months. In this case, SSE-S3 nor SSE-KMS with AWS Managed CMK are applicable, and you have to use KMS with Customer Managed key and manually rotate it.
I need to develop a solution to store both symmetric and asymmetric keys securely in AWS. These keys will be used by applications that are running on EC2s and Lambdas. The applications will need to be set up with policies that will allow the application or lambda to pull the keys out of the key store. The key store should also manage the key expiry, notifying various people when keys are going to expire. The initial key exchange is between my company and its partners meaning that we may have either a public or private key for a key pair depending upon the data transfer direction.
We have looked at KMS but from what I have seen KMS does not support asymmetric keys. I have also seen online that some people are using either S3 (protected by KMS) or parameter store to store the keys but this does not address the issue of key management.
Do you guys have any thoughts on this? or even SaaS/PaaS suggestions?
My recommendation would be to use AWS Secrets Manager for this. Secrets Manager allows you to store any type of credential/key, you can set up fine-grained cross account permissions to secrets, encryption at rest is used (via KMS), and secrets can be automatically rotated (by providing an expiration time and an AWS Lambda function owned by you to perform the rotation).
More details on the official docs:
Basic tutorial on how to use AWS Secrets Manager
Encryption at rest on Secrets Manager
Secrets rotation
Managing secrets policies