Готовность к ransomware

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

Хорошая новость: готовность к ransomware не начинается с дорогого «суперантивируса». Она начинается с трёх скучных вещей: резервные копии, права доступа и проверенный план восстановления. Антивирус и EDR полезны, но они не должны быть единственной надеждой. Любая защита может пропустить атаку, особенно если вход произошёл через украденный пароль, открытый RDP или учётку администратора.

Главный вопрос: что будем восстанавливать

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

Список должен быть коротким и приоритетным. Не «восстановить всё», а «в первые часы вернуть возможность работать смене». Остальные данные важны, но порядок решает, будет ли бизнес стоять целый день или перейдёт на временный режим.

Здесь хорошо помогает IT-аудит: понять, где лежат данные, какие серверы критичны, кто имеет права администратора, какие бэкапы существуют не в обещаниях, а в реальности.

Бэкап, который шифровальщик не достанет

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

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

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

Подробнее базовую логику мы разбирали в статье про резервное копирование без своего ИТ. В контексте ransomware к ней добавляется вопрос неизменяемости и изоляции.

Тест восстановления важнее красивого отчёта

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

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

Права администраторов: меньше героизма

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

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

Отдельно проверьте RDP. Открытый в интернет RDP — один из классических входов для взлома. Доступ к серверам должен идти через VPN, с MFA и журналированием. Если сомневаетесь, посмотрите материал RDP в интернет: почему нельзя.

Сегментация и мониторинг

Сеть, где гости, кассы, камеры, рабочие станции и серверы находятся «в одной комнате», сложнее защищать и восстанавливать. Сегментация не остановит все атаки, но ограничит распространение. Гостевой Wi-Fi не должен видеть серверы. Камеры не должны ходить к бухгалтерским файлам. Рабочая станция ресепшена не должна иметь доступ ко всем административным шарам.

Мониторинг нужен не только для CPU и дисков. Полезно видеть неожиданный рост изменений в файлах, падение бэкапов, заполнение диска, новые входы администраторов, недоступность критичных сервисов. В статье про мониторинг инфраструктуры есть практичный порядок, с чего начать без центра управления полётами.

План на день инцидента

План должен быть коротким. Кто принимает решение отключать сеть? Кому звонить? Где контакты подрядчика? Где лежат резервные коды MFA? Какие серверы выключаем, какие изолируем, что фотографируем для разбора? Когда можно начинать восстановление, а когда сначала нужно сохранить следы?

Не стоит обещать себе, что в стрессе все вспомнят. Одна страница инструкции и актуальные телефоны экономят часы. После восстановления нужен разбор: как вошли, что сработало, что нет, какие пароли менять, какие правила закрывать.

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