Шифровальщик зашифровал и бэкап 1С вместе с базой: схема 3-2-1-1

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

ночь, когда бухгалтерия увидела вместо базы файлы .locked

В пятницу в 19:40 главный бухгалтер оптовой компании на 40 пользователей — типичный интернет-магазин строительных материалов из Подмосковья — открывает 1С, чтобы закрыть месяц до выходных. Вместо привычного списка баз на экране список файлов с расширением .locked и текстовый файл с требованием выкупа в криптовалюте. Она звонит системному администратору, который обслуживает компанию по договору на несколько часов в месяц. Тот заходит на сервер по RDP и видит то же самое: зашифрован диск C:, зашифрован диск D:, где как раз лежала папка с ежедневными резервными копиями .dt. Расписание бэкапов работало исправно почти два года — планировщик заданий Windows каждую ночь честно создавал новый файл, никто ни разу не получал ошибку. Просто копии оказались там же, куда в итоге дотянулся вирус.

почему копия сгорела вместе с базой

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

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

цена одной ночи в деньгах и днях

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

Восстановление вручную из разрозненных копий, сверка остатков по бумагам и ручной ввод утраченных документов заняли у приглашённого сисадмина больше рабочего дня по ставке сопровождения 3800 руб/час — и это без учёта того, что часть операций за три недели пришлось поднимать заново из бумажных копий и почтовой переписки, а не восстанавливать автоматически. Отдельная проблема — в базе хранились персональные данные сотрудников и контрагентов, а 152-ФЗ обязывает оператора обеспечить их восстановление без неоправданной задержки (см. 152-ФЗ). При проверке отсутствие рабочей схемы резервного копирования — не техническая мелочь, а прямое нарушение с формальной ответственностью.

схема 3-2-1-1, которая пережила бы эту ночь

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

сколько данных теряется между копиями: почему расписание важно не меньше места хранения

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

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

как разворачивали 1С заново — и что изменили

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

Для компаний, где 1С разворачивается на нескольких серверах или нужна гарантированная изоляция ресурсов именно под контур бэкапов, разумнее взять выделенный сервер в аренду — там резервные копии не делят диск и сеть ни с чем посторонним, и производительность не проседает от чужой нагрузки. Небольшой компании на 5-15 пользователей для той же задачи обычно хватает виртуального сервера для 1С — дешевле выделенного по деньгам, но по тому же принципу: копии физически не там, где рабочая база, и не под теми же учётными данными.

как настроить бэкап так, чтобы не проверять его шифровальщиком

Три вещи, которые в истории выше не сделали, но которые обязаны быть в любой рабочей схеме.

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

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

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

Чем плоха резервная копия 1С, если она лежит на том же сервере, что и база?

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

Что означает схема 3-2-1-1 для резервного копирования 1С?

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

Как понять, что бэкап 1С реально восстанавливается, а не просто создаётся по расписанию?

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

Сколько стоит перенести резервное копирование 1С на отдельный сервер?

Изолированный арендованный сервер под контур бэкапов начинается от 1 100 ₽/мес за пользователя. Настройка расписания, прав доступа и тестового восстановления — разовая работа по ставке сопровождения 3800 руб/час, обычно несколько часов, а не дни простоя после инцидента.

Что делать в первые часы, если база 1С уже зашифрована?

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