Re: new feature: client-side, server-side encryption dumptype option
2005-12-29 10:54:20
Greg,
Thanks for responding.
I know that having the keys with the data was was not (obviously) an
optimal high security setup, but I was wondering if there was some
other purpose for doing this since it seemed a suggestion in the email
I that inspired me to write and I didn't follow the purpose for the
reason you give.
I do recognize that the recovery kit is hidiously difficult to build
for multi-architecture platforms. How-tos would help, OS specific kits
might, or might not, prove useful.
We have a saying at my site (used for HW as well as OS/software,
ie selection of "SCSI cables", Linux, redhad, suse and others)
- "Standards are very useful, that is why we have so many."
Christopher Knight
I also know that protecting the keyring is of paramount inportance
in a security situation. All I could suggest is an unencrypted copy
of the root/critical systems with updated keyring and archived and
stored in a physically high security area. For that matter I think
any mission/critical or rapid recovery system should have this anyway.
I do like keeping the amanda installation tar-ball on each box, I
know its a big use of space but its really bailed me out of a
variety of failures, including my botching upgrades. Nothing like
having the previous amanda version immediately at hand for reinstall.
Thank you Greg, I guess I wasn't that far behind the curve.
happy holidays,
Brian
On Thu, Dec 29, 2005 at 10:20:10AM -0500, Greg Troxel wrote:
> Brian Cuttler <brian AT wadsworth DOT org> writes:
>
> > I'm not meaning to make light or waste time but the following
> > questions/observations occur.
>
> no worries, your comments are useful.
>
> > Concerning tape encryption but not addressing encryption during
> > transit between client and server I wonder about the following ?
> >
> > 1) I don't fully apreciate implications having the key on the tape
> > - you don't lose it
> > - you complicate the restore
> > - I suppose you could always store it in an extended amanda tape
> > label or a secondary label on the tape.
> > - How safe is it to store the key with the encrypted data ?
> > What purpose does the encryption serve ?
>
> Your first three points are valid. Re the fourth, anyone with the
> tape can read the bits so it serves no useful security purpose, but
> does have the drawback of complexity.
>
> > 2) You do complicate the restore process.
> > - then I've felt for a long time that a recovery kit of some
> > kind might be nice.
> > - for example, VMS supports a boot strap backup utility for
> > bear metal restore
> > - I have started maintaining local accounts on each machine
> > in local "amanda" user accounts. This removes a number of
> > dependencies and homoginized the installation process for
> > (NIS/NIS+ and soon LDAP) cluster cluster vs standalone
> > amanda (client or server) systems.
> > * In the local amanda user login directory I store a copy
> > of the installation tar kit, completely built and ready
> > to expand, for that particular client or server.
> > - Something that would gather and build a recovery kit would
> > be complex but nice to have, it would have to include not
> > just amanda, which is easy, but gzip, encryption modules that
> > are outside of amanda and any libraries these things are
> > dependent on, including "install" which I often have to install
> > before I can even being with amanda.
> > - My tar kit does not contain these things.
>
> Sure, having restore kits is nice, but it ends up being os-specific.
> And you might want the data back on a different OS, depending on your
> disaster recovery plan. More of this, and howtos, would be nice.
>
> > The amanda disklist allows optional encryption, selected per DLE ?
> > Can you say, never encrypt the file system(s), root, etc, with the
> > requisit binaries, key ring, etc and encrypt everything else ?
>
> The current support is only for transport, and it is an option in a
> dumptype. So yes, you could not encrypt / and encrypt the other
> filesystems (I use dump(8); hence the language). But, if / has the
> key for the rest, this is not necessarily a good idea. Also, / tends
> to have kerberos srvtabs and private keys in /etc/ssh. So / is very
> high up on the should-be-encrypted list for me.
>
> --
> Greg Troxel <gdt AT ir.bbn DOT com>
---
Brian R Cuttler brian.cuttler AT wadsworth DOT org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: new feature: client-side, server-side encryption dumptype option, (continued)
- Re: new feature: client-side, server-side encryption dumptype option, Greg Troxel
- Re: new feature: client-side, server-side encryption dumptype option, Josef Wolf
- Re: new feature: client-side, server-side encryption dumptype option, Greg Troxel
- Re: new feature: client-side, server-side encryption dumptype option, Josef Wolf
- Re: new feature: client-side, server-side encryption dumptype option, Jon LaBadie
- Re: new feature: client-side, server-side encryption dumptype option, Josef Wolf
- Re: new feature: client-side, server-side encryption dumptype option, Chris Lee
- Re: new feature: client-side, server-side encryption dumptype option, Greg Troxel
- Re: new feature: client-side, server-side encryption dumptype option, Brian Cuttler
- Re: new feature: client-side, server-side encryption dumptype option, Greg Troxel
- Re: new feature: client-side, server-side encryption dumptype option,
Brian Cuttler <=
- Re: new feature: client-side, server-side encryption dumptype option, Greg Troxel
- Re: new feature: client-side, server-side encryption dumptype option, Brian Cuttler
- Re: new feature: client-side, server-side encryption dumptype option, Kevin Till
- Re: new feature: client-side, server-side encryption dumptype option, Geert Uytterhoeven
Re: new feature: client-side, server-side encryption dumptype option, Paddy Sreenivasan
|
|
|