Encryption Key Management Best Practices
Centralized Key Management
Centralize your key management system. For example, the following architecture can be considered well suited for the majority of businesses:
An encryption and decryption node exist at any point within the company’s network. Key management components can be deployed on different nodes and can be integrated with any encryption application. Such system enables you to have all the encryption and decryption mechanisms at the node level where the encryption/decryption is performed.
Centralized User Profiles for Authentication
Access to your sensitive data should be based on user profiles defined in your key manager. Thus, only properly authenticated users should be given the privilege of accessing the encrypted resources. An administrator should be responsible of managing the user profiles. The best practice is to build your key management system in such a way that no single user has sole access to the keys.
Separate the Processes of Encryption and Decryption
You can implement your encryption/decryption system at local level and distribute it throughout the organization or implement it at a central location on a separate encryption server. Note that all nodes should utilize the same standards, rules and quality levels. This approach has the following upsides:
- Higher performance
- Lower network bandwidth
- Higher availability
- Improved data transmission
Note that if the encryption and decryption processes are distributed, the process of key management should ensure secure distribution of keys.
Principle of Least Privilege
It’s a basic principle of using any application including encryption apps. It is the best practice not to use administrative privileges when using any application unless it is absolutely necessary because it makes apps extremely vulnerable to external and internal threats.
Support of Multiple Encryption Mechanisms
Your company should be ready for mergers and acquisitions, so it would be better to build your encryption system with an ability to support different encryption technologies. Of course, you don’t need to implement all available encryption technologies, but the major industry standard ones.
Common Solution for Encryption and Decryption for All Applications
It is highly advisable that you use a common encryption mechanism for database columns and files. It should be capable to identify the sensitive data that should be encrypted. Once encrypted, the data should become accessible only by the users with proper privileges based on application-specific user rights. The rights should be controlled by the administrator.
No Decryption or Re-Encryption in Case of Key Rotation or Expiration
Each encrypted file should have a key file associated with it to identify which resources should be used to decrypt the data contained in the file. It means that your system shouldn’t decrypt an encrypted dataset and then re-encrypt it when the keys are expired or changed. In this scenario, recently encrypted data would be decrypted using the recent key and the corresponding old key would be retrieved to decrypt the existing data.
Integration with Third-Party Apps
It is a common approach in enterprises to have a large number of external devices. These devices may be point-of-sale (POS) devices which are dispersed over the network. These do not have typical database-oriented applications and are dedicated to single function, using proprietary tools. It is always a good approach to use an encryption mechanism which can be easily integrated with any third-party application.
Sometimes companies own a big number of external devices such as POS (point-of-sale) devices included into the corporate network. Such devices typically can’t interact with databases directly but are aimed to work with proprietary tools. So, it’s a best practice to have your encryption mechanism compatible with third-party applications.
Logging and Audit Trails
Extensive logging is essential when using multiple distributed applications and it is an important component of key management. Each case of access to the encrypted data should be logged providing the ability to track the end user trying to access the encrypted data. The logs should include the following points:
- Query used to access the data
- User details
- Resources used to encrypt the data
- Database columns accessed
- Time when the data has been accessed
Regular Backups
Backup your databases frequently! The best practice is to make backups of your sensitive data every day, have a scenario of data restoring and do periodic checks of the application you use for backups.
