Зашифрованное автономное резервное копирование с использованием GPG с закрытым ключом никогда на резервном сервере?

У меня есть резервный сервер, который создает xzсжатые tarархивы деревьев каталогов для резервного копирования. Эти архивы tar могут быть огромными (несколько splitТБ), разбиты на части (2,5 ТБ), и каждый кусок записывается на ленту LTO-6, и ленты уходят за пределы площадки.

Теперь я хочу добавить шифрование. Я могу GPG зашифровать архив tar перед разделением, используя шифрование с открытым-закрытым ключом и с одним или несколькими получателями (открытые ключи администратора).

Однако в случае восстановления по крайней мере один администратор должен поместить свой закрытый ключ на сервер резервного копирования, так как файлы слишком велики, чтобы их можно было распаковать в другом месте.

GPG использует гибридную схему шифрования под капотом с симметричным шифром, подобным AES, с ключом сеанса, и только этот ключ сеанса получает открытый-закрытый ключ, зашифрованный для получателей.

Есть ли способ позволить администратору предоставить сеансовый ключ для расшифровки файла, который нужно восстановить, не помещая закрытый ключ на сервер резервного копирования ?

Я мог бы изобрести колесо, конечно:

• создать случайный ключ сеанса на сервере резервного копирования для каждого файла, для которого требуется создать резервную копию
• использовать симметричное шифрование GPG для шифрования файла
• использовать асимметричное шифрование GPG для шифрования ключа сеанса для каждого получателя

Но есть ли «стандартный» или встроенный или передовой способ достижения вышеуказанного?

Это, безусловно , возможно с --show-session-keyи --override-session-keyопций.

Сначала вам нужно начать ваш зашифрованный файл. Здесь хранится зашифрованный сеансовый ключ.

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

Затем скопируйте его на свою рабочую станцию ​​и получите ключ сеанса

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'

Теперь вы можете расшифровать файл, используя ваш сеансовый ключ

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>"

Похоже, что на большинство ваших вопросов был получен ответ, однако, если вы являетесь администратором, опасаетесь, что закрытые ключи выйдут из-под их локального контроля, и вы можете sshfsподключить удаленные резервные копии через сеанс ssh.

Установить через apt в системе каждого удаленного администратора

sudo apt-get install sshfs

Предполагая, что конфигурация администратора ssh выглядит примерно так:

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

Тогда ваши администраторы могут использовать что-то вроде ниже для монтажа

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

Для размонтирования после проверки удаленный администратор может использовать следующее

fusermount -u /mnt/remote

Преимущество использования sshfs заключается в том, что на удаленном сервере требуются только открытые ключи для GnuPG и ssh, а соответствующие закрытые ключи остаются в системах, которые владеют ими. Второй приятный момент заключается в том, что до тех пор, пока большая часть информации о файле не будет прочитана или не получит к ней доступ, она останется в соответствующей файловой системе.

Если вы все еще ищете инструменты для упрощения автоматического шифрования журналов или каталогов, возможно, вы захотите проверить инструмент концепции, который я отправил на GitHub (в частности, сценарий 4, написанный для sshsfиспользования), который с небольшой настройкой удачно зашифрует практически любой данные через GnuPG. Но имейте в виду, что он экспериментальный и некоторые его функции могут привести к повреждению данных при неправильном использовании. Исходный код содержит менее 1600 строк, поэтому аудит можно проводить менее чем за выходные.

Дополнительную безопасность можно получить, настроив конфигурацию ssh удаленного сервера для пользователей chroot, чтобы разрешить доступ только к зашифрованному каталогу и отключить интерактивную оболочку для ключей администратора, которые используются таким образом.

Если вы хотите, чтобы секретный ключ хранился на жестких дисках, вы можете создать виртуальный диск (помните их?) И загружать там секретные ключи из безопасного местоположения на сервере, если это необходимо. Используйте его для расшифровки, а когда закончите, замените его на / dev / random. В любом случае секрет должен быть в оперативной памяти для использования GPG, так почему бы не дважды?

Если вы не можете позволить секретному ключу когда-либо находиться на сервере, даже в оперативной памяти, у вас есть техническая невозможность. У GPG должен быть где-то секретный ключ, чтобы что-то расшифровать.

Информация о Ramdisk: /unix/66329/creating-a-ram-disk-on-linux