Шифровальщик портит всё, до чего может дотянуться с правами заражённой учётной записи. Если резервная копия лежит на том же сервере, на соседнем диске или в сетевой папке, куда можно писать из офисной сети, её зашифруют или удалят вместе с рабочими данными. Поэтому копия «где-то рядом» от шифровальщика не защищает, она защищает только от поломки диска. Важно понимать, что современные шифровальщики пытаются повысить свои привилегии и получить большие права доступа. У меня в практике был случай, когда взломали пользователя главного бухгалтера, у нее был доступ к конфигуратору 1С, через конфигуратор загрузили новую конфигурацию, которая вызывала внешнюю обработку. Если нет специальных настроек безопасности в 1С, а их нет в 90% случаев, обработка запускается от системного пользователя и получает права в системе близкие к Администратору.
Правило 3-2-1 решает эту проблему: держите три копии данных (рабочие плюс две резервные), на двух разных видах хранения, и одну из копий — за пределами офиса. Сегодня к нему добавляют ещё одно требование: минимум одну копию нельзя изменить с рабочих компьютеров и серверов. Это неизменяемая копия или копия, которая большую часть времени физически отключена.
Ниже разберём, как копия погибает вместе с базой, какие способы хранения выдерживают атаку, а какие нет, как проверять восстановление и как устроить простую схему для фирмы на 5–30 человек.
Как настройка выглядит на практике
Типичная ситуация из нашего опыта, без названий и подробностей. В небольшой компании был сервер с базами 1С и общими документами. Резервное копирование настроили: каждую ночь задание складывало архивы на отдельную машину в той же локальной сети. Администратор считал, что данные защищены, раз копии хранятся не на рабочем сервере.
Заражение началось с одного офисного компьютера: сотрудник открыл ссылку из письма, замаскированного под сообщение партнёра. Дальше действовала уже не автоматическая программа, а люди. Они несколько дней изучали сеть, нашли сервер с широкими правами доступа, через него добрались до машины с копиями. В день атаки рабочие файлы и базы зашифровали, а архивы на машине резервного копирования просто стёрли специальной программой, чтобы было не восстановить.
В итоге у фирмы не осталось ни данных, ни копий. Помог случай: незадолго до этого подрядчик по 1С выгружал базу на один из компьютеров перед доработкой. Эта старая выгрузка и стала отправной точкой восстановления. Всё, что вводилось после неё, пришлось восстанавливать по документам.
Вывод из таких историй простой. Копия защищает от шифровальщика не тогда, когда она «отдельно», а когда до неё нельзя добраться теми же путями и с теми же правами, что и до рабочих данных.
Почему локальный бэкап и общая папка не защищают
Шифровальщики бывают двух видов. Массовые работают вслепую: шифруют всё, что видят на дисках и в подключённых сетевых ресурсах. Для них архив копии ничем не отличается от любого другого файла. Управляемые атаки опаснее: злоумышленник целенаправленно ищет систему резервного копирования и уничтожает её до запуска шифрования, чтобы у жертвы не было выбора.
Отсюда слабые места типичных офисных схем:
- Копия на том же сервере. Другая папка или второй диск в том же корпусе доступны любой программе, запущенной на сервере с правами администратора.
- Сетевая папка, подключённая как сетевой диск. Если сервер или пользователь может записать туда архив, то программа, запущенная от его имени, может этот архив перезаписать.
- Хранилище (NAS) в той же сети под общей учётной записью. Когда логин и пароль от хранилища лежат в задании копирования на сервере, злоумышленник находит их там же.
- Внешний диск, который никогда не отключают. Для системы это обычный локальный диск.
- Теневые копии Windows. Удобны для отката случайно изменённого файла, но большинство шифровальщиков удаляют их первым делом.
- Синхронизация с облачным диском. Программа синхронизации честно отправит в облако уже зашифрованные файлы. Спасти может только история версий на стороне облака, если она включена и достаточно длинная.
Есть и вторая проблема — глубина хранения. Если копии хранятся три дня, а злоумышленник провёл в сети неделю, все доступные копии могут оказаться сделанными уже после проникновения. Для данных это обычно не страшно, а вот образ сервера из такого периода может содержать оставленные им программы.
Правило 3-2-1: что оно означает
Правило сформулировали задолго до массовых шифровальщиков, но оно по-прежнему остаётся хорошей отправной точкой.
- 3 копии. Рабочие данные считаются первой копией. К ним добавляются минимум две резервные. Одна копия может не создаться или оказаться повреждённой, две сразу — гораздо реже.
- 2 вида хранения. Например, диск сервера и отдельное сетевое хранилище, или хранилище и облако. Смысл в том, чтобы одна неисправность или ошибка не уничтожила всё сразу.
- 1 копия вне офиса. Пожар, залив, кража, изъятие техники, отключение электричества на неделю — всё это бьёт по всему, что стоит в одном помещении.
Современные дополнения: 3-2-1-1-0
Из-за шифровальщиков правило часто расширяют до формулы 3-2-1-1-0:
- ещё одна «1» — хотя бы одна копия неизменяемая или отключённая от сети;
- «0» — ноль ошибок при проверке восстановления. Копия, которую ни разу не пробовали развернуть, остаётся надеждой, а не гарантией.
Неизменяемые копии
Неизменяемая копия — это копия, которую нельзя удалить или перезаписать до истечения заданного срока. Причём даже с правами администратора того сервера, который её создал. Как это реализуют:
- объектные хранилища с блокировкой объектов (в S3-совместимых хранилищах эта функция обычно называется Object Lock): срок хранения задаётся при записи, и до его окончания удалить файл нельзя;
- снимки файловой системы на сетевом хранилище, которые делает само хранилище по своему расписанию, а удалить их можно только из его собственного интерфейса под отдельной учётной записью;
- системы резервного копирования с защищённым хранилищем, куда сервер может только дописывать новые копии, но не может менять и удалять старые.
Копии без постоянного подключения
Самый простой вариант неизменяемости — отключённый носитель. Два-три внешних диска по очереди: подключили, сделали копию, отключили и увезли из офиса. Способ дешёвый и надёжный, но держится на дисциплине человека. Если диск забывают отключать, он становится обычным локальным диском со всеми рисками.
Похожий эффект даёт схема «забирает, а не принимает»: не сервер отправляет копии в хранилище, а хранилище само по расписанию забирает их с сервера. Тогда на сервере нет пароля от хранилища, и из заражённой сети до него не дотянуться.
Где хранить копию: что выдержит шифровальщик
| Вариант хранения копии | Защищён от шифровальщика | Почему |
|---|---|---|
| Папка или второй диск на том же сервере | Нет | Доступен любой программе, запущенной на сервере |
| Общая сетевая папка, подключённая как диск | Нет | Кто может записать архив, тот может его зашифровать |
| Теневые копии Windows | Нет | Удаляются командами с правами администратора, шифровальщики делают это в первую очередь |
| Внешний USB-диск, подключённый постоянно | Нет | Система видит его как обычный локальный диск |
| Синхронизация папки с облачным диском | Частично | Зашифрованные файлы тоже синхронизируются; выручит только история версий в облаке |
| Сетевое хранилище, куда пишет сервер под общей учётной записью | Скорее нет | Пароль хранится на сервере, злоумышленник найдет его и использует |
| Сетевое хранилище, которое само забирает копии и делает снимки | Да, при правильной настройке | С сервера нет доступа к хранилищу, снимки удаляются только из его интерфейса |
| Внешние диски по очереди, хранятся вне офиса | Да | В момент атаки диск отключён; риск — забыть отключить или давно не менять |
| Облачное хранилище с блокировкой удаления | Да | Удалить копию до окончания срока нельзя даже с верным паролем |
| Снимки, которые делает провайдер облачного сервера | Как правило, да | Снимки делаются на уровне платформы, из самого сервера ими нельзя управлять |
Обратите внимание: ни один вариант не защищён «по названию». Хранилище в той же сети становится надёжным только тогда, когда у рабочего сервера нет прав его менять.
Схема для небольшой фирмы
Для компании с одним сервером 1С и общими документами хорошо работает схема из трех итераций: сервер → хранилище в офисе → копия у провайдера.
- Сервер. Рабочие данные: базы 1С, файлы, почта. Здесь же делаются регулярные выгрузки и копии баз. Как настроить копирование баз 1С по расписанию, подробно разобрано в инструкции по резервному копированию 1С по расписанию.
- Хранилище в офисе. Отдельное сетевое хранилище, не входящее в домен. Оно само забирает копии с сервера по расписанию под учётной записью, у которой есть только право чтения нужной папки. На хранилище включены снимки с хранением на несколько недель. Администраторский пароль хранилища не используется больше нигде и не сохраняется на офисных компьютерах.
- Копия у провайдера. С хранилища копии уходят в облачное хранилище с хранением версий или блокировкой удаления. Учётные данные от облака отдельные, лучше с двухфакторной авторизацией.
Если сервер с 1С арендован в облаке, схема упрощается: роль внешней копии частично берёт на себя провайдер. Например, при аренде облачного сервера в Service4biz в стоимость входят 3 последние резервные копии — ежедневный снимок сервера. После сбоя или атаки можно вернуться к состоянию сервера на любой из трёх последних дней. Для глубокого архива (месяц, квартал, год) имеет смысл дополнительно выгружать копии баз в дополнительное хранилище.
Сколько копий и как долго хранить
Разумная отправная точка для небольшой фирмы:
- ежедневные копии — за последние 2 недели;
- еженедельные — за последние 1–2 месяца;
- ежемесячные — за год, особенно для баз 1С перед закрытием периода и сдачей отчётности.
Чем дольше история, тем выше шанс найти копию, сделанную до проникновения злоумышленника. Если потеря даже одного рабочего дня недопустима, копируйте базы несколько раз в день. Для клиент-серверной 1С это можно сделать средствами СУБД, для файловой — выгрузками по расписанию в нерабочее время.
Права доступа — половина защиты
- Учётная запись, от которой делаются копии, не должна иметь права удалять старые копии. Удаление и очистку выполняет отдельная учётная запись или само хранилище по сроку.
- У обычных сотрудников нет доступа к папкам с копиями, даже на чтение.
- Администраторские пароли от сервера, хранилища и облака разные.
- Доступ к конфигуратору 1С и к серверу по RDP — только тем, кому это нужно для работы.
Как проверять, что копия восстанавливается
В нашей практике это типичная история: копии годами создаются, а когда нужно восстановиться, выясняется, что задание давно падает с ошибкой, архив неполный или никто не знает пароль от него. Проверка восстановления нужна регулярно, а не «когда случится».
- Ежедневно — отчёт о результате. Настройте уведомление на почту или в мессенджер о каждом задании копирования. Ещё лучше — систему мониторинга, которая сама сообщит, если свежей копии нет дольше суток.
- Раз в месяц — пробное восстановление. Разверните копию базы 1С на отдельном компьютере или в виртуальной машине, запустите её, откройте несколько свежих документов и отчётов. Проверьте, что дата последних документов совпадает с датой копии.
- Раз в месяц — выборочная проверка файлов. Восстановите из копии пару папок с документами и откройте файлы разных типов.
- Раз в квартал — проверка внешней копии. Восстановите данные именно из облака или с отключаемого диска, а не с ближайшего хранилища. Засеките, сколько времени это занимает.
- Раз в год — учебная авария. Представьте, что сервер и офисное хранилище потеряны. Хватает ли внешней копии, чтобы продолжить работу? Кто знает пароли? Где инструкция?
Итог проверок стоит записать в короткую инструкцию: где лежат копии, как их восстановить, сколько это займёт, у кого доступы. В момент аварии этот лист бумаги часто полезнее самого опытного администратора, до которого не удаётся дозвониться.
Что зафиксировать заранее
| Вопрос | Пример ответа |
|---|---|
| Сколько данных можно потерять | Не больше одного рабочего дня |
| За какое время нужно восстановить работу | До конца следующего рабочего дня |
| Где хранятся копии | Хранилище в офисе и облачное хранилище |
| У кого доступ к внешней копии | Администратор и руководитель, пароли в защищённом менеджере |
| Когда последний раз проверяли восстановление | Дата и результат пробного развёртывания |
Если заражение уже случилось
Эта статья о том, как устроить копии заранее. Если шифровальщик уже сработал, сначала изолируйте заражённые машины и не подключайте к сети уцелевшие хранилища и диски, пока не станет ясно, что заражение остановлено. Порядок действий по шагам — в отдельной статье о том, что делать при заражении шифровальщиком.
Если нет своего администратора или не хочется разбираться с правами, снимками и мониторингом самостоятельно, можно заказать настройку резервного копирования офисных компьютеров под ключ. Важно, чтобы в работу входила проверка восстановления, а не только создание архивов.
Частые вопросы
Хватит ли внешнего жёсткого диска для резервных копий?
Одного диска недостаточно. Если он подключён постоянно, шифровальщик зашифрует его вместе с сервером. Если его отключают, копия есть, но только одна и часто лежит в том же офисе. Лучше использовать два-три диска по очереди и хранить хотя бы один вне офиса, а в идеале добавить облачную копию.
Облачный диск с синхронизацией — это резервная копия?
Сама по себе синхронизация — нет. Она переносит в облако любые изменения, включая зашифрованные файлы и удаление. Резервной копией облако становится, если в нём включена история версий с достаточным сроком или корзина, которую нельзя очистить с заражённого компьютера.
Спасут ли теневые копии Windows?
На них не стоит рассчитывать. Теневые копии хранятся на том же диске, и шифровальщики обычно удаляют их до начала шифрования. Они полезны, чтобы быстро вернуть случайно изменённый файл, но не заменяют резервное копирование.
Как часто копировать базы 1С?
Минимум раз в сутки, в нерабочее время. Если за день вводится много документов и восстанавливать их вручную долго, делайте копии несколько раз в день. Частоту определяет простой вопрос: сколько часов работы бухгалтерии вы готовы ввести заново.
Если сервер в облаке, нужны ли свои резервные копии?
Копии провайдера защищают от сбоя сервера и позволяют откатиться на несколько дней. Но срок их хранения ограничен. Для долгого архива и на случай, если проблему заметят не сразу, стоит периодически выгружать базы 1С и важные документы в дополнительнон хранилище.
Можно ли доверить копирование антивирусу с защитой от шифровальщиков?
Антивирус снижает риск, но не заменяет копии. Злоумышленники часто используют легальные программы для шифрования и сначала отключают защиту. Если антивирус не сработал, выручит только копия, до которой атака не дотянулась.