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

У мене є резервний сервер, який створює xzстислі tarархіви дерев каталогів для резервного копіювання. Ці архіви з дьогтем можуть отримати величезні (кілька ТБ), складені splitна шматки (2,5 ТБ), і кожен фрагмент записується на стрічку LTO-6, і стрічки виходять за межі місця.

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

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

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 (конкретно, сценарій чотири, написаний для sshsfвикористання), який з невеликим налаштуванням з радістю зашифрує практично будь-який дані через GnuPG. Але будьте попереджені, що це експериментально, і деякі його функції можуть призвести до пошкодження даних при неправильному використанні. Вихідний код менше, ніж ~ 1600 ~ рядків, тому дуже можливо провести аудит менше ніж у вихідні дні.

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

Якщо ви хочете, щоб секретний ключ не тримався на жорстких дисках, ви можете створити рамковий диск (пам’ятаєте ці?) І завантажити необхідні секретні ключі туди з вашого захищеного місця на сервері. Використовуйте його для розшифровки та, коли закінчите, перезапишіть його на / dev / random. Секрет повинен полягати в оперативній пам’яті, щоб якось використовувати GPG, так чому б не двічі?

Якщо ви не можете дозволити, щоб секретний ключ ніколи не був на сервері, навіть в оперативній пам'яті, у вас є технічна неможливість. GPG повинен десь мати секретний ключ, щоб щось розшифрувати.

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