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.
Related
I am proposing to use AWS KMS to encrypt my database. However by boss challenge me that what if the someone in Amazon staff has access to steal my KMS and decrypt my database.
The information inside the database is very important and cannot take any risk other people can decrypt it.
Is there other solution to solve this issue? to make sure no one can steal the Key?
Should we use some on-prem HSM to store the key instead ?
As the FAQ points out, AWS KMS is designed such that
no one, including AWS employees, can retrieve your plaintext KMS keys from the service.
If you read further down, it also provides links to various articles detailing the specification and design of the KMS. And as you can see from the volumes of these articles, the full scope of design consideration and how it complies with FIPS certification is beyond the scope of this answer.
However, as an example, refer to the cryptographic details tech paper for some ideas of how it works. There are 2 areas mentioned where keys are present:
In the KMS Keys Repository
In the HSM modules
KMS Keys Repository
The repository serves as durable storage for the keys. Keys are, of course, stored encrypted. The article further explains that the key repository leverages on IAM roles.
Only under AWS IAM roles and accounts administered by each customer can customer KMS keys be created, deleted, or used to encrypt, decrypt, sign, or verify data.
This is the same way authentication and authorization to any other AWS services are managed. Hence, this is one way to prevent AWS employees from gaining access to the keys. How IAM works and how it is secured is once again beyond the scope of this answer.
HSM Modules
Unlike the KMS keys repository, the HSM Modules will have access to the plain text keys. However, the plain text keys are only loaded in-memory for the duration that they are used. They are not durably stored in the HSM modules.
These keys are made available only on the HSMs and only in memory for the necessary time needed to process your cryptographic request.
Hence, employees with access to these modules would be able to theoretically gain access to these keys. To mitigate this risk, if you go to the design goals section, the article further explains the modules use quorum-based access controls.
Multiple Amazon employees with role-specific access to quorum-based access controls are required to perform administrative actions on the HSMs.
That is, no single employee will have administrative access to these modules. Multiple employees are always required. Once again, how AWS assigns which roles to which employees at which management level is beyond the scope of this answer.
As the question requested, these are just some of the considerations of how the service is secured against AWS employees. For an organization to make a decision on whether to use AWS, usually it should be based on a comprehensive set of security policies and an audit whether AWS complies to these requirements.
EDIT
Since you mentioned also how to convince stakeholders, this is usually a business question rather than a technical one.
I would refer them to AWS compliance for evidence that AWS goes through rigorous 3rd party audits. Would then point out the security of a system is only as strong as the weakest link. That is, using AWS does not mean we automatically have AWS security. We have to ensure our software, our people, and our processes are secure against exploits. So unless we are sure we have better security profile than AWS (with all their compliance and audits), our focus and worry should be more on securing our resources.
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.
This question is about the rotation of AWS secrets manager. When creating a secret, you could choose rotation frequency, but I can't figure out how rotation works.
Imagine a scenario like the following.
You create a secret A1 in aws secret manager, and specify the rotation frequency is 30 days.
You encrypt the data with A1.
30 days later, A1 has been rotated to be A2.
then, you program retrieves AWS secret manager and got the value of A2. How do you decrypt the data that has been encrypted with A1?
Secrets Manager rotation is primarily used for API keys or passwords.
Your encrypted values are stored in the Secrets Manager secret, but the encryption key itself is stored in KMS.
When the rotation occurs, these values are replaced by the same KMS customer master key will be used to encrypt the new value.
If you're ever wanting to store an encryption key you would use either AWS KMS, or AWS CloudHSM (if your organisation has specific regulatory requirements or wants to invest in a dedicated HSM).
You should use KMS for storing encryption keys, not Secrets Manager. You can rotate encryption keys in KMS while keeping the old keys available.
Secrets Manager is for things like passwords, where rotation involves updating an account to have a new password, and the old password would be no longer needed.
I found that AWS RDS allows encrypting DB resources with AWS KMS. Because it is done inside the AWS infrastructure the encryption key can be easily rotated automatically. It is cool, but it is only encryption-at-rest.
I would additionally like to have encrypted some particular columns in the database. For example SSN. I would like to store them encrypted and decrypt them to display inside my application. Moreover, I would like to have an individual key for every user.
The main problem which I observed will be the rotation of the key. As I'm thinking to rotate the key for one user I would like to do this inside my application:
get a current encryption key from KMS
decrypt all the data from RDS encrypted with the current key
generate a new encryption key
encrypt everything again and store data in RDS
store the new key in the KMS
The main problem here would be to keep everything in a "transaction" - to "commit" if everything was fine and to "rollback" everything if anything went wrong.
I wonder if such keys rotation for the encryption at the columns level could be done inside the AWS infrastructure automatically. Do you have any ideas about that? Maybe you know any other, better approach for such a situation?
What problem are you solving by having individual keys per user? The KMS paradigm is to use policy to grant access to a Customer Master Key (CMK). As Mark pointed out above, there is a limit on the number of keys.
Have a look at this walkthrough
There is a section at the bottom about Key rotation strategies that might help:
"A recommended approach to manual key rotation is to use key aliases within AWS KMS. This allows users to always select the same key alias when configuring databases, while the key administrator rotates the underlying CMK. By keeping the old CMK, you allow any applications that currently use this key to still decrypt any data that was encrypted by it, as long as the CMK key policy still gives the AWSServiceRoleForRDS role permission as a Key User. It also allows for any new data to be encrypted with the new CMK."
I would additionally like to have encrypted some particular columns in the database.
Then I assume you will use a form of key wrapping ( data keys )
The main problem which I observed will be the rotation of the key
..
encrypt everything again and store data in RDS
store the new key in the KMS
The purpose of the key rotation is limit amount of data encrypted by a single key, not to re-encrypt the whole encrypted content.
Suggestion:
as already linked - encrypt your data using a random (per row?) data key.
encrypt the data key using the user-specific key.
encrypt the user-key with a KMS-key
Key Rotation (KMS) should be transparent for you with no action to do.
If you wish to manually rotate the user keys, you may, IMHO it is not so critical - the user keys are used to encrypt the data keys - relatively short data with high entropy.
IMHO the action by rotation taken should be creating a new key and preserving the old one for decryption purposes, not to re-encrypt all the database records
Are you using something like AWS Cognito to give each user temporary IAM permissions when they log in? Otherwise, I don't see the point of giving each user a separate KMS key, since you would be giving a single entity (your server) access to all the keys. Also note that there is a limit of 10,000 KMS keys in an AWS account. That's quite a bit, but if you have a website where anybody can sign up you might run up against that limit if you are assigning each user a key.
As for handling key rotation automatically, since you have to write the custom code to encrypt individual column values in your database, you will also have to write the code to perform all the steps of the key rotation process. You could create that as an AWS Lambda function and configure it to run "automatically", but it isn't something Amazon gives you out of the box without any custom code.
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