Encrypting your backup data always sounds like a good idea. It protects data and appears to be cost-free. So what's not to like?
In practice, it isn't always a good idea, it doesn't always protect your data and it is not free. There is a time and a place to deploy encryption, but it needs planning and thought.
The walls have ears
Protecting data on the move is usually advisable because you can have no clear idea of who might be listening in. It does have a cost, however, as it needs computing power to process.
If you are encrypting data at the server before sending it, you may need to specify, for example, an eight-core rather than a four-core box if you want to minimise the encryption overhead and the effect it can have on the backup window. This is not a cheap option.
If you are certain that the data travels only over your corporate network, you might get away with encrypting only when the data arrives at its destination.
This can be cheaper as most tape drives and other backup data repositories will include encryption hardware, and it can help shorten the backup window by allowing data to flow at full wire speed.
Protecting data at rest is a different matter. As old as war itself, encryption scrambles data so it can't be read unless you possess the keys. And that is at the heart of the problem.
Encrypting at the end-point – whether on tape or disk – offers a number of benefits, including security, a shorter backup window and no more hardware to buy.
It also means that the data can be deduplicated or compressed before it arrives (encryption's scrambling process renders deduping and compression pointless), although many prefer to rehydrate the data before storing it as an archive because this removes dependencies on proprietary technologies that might not be around in five years time.
However, encrypting early in the data path offers better protection and is more device-agnostic. It gives you control over both the type and strength of the encryption, and means you can back up encrypted data to disk drives now and archive to tape drives across the WAN later, for example.
You need to ensure that the keys will still be available
You also gain control over which data is encrypted, which reduces compute overheads. You might for example want to encrypt only sensitive data.
But the hidden gotcha is key management. If you are encrypting long-term data, then you need to ensure that the encryption keys will still be available to the correctly privileged individuals in five or ten years time, or maybe even more.
Key management means describing who has access to which keys; those that grant access to databases will be held by database administrators, for example.
Duties need to be allocated too, so access rights should be set up for storing, backing up, referencing and rotating keys. To add to the complexity, keys need to be rotated regularly, and different encryption technologies are mandated in different geographies.
It doesn't help that there are few standards to simplify matters, although KMIP, a standard ratified in October 2010 by the open standards body Oasis, is a step in the right direction.
So is tape or archive encryption good thing?
Yes, if it is properly managed and organised, but the costs can be higher than anticipated. It is not just about the amount of CPU you can throw at the problem. ®