Неизменяемый бэкап против шифровальщиков: почему 3-2-1 больше не спасает

Восемь лет чиню чужие последствия шифровальщиков. И знаете, что удивляет клиентов больше всего? Не сам факт взлома. А то, что вирус добрался и до бэкапов. «У нас же было правило 3-2-1!» — говорят мне. Было. Только вирусу это правило совершенно не мешало.

Что не так с классическим правилом 3-2-1

Три копии данных, на двух разных носителях, одна вне офиса. Правило придумали в эпоху, когда главной угрозой был пожар, залив или дурак с ногой, задевшей провод питания сервера. От физической катастрофы оно спасает прекрасно. От целенаправленной атаки — нет.

Проблема простая. Если бэкап доступен на запись из той же сети, где сидит шифровальщик, он его найдёт. Современные штаммы — LockBit, Akira, разные их клоны — первым делом сканируют сеть на предмет NAS, папок с расшариванием, агентов Veeam. Не потому что кто-то специально их так написал против вас. Это дефолтное поведение любого серьёзного шифровальщика последних лет. Шифрование самих файлов — это уже вторая фаза. Первая — зачистка путей отступления.

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

Как шифровальщик охотится именно за бэкапами

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

Технически это делается через уже знакомые нам инструменты. Vssadmin delete shadows — команда, убивающая теневые копии Windows, встроена буквально в каждый второй скрипт шифровальщика. Дальше идёт поиск примонтированных сетевых дисков, поиск агентов резервного копирования по именам процессов (тот же Veeam Agent, Acronis, Bacula), попытка получить доступ к консоли управления бэкапами — а если она защищена тем же паролем администратора домена, что и всё остальное, считайте, что защиты нет вообще.

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

Что такое неизменяемый бэкап на самом деле

Immutable backup — это резервная копия, которую физически нельзя изменить или удалить в течение заданного срока, даже если у злоумышленника есть полные права администратора на всю вашу инфраструктуру. Ключевое слово — физически. Не «политика запрещает», а именно техническая невозможность.

Работает это через объектное хранилище с режимом object lock (S3-совместимые хранилища вроде Wasabi, Backblaze B2, тот же Yandex Object Storage поддерживают WORM — write once, read many), либо через специализированное хранилище с аппаратной защитой от записи, либо через ленточные накопители с офлайн-хранением — да, старая добрая лента снова в моде, потому что если кассета физически лежит в сейфе, никакой хакер до неё по сети не доберётся.

В Veeam Backup & Replication, который у нас стоит у большинства клиентов, за это отвечает Hardened Repository — репозиторий на Linux-сервере с иммутабельностью на файловой системе через атрибут immutable в XFS. Настраивается один раз, задаётся срок неизменяемости — у нас обычно 14 дней, этого хватает, чтобы обнаружить атаку и успеть восстановиться раньше, чем период истечёт. Даже если злоумышленник получит root на этом сервере, удалить файлы бэкапа за отведённый период он не сможет. Ядро операционной системы физически откажет в этой операции.

Почему одной иммутабельности тоже мало

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

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

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

Сколько это стоит и кому реально нужно

Тут возникает закономерный вопрос от директора клиники или юрфирмы на 15-20 рабочих мест: а мне это точно надо, или это для банков и госструктур? Отвечаю честно — надо всем, у кого есть база 1С, картотека клиентов или медицинские данные, потеря которых остановит бизнес больше чем на день. Средний простой после серьёзной шифровальщицкой атаки без нормального бэкапа — от пяти до пятнадцати рабочих дней. Посчитайте сами упущенную выручку за этот срок и сравните с ценой защиты.

По деньгам это не космос. Лицензия Veeam на настройку с Hardened Repository для компании до 50 рабочих мест — обычно укладывается в 60-90 тысяч рублей разово плюс работы по настройке. Объектное хранилище с immutable в облаке — от 3 до 8 тысяч рублей в месяц в зависимости от объёма данных, у нас клиенты с базой 1С на 200-300 ГБ укладываются в нижнюю границу. Сравните с суммой выкупа, который сейчас просят за малый бизнес — от 300 тысяч до пары миллионов рублей, и это без гарантии, что после оплаты вообще что-то расшифруют.

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

С чего начать, если у вас пока просто внешний диск

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

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

Мы у себя в «АйТи-Фреш» такой аудит бэкапной инфраструктуры делаем как отдельную услугу — обычно за один-два выезда становится понятно, где дыра, и во сколько обойдётся её закрыть. Дешевле, чем узнавать это после реального шифрования.

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

Достаточно ли просто хранить бэкап на внешнем жёстком диске, который отключают от компьютера?
Физически отключённый диск — это тоже своего рода air gap, и он действительно защищает от шифровальщика, пока диск отсоединён. Проблема в человеческом факторе: диск часто забывают отключать, или он подключён по расписанию именно в момент атаки. Immutable-хранилище снимает эту зависимость от дисциплины сотрудника.

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

Сколько времени должна храниться неизменяемость бэкапа?
Мы обычно ставим 14 дней как разумный минимум — этого хватает, чтобы обнаружить скрытое присутствие вируса в сети и восстановиться из чистой копии. Для более чувствительных данных, например медицинских, разумно увеличить до 30 дней.

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