Бэкап с шифрованием на чужое хранилище: схема доверия

MAATRIX

Как только бэкап уезжает на чужое хранилище — облачный провайдер, объектное S3-совместимое хранилище, VPS другого дата-центра — встаёт вопрос доверия: а что мешает владельцу этого хранилища, его сотруднику или взломщику прочитать ваши данные? Ответ должен быть «ничего не мешает, но и не поможет» — если бэкап зашифрован правильно. Разберём, как выстроить схему доверия для бэкапа на чужой инфраструктуре и на какой грабле спотыкаются даже те, кто всё сделал технически верно.

Модель доверия: кто должен видеть ваши данные

Когда бэкап уходит наружу, есть только два честных варианта модели доверия. Первый: вы доверяете провайдеру хранилища не только сохранность байтов, но и их содержимое — он технически может прочитать ваши данные, даже если обещает не делать этого. Второй: вы доверяете провайдеру только сохранность байтов, а содержимое ему физически недоступно. Второй вариант — единственный, который стоит использовать для чего-либо чувствительного: конфигов с секретами, дампов баз с персональными данными, ключей, документов.

Ключевой принцип реализации второго варианта прост в формулировке и часто нарушается на практике: шифрование должно происходить на стороне отправителя, то есть на вашем собственном сервере, до того как данные покинут его пределы. Не на стороне провайдера хранилища — «шифрование на сервере хранения» означает, что у него есть ключ, а значит и техническая возможность расшифровать. Не в процессе передачи — TLS защищает канал, но канал заканчивается на диске провайдера, где данные снова лежат в открытом виде, если шифрование было только транспортным. Правильно — данные превращаются в зашифрованный блок ещё до того, как покидают вашу машину, и уже в таком виде путешествуют по сети и оседают на чужом диске.

Из этого принципа следует практическое правило: провайдер хранилища должен физически хранить только непрозрачный зашифрованный блок данных. Он не участвует в шифровании, не видит ключ, не имеет технической возможности расшифровать содержимое даже по требованию — потому что у него просто нет соответствующего секрета. Это снимает с него саму возможность нарушить конфиденциальность, случайно или намеренно, и снимает с вас необходимость верить его политикам, а не архитектуре.

Как это выглядит в инструментах резервного копирования

Реализовывать шифрование вручную — накатывать OpenSSL на архив перед отправкой, писать обвязку с gpg — можно, но специализированные инструменты резервного копирования давно решили эту задачу «из коробки». Клиентское шифрование перед отправкой в удалённое хранилище — стандартная функция современных бэкап-утилит: репозиторий инициализируется с паролем или ключевым файлом, и дальше все объекты, которые в него попадают, шифруются локально ещё до передачи по сети, будь то SSH, S3-совместимый протокол или другой транспорт.

Практическая механика везде похожая, хоть детали различаются между инструментами и их версиями: при первом запуске создаётся зашифрованный репозиторий с мастер-ключом или паролем, дальше каждый файл или блок данных при бэкапе шифруется на месте, и в удалённое хранилище уходит уже нечитаемый снаружи набор объектов. Восстановление работает в обратную сторону — данные скачиваются в зашифрованном виде и расшифровываются локально тем же ключом. Про пошаговую настройку одного из таких инструментов на VPS — как установить и настроить бэкап с шифрованием на VPS, там разобрана механика на конкретном примере с командами.

Важная деталь: удалённое хранилище в этой схеме — просто DAT-хранилище байтов. Ему не нужно ничего знать о содержимом, не нужны доверенные вычисления на его стороне, не нужен доступ к вашей инфраструктуре. Это может быть объектное хранилище любого провайдера, обычный VPS с местом на диске, даже недорогой холодный тариф — требование к нему одно: надёжно хранить блоки и отдавать их по запросу. Сравнение самих инструментов клиентского шифрования — в статье restic или borgbackup: что выгоднее и когда.

Что реально видит провайдер удалённого хранилища

Если схема выстроена правильно, провайдер видит набор файлов со случайными на вид именами или единый блочный репозиторий, метаданные о размере и времени изменения объектов, и объём трафика при передаче. Он не видит: имена ваших реальных файлов и каталогов, содержимое дампов баз, конфигурационные секреты, пароли и токены, которые попали в бэкап. Даже если провайдер полностью скомпрометирован — взломан, недобросовестен, обязан по закону выдать данные третьей стороне — он физически может отдать только зашифрованный блок. Расшифровать его без ключа с текущими алгоритмами шифрования, которые используют актуальные инструменты бэкапа, на практике невозможно за разумное время.

Это снимает целый класс рисков, специфичных именно для чужой инфраструктуры: инсайдер провайдера, который просматривает диски клиентов; утечка при взломе самого хранилища; ошибка конфигурации на стороне провайдера, которая на время открывает доступ к чужим бакетам; юрисдикционные риски, когда данные физически лежат в стране с иными законами о доступе к информации. Ни один из этих сценариев не даёт атакующему ничего полезного, если ключ шифрования никогда не покидал вашу инфраструктуру.

Отдельно стоит понимать, что провайдер хранилища в этой модели не обязан быть особо доверенным сам по себе — задача выбора места хранения смещается от «кому я доверяю свои данные» к «кто надёжно хранит байты и не теряет их». Разница между объектным хранилищем и обычной файловой системой для этой задачи разобрана в статье объектное хранилище против файловой системы — для зашифрованного бэкапа подходит и то, и другое, выбор скорее про удобство интеграции и стоимость.

Критический риск: как зашифровать себя от собственных данных

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

Сценарий выглядит так на практике: сервер полностью выходит из строя — сгорел диск, недоступен дата-центр, скомпрометирован и переустановлен с нуля, — и вместе с ним пропадает файл с паролем от репозитория бэкапа, который лежал там же, «для удобства». Зашифрованный архив на удалённом хранилище на месте, цел, доступен по сети — и абсолютно бесполезен, потому что расшифровать его нечем. Вы буквально защитили бэкап от посторонних глаз настолько хорошо, что сами оказались в их числе.

Второй вариант того же риска — не потеря сервера, а потеря или забывание самого ключа человеком: пароль был только в голове или в одной заметке, которую случайно удалили, сотрудник, который его знал, уволился и не передал доступ. Итог идентичен первому сценарию: данные физически существуют, но необратимо недоступны. С современными алгоритмами шифрования восстановить содержимое без ключа перебором на практике нереально — это не баг, а именно то, ради чего всё затевалось, только развёрнутое против вас самих.

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

Где хранить ключ, чтобы не повторить эту ошибку

Единственное системное решение — хранить ключ шифрования отдельно и надёжно, в месте, не зависящем от того же сервера, который бэкапится. «Отдельно» здесь ключевое слово: если ключ лежит на том же диске, в том же дата-центре, у того же провайдера, что и защищаемые данные, единая точка отказа никуда не делась, просто спряталась на шаг дальше.

Практические варианты хранения ключа, от простого к более защищённому:

• Менеджер паролей (в том числе самостоятельно размещённый, вроде Vaultwarden) — удобно для команды, есть история изменений, доступ можно выдавать и отзывать. Про бэкап и восстановление такого менеджера — в статье Vaultwarden: бэкап и восстановление паролей, да, ключ от бэкапов тоже стоит бэкапить, только отдельно от основных данных.
• Физически отдельный защищённый носитель — зашифрованная флешка в сейфе, распечатанный ключ в конверте у нескольких доверенных людей (принцип «раздельного хранения секрета» между несколькими держателями снижает риск и утраты, и единоличного доступа).
• Специализированное хранилище секретов — Vault, облачный KMS, менеджер секретов инфраструктуры, если у вас уже есть такая система для других целей.
• Второй, запасной ключ к тому же репозиторию, если инструмент это поддерживает — многие бэкап-утилиты позволяют завести несколько независимых паролей к одному хранилищу, и разумно добавить второй заранее, пока есть доступ, а не когда единственный уже потерян.

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

Практическая схема: как это собрать целиком

Соберём принципы в конкретную последовательность действий для сервера, который бэкапится на чужое хранилище:

# 1. На исходном сервере — инициализация зашифрованного репозитория
export RESTIC_REPOSITORY=s3:https://s3.example-storage.com/my-backup-bucket
export RESTIC_PASSWORD_FILE=/root/.restic-pass
echo "длинный-случайный-пароль-не-менее-20-символов" > /root/.restic-pass
chmod 600 /root/.restic-pass
restic init

# 2. Сразу же — копия пароля в независимое место
# (менеджер паролей, второй носитель — НЕ файл рядом на этом же сервере)

# 3. Добавить запасной ключ, пока есть доступ
restic key add
# ввести второй пароль, сохранить его отдельно от первого

# 4. Регулярный бэкап по расписанию (cron)
restic backup /etc /var/lib/postgresql/backups /home/app/config

# 5. Периодическая проверка — не самого факта бэкапа, а возможности восстановления
restic check
restic restore latest --target /tmp/restore-test --path /etc

Обратите внимание на порядок: шаг 2 идёт сразу после инициализации, а не «когда-нибудь потом». Именно между шагами 1 и 2 чаще всего теряют пароль — репозиторий уже создан, бэкапы уже идут, а копия ключа так и осталась только в файле на сервере, потому что руки до менеджера паролей не дошли.

Шаг 5 закрывает второй практический риск, отдельный от потери ключа: даже с ключом на руках бэкап может не восстановиться, если сам процесс копирования был настроен неверно — не те каталоги, несогласованный дамп базы, повреждённые объекты. Тестовое восстановление — единственный способ убедиться, что вся цепочка рабочая, а не только «бэкапы вроде идут». Если для бэкапов важен выбор самой площадки хранения — сравнение вариантов под конкретный сценарий разобрано в статье VPS для бэкапов и архива: что выбрать и как настроить.

Частые вопросы