Бэкапы зашифровали вместе с боевыми данными: как этого избежать

MAATRIX

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

Как шифровальщик добирается до бэкапов

Современный шифровальщик редко ограничивается тем диском, на который попал изначально. После получения доступа — через слабый пароль на RDP, фишинг или уязвимый сервис — вредонос почти всегда проводит разведку: смотрит примонтированные сетевые диски, сохранённые подключения, доступные шары. Если на заражённом хосте есть буква диска Z:\ или точка монтирования /mnt/backups, ведущая на бэкап-хранилище, шифровальщик пройдёт по ней точно так же, как по локальному C:\ или /var.

Условия, при которых это происходит чаще всего:

• Бэкап-хранилище примонтировано постоянно, а не только на время выполнения задачи бэкапа. SMB-шара в fstab или Windows-диск, подключённый через "Подключить сетевой диск" с сохранением пароля, — открытая дверь 24/7, даже если бэкап пишется туда раз в сутки.
• Одни и те же учётные данные используются для входа на сервер и для доступа к хранилищу бэкапов. Скомпрометировав пароль от сервера, атакующий автоматически получает пароль и от бэкапов.
• Хранилище даёт право на запись и удаление, а не только на чтение старых копий или дозапись новых. Шифровальщику для порчи файла нужна именно возможность записи — того же права, которое требуется штатному процессу бэкапа, чтобы класть новые архивы.
• Нет временного разрыва между сервером и хранилищем. Если оба всегда в сети и всегда видят друг друга, у вредоноса есть сколько угодно времени — он не спешит, шифрование может идти часами в фоне, пока его не заметят по нагрузке на диск.

Похожий сценарий, только без злого умысла, разбирали в статье про хранилище бэкапов, доступное продакшену на запись — там NFS-экспорт с правом rw привёл к тому, что чужой cron-джоб случайно вычистил копии. С шифровальщиком механика та же: если что-то на проде технически может писать в бэкап-хранилище, рано или поздно туда что-то напишет.

Почему принцип 3-2-1 — это не про количество копий

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

Для защиты именно от шифровальщика правило стоит читать не как «три копии», а как «хотя бы одна копия физически или логически недостижима с продакшена в момент атаки». Это добавляет к классическому 3-2-1 ещё одно требование, которое иногда называют 3-2-1-1-0:

Разбор классического 3-2-1 с бюджетными вариантами реализации есть в статье про правило 3-2-1 для бэкапов недорого — там про то, как уложиться в скромный бюджет, не жертвуя изоляцией. Здесь же добавляем именно антиransomware-часть: копия, до которой шифровальщик физически не дотянется, даже если получит root на продакшене.

Immutable-хранилища: когда даже администратор не может стереть бэкап раньше времени

Immutable (неизменяемое) или write-once хранилище — это место, куда можно записать данные, но нельзя их изменить или удалить до истечения заданного срока, даже обладая полными правами на сервере, откуда идёт запись. Технически это реализуется по-разному:

Object Lock в S3-совместимых хранилищах. Большинство современных S3-совместимых провайдеров поддерживают режим object lock с политикой retention: объект, загруженный с такой меткой, физически нельзя перезаписать или удалить до истечения срока — ни через API, ни через консоль, ни с правами root на сервере-клиенте, потому что запрет применяется на стороне хранилища, а не на стороне того, кто пишет. Даже украв ключи доступа к бакету, атакующий не сможет удалить уже помеченные объекты — максимум помешает записи новых.

Append-only режим в специализированных инструментах бэкапа. BorgBackup поддерживает режим --append-only для репозитория: клиент с таким доступом может добавлять новые архивы, но не может удалять старые записи или менять историю — операции prune и delete для него просто недоступны на уровне протокола. Настраивается через отдельного SSH-пользователя на бэкап-сервере с ограниченным authorized_keys:

# authorized_keys на бэкап-сервере, для пользователя append-only
command="borg serve --append-only --restrict-to-path /mnt/backups/prod",restrict ssh-ed25519 AAAA...

Полное удаление старых архивов (например, ротацию по возрасту) в такой схеме выполняет отдельный процесс на самом бэкап-сервере, с локальными правами — не с продакшена. restic устроен похоже: репозиторий можно открыть в режиме, где клиент только пишет снапшоты, а forget/prune выполняются локально на хранилище отдельным заданием.

Файловая система только для чтения на уровне снапшотов. Если бэкап-сервер использует ZFS или Btrfs, можно брать снапшот сразу после записи бэкапа и переключать его в read-only — тогда даже компрометация самого бэкап-сервера (не только продакшена) не даст стереть уже сделанные снапшоты без явного снятия защиты вручную.

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

Изолированный бэкап-сервер: почему pull лучше push

Даже без immutable-режима сильно снижает риск архитектура, где бэкап-сервер физически не даёт продакшену прав на запись или удаление. Два принципиальных варианта организации потока данных:

Push-модель (продакшн сам отправляет данные на бэкап-сервер) — удобнее в настройке, но требует, чтобы у продакшн-хоста были учётные данные с правом записи в хранилище. Если продакшн скомпрометирован, скомпрометированы и эти учётные данные.

Pull-модель (бэкап-сервер сам подключается к продакшену и забирает данные) — учётные данные для доступа к хранилищу вообще не существуют на продакшн-хосте. У продакшена в лучшем случае есть read-only доступ для снятия дампа, а инициатива и права на запись бэкапа остаются полностью на стороне изолированного сервера.

Pull-модель избавляет от необходимости доверять продакшн-хосту вообще — а именно он в сценарии шифровальщика и есть скомпрометированная сторона. Практическая реализация на Linux: бэкап-сервер по расписанию сам заходит по SSH с ограниченным ключом (command="pg_dump ..." или аналог) и забирает дамп, либо использует rsync --daemon в режиме только для чтения с продакшена. Ключевое условие — на продакшн-сервере должен быть только ключ или пароль для чтения нужных данных, но не для доступа к самому бэкап-хранилищу.

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

Практическая настройка: минимальный набор для VPS

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

1. Отдельные учётные данные для каждого направления. Пользователь на бэкап-сервере, под которым продакшн пишет бэкапы, не должен иметь права rm, prune, delete — только добавление новых архивов.

# создаём ограниченного пользователя на бэкап-сервере
useradd -m -s /usr/sbin/nologin backupwriter
mkdir -p /home/backupwriter/.ssh
# в authorized_keys — ключ продакшена с ограничением команды
echo 'command="borg serve --append-only --restrict-to-path /mnt/backups/prod",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... prod-key' \
  > /home/backupwriter/.ssh/authorized_keys
chown -R backupwriter:backupwriter /home/backupwriter/.ssh
chmod 700 /home/backupwriter/.ssh && chmod 600 /home/backupwriter/.ssh/authorized_keys

1. Никаких постоянно смонтированных дисков бэкапов на продакшене. Если сейчас каталог с бэкапами смонтирован через fstab или сохранённое сетевое подключение Windows — уберите постоянное монтирование, оставьте только временное подключение на время самой операции бэкапа с последующим отключением, либо вовсе перейдите на pull-модель, где ничего монтировать не нужно.

1. Отдельная ротация на стороне хранилища, не на стороне продакшена. Скрипт, который решает, какие старые архивы удалить, должен выполняться локально на бэкап-сервере под учёткой с полными правами — а не приходить командой с продакшена.

# на бэкап-сервере, отдельным cron под привилегированным локальным пользователем
0 4 * * * root borg prune --keep-daily=14 --keep-weekly=8 --keep-monthly=6 /mnt/backups/prod

1. Ограничение сети firewall'ом. На бэкап-сервере закрыть входящие подключения от продакшн-хоста ко всему, кроме нужного порта SSH/rsync, и явно запретить исходящие с прода к бэкап-серверу, кроме этого же направления (если используете pull-модель, то с прода вообще ничего инициировать не нужно).

1. Мониторинг аномального изменения объёма. Резкий рост объёма записанных данных за короткое время (шифрование меняет содержимое файлов, а инструменты дедупликации вроде restic и borg при этом видят почти 100% "новых" блоков) — сильный косвенный сигнал, что на проде что-то шифрует файлы прямо сейчас. Такой алерт полезно завести отдельно от алерта «бэкап-джоб упал».

Отдельно стоит помнить: шифрование самого бэкапа (--encryption=repokey в borg, restic init с паролем) защищает от кражи содержимого при утечке хранилища, но не от порчи или удаления файлов — это разные угрозы, и immutable-режим с ротацией нужен независимо от того, шифруете вы содержимое бэкапа или нет.

Регулярное тестирование восстановления — без него всё остальное не считается

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

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

• Раз в месяц — полное восстановление одного случайно выбранного бэкапа на отдельный тестовый сервер, с проверкой, что сервис реально стартует и данные читаются (для базы — что видны актуальные строки, а не пустая схема).
• После любого изменения в схеме бэкапа (смена версии инструмента, миграция на новое хранилище, смена ключа шифрования) — внеплановая проверка сразу же, не дожидаясь месячного цикла.
• Хронометраж восстановления. Помимо факта «восстановилось», фиксируйте, сколько времени заняло полное восстановление — это отдельная метрика для RTO (Recovery Time Objective), которая обычно оказывается больше, чем кажется на бумаге, особенно если бэкап лежит на медленном внешнем хранилище или его нужно предварительно скачивать целиком.

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

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