The documentation just lists server side encryption, where Google handles the keys. Is it possible to use customer supplied keys ala Cloud Storage?
It is not possible to use Customer Supplied Encryption keys, at this time, with Cloud Datastore.
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.
Does Google Cloud SQL support column-level encryption?
I know that it is possible for BigQuery tables but not sure about Cloud SQL!
link
It's not a out of the bow feature on Cloud SQL, you need to do it manually when you read and write the data. You can use Cloud KMS for hat.
With BigQuery, keep in mind that you need to keep the key in BigQuery also and only the IAM permission allow to access or not to the keyset.
Eventually, all the data are encrypted at rest, but I'm sure that your use case is for a specific column, not for the whole database.
When using a key stored inside Google Cloud HSM, is it possible to get the following metadata fields about the HSM hardware being used:
Device model name
Device serial number
Firmware Version
Hardware Version
Valid FIPS certificate for device
Number of the certificate issued for device
? When ordering a certificate from a CA, we are asked for these fields for regulatory reasons.
You can see the relevant information Google Cloud HSM makes available about key provenance at https://cloud.google.com/kms/docs/attest-key; you can download an attestation which will assert that the key is limited to an HSM. However, we do not make all the information you are requesting available (and the information specific to a particular HSM does not map well to our on-demand shared infrastructure model).
Can you share the name of the Certificate Authority with these requirements? We'd be happy to approach them about accepting Cloud HSM keys.
Thanks for using Google Cloud and Cloud HSM.
Topic - Google Cloud KMS and support for custom keys
I was exploring the documentation for the google cloud KMS. It mentions that the Cloud KMS is more of management service that helps controlling and managing the DEKs which are used by google in 2 ways
CMEK - Allowing google to create KEK and us to manage the rotation and other aspects
CMEK - Allowing to import your own key which will act as KEK on top of google DEK.
From what I understand and seen, cloud KMS allows control over the key that encrypts the DEK.
Does Google Cloud KMS also support storing our custom private keys (CSEK) for encryption and usage/signing.
Customer-supplied Encryption Keys (CSEK) are a feature of Google Cloud Storage and Google Compute Engine.Google uses the encryption key supplied by the customer to protect the Google-generated keys used to encrypt and decrypt the user’s data [1].
When a customer supplied a CSEK (Customer Supplied Encryption Key) Cloud storage does not store the CSEK key permanently on the google server or manage the key. You have to provide the key for each cloud storage operation, and your key is purged from Google’s servers after the operation is complete. Cloud Storage stores only a cryptographic hash of the key so that in the future if the customer again supplies the key, it can be validated against the hash. But the key cannot be recovered from this hash, and the hash cannot be used to decrypt the data [2].
In Case of Google Compute Engine also, Google does not store your keys on it’s servers and cannot access your protected data unless you provide the key. If you by mistake forget or lose your key, there is no way for Google to recover the key or to recover any data encrypted with the lost key. For instance when you delete a persistent disk, google discards the cipher keys, rendering the data irretrievable [3].
Useful Links:
[1] https://cloud.google.com/security/encryption/customer-supplied-encryption-keys
[2] https://cloud.google.com/storage/docs/encryption/customer-supplied-keys
[3] https://cloud.google.com/compute/docs/disks/customer-supplied-encryption
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.