Sauvegarde hors site cryptée à l'aide de GPG avec une clé privée jamais sur le serveur de sauvegarde?

J'ai un serveur de sauvegarde, qui crée xzdes tararchives compressées d'arbres de répertoires à sauvegarder. Ces archives tar peuvent devenir énormes (plusieurs To), sont spliten morceaux (2,5 To), et chaque morceau est écrit sur une bande LTO-6, et les bandes vont hors site.

Maintenant, je veux ajouter un cryptage. Je peux chiffrer GPG l'archive tar avant de la fractionner, en utilisant le chiffrement par clé publique-privée, et avec un ou plusieurs destinataires (clés publiques admin).

Cependant, en cas de récupération, au moins un administrateur doit mettre sa clé privée sur le serveur de sauvegarde, car les fichiers sont trop volumineux pour être décompressés ailleurs.

GPG utilise un schéma de chiffrement hybride sous le capot, avec un chiffrement symétrique comme AES avec une clé de session, et seule cette clé de session obtient une clé publique-privée chiffrée pour les destinataires.

Existe-t-il un moyen de laisser un administrateur fournir la clé de session pour le déchiffrement du fichier à récupérer sans mettre la clé privée sur le serveur de sauvegarde ?

Je pourrais bien sûr réinventer la roue:

• créer une clé de session aléatoire sur le serveur de sauvegarde pour chaque fichier à sauvegarder
• utiliser le chiffrement symétrique GPG pour chiffrer le fichier
• utiliser le chiffrement asymétrique GPG pour chiffrer la clé de session pour chaque destinataire

Mais existe-t-il un moyen «standard» ou intégré ou conforme aux meilleures pratiques de réaliser ce qui précède?

C'est certainement possible avec les options --show-session-keyet --override-session-key.

Vous avez d'abord besoin du début de votre fichier crypté. C'est là que la clé de session chiffrée est stockée.

root@qwerty:~/gpg# head -c 1024k bigfile.gpg > head.gpg

Copiez-le ensuite sur votre poste de travail et récupérez la clé de session

PS C:\Users\redacted\Downloads> gpg --show-session-key .\head.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"
gpg: session key: '9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D'

Vous pouvez maintenant décrypter le fichier à l'aide de votre clé de session

root@qwerty:~/gpg# gpg -d -o bigfile --override-session-key 9:926EC16DF1248A1C4401F5AD5D86C63C1BD4BF351ECEFB121C57EC209DE3933D bigfile.gpg
gpg: encrypted with 2048-bit RSA key, ID DC21D645, created 2016-02-01
  "admin <admin@domain.tld>"

Il semble que la plupart de vos questions aient été résolues, cependant, si votre équipe d'administrateur se méfie des clés privées qui se retrouvent hors de leur contrôle local, vous pourriez envisager sshfsde monter les sauvegardes à distance sur une session ssh.

Installer via apt sur le système de chaque administrateur distant

sudo apt-get install sshfs

En supposant que la configuration ssh des administrateurs ressemble à quelque chose comme ci-dessous

# configuration for ssh login to remote server
Host Remote
    Hostname Remote.web.domain
    User admin
    IdentityFile ~/.ssh/private.key

Ensuite, vos administrateurs peuvent utiliser quelque chose comme ci-dessous pour le montage

# make a mount point
mkdir -p /mnt/remote
# mount remote directory to local file system
sshfs Remote:/path/to/encrypted/dir /mnt/remote

Pour démonter après inspection, l'administrateur distant peut utiliser les éléments suivants

fusermount -u /mnt/remote

Le petit plus sur l'utilisation de sshfs est que seules les clés publiques pour GnuPG et ssh sont nécessaires sur le serveur distant, les clés privées associées restent sur les systèmes qui les possèdent. Le deuxième élément intéressant est que jusqu'à ce que la lecture ou l'accès à la plupart des informations sur les fichiers reste sur son système de fichiers associé.

Si vous cherchez toujours des outils pour faciliter le chiffrement automatique des journaux ou des répertoires, vous voudrez peut-être vérifier l'outil prof of concept que j'ai poussé vers GitHub (en particulier le scénario quatre écrit pour l' sshsfutilisation) qui, avec un peu de personnalisation, chiffrera avec plaisir presque tous les données via GnuPG. Mais soyez averti qu'il est expérimental et que certaines de ses fonctionnalités peuvent endommager les données en cas d'utilisation abusive. Le code source est inférieur à ~ 1600 ~ lignes, il est donc très possible d'effectuer un audit en moins d'un week-end.

Une sécurité supplémentaire peut être obtenue en installant la configuration ssh du serveur distant aux utilisateurs chroot pour autoriser uniquement l'accès au répertoire chiffré et désactiver le shell interactif pour les clés admins utilisées de cette manière.

Si vous voulez que la clé secrète soit conservée hors des disques durs, vous pouvez créer un disque virtuel (vous vous en souvenez?) Et y charger les clés secrètes à partir de votre emplacement sécurisé hors serveur, si nécessaire. Utilisez-le pour le décryptage et une fois terminé, remplacez-le par / dev / random. Le secret doit aller dans la RAM pour être utilisé par GPG de toute façon, alors pourquoi pas deux fois?

Si vous ne pouvez jamais laisser une clé secrète sur le serveur, même en RAM, vous avez une impossibilité technique. GPG doit avoir la clé secrète quelque part afin de décrypter quoi que ce soit.

Informations Ramdisk: /unix/66329/creating-a-ram-disk-on-linux