ГК Softline: бэкап не гарантирует восстановление после атаки

Успешное завершение задания резервного копирования еще не означает, что компания сможет восстановить систему после инцидента. Копия может оказаться поврежденной, содержать уже зашифрованные данные или храниться в инфраструктуре, к которой получили доступ злоумышленники. Даже исправный бэкап не поможет, если команда не знает, сколько займет восстановление и в какой последовательности возвращать критичные сервисы.

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

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

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

Одна локальная копия не защищает от шифровальщика

Правило «3-2-1» сохраняет практическую ценность: три экземпляра данных размещаются на двух типах носителей, причем один хранится за пределами основной инфраструктуры. Такая схема снижает вероятность одновременной потери рабочих данных и всех резервных копий.

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

Технически реализовать правило «3-2-1» стало проще: одну копию можно хранить локально для быстрого восстановления, вторую размещать в географически удаленном облачном хранилище. Однако само наличие такой возможности ничего не меняет, если политика не настроена, а внешняя копия не отделена от основной инфраструктуры.

В ИБ-проектах Softline встречаются компании, которые по-прежнему хранят единственную копию локально. Такая схема удобна в штатной эксплуатации, но сохраняет общую точку отказа. Атака, ошибка администратора или повреждение площадки способны одновременно затронуть рабочую систему и бэкап.

Частота копирования должна зависеть от ущерба

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

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

Для критичных систем настроили ежедневное резервирование и еженедельную полную копию. Менее значимые сервисы перевели на еженедельные инкрементные и ежемесячные полные копии с хранением до полугода. Резервные данные разместили в другом дата-центре, отдельно от основных мощностей.

Этот подход позволил связать частоту копирования с последствиями потери данных. Политика перестала быть общей настройкой для всей инфраструктуры и стала частью управления непрерывностью конкретных бизнес-процессов.

Для каждого сервиса нужно определить два параметра: какой объем данных компания готова потерять и сколько времени может занять восстановление. Если эти требования не установлены владельцем бизнес-процесса, ИТ-служба вынуждена выбирать периодичность копирования без понимания возможного ущерба.

Неизменяемая копия снижает риск удаления бэкапов

Размещение второй копии в облаке само по себе не защищает ее от злоумышленника. Если хранилище доступно через скомпрометированную учетную запись, данные можно удалить или перезаписать вместе с локальными бэкапами.

Для критичных копий применяются неизменяемые хранилища с поддержкой WORM, или Write Once, Read Many. После записи данные можно читать, но нельзя изменить в течение установленного срока. Даже при компрометации административной учетной записи злоумышленнику сложнее уничтожить сохраненную точку восстановления.

Такую схему использовала крупная логистическая компания при локализации ИТ-инфраструктуры. Заказчик выбрал S3-совместимое хранилище с поддержкой WORM и разделил копии по назначению. Локальный экземпляр используется для быстрого восстановления, а облачный защищает от сценария, при котором основная площадка и доступные из нее бэкапы оказываются скомпрометированы.

Система охватывает около 200 виртуальных машин, а объем резервных данных превышает 30 Тбайт. При таком масштабе иммутабельность становится частью архитектуры восстановления, поскольку ручной контроль каждой копии невозможен.

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

Проверять нужно восстановление, а не копирование

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

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

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

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

Бэкап и архив решают разные задачи

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

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

Отдельного контроля требуют старые системы, которые продолжают работать после ухода зарубежного вендора. Сохранение привычного инструмента резервного копирования допустимо, если компания обеспечивает его поддержку и понимает порядок восстановления. Использование legacy-решения без доступной экспертизы создает зависимость, которая проявится в момент инцидента.

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

За восстановление отвечает не одна ИТ-служба

Владелец бизнес-процесса определяет допустимое время простоя и объем возможной потери данных. ИТ-служба настраивает копирование, хранение и порядок восстановления. Служба информационной безопасности контролирует доступы к резервной инфраструктуре, разделение учетных записей и защиту копий от изменения.

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

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

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