«Отказ от выкупа часто представляется как акт отчаяния или слепая удача. На самом деле это осознанная стратегия, основанная на восстановлении данных, изоляции инцидента и работе с внешними командами, когда нет паники, а есть план.»
Что произошло
В конце прошлого года компания-разработчик из сектора EdTech столкнулась с классической атакой: сотрудник бухгалтерии открыл вложение в письме, которое выглядело как счёт. Через несколько часов шифровальщик распространился по сетевому хранилищу и зашифровал базы данных, резервные копии проекта и часть рабочих документов. Злоумышленники оставили сообщение с требованием выкупа в криптовалюте, эквиaaaaaaaaвлентного примерно 15 миллионам рублей, и угрожали публикацией украденных данных на специализированных форумах.
Особенность ситуации была в том, что компания не относилась к критической информационной инфраструктуре (КИИ) и не имела жёстких требований по защите от ФСТЭК. Их защита строилась на базовых практиках, которые и не сработали. Однако вместо хаоса, руководство и технический директор действовали по заранее продуманному сценарию, который не предполагал переговоров с киберпреступниками.
Почему решили не платить
Решение не платить выкуп было принято в первые же часы, и оно основывалось на нескольких ключевых факторах.
- Ненадёжность преступников. Нет гарантий, что после оплаты будет предоставлен ключ расшифровки, а данные не будут проданы или опубликованы. Многие компании, заплатившие, сталкивались с повторными требованиями или с утечкой данных вопреки обещаниям.
- Финансовая нецелесообразность. Сумма выкупа была сопоставима с годовым бюджетом на ИТ-безопасность и частью прибыли. Её выплата поставила бы бизнес в тяжёлое положение без гарантии восстановления.
- Правовые и репутационные риски. В российской практике выплата выкупа может быть расценена как финансирование противоправной деятельности. Кроме того, сам факт оплаты, если станет известен, подрывает доверие клиентов и партнёров.
- Наличие рабочей стратегии восстановления. Это был самый важный фактор. У компании был «план Б», который не зависел от доброй воли злоумышленников.
[ИЗОБРАЖЕНИЕ: Инфографика с основными причинами отказа от выплаты выкупа: ненадёжность, финансы, репутация, наличие плана B]
Пошаговая стратегия выживания
Действия команды можно разделить на три основных этапа, которые выполнялись почти параллельно.
Этап 1: Сдерживание и оценка
Первым делом была изолирована поражённая сеть. Физически отключили серверы с зашифрованными данными от основной инфраструктуры, чтобы остановить распространение. Одновременно началась работа по определению точного вектора атаки и оценке ущерба.
# Пример команды для изоляции сегмента сети на маршрутизаторе
iptables -A FORWARD -s 192.168.10.0/24 -j DROP
Было критически важно понять, какие именно данные были затронуты: только файлы на общем хранилище или также базы данных приложений? Оказалось, что основная рабочая PostgreSQL-база, которая обслуживала текущих пользователей, не была затронута, так как работала на отдельном сервере с другими учётными данными. Это стало ключевой удачей.
Этап 2: Восстановление данных
Поскольку резервные копии на основном хранилище также оказались зашифрованы, команда обратилась к дополнительным каналам. Оказалось, что часть критически важных данных автоматически синхронизировалась в сторонний облачный сервис российского провайдера, но в виде логов и сырых дампов, а не готовых бэкапов.
Главная техническая задача свелась не к восстановлению из бэкапа, а к реконструкции данных. Команда взяла последний валидный снапшот базы недельной давности и начала применять к нему журналы транзакций (WAL), которые сохранились в неизменном виде в отдельном хранилище. Это позволило восстановить состояние данных практически до момента инцидента, потеряв лишь несколько последних транзакций.
[КОД: Пример команды для применения WAL-логов к базе PostgreSQL с помощью pg_rewind]
Для файлового хранилища пришлось пойти на компромисс. Не все данные удалось восстановить. Были определены критически важные документы (договоры, исходники ключевых модулей), и их восстановили вручную из локальных копий на компьютерах сотрудников, которые не были подключены к сетевому диску в момент атаки. Всё остальное было признано утраченным.
Этап 3: Внешние коммуникации и работа с инцидентом
Параллельно был запущен процесс внешних коммуникаций. В отличие от распространённой практики скрывать инцидент, технический директор уведомил ключевых клиентов о «временных технических неполадках», приведших к частичной потере данных. Были предложены конкретные компенсации в виде продления доступа к сервису. Это помогло сохранить основную клиентскую базу.
Были привлечены внешние специалисты по ИБ для проведения полноценного анализа инцидента (Digital Forensics and Incident Response — DFIR). Их отчёт позволил закрыть уязвимости, через которые произошло проникновение: отключили устаревший протокол SMBv1, ужесточили политики доступа к сетевым ресурсам, внедрили сегментацию сети по функциональному признаку.
[ИЗОБРАЖЕНИЕ: Схема сегментации сети до и после инцидента: общая плоская сеть против изолированных сегментов для бухгалтерии, разработки и продакшена]
Что спасло компанию: неочевидные факторы
Помимо чёткого плана, сработали несколько факторов, на которые обычно не обращают внимания при планировании защиты.
- Разделение учётных записей. У сервера баз данных были уникальные учётные данные, отличные от учёток для доступа к файловому хранилищу. Это не позволило шифровальщику автоматически перекинуться на СУБД.
- Журналы транзакций в отдельном хранилище. Архивация WAL-логов PostgreSQL велась на отдельный, не общедоступный диск. Это не было частью формальной политики бэкапов, а скорее технической особенностью настройки, которая в итоге спасла данные.
- Культура локального хранения у сотрудников. Часть сотрудников по привычке сохраняла важные рабочие файлы локально, несмотря на политику использования сетевого диска. В условиях атаки это стало источником для восстановления.
- Готовность к компромиссу. Компания не пыталась восстановить всё на 100%. Были чётко определены неприкосновенные данные и данные, которые можно было потерять. Это резко сократило время и сложность восстановления.
Выводы и рекомендации для российского ИТ
Этот кейс показывает, что отказ от выкупа — это не геройство, а технически и экономически обоснованное решение, если к нему подготовиться.
- Создайте реалистичный план восстановления (Disaster Recovery Plan). Он должен включать не только создание бэкапов, но и их регулярное тестирование на восстановление. Храните копии данных на физически изолированных носителях или в сторонних облаках с разными учётными данными.
- Практикуйте сегментацию сети. Изоляция сегментов (офис, продакшен, финансы) не позволит зловреду свободно путешествовать по всей инфраструктуре.
- Готовьте сценарий коммуникаций. Заранее определите, кого и как вы будете уведомлять в случае инцидента: клиентов, партнёров, регулятора (если являетесь оператором КИИ). Честность с клиентами часто окупается.
- Рассмотрите страхование киберрисков. Страховой полис может покрыть расходы на привлечение DFIR-специалистов, восстановление данных и даже репутационные убытки, что снижает финансовое давление в момент кризиса.
- Воспринимайте инцидент как возможность. Проведённый анализ уязвимостей после атаки часто приводит к более сильной и отказоустойчивой архитектуре, чем была до этого.
Итог для компании: потеряна часть архивных данных и две недели продуктивности на восстановление. При этом сохранены основные клиенты, не выплачены миллионы злоумышленникам и, что важнее, построена значительно более устойчивая к инцидентам ИТ-инфраструктура. Угроза, которую удалось обратить в точку роста.