[ale] best practices for key management w/encrypted backups
Robert Reese~
ale at sixit.com
Wed May 13 10:33:39 EDT 2009
Hi Sid,
> I have been tasked w/reviewing/testing/etc our processes for
> managing encrypted backups & it got me to thinking "what's the
> right # of keys to deploy (global master pair? one per client?
> one per application?)? how often should they be rotated?
> where/how should they be stored?", etc.
>
> my 1st inclination is to write a script to generate a metric 5h1+-
> ton of key pairs, burn them onto a bunch of CDs and distribute them
> to clients for one-time use but is that thermonuclear overkill?
> obviously nobody wants to end up on /. but on the other hand ending
> up w/a backup you can't decrypt/restore is arguably worse (far IMO).
Then why bother encrypting it at all? I heartily disagree that not being able
to restore is worse. It is certainly a less likely possibility than having your
security compromised! You don't mention what the encryption is protecting, but
I'm going to assume that its leakage would cause irreparable harm to the company
and/or to clients and/or consumers, or that it breaks regulations and statutes
somewhere along the lines. Ending up on /. can not only kill the company's
reputation and possibly the business itself but can lead to lawsuits against the
business and against the company or person(s) responsible for the security of
that data. Hint, hint. Not to mention criminal charges and fines, possibly
even jail or prison time for the responsible parties.
If you are an employee of this company, what are your chances of gaining
similarly-positioned employment after you get fired or the company goes under?
Or worse, what if you find that the company survives by laying off a vast swath
of employees? OTOH, I suppose jail or prison and/or fine is worse than getting
fired or sued, or being responsible for killing off a company or losing people
their jobs.
It bears reminding that it would be very irresponsible if there were only one
backup that could be used for restoration. Sure, you lose a week's worth of
work but the alternatives make that sound pretty palatable. Furthermore, it is
irresponsible to lose the private key or forget the passphrase which is your
fear.
But not to worry.... you came to the right place. ;c) As far as the keys go,
you don't specify which encryption platform you are using. IMnshO, PGP
Enterprise is the way to go. With PGP Enterprise, you can distribute a few keys
that require more than one person's key or even multiple persons keys to open
the encryption. You can also use the same setup to include back door decryption
of employee keys.
I'd use perhaps four keys in your position - the backup manager's, one that is
divided among second-level execs and one that is divided among the top execs. I
would not require that all persons receiving key parts be required to decrypt
but I would require at least three people's key parts to decrypt the backup.
The fourth key's responsible for creating a secure container in which reside the
backup manager's key and passphrase. Obviously that too should have keyparts
assigned to multiple people requiring at least three keyparts to open. This
scenario gives plenty of options in decrypting the backups but leaves the amount
of keys very low.
As for the life of the key, that only affects when something can be used to
encrypt to the public key as well as whether at the time of signing the key was
not expired. It does not affect whether or not something can be decrypted with
it. In that case the backups should be destroyed after a time period.
Of course, your question begs another: what is protecting the data on the site's
machines? Am I to assume the only protected data is that which is backed up?
What system is in place to prevent the data from being leaked or otherwise
acquired? If encryption is being used, what is being used and how? How can
that system be used to model the backup system?
If you need, I probably can get you in touch with with Will Price or Jon Callas
at PGP Corp., if just briefly. However, I think if you go to pgp.com and look
at their PGP Enterprise stuff you will find every question you have answered
already, including the ones you did not ask or didn't know you had.
Cheers,
Robert~
More information about the Ale
mailing list