As a security architect, security administrator or database administrator, one of the first big questions you face with the encryption of data at rest is how to organize, plan, and implement encryption keys to protect that data. Should you use one key for everything? Or, should you use a different key for each application? Or, perhaps you should use a different key for every table and column? Or, should you use a different key for each department? It is hard to find good security best practice guidance on this topic, so let’s put some focus around this question and see if we can come up with some general principles and guidance.

First, I like to start by identifying any applications or databases that contain highly sensitive information such as credit card numbers, social security numbers, or other personally identifiable information. These sources will be the high-value targets of cybercriminals, so you will want to protect them with your best security. For each of these applications and databases, assign encryption keys that are not used by any other application or database, and carefully monitor the use of these keys. Your encryption key management solution should help you with monitoring key usage. The objective is to protect the highly sensitive data and the related encryption keys from unauthorized access. If you have multiple sensitive applications and databases, assign each its own unique key.

Second, identify all of your major applications that are used across a broad set of departments within your company. Since these applications span multiple departments and will have a broad set of users with different needs, you should assign each of these applications their own specific encryption keys. In the event one application or database is compromised, it will not affect all of the other applications and databases.

Third, the remaining applications and databases are probably those that are used by one specific department within your organization. You will probably find that most departments in the organization have a number of specialized applications that help them get their work done. In terms of raw numbers, this might be the largest category of applications. Assign each department its own set of encryption keys that are not used by other departments. You may find that you need to sub-divide the department and assign keys for each sub-group, but the goal is to use encryption keys for the department that are not shared with other departments.

Lastly, cloud implementations are a special category and should always have separate keys. In the event that a Cloud Service Provider experiences a security breach, you will want to be sure that your internal IT systems are not affected. Assign specific encryption keys for your cloud applications and do not share the keys with internal, non-cloud applications.

Over the years I’ve occasionally seen organizations create and use a very large numbers of keys. In one case a unique key was used for every column and row in a table. In another case a different key was used for every credit card transaction. Large numbers of keys present management problems, and probably lowers overall security. Keep the number of encryption keys to a manageable level.

The above guidelines should help you protect your sensitive data and easily manage your encryption keys. There is a summary table for the above guidelines:

There are always exceptions to general rules about how to deploy encryption keys for the best security. The above comments may not be appropriate for your organization, and you should always adjust your approach to your specific implementation. Hopefully the above will be helpful as you start your encryption project.