Andrew Lentvorski wrote: > John H. Robinson, IV wrote: > > >data stands a better chance of being irrevocably lost. You add another > >single point of failure: loss of the keys. > > Correct, but you are assuming your only risk is loss.
I am assuming that you want to use these backup in order to restore because your entire machine room was 1) flooded 2) on fire 3) crushed by a boeing 747. We are not talking about ``oops, i deleted my .bashrc'' instead we are talking about Disaster Recovery. Archives are something different, which you can happily encrypt untl the cows come home, leave, and come home again. You won't need archives yesterday like you will your Disaster Recovery when your entire corporate IT inftrastructer is *gone*. > *Theft* is now a bigger issue. The person most likely to steal from you works for you. Who are you protectng against, again? With your theory, you need to excrypt to disk. Which is what I said when I said let the application encrypt. Most don't bother, so this is a real issue. > With proper redundancy, a system effectively never goes down. You can > lose entire sites if you have a geographical spread. If you are a Fortune 1000 company, you can do this. If you are a simple machne shop in New Orleans (Hi, Katrina!) y7ou may not be able to do this. You can contract for DR sites. This works until the DR people are flooded with requests for space and machine because of a widespread disaster (hi, Katrina!) > However, you still need backups in case of break-ins, administrator > stupidity, application instability, etc. Stealing those backups is > becoming a much bigger risk than losing them. Those don't need to be offsite. Those you don't need yesterday. Those you simply need today. > It's all about risk vs. cost. Running a business nowadays, all backups > would be encrypted. You have a 500 server machine room. You have to restore them all. They are all encrypted. GO! Perhaps we are not even talking about the same thing, and if so, I appologise. If you did simply mean daily archives, and I am talking about disaster recovery, then we are speaking completely different languages. > >If you are going to encrypt the backup tapes, then you are going to have > >to have a fantastic key management system. One that can survive the loss > >of the site, and the loss of the primary personnel (that may know the > >keys by heart. Or may not). > > USB key in an offsite safe deposit box. This really isn't that hard. Key management is not that easy, either. For a very small small shop, or a home user, it is that easy. For a larger company, it gets harder. Who can access that safety deposit box? What if that person is not avalable? Or that person? What credentials are required? If you want to really learn something, go attend some of the Disaster Recovery presentations at a Large Installation System Administration (LISA) conference. I was a bg proponent of encrypting backup tapes until I actually learned what it really entailed. > >This does have to be balanced against the loss of a tape by the courier, > >or offsite storage provider. The best solution? The application itself > >encrypting the sensitive data. This way it is safe, no matter what, and > >you need take no special precautions with the backup tapes. Other key > >management caveats still apply. > > And where is that key stored? > > Oh, right, on the unencrypted disk with the application itself. Oops. You say this as if this is not already a solved problem: five letters: HTTPS. We do this already. We manage it already. While Apache does not use t to ecrypt data, it does use the certifcate(key) to perform identifcation. You don;t store your HTTPS key unencrypted on the disk, do you? > Key management is annoying, but it is not hard. However, it just needs > to be explicitly considered rather than being ad hoc. The question is > whether the annoyance is worth the gain. For a modern business, I > assert that it is. For a lot of things, I agree with you. For Disaster Recovery (backup) tapes, I disagree. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
