In our final installment of questions from “Encryption Key Management with Microsoft SQL Server 2008” we tackle the topics of encryption key management in High Availability (HA) and disaster recover scenarios. If you missed the first two blogs in the series, you can always go back and read about “The Performance Impacts of TDE on Microsoft SQL Server” and “How often do I need to rotate encryption keys on my SQL Server?” If you still have any questions about encryption or encryption key management on your Microsoft SQL Server, feel free to send them our way. It is always a pleasure to hear from members of the data privacy community. Here is the last question in this series:
Can you speak to how encryption key management works in High Availability (HA) and disaster recovery scenarios?
An encryption key management solution becomes a part of your critical infrastructure if you are properly protecting keys. If your key manager goes down, your applications stop functioning until you have key management back up. We really address those concerns in a number of ways. One way is that our key manager is built for redundancy. We know it is hardware, and if it is hardware it can fail, so we implement a hardware platform that is resilient and has a lot of redundancy built in. The first layer of keeping an encryption key manager up and running consistently is to have a good hardware platform.
Secondly, we build real-time mirroring of keys and policy around keys directly into the product. You can actually deploy a high-availability failover key server with all key activity and access controls mirrored in real-time to a fail-over key server. If you use SQL Server, you can define right in our software one or more fail-over servers. For example, in SQL Server, through the configuration panels you can define multiple key servers for fail-over. If you have a failed server, a hardware problem, or network outage, you can actually define fail-over servers and that will take place in real time.
Furthermore, there is a lot of resilience in the EKM provider software that we install on the Windows server so that if there is a software failure, there are some self-healing mechanisms there too. If our module were to be killed off by the security administrator, it will get re-started automatically. So there are a lot of redundancy and self-healing components built in to both the software and configuration components on the key server.
We have done a lot to help customers deal with the concern about resilience of a key manager because it is critical infrastructure, and we fully support that through real-time mirroring. It is not an operating system feature. The key server itself has implemented this mirroring capability. It is itself self-healing. So if two key servers are mirroring to each other and the network goes down, they will queue up those mirroring transactions, and when the network comes back, it will re-commit those changes. Alliance Key Manager is a robust facility for making sure you have good backups of your encryption keys.
This concludes our series of questions from the recent webinar “Encryption Key Management with Microsoft SQL Server 2008.” We encourage you to view the webcast and learn even more about how easily and affordably you can begin meeting data privacy compliance requirements with encryption and encryption key management.