GPG для администратора: шифрование резервных копий, подпись и проверка целостности

Резервная копия — те же данные в другом месте, часто с меньшей защитой. Шифрование открытым ключом GnuPG (GPG) решает две задачи: копию нельзя прочитать без закрытого ключа, а закрытый ключ не нужен на сервере, который делает копии, достаточно открытого. Подпись и контрольная сумма показывают, что файл не изменили и не повредили. Ниже порядок: ключи, скрипт шифрования и проверки, восстановление и хранение ключей.

Статья опирается на логику направления «Безопасность данных» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена на GnuPG 2.2.40 (Debian 12) во временном каталоге ключей, который после проверки удалён. Для обязательных требований по криптографическим средствам (ФСБ России) используйте сертифицированные средства: статья описывает общую практику. Схема резервного копирования: копирование 3-2-1; общие вопросы шифрования: шифрование дисков и данных.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Схема

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

Шаг 1. Создайте ключи

Пример на отдельной машине администратора. Ключ подписи Ed25519 и подключ шифрования Curve25519 с годовым сроком действия (замените имя и адрес). Закрытая часть защищается парольной фразой: GnuPG запросит её при создании. На реальных ключах задавайте длинную парольную фразу (в проверке на стенде она была пустой только ради пакетного режима).

gpg --quick-generate-key "Backup Admin <backup@example.com>" ed25519 sign 1y
gpg --list-keys --with-colons backup@example.com | awk -F: '/^fpr/{print $10; exit}'
gpg --quick-add-key ОТПЕЧАТОК cv25519 encr 1y
gpg --list-keys --keyid-format long backup@example.com

Что должно получиться: основной ключ с пометкой [SC] (подпись и сертификация) и подключ [E] (шифрование), срок до даты через год. При создании ключа GnuPG сам сохраняет сертификат отзыва в каталоге ~/.gnupg/openpgp-revocs.d/: перенесите этот файл в офлайн-хранилище. Им можно объявить ключ недействительным, если закрытый ключ утерян или скомпрометирован.

Шаг 2. Экспортируйте ключи по назначению

gpg --export --armor backup@example.com > backup-public.asc
gpg --export-secret-keys --armor backup@example.com > backup-secret.asc

• Открытый ключ (backup-public.asc) импортируйте на сервер копий: gpg --import backup-public.asc.
• Закрытый ключ (backup-secret.asc) уберите в офлайн-хранилище (зашифрованный носитель, сейф), удалите с рабочих машин. Храните несколько копий в разных местах: потеря закрытого ключа делает все копии нечитаемыми.
• Для автоматической работы сервера без закрытого ключа шифрования не нужен: для шифрования требуется только открытый ключ.

Шаг 3. Скрипт шифрования, подписи и проверки

Скрипт архивирует каталог, шифрует архив открытым ключом получателя, создаёт отделённую подпись и контрольную сумму SHA-256. Для подписи нужен ключ подписи в связке (на сервере копий).

#!/usr/bin/env bash
# Шифрование каталога для резервной копии открытым ключом GPG, подпись и проверка.
# Использование:
#   ./gpg_backup.sh encrypt КАТАЛОГ ВЫХОД.tgz.gpg ПОЛУЧАТЕЛЬ   # архив, шифрование, отделённая подпись (ВЫХОД.sig)
#   ./gpg_backup.sh verify  ВЫХОД.tgz.gpg                      # проверка подписи
#   ./gpg_backup.sh list    ВЫХОД.tgz.gpg                      # расшифровать и показать состав архива
# Закрытый ключ нужен только для расшифровки и подписи. Для подписи используйте отдельный ключ.
set -euo pipefail
cmd=${1:-}
case "$cmd" in
  encrypt)
    dir=${2:?каталог}; out=${3:?выходной файл}; rcpt=${4:?получатель (адрес или отпечаток ключа)}
    tar czf - -C "$(dirname "$dir")" "$(basename "$dir")" | gpg --batch --yes --trust-model always -e -r "$rcpt" -o "$out"
    gpg --batch --yes --detach-sign -o "$out.sig" "$out"
    sha256sum "$out" > "$out.sha256"
    echo "готово: $out, $out.sig, $out.sha256"
    ;;
  verify)
    f=${2:?файл}
    sha256sum -c "$f.sha256"
    gpg --verify "$f.sig" "$f"
    ;;
  list)
    f=${2:?файл}
    gpg --batch -d "$f" | tar tzf -
    ;;
  *) echo "Использование: $0 encrypt|verify|list ..." >&2; exit 2 ;;
esac

./gpg_backup.sh encrypt /srv/data /backup/data-2026-10-12.tgz.gpg backup@example.com
./gpg_backup.sh verify  /backup/data-2026-10-12.tgz.gpg
./gpg_backup.sh list    /backup/data-2026-10-12.tgz.gpg

Результаты проверки на тестовом каталоге из двух файлов:

Подпись, проверенная отдельной командой gpg --verify ФАЙЛ.sig ФАЙЛ, после такого изменения даёт BAD signature. Размер зашифрованного архива с маленькими файлами — сотни байт: это издержки формата.

Восстановление

1. Скопируйте копию и файлы .sig, .sha256 на машину восстановления.
2. Импортируйте закрытый ключ из офлайн-хранилища: gpg --import backup-secret.asc (потребуется парольная фраза).
3. Проверьте целостность: ./gpg_backup.sh verify ФАЙЛ. При ошибке не восстанавливайте: возьмите другую копию.
4. Расшифруйте и распакуйте: gpg -d ФАЙЛ.tgz.gpg | tar xzf - -C /восстановление.
5. Удалите закрытый ключ с машины восстановления после работы (gpg --delete-secret-keys ОТПЕЧАТОК), если она не предназначена для хранения ключей.
6. Регулярно (раз в квартал) пробуйте восстановление из копии: копия, которую не удалось расшифровать, не является копией: проверка восстановления.

Шифрование паролем (без пары ключей)

Для разовых файлов подходит шифрование парольной фразой: gpg -c --cipher-algo AES256 файл. Расшифровка: gpg -d файл.gpg. При неверной фразе выдаётся decryption failed: Bad session key. Парольная фраза должна быть длинной и храниться отдельно от файла; для регулярных копий надёжнее схема с открытым ключом.

Срок действия, продление и отзыв

• Срок действия ключа ограничивает ущерб при потере; перед окончанием продлите: gpg --quick-set-expire ОТПЕЧАТОК 1y. Продление не меняет ключ, но обновлённый открытый ключ нужно передать на сервер копий.
• Старые копии, зашифрованные подключом с истёкшим сроком, остаются читаемыми закрытым ключом: срок влияет на создание новых шифрований.
• При компрометации закрытого ключа: опубликуйте сертификат отзыва (gpg --import ФАЙЛ.rev на машинах, где ключ используется), перешифруйте важные копии новым ключом, смените ключи.

Типовые ошибки

Диагностика

Где это в модели зрелости

Материал относится к направлению «Безопасность данных» (материалы направления, карта зрелости). Для уровня 2 копии должны храниться по схеме 3-2-1 с проверенным восстановлением, а передача и хранение — быть защищены: шифрование копий и подписи закрывают эти пункты.

Как проверить

1. Копии шифруются открытым ключом, закрытый ключ хранится офлайн в нескольких экземплярах, сертификат отзыва сохранён.
2. Для каждой копии есть подпись и контрольная сумма; проверка выполняется до восстановления.
3. В течение последнего квартала выполнена пробная расшифровка и восстановление.
4. Срок действия ключей известен, продление и ротация запланированы.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Руководство GnuPG: gnupg.org; man gpg.
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: csrc.nist.gov. Международная практика, не российский норматив.