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>