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