Tape backup encryption tutorial: Table of contents
Today there are three main tape backup encryption choices on the market:
- Host-based encryption solutions
- In-band encryption appliances/switches
- Media-based encryption (including tape drive encryption)
Host-based encryption can be most useful when encryption is required for a single system or a limited set of systems. It's isn't possible to encrypt all data upon egress from a host without turning to a host-based approach. The host-based approaches on the market are widely varied, and can be implemented via application technologies (such as database column encryption software), host agents, or specialized storage or network adapter cards with encryption functionality. Products are available from every major adapter vendor, storage vendors offering multipath or other agents that interact in-band, storage virtualization vendors and many more.
In-band appliance encryption operates in a very similar manner, encrypting data that is transferred across a wire, only it sits in the middle of a storage connection and can be shared by many different applications and hosts. Data transmitted between the host and the appliance will always be unencrypted. Such devices are an easy way to implement encryption for multiple hosts and across multiple types of storage, including primary storage, archive tiers and even tape. These devices can be used to selectively apply encryption to only some storage tiers. Some vendors with in-band encryption appliances include Brocade's Encryption Switch, Cisco System Inc.'s MDS Storage Media Encryption and NetApp's DataFort.
Media-based encryption uses a variety of technologies to encrypt data in media-specific formats. These technologies might be storage array integrated, so that each drive in an array is encrypted. More typical is tape encryption, where a backup media server, a tape library, virtual tape library (VTL), or the individual tape drives themselves (LTO-4 or LTO-5 drives) encrypt the data as it is written to a disk or tape. IBM Corp.’s DS8000 Series arrays, for instance, provide drive-level encryption utilizing full encryption-ready drives. And Quantum Corp.’s Scalar series ATL libraries with LTO-5 drives, as well as those from most other library manufacturers, come encryption ready.
There are a number of caveats for each of the choices that make selecting a backup tape encryption approach complex. Here is a list of tape backup encryption best practices:
1. Guarantee all tapes are encrypted. Organizations should look for solutions that will guarantee the encryption of all tape, and not enable paths around encryption or cause unnecessary complexity when managing multiple paths to tape (such as multiple archiving and backup systems).
2. Encrypt close to the destination. Ideal products will encrypt data at the right layer of the infrastructure to allow capacity optimization and other data management solutions to work to their full effect. As a general rule, all tape should be encrypted, but if if encryption happens too close to the source, data flexibility and efficiency is lost. For example, if the opportunity to deduplicate or compress data on disk or across WAN links is lost, scanning for data such as duplicate files becomes much more difficult. Also, closer-to-the-host encryption requirements can be addressed with a different solution than the one selected to provide comprehensive tape encryption.
3. Encrypt on a per-media basis. Encryption of tape media is done to reduce risk and minimize the effort involved in handling any incident. Expiration of a single piece of media, or loss of a single piece of media, needs to be gracefully handled. That means each tape, or at worst, a group of tapes in a backup or data set, needs to be encrypted with a unique key. That way, keys and media are best protected, the loss of a key will not jeopardize more than a single tape, and there is little management effort involved in adhering to best practices of regularly expiring and disposing of keys in the event of a tape loss.
The requirements clearly set the stage for media-based encryption as the preferred approach for many. In contrast to media-based encryption, host-based and appliance-based encryption can be difficult to work with for the purpose of encrypting tape media. Host-based approaches come with significant management overhead at scale, and may consume precious host resources. Appliance-based approaches may mean that the encryption system doesn’t understand tape formats, and any key expiration may require the painful rekeying of large sets of media. Appliance-based approaches that address multiple storage tiers may turn tape encryption into a multi-discipline team practice and complicate backup management. In addition, appliance-based approaches may also require careful engineering to address all the data paths that may be used to write to tape inside large organizations. Also, managing host-based encryption for each host can easily become unmanageable at scale.
For these reasons media-based encryption seems the obvious choice. But when it comes to media-based encryption, there are certain things you need to watch out for. Backup media servers are typically not the best place for encryption. Media servers may be under significant performance pressure to begin with, and because of that, they may not have the resources to efficiently encrypt tape. Plus, there are several components involved in tape encryption management, including especially important key management servers that are responsible for assigning, securing and managing the keys for tape media. For many backup products on the market, the integrated key management may not be highly automated or built to scale to thousands of tapes.
While media-based encryption is a general recommendation, keep in mind there are always exceptions for the unique needs of a business.
While media-based encryption is a general recommendation, keep in mind there are always exceptions for the unique needs of a business. Encryption is typically a licensed feature, and requires additional key management systems. The costs may mean that in-band encryption appliances are sometimes more cost effective. Moreover, it may be that a VTL system in your enterprise either has integrated encryption, or integrations with third-party encryption engines that provide easier routes to encrypted tape.
The key management system required by any encryption product is one of the most important elements of an encryption approach, and it is too often overlooked. Today there is little interoperability between key management systems and different vendors' encryption offerings. Key management will come from your tape system or appliance vendor. With that in mind, key management for media-based encryption should be considered a standalone system today, even if there is other encryption in the enterprise. Future standards such as the Oasis Key Management Interoperability Protocol (KMIP) standard may someday make a single key management system for all enterprise systems possible. Given the importance and inevitability of tape encryption as a best practice, organizations should be evaluating a tape vendor’s key management system any time they are considering a tape system investment.
Finally, a data encryption foundation anchored in tape doesn’t mean every enterprise need is addressed, and it does not rule out further use of additional technologies. The wide range of choices available in the market today means an organization can easily build a layered approach that more extensively encrypts some sets of more critical data, and works right alongside tape backup encryption. With the right key managers, the management overhead can be minimized and greatly reduce a businesses' risk.
About this author: Jeff Boles is a senior analyst and the director of Taneja Group's hands-on Technology Validation Services, focused on validating vendor solutions in real-world use cases. Prior to his several years with Taneja Group, Jeff's background includes more than 20 years of senior management and hands-on infrastructure engineering within the trenches of operational IT.
This was first published in April 2011