Невидимые резервные копии: что это и как спрятать бэкап

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

Теневые копии Windows: невидимые, но не защищённые

Служба теневого копирования томов (Volume Shadow Copy Service, VSS) в Windows умеет делать снимки диска в определённые моменты времени. Эти снимки не видны как отдельные файлы в проводнике, но через свойства папки («Предыдущие версии») можно вернуть файл на состояние, сохранённое в снимке. На серверах Windows теневые копии общих папок часто включают для того, чтобы пользователи сами восстанавливали случайно удалённые документы.

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

Почему обычные бэкапы погибают вместе с данными

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

Четыре способа сделать бэкап невидимым для атакующего

1. Pull вместо push: сервер копий сам забирает данные

В схеме push основной сервер отправляет копию в хранилище и, значит, знает, где оно и как в него писать. В схеме pull отдельный сервер копий сам подключается к основному по расписанию, забирает данные и складывает у себя. Основной сервер не имеет учётных данных для доступа к хранилищу копий и даже не знает его адрес. Захватив основной сервер, злоумышленник не найдёт там ничего, что вело бы к бэкапам.

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

2. Неизменяемые хранилища (immutable)

Многие объектные хранилища, совместимые с S3, поддерживают блокировку объектов (Object Lock): записанный файл нельзя удалить или перезаписать до окончания заданного срока, даже имея ключи доступа. Если в режиме строгой блокировки задан срок 30 дней, у злоумышленника, укравшего ключи, не получится уничтожить копии за этот период. Похожий эффект дают инструменты резервного копирования в режиме «только добавление» (append-only): клиент может добавлять новые копии, но не может удалить старые.

• Проверьте, поддерживает ли ваш облачный провайдер в России блокировку объектов и в каком режиме.
• Срок блокировки выбирайте больше, чем время, за которое вы гарантированно заметите атаку: обычно 14–30 дней.
• Учитывайте стоимость: заблокированные копии нельзя удалить раньше срока, и вы платите за их хранение.

3. Отдельный контур учётных записей

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

4. Офлайн-копия: последний рубеж

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

Пример схемы для небольшой компании

Условная компания: 25 сотрудников, сервер с 1С и общими папками в офисе, сайт и CRM на VPS у российского хостера.

Бюджет такой схемы для малого бизнеса — небольшой сервер копий или виртуальная машина, объектное хранилище на десятки или сотни гигабайт и пара внешних дисков. Настройка занимает несколько дней работы администратора. Это несопоставимо с ценой простоя и выкупа.

Проверка: копия, которую не восстанавливали, не существует

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

• Проверяйте, что в копию попадает всё нужное: база, файлы, вложения, настройки.
• Измерьте реальное время восстановления (RTO) и сравните с тем, сколько бизнес может простоять.
• Проверьте, что копии зашифрованы, а ключ хранится отдельно от копий и не потерян.
• Убедитесь, что уведомления об ошибках резервного копирования приходят живому человеку.

Резервные копии и персональные данные

Бэкап клиентской базы — тоже база персональных данных. На него распространяются требования 152-ФЗ: хранение в России, защита, ограничение доступа. Незашифрованная копия, утёкшая из облачного хранилища, — такая же утечка, как взлом CRM, со штрафами, которые с 2025 года зависят от числа пострадавших. Поэтому шифруйте копии до отправки в хранилище и выбирайте хранилище в российском дата-центре. Подробнее — в статье об оборотных штрафах за утечку ПДн.

Частые ошибки

• Считать теневые копии или корзину облачного диска полноценным бэкапом.
• Хранить ключи доступа к хранилищу копий на защищаемом сервере.
• Держать сервер копий в том же домене Windows с теми же администраторами.
• Перезаписывать единственную копию каждую ночь: зашифрованные данные перезапишут чистые.
• Не проверять восстановление годами.
• Забыть про сайт и CRM у хостера, полагаясь на «бэкапы хостинга» без проверки, где они хранятся и как их восстановить.

Как проверить, видит ли атакующий ваши бэкапы

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

1. Видит ли он сетевые диски или папки, куда пишутся копии?
2. Есть ли на сервере ключи, пароли или токены доступа к облачному хранилищу копий?
3. Использует ли администратор один и тот же пароль для сервера и для панели хранилища?
4. Может ли он удалить копии через консоль хостинга, если войдёт в почту администратора?
5. Сколько дней хранятся копии и успеете ли вы заметить атаку за этот срок?
6. Где лежит последняя копия, до которой невозможно дотянуться по сети, и сколько ей дней?

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

Общие принципы — правило 3-2-1, глубину хранения, RPO и RTO — мы разбирали в статье как настроить резервные копии. Что делать, если атака уже произошла, — в плане шифровальщик в компании: первые 24 часа. Если нужно построить схему бэкапов, которую шифровальщик не достанет, или проверить существующую, напишите нам: это входит в аудит безопасности и техническую поддержку.