My understanding is that by generating your own key and use that to encrypt stuff, it prevents a cloud provider from being able to read your data at rest. But before a cloud provider can use this customer managed key to encrypt/decrypt, it has to first have access to the key's plaintext. What stops a cloud provider from actually storing that plaintext and still has access to my data at rest?
Different cloud provider might have different approach to this, so I'm using AWS S3 as a reference here, which requires you to send the key in the request. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html
In the SSE-C scenario you refer to, the user provides AWS the plaintext data and plaintext key (over https) and then AWS performs the encryption and discards the key. The benefit to the user is that the user does not have to perform cryptographic operations.
If there is a concern about AWS having access to plaintext data or keys, the user can encrypt the data on the client computer and then send the data to AWS already encrypted. This is the client-side encryption scenario.
Related
I am storing data in file in aws s3 and already enabled SSE. but i am curious to know is there a way to encrypt the data so when someone download the file so they cant see the content?? I am just new to AWS and it would be great if somw one give the input
Use the AWS Key Management Service (AWS KMS) to encrypt the data prior to uploading it to an Amazon S3 bucket. Then the data will remain encrypted until it's decrypted using the key. YOu can find an example here (for Java SDK)
https://github.com/awsdocs/aws-doc-sdk-examples/blob/main/javav2/example_code/s3/src/main/java/com/example/s3/KMSEncryptionExample.java
already enabled SSE.
SSE encrypts the content on S3, but an authenticated client cloud access the content in plain, the encryption is done under the hood and the client is unable to access the ciphertext (encrypted form)
You can use the default s3 key or a custom KMS key (CMS) , where the client need explicit access to decrypt the content.
download the file so they cant see the content??
Then the content needs to be encrypted before the upload. AWS provides some support for the client-side encryption but the client is free to implement its own encryption strategy and the key management.
To solve trouble with managing the keys on the client side, it's often more practical to stick with SSE and allow access to S3 or the used CMS (key) only to identities that must access the content.
I am reading AWS encrypt cli document from https://docs.aws.amazon.com/cli/latest/reference/kms/encrypt.html and https://docs.aws.amazon.com/cli/latest/reference/kms/decrypt.html. I found that I am able to encrypt/decrypt without creating a data key. When I read https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html, it says that I need to use KMS CMK to generate a data key which is used to encrypt my data.
So I am confused about whether I need a data key at all?
CMK is designed to encrypt/decrypt the data keys. Therefore, there is a limit of 4 KB on the amount of plaintext that can be encrypted in a direct call to the encrypt function. You can easily test this by passing in message larger than 4 KB.
These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.
You are likely using a default CMK that was created by another AWS service that uses KMS encryption.
Of course all encryption and decryption operations require a key. If you did not explicitly create one for your application, then you are using the current default key.
Ensure that KMS Customer Master Keys (CMKs) are used by your AWS services and resources instead of default KMS keys, in order to have full control over data encryption/decryption process and meet compliance requirements. A KMS default master key is used by an AWS service such as RDS, EBS, Lambda, Elastic Transcoder, Redshift, SES, SQS, CloudWatch, EFS, S3 or Workspaces when no other key is defined to encrypt a resource for that service. The default key cannot be modified to ensure its availability, durability and security. On the other side, a KMS Customer Master Key (CMK) provides the ability to create, rotate, disable, enable and audit the encryption key used to protect the data.
See https://www.cloudconformity.com/knowledge-base/aws/KMS/default-key-usage.html
I'm currently going about setting up encryption on AWS DynamoDB for individual columns on a table that are deemed sensitive. From my research, I've decided that the best way of doing this is likely with AWS KMS. From this sprouted a (perhaps very basic) question about the fundamental workings of doing this.
The true purpose, I would suppose, of me encrypting this data is to prevent people from accessing my data via a compromised AWS account (and perhaps AWS itself being compromised, but I'd imagine that's secondary). However, if my AWS account is compromised... doesn't the attacker have access to my KMS key (not directly, but the ability to use the API to encrypt and decrypt data?)
This is a really basic question, I'm sure, but I feel like I can't move forward with a hole in my knowledge this big.
The purpose of having KMS is to protect your data while the key is never visible to your application since the key never leaves KMS. You submit data to AWS KMS to be encrypted, or decrypted, under keys that you control. You set usage policies on these keys that determine which users can use them to encrypt and decrypt data. All requests to use these keys are logged in AWS CloudTrail so you can understand who used which key when.
Having KMS makes it impossible for an attacker to get the encryption keys. Even if an attacker get on hold of your AWS Account(Assuming he gets Admin Access and KMS Access) and use KMS to decrypt a message, you will be able to see that through the logs in accessing these keys which is a necessary security steps to identify these threats.
So in general, if you provide least privilege to users(Not allowing everyone to access KMS), while keeping root account safe with MFA, it will be really difficult for an attacker to access KMS.
Has anybody tried to use AWS KMS on Heroku?
On one hand, Heroku runs on AWS, so presumably it should work.
On other hand, I haven't seen any references that it was used in Heroku.
My main goal is to be able to get an encryption key from a hardware secure module (vs hardcoding it in my code or putting it in an environmental variable).
There is no reason why you should not be able to call a KMS endpoint from anywhere you have internet connectivity.
You still need to have an access key and secret access key for the AWS account you are using and that account needs to have permissions on KMS.
You will need to distribute the encrypted stuff and the aws keys to your Heroku instance. You can then decrypt and use KMS from there.
One thing that it worth mentioning: when using KMS you never see the actual key KMS uses. You can create the key, you can encrypt and decrypt, and/or you can have permissions on the specific API operations, but you cannot get the plaintext key.
What you normally do is some sort of envelope encryption in which you generate your own key and encrypt it via KMS and send the encrypted key and the encrypted data to the destination.
I'm working with AppSync on a project, and will be capturing relatively sensitive user data which will require encryption at rest in a database.
Currently, I am building with DynamoDB resolvers after a mutation or query, but happy to explore other solutions (such as encrypting with KMS through a Lambda function and then sending to DynamoDB; or using DynamoDB Streams to refactor the data once a new entry is created in a table?)
The KMS would be managed through IAM, with user's assigned through a Cognito user pool (I'm quite new to this, but believe that's the best approach).
this all depends on who you are protecting the data from. if the decrypt is going to actually happen in AWS, then AWS has the decrypt key at least temporarily (because you let them manage the keys, and give them to ciphers that reside in AWS). you can assume that AWS are trusted to forget the key and the decrypted plaintext ASAP, and not backdoor your decrypts. if you are only worried about third-parties (ie: not-AWS) getting in, then this is ok. Just keep in mind that your defenses against the cloud provider if you do not do end-to-end are limited.
If you are actually worried about AWS decrypting your stuff, there are a few major issues, because that demands end-to-end encryption to handle: decrypts would have to happen outside of AWS (ie: decrypt on a phone or a program that runs on a user's laptop), which implies that keys themselves are only decrypted outside of AWS, and if you search data you are not telling AWS what you are searching for (ie: angry-protesters-on-my-last-visit.mp4). The latter is possible do to, but there are very few general purpose products that even attempt to do correct end-to-end encryption.
DynamoDB now supports encryption at rest, you can enable it on your table.