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.
Related
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.
I know we can select a KMS (customer or AWS managed) key when creating our RDS database.
However I find the documentation quite vague about the different processes so I've got the following questions:
Does it mean that only one datakey will be used for the whole database to encrypt everything ?
Where exactly is the encrypted version of the data key located ?
When does RDS decrypt the encrypted datakey to use it ?
How often does RDS need to make an API call against KMS to decrypt the encrypted version of the data key it keeps ?
Does it mean that only one datakey will be used for the whole database
The documentation really doesn't specify any details. Based on the aws best practices and other documentation I'd assume the data key is cached and reused for certain time and then regenerated.
However the details are not publicly available. All the storage encryption is hidden under the hood and not visible to the client
How often does RDS need to make an API call against KMS to decrypt the encrypted version of the data key it keeps ?
AWS KMS calls are logged in the CloudTrail and you will see the calls on the bill as well. At least for the CMK (I'm not sure how is it for the default service KMS).
I am wondering if you please help me out with the following question.
What are the differences between the KMS and the secret manager in GCP? Thank you in advance.
https://cloud.google.com/secret-manager/docs/
HB
Cloud KMS encrypts data and returns the encrypted ciphertext. Cloud KMS does not store the secret, only the keys to encrypt/decrypt.
Secret Manager actually stores the secret material. Secret Manager also keeps a history (versions) of secret material. All data in Secret Manager is encrypted. By default, it is encrypted with a Google-managed key. You can actually use Cloud KMS to encrypt Secret Manager secrets (this is called "CMEK"), in which case the user controls the keys.
Cloud KMS is designed as a cryptographic oracle system: nobody, including yourself, can get the keys out: this means they're locked inside the system and you don't have to worry in practice about them leaking. The tradeoff is that the only thing you can do with those keys is encrypt, decrypt, and other cryptographic operations: useful for protecting data, or even for encrypting secrets, but if you have a database password or something else which you want to keep secret, but then actually be able to use or send elsewhere, you have to store the encrypted version, then use Cloud KMS to decrypt it.
When you do have configuration info like a database password, where your software actually needs the secret, not cryptographic operations, then Secret Manager is designed for that use case. The tradeoff is that if you get a copy of the secret out, it's harder to keep it from leaking and be certain it's controlled.
Thanks for using GCP!
Is it possible to get files from encrypted S3 buckets using boto 2? I am working with a project that uses S3 in several places and has to read/write to an encrypted S3 bucket. I would like to make as small a change as possible, for the time being, to support encryption.
Encryption actually works at the object level, rather than the bucket.
There are several ways to use encryption. If it is Protecting Data Using Server-Side Encryption with Amazon S3-Managed Encryption Keys (SSE-S3), then as long as your app has permission to access the object then it will be automatically decrypted. (The app won't even notice that it was encrypted!)
If it is Protecting Data Using Server-Side Encryption with AWS KMS–Managed Keys (SSE-KMS), the app will also need adequate permissions to use the key in KMS. The object will be automatically decrypted, but it needs permissions to use the key.
If the app is Protecting Data Using Server-Side Encryption with Customer-Provided Encryption Keys (SSE-C), then the app must provide the encryption key when it tries to access the object.
And finally, if it is Protecting Data Using Client-Side Encryption, then the app is totally responsible for encryption/decryption.
It is most likely that your data is using Server-Side Encryption with Amazon S3-Managed Encryption Keys (SSE-S3). If so, then your app doesn't have to do anything — it will all be handled automagically by Amazon S3.
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.