КИБЕРБЕЗОПАСНОСТЬ

Ransomware-атака закончилась, а клиент ушёл: новая проблема MSP

Только 16% пострадавших компаний восстанавливаются после ransomware за сутки: для MSP скорость и прозрачность стали условием продления контракта.

✍️ Редакция iTech News | 11.11.2026 | ⏱ 4 мин | Источник: BleepingComputer
Ransomware-атака закончилась, а клиент ушёл: новая проблема MSP

Только 16% организаций, пострадавших от шифровальщиков, полностью возвращаются к работе за одни сутки. Для MSP восстановление после ransomware теперь измеряется не только поднятыми серверами и возвращёнными данными: клиент оценивает, кто и когда сообщил о проблеме, почему простой затянулся и откуда взялись часы аварийных работ в счёте.

Об этом сообщает BleepingComputer в спонсорском материале Kaseya. Компания продвигает довольно приземлённую мысль: технически успешное восстановление не гарантирует продление контракта. Если заказчик два дня ждёт статуса, а затем получает счёт с непонятными расходами, у него остаётся впечатление не от спасённых бэкапов, а от плохо управляемого кризиса.

После атаки клиент помнит не только простой

По приведённым в материале отраслевым данным, 55% пострадавших компаний восстанавливаются в течение недели. Для бизнеса это не просто неудобный срок: в это время не работают продажи, поддержка, внутренние системы, доставка или производство — в зависимости от профиля организации. У клиента MSP возникает логичный вопрос: если инциденты неизбежны, насколько провайдер способен организовать реакцию и объяснить происходящее?

Kaseya приводит ещё одну цифру из своего отчёта Cybersecurity Outlook за 2026 год: 12% MSP потеряли клиентов после инцидентов безопасности. В числе причин названы ransomware, захват учётных записей и компрометация деловой почты. Это не означает, что клиент обязательно уходит после каждой атаки. Скорее, атака становится стресс-тестом сервиса, где SLA на бумаге проверяется вместе с навыком инженеров разговаривать с людьми, которые только что потеряли доступ к бизнесу.

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

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

Три метрики вместо обещаний «быстро восстановим»

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

Рецепт Kaseya ожидаемо ведёт к её платформе Trifecta, объединяющей RMM, PSA и BCDR: удалённый мониторинг и управление, автоматизацию сервисных процессов и резервное копирование с аварийным восстановлением. По версии компании, единый набор данных должен связать событие мониторинга, тикет, состояние восстановления и учёт затраченного времени. В её отчёте среди факторов более быстрого восстановления указаны подготовленные внутренние IT- или security-команды — 35% — и интегрированные инструменты управления IT и безопасностью — 18%.

Для российских интеграторов, аутсорсеров и внутренних IT-служб здесь важен не конкретный продукт, а сама постановка задачи. Восстановление после ransomware должно иметь владельца, единый журнал действий и заранее согласованный сценарий коммуникации: кому звонят в первые минуты, как часто обновляют статус, какие системы считаются критичными и как учитывают внеплановые работы. Иначе даже хорошо настроенные резервные копии решат лишь половину проблемы.

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

Поделиться: Telegram X LinkedIn