In the world of customer data, security is an absolute necessity. Anyone who does not take the matter seriously will likely find themselves in a world of hurt followed quickly by unemployment if a company’s customer data is stolen, compromized, or otherwise used in a way it was never meant to be. For this reason, I’ve been re-reading some books on encryption techniques and one of the things stressed is the need to back up and safely store copies of the encryption keys. This makes sense as we need to know that we can recover the data in the future, which also means the keys.
But where the heck can we store those keys?
I asked this same question the last time I read the books and even fired off an email to the authors, but never found a solid answer. In the past I’ve used various tools to backup databases and they would often include functions such as compression and encryption. At first, this seemed like a really good idea. Not only would we be able to save space and storage media, but we’d be able to ensure the data would never be used by another person if they happened to find a lone DVD laying about the office. However, with most employers and clients demanding that passwords and administrative keys be changed every 30 days, I quickly eliminated encryption from the backup procedure.
Creating passwords is easy, but effectively managing expired passwords? That’s a whole ‘nother story. These passwords were the keys to the database. Ensuring that we could restore a backup from any point in time meant that we would need to track the passwords and ensure that they were available in the event of a catastrophic system failure, which often means an “offline solution”. It would be stupid to write the key on the DVD case, and having a master list stored in an envelope in a drawer of someone’s desk is also out of the question. We considered using locked databases on our PDAs which would be synchronized daily, but this wouldn’t be any more secure than storing the passwords in our email.
Since a concensus could not be reached on how to manage encryption keys, encryption was never implemented on the backups. Is this a good thing? I really can’t say. The company has never reported a backup DVD missing and, as far as I know, there has been no outside attempt to steal the company’s data. Suffice to say, this is not an easy problem to solve.
The problem becomes even more complicated if there are many different keys with different access levels against the data. Just how can we keep them all safe? How can we manage for data recovery situations on a completely different system, while still protecting those keys in the event something is lost or stolen? In numerous books about encryption, we’re told to keep the keys completely separate from the actual data, but this doesn’t seem to be a solution that many IT departments are fully ready to handle.
Some database platforms help simplify some of the problems involved with encryption by storing the keys with the database and making them available with the backup. Microsoft’s SQL Server is a good example of this. But there are a few keys such as the Service Master Key and the Database Master Key that really should be backed up elsewhere. These backups will need to have passwords as well, and with the need to rotate passwords, how can we keep them safe?
I don’t have the perfect solution, but I am open to suggestions.