Зашифрованное внешнее резервное копирование с использованием GPG с закрытым ключом, никогда не на сервере резервного копирования?
У меня есть резервный сервер, который создает xz сжатые tar архивы деревьев каталогов для резервного копирования. Эти tar-архивы могут быть огромными (несколько ТБ), разделены на части (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>"
Если вы хотите, чтобы секретный ключ не попадал на жесткие диски, вы можете создать ramdisk (помните их?) и загрузить туда секретные ключи из безопасного не-серверного места по мере необходимости. Используйте его для расшифровки, а когда закончите, перезапишите его с помощью /dev/random. В любом случае секрет должен попасть в оперативную память для использования GPG, так почему бы не дважды?
Если вы не можете допустить, чтобы секретный ключ когда-либо был на сервере, даже в оперативной памяти, то у вас есть техническая невозможность. GPG должен где-то иметь секретный ключ, чтобы что-то расшифровать.
Ramdisk info: https://unix.stackexchange.com/questions/66329/creating-a-ram-disk-on-linux
Похоже, что на большую часть вашего вопроса был дан ответ, однако,Если ваша команда администраторов опасается того, что закрытые ключи выйдут из-под их локального контроля, вы можете подумать о 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, чтобы разрешить доступ только к зашифрованному каталогу и отключить интерактивная оболочка для ключей администратора, которые используются таким образом.