Кибератаки и бэкап: как бизнес перестраивает стратегии защиты данных

За третий квартал 2025 года в России было зафиксировано свыше 42 тыс. кибератак, что на 73% больше, чем годом ранее, и уже около 40% от среднего ежегодного числа инцидентов. На этом фоне активно формируется рынок решений для резервного копирования и аварийного восстановления: бизнес перестает относиться к бэкапу как к формальной «галочке» и выстраивает полноценные стратегии обеспечения непрерывности работы.

О том, как меняются требования к киберустойчивости и почему наличие бэкапа еще не означает готовность к восстановлению, РБК поговорил с Александром Шукевичем, директором по продажам «Хайстекс».

— Александр, для тех читателей, которые пока не знакомы с вашей компанией, чем занимается «Хайстекс» и каковы ваши позиции на рынке?

—  «Хайстекс» — российский разработчик программного обеспечения в области аварийного восстановления, резервного копирования и миграции между платформами и облаками. Если говорить проще, мы помогаем компаниям безопасно и последовательно переходить с одной платформы на другую, снижать риски простоя и быть уверенными, что в случае сбоя данные и сервисы можно быстро восстановить. 

— Какие ошибки чаще всего допускают компании при построении СРК (система резервного копирования) и DR?

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

Вторая типичная история — игнорирование базового правила 3-2-1: три копии данных, на двух типах носителей, одна из копий вне основной площадки. Когда все хранилища находятся в одном контуре, при масштабном инциденте можно потерять сразу все.

Отдельная проблема — неправильно заданные RPO и RTO (допустимое время восстановления и допустимый объем потери данных). Часто эти параметры определяются в ИТ-блоке без увязки с бизнес-приоритетами. В результате либо тратятся лишние ресурсы на избыточно жесткие показатели, либо компания мирится с недопустимым простоем критичных систем.

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

— Где чаще всего компании переплачивают в этой области, и как оптимизировать затраты без потери надежности? Есть мнение, что проекты миграции и DR — это долго, дорого и почти всегда болезненно. 

— Здесь важно разделять подходы. Если вы пытаетесь мигрировать инфраструктуру вручную, под каждую систему писать отдельный сценарий, не автоматизируя процессы, проект действительно может растянуться и стать дорогим. 

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

Второе — непрозрачное потребление облака, особенно в гибридных и мультиоблачных средах: невыключенные ВМ, забытые диски, отсутствие единого учета. Поэтому многие компании внедряют FinOps-подход: регулярно «разбирают» инфраструктуру и привязывают ИТ-расходы к ответственности бизнес-подразделений. 

— Если читатель, который отвечает за ИТ или риски, захочет оценить готовность к аварийному восстановлению, с чего вы рекомендуете начать?

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

Второй: понять, какой у вас сейчас RPO и RTO по этим системам. То есть, сколько данных вы потенциально можете потерять и за какое время реально восстановиться.

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

— Как изменились требования заказчиков за последние годы?

— Мы работаем на этом рынке с 2016 года, за это время в наших проектах было мигрировано более 92 тыс. и защищено около 24 тыс. виртуальных машин. Этот объем позволяет довольно уверенно говорить о смене подхода заказчиков.

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

Еще один заметный тренд — стремление уйти от зависимости от одного вендора. Vendor lock-in, характерный для многих западных решений, и особенно в облаках, сегодня воспринимается как серьезный риск. Бизнес выбирает кроссплатформенные продукты, которые позволяют работать с разными гипервизорами и облачными средами и при необходимости менять площадку без тяжелых миграционных проектов.

Наконец, растет интерес к управлению затратами. В условиях волатильности компании смотрят не только на технические параметры защиты данных, но и на экономику инфраструктуры, в том числе облачной. Здесь на первый план выходят подходы FinOps, которые дают прозрачность использования ресурсов и позволяют контролировать расходы на уровне сервисов.

— Как вы оцениваете перспективы российского рынка DR и СРК на ближайшие годы?

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

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