У многих компаний резервное копирование данных находится где-то внизу списка задач по ИТ-направлению: после запуска сайта и внутренних сервисов, доработки CRM, настройки складского учета. О бэкапах вспоминают, когда инцидент уже произошел: перестала открываться база заказов, вирус-шифровальщик заблокировал доступ к файлам, каталог товаров по ошибке удалили — как раз накануне старта распродажи. В этот момент выясняется, что резервная копия есть, но с нюансами — например, ей неделя. Или восстановление занимает двое суток. Потери данных и простои часто оборачиваются материальным ущербом для бизнеса. Владимир Маракшин, директор департамента стратегического развития «Киберпротект», — о том, почему резервная копия сама по себе еще не спасает бизнес и что нужно сделать до выбора конкретного решения для бэкапа.
Киберустойчивость — это способность компенсировать последствия кибератак. Можно сказать, что это вторая линия обороны: если злоумышленникам все-таки удалось обойти системы защиты, то бизнес сможет быстро и без значительных потерь ликвидировать последствия.
Большое заблуждение — думать, что, вложившись только в защиту, вы автоматически получаете иммунитет к любым инцидентам. Другое большое заблуждение — полагать, что раз у вас небольшой бизнес, на рынке нет острой конкуренции и известных вам недоброжелателей, значит, вы никому не интересны и вам не нужно инвестировать в кибербезопасность и киберустойчивость. Дело в том, что для киберпреступников любой бизнес — это привлекательная мишень и возможность извлечь выгоду. Атака на вас может и не быть таргетированной, просто однажды сотрудник передаст доступы к критическим системам, попавшись на массовую фишинговую рассылку.
Начните с аудита
Киберустойчивую систему стоит начинать с аудита и инвентаризации: понять, какие ИТ-системы у вас есть, какие процессы с ними связаны. Эти данные мало задокументировать единожды — нужно обновлять их регулярно, потому что такие знания стремительно устаревают.
Два наиболее уязвимых контура — это сервисы с внешним доступом и системы управления инфраструктурой. Первые — например, CRM и ERP. Без надобности вообще не стоит выставлять такие системы во внешний контур. Вторые — это, например, платформы виртуализации и системы управления доступами. Получив доступ сюда, злоумышленник может влиять на сотни и тысячи связанных систем, угроза становится критической.
Аудит помогает вскрыть зависимости, которые раньше были неочевидными. Например, CRM подгружает данные из отдельной внешней базы, которую в ином случае было бы очень просто забыть включить в бэкап.
Следующий шаг после аудита — понять, какие системы действительно критичны для бизнеса. Важно смотреть не только на саму систему, но и на то, что произойдет, если она перестанет работать.
Один и тот же сбой для разных компаний будет иметь разную цену. Если сайт-визитка строительной компании недоступен несколько часов, это неприятно, но, скорее всего, не остановит бизнес. Но если это интернет-магазин, потери уже можно сосчитать напрямую — через среднюю дневную выручку, незавершенные заказы, проблемы с отгрузкой и обращения в поддержку.
Поэтому сначала стоит оценить последствия простоя. Где компания сразу теряет деньги, где появляются операционные проблемы, а где риск скорее репутационный. Например, сбой в базе заказов быстро ударит по продажам и логистике. А временная недоступность внутренней отчетности может быть менее критичной, если она не влияет на обслуживание клиентов прямо сейчас.
Когда ожидаемый эффект понятен, уже можно смотреть на метрики RTO и RPO.
RTO, Recovery Time Objective, — это допустимое время простоя. Проще говоря, сколько система может быть недоступна без серьезных последствий для бизнеса.
RPO, Recovery Point Objective, — это допустимая потеря данных, то есть за какой период данные можно потерять без серьезного ущерба. Если база заказов восстановилась из вчерашней копии, все операции после этой копии придется собирать заново: сверять оплаты, заказы, возвраты и отгрузки по другим системам. Для интернет-магазина это быстро превращается в отдельную операционную задачу. А вот для архива документов или части внутренней отчетности откат на сутки иногда не критичен.
Важно понимать, что система резервного копирования — не надстройка над ИТ-инфраструктурой, это его важная составляющая. Она должна быть частью этой инфраструктуры с самого начала. Иначе можно столкнуться с неприятной ситуацией. Например, система уже построена так, что корректную резервную копию сделать сложно или вообще невозможно. Или данных стало так много, что копирование не укладывается в отведенное время. Или выбранные технологии не поддерживают нужный сценарий восстановления. Исправить это потом можно, но обычно уже дороже и сложнее.
На практике это значит, что бизнесу необходимо выбирать решения, которые изначально учитывают защиту разных типов инфраструктуры и угроз. Такой подход, например, реализован в «Кибер Бэкапе», который поддерживает работу с физическими и виртуальными средами, базами данных, контейнерами и приложениями, включая сценарии восстановления после атак и шифровальщиков.
Что автоматизировать, а где оставлять решение человеку
На бумаге архитектура почти всегда выглядит устойчивой. Но в момент сбоя выясняется, что часть процессов держится на ручных действиях. Например, есть сотрудник, который знает последовательность шагов и должен все восстановить. Но такая ситуация — это всегда стресс, что увеличивает вероятность ошибки. Поэтому все повторяющиеся и типовые операции лучше автоматизировать. Например, перезапуск серверов.
Но есть вещи, которые полностью автоматизировать не получится — это слишком дорого и сложно для конкретного бизнеса. Например, полное переключение на резервную площадку — как раз тот случай, где решение часто остается за человеком. Это уже не типовая операция, а управленческий выбор: действительно ли пора запускать резервный контур, какие системы поднимать первыми и какие риски бизнес готов принять.
Конечно, для такой ситуации у сотрудника должен быть четко прописанный сценарий действий. При этом, что тоже очень важно, — проверенный в реальности, так как «зеленые» статусы в интерфейсе не гарантируют киберустойчивости. Возьмите конкретную систему и попробуйте поднять ее из копии. Проведите замеры времени, чтобы определить скорость восстановления. Проверьте сохранность данных и время, за которое удалось восстановить работу системы из копии (RTO и RPO).
Если эксперимент показывает, что восстановление занимает больше времени, чем может ждать бизнес, — разделите процесс на этапы и автоматизируйте те, где человеческое вмешательство не обязательно.
Подобные проверки нужно обязательно проводить после всех серьезных изменений — вы переехали в облако, сменили платформу, добавили еще одну ИТ-систему. Тестирование самих копий на предмет того, можно ли из них восстановиться, достаточно делать раз в месяц или квартал. Полноценное восстановление всей системы на резервной площадке — раз в год.
Выбирая модель бэкапа: почему правила 3-2-1 уже недостаточно
Когда компания понимает, что именно она защищает, как быстро должна восстановиться и сколько данных может позволить себе потерять, выбирать модель становится проще. Есть всего три подхода: хранить копии у себя (on-prem), в облаке или комбинировать оба варианта (гибрид).
Проще всего отсечь облачный сценарий: если законодательство или требования вашей отрасли запрещают хранить данные за пределами ресурсов компании — вам подходит только on-premise и резервное копирование нужно строить внутри собственной инфраструктуры.
Бывает и обратная ситуация: значительная часть сервисов уже работает в облаке. Тогда тянуть копии обратно на физические серверы только ради бэкапа — сложно и дорого.
Часто наиболее устойчивой оказывается гибридная схема: управление и основные данные остаются на серверах компании, а копии хранятся у внешнего оператора. Это защищает от физической аварии на основной площадке. Другой вариант в рамках гибрида — заранее договориться с партнером о запуске минимального набора систем на его стороне. Если какие-то из них выйдут из строя — вы сможете с минимальными потерями времени восстановить работу на параллельном контуре.
Однако сама по себе выбранная схема хранения еще не гарантирует, что данные действительно удастся сохранить при сбое или атаке. Дальше важно понять, сколько копий есть, насколько они разнесены между собой и можно ли их потерять вместе с основной системой.
Здесь по-прежнему работает классическое правило 3-2-1: у компании должно быть минимум три копии данных, они должны храниться как минимум двумя разными способами, а одна копия — отдельно от основной инфраструктуры. Такой подход хорошо защищает от технических сбоев: выхода из строя диска, сервера, а иногда и всей площадки.
Но сегодня этого может быть недостаточно. Поэтому классическое правило все чаще расширяют до схемы 3-2-1-1-0. Первые три пункта остаются прежними: минимум три копии данных, два разных типа хранения и одна копия вне основной площадки.
Дополнительная единица — это копия, которую нельзя просто так изменить или удалить. Это важно на случай атаки: если злоумышленник получил доступ к системе, он не сможет стереть все резервные копии вместе с рабочими данными. Ноль в этой схеме — это отсутствие ошибок при проверке восстановления. Иначе говоря, копия должна не просто числиться в системе. Она должна открываться, содержать нужные данные и позволять поднять рабочую систему.
Раньше часто было достаточно разнести копии по разным местам. Сейчас этого мало: злоумышленники нередко сначала ищут и удаляют резервные копии, а уже потом блокируют рабочие данные. Если копии можно удалить, восстановиться может быть просто не из чего.
Но даже схема 3-2-1-1-0 не закрывает еще один риск — неполный охват. Если появился новый сервис, база данных или интеграция, их нужно отдельно включить в резервное копирование. Иначе получится, что правила хранения соблюдены, копии защищены, проверки проходят, но важная часть инфраструктуры в них просто не попадает. Обычно это упирается не в технику, а в процесс: должно быть понятно, кто отвечает за обновление списка систем и кто проверяет, что новые сервисы действительно добавлены в бэкап.
Еще одна неприятная ситуация — когда бэкап вроде бы настроен правильно, но в него попало не все. Например, в компании появился новый сервис: его запустили, сотрудники начали им пользоваться, там уже хранятся рабочие данные. А в резервное копирование его не добавили. До сбоя это обычно никто не замечает. Потом начинается восстановление — и выясняется, что копии есть, но именно этого сервиса в них нет. Поэтому после каждого заметного изменения в инфраструктуре нужно возвращаться к списку систем и проверять, что бэкап тоже обновился.
Бэкапы не для галочки
Если убрать технические детали, задача бэкапа сводится к одному: сможет ли бизнес вернуться к работе в понятный срок и с допустимыми потерями.
Когда компания понимает, какие системы у нее есть, ранжирует их по критичности, определяет, сколько времени есть в запасе в случае инцидента и как именно происходит восстановление, ситуация меняется. Резервное копирование перестает быть галочкой в интерфейсе, а превращается в рабочий инструмент, который позволяет пережить любой сбой.
Хороший бэкап — это заранее подготовленный способ вернуть бизнес в работу в понятный срок и с понятными потерями. Именно в этом разница между «у нас есть резервные копии» и «мы готовы к инциденту».
Читать далее:
Вселенная внутри черной дыры: наблюдения «Уэбба» подтверждают странную гипотезу
Испытания ракеты Starship Илона Маска вновь закончились взрывом в небе
Сразу четыре похожих на Землю планеты нашли у ближайшей одиночной звезды
Обложка: magnific
