I’m not fond of software encryption (or compression, for that matter). Particularly in a 24×7 enterprise environment, clients (i.e., production servers) have better things to be doing than doing on-the-fly software encryption or compression. In these environments, hardware encryption routers should be the product of choice for achieving totally secure backups. Such devices also have advantages in terms of key management – much more flexible, scalable and appropriate for role based data access.
That being said, in smaller environments, or environments where servers are relatively idle overnight, NetWorker’s datazone encryption can be sufficient to achieve a reasonable modicum of backup protection with minimum effort – and most importantly, cost.
To get started using NetWorker datazone encryption, you first need to assign a pass phrase. This is done in the NetWorker server properties (typically accessed within NMC):
With the pass phrase in place, you can then configure directives within NetWorker to make use of AES 256 bit encryption. However! As soon as you turn encryption on, you lose all potential for hardware based compression for your media. Why? Quite simply, compression is about finding patterns in data and reducing all the matching patterns to a single reference point; however, encryption is all about eliminating patterns, making the data appear completely random.
Thus, if you want to still get some measure of compression, you should, when using this method, employ software based compression in your directive as well.
Thus, a base directive might look like the following:
<< / >> +compressasm: . +aes: .
This will apply compression first to all files encountered, then once the file has been compressed, it will be encrypted. A side benefit of this is that by compressing first, you reduce the amount of data to be encrypted*.
So long as the datazone pass phrase is stored in the server, encryption will occur, and no password will be required to recover the data. Remember, this style of encryption, using a single pass-phrase, isn’t about being able to restrict whom within the datazone can recover the data, but instead it’s about keeping the data stored on-tape (which is potentially off-site, or otherwise at higher risk of theft), from being recovered.
[Edit, 2009-08-15]
It’s been pointed out to me that you can’t compress + encrypt at the client side. Indeed, I’ve now found the part in the administration guide that explicitly says this. What is extremely disappointing about this is that NetWorker actually doesn’t warn you that it’s not going to compress + encrypt! To me, that’s a security issue.
So, for the examples above, forget about enabling client side compression as well as encryption – you can have one or the other, but not both.
—
* In the same way that ice-cream that’s 99% fat free, but 87% sugar is a “benefit”.
I wonder if you could clarify something for me?
When you say “As soon as you turn encryption on, you lose all potential for hardware based compression for your media” do you mean just adding the pass phrase will impact all clients or only those where the AES directive is in use?
Let’s say I have a data zone on which I have been relying on hardware compression by default at the tape device level. I add a “remote” dedicated storage node (that writes to it’s own NAS device). I want that data to be encrypted in case that NAS device goes walk-about. If I configure the server with a pass phrase and I configure the new client for the storage node with the AES directive but I leave all my other clients as they were – no AES directive, will I lose the compression I was getting before the pass phrase was configured or will I only not get compression for the new storage node?
I thought it was only the s/w compression that was not compatible with encryption. Won’t the compression that is done between device driver and device still take place?
Hi Andy,
It’s when you start actually using the AES directive – not just when you add the pass-phrase. It affects all forms of compression, both software and hardware.
Logically it’s quite simple – compression is about finding repeated patterns in the data and reducing them to a minimum number referencing the same ‘chunk’. Encryption on the other hand is about finding repeated patterns in the data and scrambling them.
Therefore, if you compress first (via software compression), then encrypt, you at least get a smaller data stream that is being scrambled by the encryption algorithm. However, if you encrypt first, you’re left with a datastream which is almost entirely, if not completely random/scrambled, and has no patterns that are susceptible to compression.
It’s not to say there’s a limited chance that a tiny amount of compression might still happen on an encrypted data stream, but I’d suggest it’s no more than something that you’d get on compressing an encoded video file or a (only mildly compressed) zip file – e.g., maybe 1%.
With your example above, with having a datazone passphrase set, but only using the AES directive on a particular host, only that host would ‘lose’ data compressibility. Other hosts that are not being encrypted should continue to have their data compressed as per normal.
Cheers,
Preston.
Hi Preston,
Do you know how EMC has implemented this encryption. Do the generate a shared key, that is downloaded to the client on first backup or do they (I hope not!) store the passphrase in one of the local ressource files on the client?
/Jens
PS: Thank’s for some good interesting reading 🙂
Hi Jens,
(FYI, don’t forget that the article is incorrect in advising to use a combination of aes and compressasm in the directive – only one or the other can be used.)
The datazone passphrase used for encryption is stored on the NetWorker server, encrypted, and to my knowledge is shared encrypted with the client – i.e., it’s neither stored unencrypted nor passed unencrypted between services.
Cheers.