Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Microsoft SQL Server Encryption - Key Management Security Best Practices

Posted by Patrick Townsend on Apr 12, 2017 7:48:32 AM

This is part 7 in a series focusing on critical aspects of SQL Server encryption. In the previous part of this series we looked at encryption key management business recovery topics. In this part we look at encryption key management security best practices. Protecting encryption keys from loss is the most important part of an encryption strategy and there is good documentation on security best practices for encryption key management. Security best practices for key management also appear in many compliance regulations such as the Payment Card Industry Data Security Standard (PCI-DSS) and others.

Separating Encryption Keys from the Data They Protect

Encryption-Key-Management-SQL-ServerOne of the core best practices for encryption key management is to separate the storage of encryption keys away from the data that they protect. Using a key management system designed for the creation and storage of keys is central to this security best practice. The separation of encryption keys away from protected data makes the compromise of sensitive data much harder. Compromising and retrieving locally stored encryption keys is usually a simple task, and this is true for SQL Server locally stored keys.

These common practices are weak security for SQL Server encryption keys:

  • Encryption keys stored in application programs
  • Encryption keys stored in a SQL Server table
  • Encryption keys stored in folders on a local or remote Windows server
  • Encryption keys stored with password protection
  • Encryption keys stored locally by SQL Server Transparent Data Encryption (TDE)

Separating encryption keys from protected data substantially raises the bar for attackers, and largely eliminates the threat of loss from replaced hard drives, stolen virtual machine or cloud images, and lost backup images.

Separation of Duties

Separation of Duties (SOD), sometimes called Segregation of Duties, is a core security principle in financial, medical and defense applications. In the context of protecting sensitive data separation of duties is important to minimize accidental or intentional loss of sensitive data by insiders. As applied to Information Systems separation of duties requires that those who create and manage encryption keys should not have access to sensitive data, and those who manage databases (database administrators) should not have access to encryption keys.

Organizations should assign encryption key management duties to specific security administrators who do not have database administration duties, and not assign key management duties to DBAs. In modern key management systems this is managed by the assignment of user-friendly names to encryption keys. The user-friendly names for encryption keys, sometimes call key aliases, are exchanged between the security administrator and the SQL Server DBA. This avoids sharing the actual encryption keys.

Dual Control

The NIST guide for Key Management Best Practices defines the encryption key management role as critical part of the security strategy. Management of encryption key systems should implement Dual Control. This means that two or more security administrators should authenticate to the key server before any work is performed. Requiring a quorum of security administrators to authenticate minimizes the threat of insider damage or theft of critical encryption key secrets.

Split Knowledge

Because encryption keys are critical to the security of protected data, this security best practice requires that no one person sees or takes possession of an encryption key that is visible in the clear. Modern key management systems minimize this threat by not exporting or displaying encryption keys to administrators or users, and not using passwords as a part of the key creation process. If you use a key management system that generates or exports keys based on passwords, or which exposes encryption keys in the clear to administrators or users, you should implement split knowledge controls. SQL Server protects Transparent Data Encryption keys by never storing them in the clear on the SQL Server instance.

Minimum Number of Key Administrators

Another security best practice designed to reduce insider threats and the loss of administrative credentials is to keep the number of people who manage your key management system to the smallest reasonable number. The fewer administrators who have access to the key management system the fewer opportunities for accidental or intentional loss of encryption keys.

Multi-factor Authentication

Like any critical component of our information management system, encryption key management systems should implement multi-factor authentication, sometimes called two factor authentication, to reduce the threat of the theft of administrative credentials. Cyber criminals use a number of techniques to capture important administrative credentials including phishing, social engineering, memory scraping, and other types of attacks. Multi-factor authentication is an important security control and best practice for encryption key management systems.

Physical Security

Physical security controls are also an important security best practice for encryption key management and similar security applications and devices. Physical controls in the data center include keyed access to server rooms, locked cabinets and racks, video monitoring and other controls. While physical security of key management hardware security modules (HSMs) is fairly easy to accomplish, it is also necessary to insure physical controls for virtual environments that use VMware and Hyper-V, and for cloud environments. In cloud environments you may have to work with your cloud service provider to insure proper protection of virtualized key management server instances.

Data Encryption Key Rotation

Periodically changing the data encryption key (DEK) of your protected data is also a security best practice and required by some compliance regulations like PCI-DSS. This is sometimes referred to as “key rotation” or “key rollover”. Your key management system may help in this area by allowing the specification of the crypto-period of the key and automatically changing the key for you. Of course, the retention of the older key is needed to insure that encrypted data can be decrypted. Changing encryption keys and re-encrypting sensitive data is a security best practice.

Key Encryption Key Rotation

In proper key management systems the data encryption keys (DEK) are protected by separate key encryption keys (KEK). Key encryption keys are only used to protect DEK and are never used to directly protect sensitive data. Key encryption keys reside only on the key management system and must not leave that system except as a part of a secure backup. KEK rotation is generally less frequent than DEK rotation, but should be a part of your key management system.

Administrator and User Authentication

Key management systems are designed to generate strong encryption keys and protect them from loss. Of course, it must also enable the use of encryption keys to protect sensitive data. The key management system should implement strong authentication controls for access to the key server, and further should implement strong authentication for the use of specific encryption keys. This is normally implemented using PKI infrastructure and mutual authentication between clients and servers. This exceeds the typical authentication that you might encounter using a web browser with a secure session. A key management system should insure that a secure session is negotiated by a known and trusted client. To insure this most key management systems incorporate a private certificate authority and do not rely on public certificate authorities to insure the highest level of trust in the authentication.

Network Segmentation

As critical security systems it is a best practice to use network segmentation of key management systems and of the applications that access the key management systems. Network segmentation can be accomplished through normal IT infrastructure, through virtualized network management as implemented by VMware, and in cloud platforms using cloud service provider network segmentation rules. Further network access controls can often be implemented in the key management system using firewall rules.

Auditing and Logging

Lastly, all security devices including key management systems should collect and transmit audit and system logs to a log collection server or SIEM monitoring solution. Active monitoring of critical application and security systems is an important security control and best practice. Key management systems should fully implement support for active monitoring.

In summary, security best practices for key management systems used for SQL Server data protection should reflect well-understood and documented best practices for security devices. The core source of these best practices is the National Institute for Standards and Technology's Special Publication 800-57, “Recommendation for Key Management.” Your key management solution for SQL Server should implement these best practices.


Encryption and Key Management for Microsoft SQL Server

Topics: SQL Server, SQL Server encryption

Subscribe to Email Updates

Posts by Topic

see all