|
|
| (3 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| == Different encryption configuration ==
| | #redirect [[Encryption]] |
| | |
| '''Transport Data Tag'''<br/>
| |
| no no A<br/>
| |
| yes no B<br/>
| |
| no yes C<br/>
| |
| yes yes D [separate encryption, back to clear on server]<br/>
| |
| yes still E [client encrypts, server passthrough]<br/>
| |
| | |
| | |
| In scenarios A and C, and eavesdropper on the network can observe the
| |
| data. In B D and E an eavesdropper cannot.
| |
| | |
| In secenarios A and B, one can retrieve the data from backup tapes
| |
| without keying material. This is perhaps obvious, but very important
| |
| for backups.
| |
| | |
| In C, D, and E, the backup tapes are encrypted. Thus, one could store
| |
| them someplace where you trust people not to destroy them but you
| |
| don't trust them to read them. This can make some sense for
| |
| particularly sensitive data.
| |
| | |
| In E, the backup data doesn't appear on the server in plaintext. This
| |
| can be useful for backing up clients with particularly sensitive
| |
| data. To really make sense, the client should be configured so that
| |
| it will only honor dump requests to a preconfigured set of public
| |
| keys.
| |
| | |
| == SSH ==
| |
| ssh provides transport encryption and authentication. The only caveat is that the amanda binary needs to be installed at the same location in the server as well as in the client since server is running:
| |
| /path/ssh -l <CLIENT_LOGIN> client.zmanda.com $libexecdir/amandad
| |
| to start the backup process.
| |
| | |
| While this is possible, it has two disadvantages:
| |
| | |
| 1. You need to set up keys for both, ssh _and_ amanda.
| |
| | |
| 2. You need to set up ssh keys either by storing the passphrase in
| |
| cleartext or use ssh-agent. Using ssh-agent has security-flaws, too.
| |
| In addition, with ssh-agent, you will need to type the passphrase
| |
| at least once after every reboot. Not very suitable for a
| |
| fully-automated backup-system, IMHO.
| |
| | |
| When you use a public key on the client to encrypt, you can lock away
| |
| the private key in a secure place. Both, transport _and_ storage will
| |
| be encrypted with such a setup.
| |