I'm implementing a service that requires me to call my customers' API using their API keys. My customers will provide me with their API keys in their accounts.
When I'm calling my customers' API, I have to retrieve their API key before making the call. Since these are my customers' API keys and I want them to be kept safely, I'm considering keeping all of them in AWS Secrets Manager. I have roughly about 5,000 users (still growing) and I plan to store all their keys into a single secret in Secrets Manager. My application makes about a few millions calls to my customers API a month and it needs to retrieve the keys at high frequency and concurrency.
However, I'm not sure if this is the kind of use case for Secrets Manager because their docs sound to me like it was meant for just keeping secret information for the application and not for customers like a database. At the same time, storing encrypted keys in the database and having to decrypt them with a KMS key sounds like I may end up with roughly the same cost.
Is Secrets Manager meant for such a use case to store customers' sensitive information such as API keys? If not, what should I consider in my case?
50k api keys in a single secret is goinfg to be very unwieldy. Assuming a 40 byte token, you're looking at 2mb of data - SSM has a max data length for a value of 4096 bytes unless I'm mistaken.
To me it would make more sense to generate a key with KMS and use that key to encrypt customer API keys before writing them to a DynamoDB table (or even RDS if you so desire) When you need to use a customer API key, fetch it from dynamoDB, decrypt it with the KMS key, and then make use of it.
If you want automatic key rotation, SSM could be used to encrypt the key you use to encrypt the client API tokens. Your token decryption key would remain usable while the wrapping SSM entry would be reencrypted with a key rotation set by policy.
Finally, as Software Engineer suggested above, there is Vault.
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.
My needs - Read/Write Encrypted Data
I have a software application that can build webpages and emails and I need to encrypt content stored in the database (PII plus user generated content by financial/healthcare institutions).
I would like to use AWS KMS/AWS Secrets Manager to manage the hash so the hash is secured and keys that gate the hash are automatically rotated and managed by AWS. I'll use this hash to encrypt/decrypt data. Two way encryption is required.
My Question
It seems there are two options, and I'm not sure which is preferred and which is the proper way to use AWS for this:
Option 1 - Encrypt DB Access (Not preferred)
I could store all PII and encrypted data in a separate RDS DB, and simply gate API access with encryption provided by AWS Secrets Manger and KMS. This kinda stinks because the encrypted data relates to tables in the main DB. So hosting this data elsewhere is cumbersome to maintain.
Option 2 - Encrypt the data on a field level (!Preferred!)
I would prefer to store encrypted data in the DB directly. For instance a table may have 7 columns unencrypted, but the content column contains encrypted data. I then need to figure out a way to encrypt/decrypt this securely. I would need some sort hash that encrypts/decrypts the data. Storing in directly in PHP seems like a bad idea so could I use AWS KMS / Secrets Manager to do this?
Plan A -
I store a hash in Secrets Manager (Encrypted with KMS), so when the application wants to encrypt/decrypt content, it uses the required IAM user to get the hash from AWS Secrets Manager, encrypts/decrypts the content and then removes the hash from memory.
Plan B* -
I use KMS directly (No secrets manager) and pass encrypted/decrypted content to KMS directly and it encrypts/decrypts on the fly, never needing to expose or send the key it's using to perform these actions.
Thanks again for taking the time
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.
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!
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