We know that there are three options
1.(default) Google-managed encryption keys
2. Customer-supplied encryption keys
3. Customer-managed encryption keys
For a particular customer data, how we can restrict the access so that the data remains unreadable even if it is downloadable.
You cannot download encrypted data from GCP/BQ/etc without the encryption key or access to the encryption key.
The exception is if you upload self-encrypted data as normal data.
Related
I need to store OAuth token, and various quite sensible user information data into my firestore. I've learned that Firestore is safe and that they already encrypt data, should I do it still ?
If I do it, I'll use a key stored in .env to encrypt / decrypt data via a aes-256-cbc cypher but I think it might be overkill...
PS. I use Next.js API Routes
Encrypting the data is entirely optional and doable, but the practicality of doing so far exceeds the actual usefulness of any encryption implementation.
The data is already transferred securely via HTTPS and decoded on the client. If you were to encrypt the data, any information to decode the data would also be available from within your app, making the encryption redundant.
The only reasonable risk is if the clients' device is compromised, hackers can access the decrypted data directly but that is not feasible to prevent.
In this video GCP engineers show how to encrypt data using a customer provided encryption key. This allows data to be encrypted E2E and the customer can keep the private key securely stored in house.
However, does this still allow joining tables based on certain values in the columns? AFAIK, encryption always adds some randomness to the message and as such, each time a value is encrypted, it will result in a different output while in its encrypted state. As such, joins should not work.
Am I correct in this belief? What are possible mitigations to enable joining despite having encryption? Any personally identifiable information is a common target for encryption, however joins, even on an encrypted value such as the customer ID, are essential for many applications.
Option 1: If we use an AWS KMS-managed customer master key (CMK), does that provide end-to-end encryption?
Option 2: Or, would we have to use a client-side master key, so that only the client can decrypt their data?
Update: KMS is not asymmetric, though you can use Envelope Encryption to generate a data key from the CMK. The key is generated on a physical HSM making it not accessible externally. You will only have to worry about the access to the CMK which you can achieve using IAM access control.
For a detailed explanation how the mechanism works, check the Envelope Encryption section on the KMS Cryptographic Details white paper.
So if you only worried about eavesdropping can be a good solution. If you are looking for strictly end-to-end encryption you might have to use asymmetric keys on which KMS can help you with too.
Aws kms does not store any data it provide you two keys
1 plain key : with the help of it you encrypt the data and delete it(key)(no need to save anywhere).
2.encrypted data key :- you need to save this key to decrypt the data( to decrypt the data first you got plain key from aws using encrypted data key) and with the help of plain key you decrypt the data.
So encryption is done at client side.
I learned about the table encryption for MariaDB here.
However, it seems the keys are located in a single file in a way an attacker could easily decrypt the data by having read access on the filesystem.
Assuming that it can be safer, I would like to encrypt database depending on one public key, and connect to the database through a private key file stored on my side.
Is that in any way possible?
It is typical that encryption just moves the problem. It is possible to protect the key in storage but not easy or cheap and it is virtually impossible to protect it in RAM when being used by the DB.
Solutions to protecting the key in storage include moving it to an HSM or another more secure and limited access system that provides the key to the DB over a secure link.
One advantage is that is the DB is obtained without the key it is secure, the problem is that the same access can also provide the key to the attacker. The work factor has increased and that may meet the security needs.
I am developing a web based application that will be employed by numerous third party organisations
in numerous countries around the world.
The browser based client will feed sensitive data into a shared back end database.
All organisations in all countries will Read/Write data into the same database.
I wish to encrypt the data entered within the browser so that its safe while in transit
to the back end database. e.g. client side encryption.
I also wish to encrypt the data while at rest in my database.
This application will be developed using Java, Javascript (REACT.js), and Scala.
The backend database will be MongoDB.
I cannot find a good Key Management example/description e.g. how a key is properly generated,
distributed, stored, replaced, deleted, and recovered during its life time.
I have the following choices/decisions to make:-
Flavour of encryption, e.g TripleDES, RSA, Blowfish, Twofish, AES etc..
Key(s) Symmetric/Asymmetric and its/thier length
How should I securely distribute the keys to my clients.
How to keep my keys safe on my back end servers.
If keys should have a lifecycle of generated, distributed, stored, replaced, deleted.
How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?
How should I store my multiple keys for my multiple clients to enable me to encrypt/decrypt
each clients data.
Use HTTPS with certificate pinning to secure the data in transit.
Use AES for encryption. Do not use TripleDES, RSA, Blowfish or Twofish in new work.
Use an HSM.
Encrypt the data with a long-life key that is not distributed, encrypt that key with short life keys that can be changed as needed.
Considering the scope of the project get a cryptographic domain expert to design the security and vet the code.