2

There is a requirement to implement additional level of security for an application. Let's say there is a table with 10'000'000 users. The sensitive fields are user.first_name and user.last_name. We need to encrypt that data before storing it into the database and later decrypt on the application level to show it on the UI.

As far as I can see the recommended way to do it with KMS is:

Write Part

  • call KMS service to get data key
  • encrypt the fields using data key
  • on the application level persist user record with encrypted fields into the database

Read Part

  • retrieve the record with encrypted fields from the database
  • decrypt the fields using data key
  • show the data on the UI

I have a set of questions that i need to clarify:

  1. Does it make sense to use a new data key for each user?
  2. 10'000'000 users means 10'000'000 different data keys , what is the best practice to store them and access them from the machine that is doing decryption?
  3. Is it ok to have a single data key for the whole user table?
  4. What is the best practice to store a single key securely on local machine?
  5. What will happen when accidentally the data key will be lost? Are there any recovery procedures?
yurko
  • 1,502
  • 1
  • 13
  • 14

1 Answers1

1

The exact solution to be implemented should be decided based on the organization policy and the regulatory needs. However, the following points would hopefully help you develop a solution:

  1. You can create a separate data key for each field by using a pseudo random number generator. The data key will be used to encrypt the raw data and then the data key itself will be encrypted using a common "Customer Master Key" from KMS. The encrypted data key will then be stored along with the encrypted data (first name and last name, in your case).
  2. During decryption, the encrypted data key (stored along with the encrypted data) will be first decrypted using the master key from KMS and then the data will be decrypted using the data key
  3. KMS can be configured to rotate the master key automatically every year. However, KMS keeps track of the old keys so that the encryption done with the old keys can be decrypted in the future even after the master key is rotated
  4. The master key in KMS will be replicated across multiple Availability zones and therefore it is highly available
  5. If you have more stringent security requirements, you may consider CloudHSM which stores the key in dedicated hardware that is not shared with other AWS customers
  6. You can also use a KMS custom key store backed by CloudHSM. However, in that case the automatic key rotation will not be available
Saptarshi Basu
  • 8,640
  • 4
  • 39
  • 58