rclone crypt: клиентское шифрование бэкапов в S3 и ротация ключей

Клиентское шифрование бэкапов – это базовая гигиена безопасности для админов, девопсов и веб-мастеров. Даже если S3-провайдер обещает «надёжное хранение» и серверное шифрование, последний рубеж контроля остаётся за вами. В экосистеме Linux простой и зрелый способ зашифровать резервные копии перед отправкой в S3 – это связка rclone + crypt. Ниже – практика от нуля до продовой ротации ключей: как построить схему, как жить с ней в эксплуатации и что делать, когда пришло время менять ключи.

Зачем crypt поверх S3 и в чём модель угроз

rclone crypt реализует шифрование на стороне клиента: файлы шифруются до передачи в облако, так что провайдер видит только шум, а при правильной настройке – даже не видит исходных имён файлов и директорий. Это снижает риски при:

• ошибках в правах доступа к бакету или утечке облачных ключей;
• внутренних инцидентах у провайдера;
• регуляторных запросах, если доступ к бакету возможен без вашей воли;
• переносе бэкапов между провайдерами/регионами.

Важно помнить ограничения: шифрование не скрывает объём, количество объектов и время модификации; за метаданные отвечает ваша политика. Также шифрование не заменяет контроль доступа к аккаунту и сетевую изоляцию.

Политика ключей и ротация: спланировать до внедрения

Перед тем как нажимать клавиши, договоритесь с собой и командой о правилах:

• Как часто ротируем ключи/пароли для crypt (например, ежегодно или при смене ответственных)?
• Где храним секреты (менеджер паролей, офлайн-сейф, процедурная распечатка)?
• Как документируем и тестируем процедуру восстановления при утере ключа?
• Как будем валидировать перенос на новые ключи (полная проверка, выборочная, контрольные суммы)?
• Сколько времени держим два комплекта бэкапов (старый префикс и новый) до утилизации?

У rclone crypt ключи выводятся из заданных паролей; менять пароль – означает пере-шифровать весь объём. Поэтому план ротации должен учитывать время и стоимость повторной передачи данных (или как минимум чтения).

Схема: два удалённых хранилища – S3 и поверх него crypt

Rclone строится на идее «удалённого» (remote). Мы объявляем:

1. «Чистый» s3-remote – доступ к бакету/префиксу.
2. «Шифрованный» crypt-remote – который использует первый как бэкенд.

Работать будем всегда через crypt, чтобы данные ни разу не ушли в облако в открытом виде. Для ротации создадим второй crypt-remote с новыми паролями – и выполним пере-шифровку копированием между crypt-remotes.

Установка и первичная проверка rclone

Проверьте, что в системе актуальная версия rclone (особенно если используете продвинутые опции S3):

rclone version
rclone help

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

Создаём S3-remote

Используем интерактивный конфигуратор. Он сохранит параметры в ~/.config/rclone/rclone.conf. Минимально нужны ID/secret, регион, бакет и префикс:

rclone config

Рекомендуемые практики:

• Выдавайте для бэкапов отдельного пользователя в S3 с минимальными правами и ограничением по бакету/префиксу.
• Включите версионирование бакета и политику life-cycle на удаление старых версий/старых бэкапов, согласуя сроки хранения.
• Рассмотрите серверное шифрование бакета как дополнительный (но не альтернативный) слой.

Создаём crypt-remote поверх S3

Запустите конфигуратор снова и добавьте crypt:

rclone config

Ключевые параметры crypt:

• Путь к underlying remote: например, s3:backups/projectA.
• Режим шифрования имён: рекомендуется «стандартный» с шифрованием имён и директорий.
• Два пароля: основной и для имён (в rclone это два отдельных секрета). Оба следует хранить одинаково надёжно.

Проверьте, что из команды (или ci-лога) не утекут пароли. Не используйте их как аргументы командной строки. По умолчанию rclone хранит секреты «обскуренными» в конфиге (реверсивно), поэтому защитите весь конфиг паролем:

rclone config
# Выберите пункт для установки пароля на конфиг (configuration password)
rclone config file

В автоматизации применяйте переменную окружения для разблокировки конфига: RCLONE_CONFIG_PASS. Значение храните во внешнем секрете и не логируйте.

Базовая задача бэкапа

Простейшая схема – синхронизировать локальную директорию с шифрованным remote. Внимание к флагам: --delete-excluded и прочие опции могут навредить, если вы не уверены в правилах исключений.

# Сухой прогон
rclone sync /srv/data crypt:daily --dry-run --progress --stats 30s

# Боевая синхронизация
rclone sync /srv/data crypt:daily --transfers 8 --checkers 16 --progress --stats 30s

Для каталогов с большим количеством мелких файлов подумайте о бандлировании (архивация перед заливкой) или настройке параллелизма – это разгрузит API S3 и ускорит прохождение окна бэкапа.

Файлы исключений и фильтры

Удерживайте мусор вне бэкапа: кеши, временные файлы, сборочные артефакты. Для этого удобно использовать --exclude-from:

# пример запуска с файлом исключений
rclone sync /srv/data crypt:daily --exclude-from /etc/rclone/backup.exclude --progress

Проверка целостности и тест восстановления

Периодическая валидация – обязательна. Идеально – «чтение и сверка». Для crypt на S3 у многих провайдеров недоступны криптографические хэши на стороне объекта, поэтому используйте принудительную проверку «скачать и сравнить» на выборке данных или полностью согласно SLO/ритмам:

# Выборочная проверка по маске
rclone check crypt:daily /srv/data --one-way --download --max-backlog 1000 --progress

# Тестовое восстановление в песочницу
rclone copy crypt:daily /tmp/restore-test --progress

Минимум раз в квартал выполняйте полноценное восстановление критичных директориях в изолированную среду и убедитесь, что сервисы запускаются. Для автоматизации мониторинга и сверок посмотрите материал «проверка и мониторинг бэкапов rclone на VDS» – подробный разбор настройки cron, логов и алертов.

Ротация ключей: стратегия без простоя

Ротация ключей в rclone crypt – это создание нового crypt-remote с новыми паролями и «пере-шифрование» данных копированием из старого remоte в новый. Серверной копии на стороне S3 для этой задачи недостаточно: нужно расшифровать старым ключом и зашифровать новым на клиенте.

Подготовка

1. Создайте второй crypt-remote, назовём его crypt_new, указывающий на другой префикс бакета (например, s3:backups/projectA-rotated) и с новыми паролями.
2. Зафиксируйте текущие бэкапы: выполните финальный sync в старый remote.
3. Оцените объём и окно: ротация потребует чтения всего объёма и его повторной заливки.

Копирование с пере-шифровкой

# Копируем всё содержимое, decrypt->encrypt на лету
rclone copy crypt:daily crypt_new:daily --transfers 8 --checkers 16 --progress --stats 30s

# При больших объёмах запускайте по уровням: daily, weekly, monthly
rclone copy crypt:weekly crypt_new:weekly --progress
rclone copy crypt:monthly crypt_new:monthly --progress

Параметры параллелизма подберите опытным путём, учитывая лимиты S3 и полосу. На особо больших объёмах полезно «размазывать» ротацию пачками по префиксам.

Верификация

Сравнить «старое» и «новое» прямо между двумя crypt-remotes можно так:

# Вариант со скачиванием для надёжности
rclone check crypt:daily crypt_new:daily --download --progress

Дождитесь чистого отчёта. Отдельно проверьте восстановление приложений из crypt_new на тестовой среде.

Переключение и утилизация

1. Переключите ваши задания sync/copy на crypt_new.
2. Держите оба набора бэкапов столько, сколько требует политика (например, 30 дней).
3. После дедлайна удалите старый префикс: вручную или через политику life-cycle в бакете.

Никогда не публикуйте и не логируйте пароли от старого crypt – при утилизации пересмотрите доступы и удалите все копии записей со старыми секретами.

Безопасность секретов rclone

Несколько правил, которые спасают от инцидентов:

• Файл rclone.conf храните с правами 600 и под отдельным пользователем.
• Включите пароль на конфиг и задавайте его через RCLONE_CONFIG_PASS из безопасного источника окружения (systemd EnvironmentFile, менеджер секретов).
• Не передавайте пароли аргументами командной строки (они попадают в историю и мониторы процессов).
• Отключите избыточное логирование в проде: -vv используйте только для отладки.
• Резервируйте сам файл конфигурации и план восстановления (иначе потеря пароля = потеря бэкапов).

Производительность и надёжность передачи

Для S3-провайдеров с высокими RTT и/или ограничением RPS полезно аккуратно настраивать параллелизм и размер потоков. Общие приёмы:

• Балансируйте --transfers и --checkers под свою сеть и лимиты API.
• Разделяйте бэкапы по префиксам, чтобы ускорить листинг и проверки.
• Учитывайте «окна бэкапа»: планируйте в периоды низкой нагрузки.
• При проблемах сети используйте --retries, --low-level-retries, --timeout и --contimeout.

Подробный разбор низкоуровневых параметров см. в статье про тюнинг multipart и параллелизма в rclone для S3. Если ротация и бэкапы нагружают прод, вынесите их на отдельный VDS и управляйте окнами синхронизации отдельно.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Восстановление из шифрованного бэкапа

Наличие правильных паролей crypt – обязательное условие. Дальше восстановление выглядит обычно:

# Посмотреть содержание каталога на удалёнке
rclone ls crypt:daily

# Восстановить каталог в рабочее место
rclone copy crypt:daily/www /srv/www-restore --progress

Если при восстановлении видите «бессмысленные» имена файлов – вероятно, crypt-remote настроен с иными паролями или неверно указан префикс. Исправьте конфигурацию и перепроверьте.

Частые ошибки и как их избежать

• Забыли защитить конфиг паролем. Исправление: включите пароль на конфиг и перевыпустите секреты, которые могли утечь.
• Шифрование имён выключено. Метаданные видны провайдеру. Исправление: создайте новый crypt с шифрованием имён и выполните ротацию.
• Ротация «серверной копией» внутри S3. Это не меняет ключи, данные останутся зашифрованы старым набором. Делайте копию через два crypt-remotes.
• Недооценка времени ротации. Оцените объём, пропускную способность, сделайте поэтапную ротацию и верификацию.
• Слишком агрессивный sync при ошибках сети. Настройте таймауты и ретраи, используйте copy вместо sync для консервативных этапов.

О политике хранения и соответствия требованиям

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

Итого

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