|
| From: | Jonathan Dray |
| Subject: | Re: [Duplicity-talk] backup from multiple devices with GPG asymetric key encryption - best practices |
| Date: | Thu, 13 Jan 2022 01:00:05 +0100 |
Hi all,adding to that (I have a similar setup) you can add an additional S3 user with write/delete privileges. I use that from my laptop to clean up backups. You just need to copy over the duply/duplicity profiles (Which is a good idea for recovery purposes as well).
Also consider glacier lifetime rules to move backups to glacier tier on S3 automatically to save cost.
Kind regardsChristian
_______________________________________________-------- Ursprüngliche Nachricht --------Von: Rinck Sonnenberg via Duplicity-talk <duplicity-talk@nongnu.org>Antwort an: Discussion about duplicity backup <duplicity-talk@nongnu.org>An: Discussion about duplicity backup <duplicity-talk@nongnu.org>Kopie: Rinck Sonnenberg <r.sonnenberg@netson.nl>Betreff: Re: [Duplicity-talk] backup from multiple devices with GPG asymetric key encryption - best practicesDatum: Wed, 12 Jan 2022 16:43:07 +0100Hi all,I also use GPG to encrypt and sign all my backups. I use a unique set of encrypt/sign keys for each server and agree that without automation this would be a huge hassle.To make generating and maintaining keys doable, I use Ansible to generate a unique keypair for each server.Another thing is what Scott already mentioned: if your server is ever compromised, you can and should consider your backups/keys compromised as well.To ensure I can rely on the offsite backups made before the server was compromised, I use AWS. For each server, a unique S3 bucket is created and accompanied by a server specific user with only put/append privileges. This ensures that the S3 account/credentials which are present on the server can only be used to ADD files to the bucket, not delete or modify them. That way you can be sure your pre-compromised backups are intact.That also means that you cannot use duplicity to remove older backups; so to solve that problem AWS offers lifecycle rules which allow you to delete certain files from your bucket after a set time. You'll need to be careful when doing this since you cannot delete all files (you don't want to delete manifest files for example).I believe this method creates a secure way to backup your servers and in case of corruption or compromise, you can always rely on your backups. I've been using this in production on around 40 servers for 2+ years now and have always been able to restore stuff when needed (mostly accidentally deleted files by other users..., but hey).If anyone would like more details of my setup I am happy to provide them!Regards,RinckOn Wed, Jan 12, 2022 at 4:24 PM Scott Hannahs via Duplicity-talk <duplicity-talk@nongnu.org> wrote:You can maintain a series of server dependent keys but that becomes a lot of overhead. The other way is to use gig-agent to allow access to the private keys by duplicity on the source machine. The theory is that if the source machine is compromised then the data you are protecting is as compromised as the gpg keys._______________________________________________(gog = gpg dang auto correct!)-ScottOn Jan 12, 2022, at 08:05, Jonathan Dray via Duplicity-talk <duplicity-talk@nongnu.org> wrote:Hi Scott,Thanks for the reply.I think your statement for the encryption part is correct. Encryption will be done using the public key, and private key will only be needed for the restore situation.However for the signing part it is the other way around, and the signing private key is needed for backup. As the public signing key will be needed for validation in the restore process.What do you think about the backup key pair for each server, vs a backup key pair for all devices.Would you have any recommendations ?Jonathan_______________________________________________Le mer. 12 janv. 2022 à 03:52, Scott Hannahs via Duplicity-talk <duplicity-talk@nongnu.org> a écrit :
> On Jan 11, 2022, at 9:20 PM, Jeffrey Walton via Duplicity-talk <duplicity-talk@nongnu.org> wrote:
>
> On Tue, Jan 11, 2022 at 4:46 PM Jonathan Dray via Duplicity-talk
> <duplicity-talk@nongnu.org> wrote:
>>
>> I'm new to duplicity and to GPG.
>> To catch up I read multiple articles and documentation pages online on the subject and I came up with a first working solution that I'm not happy with yet ;)
>> And also a couple of questions.
>>
>> What I have today :
>>
>> A GPG master key generated offline with tails, following this guide : https://wiki.debian.org/GnuPG/AirgappedMasterKey
>> with 2 password protected subkeys: one for encryption, and one for signing
>> Duplicity backup commands run with duply that store encrypted backup on a remote S3 like cloud storage hosted by Scaleway : https://www.scaleway.com/fr/object-storage/ Using the encryption keys generated above.
>>
>> I have successfully sent encrypted data to the remote storage and restored the backed up files from it.
>> As for the GPG setup I've imported on my test laptop the encryption and signing subkey pairs (public and private for both)
>>
>> Now I struggle on 2 main points :
>>
>> unattended backups
>> transpose the setup securely for multiple devices
>>
>>
>> Unattended backups
>>
>> I have to enter the key passphrase on each backup operation.
>>
>> I suspect it is the case because my sign key is password protected
>> I tried to set up the gpg agent and to store the password in the cache for an unlimited amount of time. Which doesn't work and isn't maybe a wise thing to do anyway.
>> That limitation makes it really hard / impossible to setup unattended backups
>>
>>
>> Multiple devices setup
>>
>> I was advised to create a new key pair specific to backup / storage vs my initial master key that was essentially targeted to be used in a web of trust context (email / git ...).
>> Also by design gpg won't let me have multiple encryption subkeys.
>>
>> Now with that in mind I guess I would have to create a specific backup key pair for each server right ?
>>
>> To sum up
>>
>> If I want a different encryption key per device (seems to be the safest option), I have to generate a new keypair for each device right ?
>>
>> or I should consider that as the encryption private will rarely be on a given server, the risk of that key being stolen is low so having only one key for encryption is reasonable ?
>>
>> As for the signing key I'm still confused on how to proceed...
>>
>> should it be managed as a subkey of a device specific keypair ?
>> or one single key for all devices ?
>> multiple signing keys as subkeys of a separate keypair ?
>> What about the passphrase protection ?
>
> I think you are hitting the Unattended Key Storage problem. It is a
> wicked hard problem in computer science. Also see Peter Gutmann's
> Engineering Security,
> https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf.
If gog is an asymmetric key system, can’t all the encryption and incremental updates be done with the public key and the private key is needed only for the downloading and restoration of files from the backups which is usually an attended situation? Or am I missing some fundamental.
Use RSA an asymmetric crypto system.
Backups require only public key
Restoration requires private key
-Scott
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________Duplicity-talk mailing listDuplicity-talk@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/duplicity-talk
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
| [Prev in Thread] | Current Thread | [Next in Thread] |