У меня есть резервный сервер, который создает xz сжатый tar архивы деревьев каталогов для резервного копирования. Эти tar-архивы могут быть огромными (несколько ТБ), split на части (2,5 ТБ), и каждая часть записывается на ленту LTO-6, и ленты уходят за пределы площадки.
Теперь хочу добавить шифрование. Я могу GPG зашифровать tar-архив перед разделением, используя шифрование с открытым и закрытым ключом, и с одним или несколькими получателями (открытые ключи администратора).
Однако в случае восстановления хотя бы одному администратору необходимо поместить свой закрытый ключ на сервер резервного копирования, поскольку файлы слишком велики, чтобы их можно было распаковать где-либо еще.
GPG использует под капотом гибридную схему шифрования с симметричным шифром, таким как AES с сеансовым ключом, и только этот сеансовый ключ шифруется для получателей с помощью открытого и закрытого ключа.
Есть ли способ разрешить администратору предоставить сеансовый ключ для расшифровки файла для восстановления не помещая закрытый ключ на резервный сервер?
Конечно, я мог бы изобрести велосипед:
Но существует ли «стандартный», встроенный или лучший способ достижения вышеуказанного?
Это определенно возможно с --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 (в частности Сценарий четвертый написано для sshsf usage), который с небольшой настройкой с радостью зашифрует практически любые данные через GnuPG. Но имейте в виду, что это экспериментально, и некоторые из его функций могут привести к повреждению данных при неправильном использовании. Исходный код составляет менее ~ 1600 ~ строк, поэтому аудит можно выполнить менее чем за выходные.
Дополнительную безопасность можно получить, настроив конфигурацию ssh удаленного сервера для пользователей chroot, чтобы разрешить доступ только к зашифрованному каталогу и отключить интерактивную оболочку для ключей администратора, которые используются таким образом.
Если вы хотите, чтобы секретный ключ хранился на жестких дисках, вы можете создать ramdisk (помните их?) И загрузить туда секретные ключи из вашего безопасного местоположения не на сервере, если это необходимо. Используйте его для расшифровки, а когда закончите, перезапишите его / dev / random. Секрет должен быть помещен в оперативную память, чтобы GPG все равно использовал его, так почему бы не дважды?
Если вы не можете позволить секретному ключу когда-либо находиться на сервере, даже в оперативной памяти, это техническая невозможность. У GPG должен быть где-то секретный ключ, чтобы что-нибудь расшифровать.
Информация о Ramdisk: https://unix.stackexchange.com/questions/66329/creating-a-ram-disk-on-linux