Наличие бэкапов еще не гарантирует восстановление бизнеса после сбоя или атаки. IT-World выяснял, как регулярные проверки, тестовые восстановления, аудит и защита резервных копий помогают избежать ситуации, когда резервные данные есть, а восстановиться из них невозможно.
Многие компании до сих пор живут с опасной иллюзией: если бэкапы делаются, значит, бизнес застрахован. На практике все иначе. Наличие резервной копии само по себе не гарантирует, что вы сможете быстро восстановиться после атаки или сбоя. Когда наступает «час Х», нередко выясняется, что копии есть, но восстановить из них работающую систему в нужный срок не получается. Эту мысль подтверждают и независимые эксперты: большинство тестов на восстановление доказывает лишь то, что задание бэкапа отработало, но это не означает, что после восстановления из резервной копии бизнес-процессы возобновятся в штатном режиме в нужное время, и это создает ложное чувство уверенности, которое держится только до первого реального инцидента.
Полезнее воспринимать систему резервного копирования (СРК) и процессы восстановления как пожарную тревогу. Огнетушитель в офисе бесполезен, если он просрочен, а сотрудники не знают, где его найти и как им пользоваться. Точно так же СРК требует постоянной готовности, регулярных проверок и тренировок. Профилактика — это то, чем нужно заниматься заранее, потому что когда инцидент уже произошел, остается только спасать то, что можно.
Эта статья ориентирована на тех, кто уже понимает, что формального отношения к бэкапам недостаточно, и хочет выстроить процессы так, чтобы быть готовым к любому развитию событий.
Регулярные учения по восстановлению
Первое, с чего начинается зрелая профилактика, — это учения. Команда администраторов СРК должна регулярно тренироваться восстанавливать системы в сжатые сроки, максимально приближенные к реальным. Цель в том, чтобы каждый четко знал свою зону ответственности и порядок действий, а не выяснял все в панике при настоящей аварии.
Здесь важно правильно понимать формат. Это не военные учения с внезапной тревогой, когда никто не знает, что произойдет. Наоборот, это заранее согласованные работы. Имитируется отказ конкретной системы, которую нужно восстановить, и к этому сценарию заранее формируется план работ, причем он должен быть по сути идентичен штатному регламенту восстановления. Получается своего рода проверка на прочность: известно, что именно «откажет», и команда отрабатывает действия по понятному алгоритму.
Смысл регулярности прост: то, что не отработано на практике, люди делают медленно, нервничают и совершают ошибки. Это подтверждает и мировая практика: даже самый лучший план восстановления провалится, если никто не знает, что делать, когда случится беда. Тренировки обучают всех участников их конкретным ролям и показывают, как всё сделать быстро и эффективно. При этом эксперты сходятся в том, что тестирование следует проводить регулярно, а не раз в год, и частые небольшие проверки часто эффективнее одной крупной ежегодной.
Здесь же стоит шире взглянуть на ответственность. План ликвидации аварий должен быть не только у администраторов СРК. Каждый, кто сопровождает или администрирует свою информационную систему, обязан понимать, что ему делать, если его система «упадет», а не просто перекладывать всё на СРК-команду. Современная практика подтверждает важность такого подхода: наиболее эффективные практики тестирования восстановления включают согласование объема теста с критичными для бизнеса сервисами — теми приложениями, системами и операционными зависимостями, которые важнее всего для выручки, соответствия требованиям и доверия клиентов.
Регулярное восстановление резервных копий
Второй краеугольный камень профилактики — это плановое восстановление копий, не связанное с имитацией аварии. Регулярно надо восстанавливать копии хотя бы критических сервисов в тестовую среду, а не в продуктивную, чтобы убедиться, что в копии действительно находится то, что нужно и в достаточном объеме и что эта копия консистентна и достаточна.
Зачем это делать? Чтобы администратор всегда понимал, что именно находится в копии, и чтобы «прогнать» восстановление в штатном режиме. В ходе таких проверок нередко всплывают неприятные сюрпризы: например, ошибка на стороне самой СРК или поврежденный объект, который система при этом показывала как полностью исправный. Это и есть так называемый «бэкап Шрёдингера» — копия, про которую невозможно сказать, рабочая она или нет, пока ее не попытаешься восстановить.
Самая опасная ситуация возникает в том случае, когда компания бэкапит что-то несколько лет и ни разу не восстанавливала. В момент аварии может оказаться, что копировалось не то или не в полном объеме. Профессиональный мир формулирует это предельно жестко. Успешное создание бэкапа лишь подтверждает: данные куда-то записались. Но настоящая проверка восстановления должна идти гораздо дальше и подтвердить три вещи:
- целостность данных: файлы не повреждены и читаются;
- работоспособность: приложения могут нормально использовать эти данные;
- скорость: восстановление укладывается в допустимые сроки (целевые показатели RTO и RPO).
Без такой проверки «галочка» об успешном бэкапе может быть обманчивой. Скрытые ошибки обязательно всплывут, но уже во время реального сбоя, когда будет поздно.
При этом «покрывать» тестовым восстановлением абсолютно всё нет смысла: СРК будет занята только тем, чтобы бесконечно восстанавливать копии, которые сама только что сделала. Поэтому регулярные восстановления в выделенную тестовую сетку проводят прежде всего для самых важных сервисов, критичность которых определяется на уровне организации. Полезный прием для проверки: можно взять БД, удалить из нее часть данных в тестовой среде и восстановить их из копии, убедившись, что механизм работает.
Аудит резервных копий и его фиксирование
Техническая проверка должна подкрепляться административной дисциплиной. В крупных компаниях это оформляется как аудит резервных копий. Руководство издает распоряжение, и ответственные сотрудники периодически проверяют валидность копий и работоспособность восстановленных систем, а результат фиксируют актами.
По сути, аудит и профилактика здесь смыкаются: аудит подразумевает именно проверку того, что инфосистема восстанавливается из копии и после этого остается работоспособной. Документальное подтверждение важно не только для внутреннего спокойствия, но и, например, при проверках на соответствие процессов резервного копирования требованиям бизнеса и регуляторов, в частности, стандартам ISO/IEC 27001, PCI DSS и ГОСТ Р 57580. При валидации результатов тестов имеет смысл использовать отчеты, скриншоты или логи. Такая практика превращает абстрактную уверенность «у нас всё бэкапится» в проверяемый и задокументированный факт.
План восстановления самой инфраструктуры СРК
Отдельное направление, о котором часто забывают, — восстановление работоспособности самой системы резервного копирования. Все привыкли думать о том, как СРК восстановит другие системы, но что произойдет, если она сама откажет или будет атакована?
Необходим согласованный план восстановления на случай отказа отдельных узлов или СРК целиком. Угроза может прийти из разных источников: это и шифровальщик, и физическая поломка оборудования, и неудачное обновление, после которого система просто перестает работать. Следует уметь реагировать на каждый из этих сценариев.
Готовность к восстановлению самой СРК: инструменты RuBackup
Для того чтобы быстро «поднять» систему резервного копирования после сбоя, полезно заранее сохранять ее конфигурацию и индексную базу копий всей инфраструктуры. Тогда при «падении» основного сервера — из-за обновления или атаки — можно развернуть новый, перенести на него сохраненную конфигурацию и индексную базу, и СРК снова станет работоспособной.
Эту задачу заметно упрощают отечественные инструменты. У СРК RuBackup от «Группы Астра» есть для подобных случаев загрузочные диски, позволяющие развернуть инфраструктуру заново и подключиться к уже имеющимся резервным копиям. Для среднего и малого бизнеса имеется отдельное решение RuBackup Oneclick, с его помощью можно развернуть серверную инфраструктуру практически с одного компакт-диска. Хотя это не основное назначение продукта, его удобно применять и для аварийного восстановления: быстро «поднять» на базовой конфигурации сам сервер RuBackup, подключить сохраненные конфигурации и базу с копиями, а затем восстанавливать остальную инфраструктуру.
Саму архитектуру RuBackup изначально проектировали с учетом требований отказоустойчивости. Центральный элемент системы — управляющий сервер. Он выполняет роль оркестратора: координирует выполнение задач резервного копирования и восстановления, управляет расписаниями, политиками хранения и взаимодействием со всеми остальными компонентами системы. Сам по себе он не хранит резервные копии, а отвечает за логику и управление процессами. Для обеспечения отказоустойчивости управляющего сервера в архитектуре предусмотрен резервный сервер. В случае выхода из строя основного управляющего узла резервный сервер берет на себя его функции, благодаря чему удается избежать простоя в работе системы и потери управляемости инфраструктуры резервного копирования. Отдельного внимания заслуживает служебная база данных, в которой хранятся метаданные, конфигурация и информация о выполненных заданиях. Как правило, она размещается на отдельном выделенном сервере, что снижает нагрузку на управляющий сервер и повышает общую устойчивость системы. Избыточность и отказоустойчивость самой БД обеспечивают не средства RuBackup, а штатные механизмы используемой СУБД — например, развертывание кластера на базе Patroni, который при сбое гарантирует автоматическое переключение на резервный экземпляр БД.
Такое разделение ролей между управляющим сервером, его резервной копией и вынесенной в отдельный кластер служебной СУБД позволяет построить отказоустойчивую архитектуру, в которой каждый компонент масштабируется и резервируется независимо, а отказ любого отдельного узла не приводит к остановке всей системы резервного копирования. Дополнительный уровень надежности обеспечивают встроенные механизмы целостности: автоматическая верификация сделанных резервных копий по размеру файлов, md5sum и электронной подписи.
Стоит отметить, что эти возможности активно развиваются: выход RuBackup 3.0 запланирован на июнь, и часть функций аварийного восстановления документируется именно в новом релизе.
Разделение на контуры и избыточность
Когда базовые процессы выстроены, имеет смысл укреплять архитектуру. Один из ключевых уроков, который компании выносят после серьезной атаки, — разделение на контуры безопасности. Вместо одной СРК создают отдельные инсталляции под разные категории данных: один контур хранения данных для внутреннего пользования, другой — для информации, открытой для всех, третий — для конфиденциальной или коммерческой, влияющей на финансы. Подробности о категориях данных можно узнать здесь.
Логика проста: чем чувствительнее информация, тем выше цена ее потери и тем больше оправданы вложения в ее изоляцию. Для банка, например, потеря данных клиентов может быть равносильна закрытию, а утечка персональных данных грозит колоссальными штрафами и серьезными последствиями любой организации. Разделение на контуры дополняется избыточностью и георезервированием, чтобы при заражении одной площадки можно было опереться на другую, не прерывая процессов СРК. Этот принцип хорошо согласуется с классическим правилом отрасли. Давняя лучшая практика в защите данных — это правило «3-2-1»: хранить минимум три копии на двух разных типах носителей, причем одну — за пределами площадки. Такова основа, но с развитием угроз ИБ-отрасль идет дальше. Современным является стандарт «3-2-1-1-0» — усиленная версия, появившаяся как ответ на угрозу программ-шифровальщиков. Самого по себе классического правила сегодня уже недостаточно: шифровальщики изменили математику. К базовой схеме «3-2-1» добавляются две дополнительные цифры: 1 — одна неизменяемая (immutable) копия, отключенная от сети (air-gap), и 0 — обязательная проверка того, что данные действительно восстанавливаются (то есть ноль ошибок при тестовом восстановлении). Таким образом, современный стандарт — это правило «3-2-1-1-0», которое добавляет к классической схеме одну неизменяемую (immutable) копию, отключенную от сети, и обязательную проверку того, что данные действительно восстанавливаются.
Итак, «3-2-1» защищает от обычных сбоев оборудования и единичных точек отказа, а «3-2-1-1-0» — еще и от шифровальщиков за счет неизменяемой и изолированной копии, а также гарантирует работоспособность бэкапов благодаря регулярному тестированию восстановления. Защита бэкапов от современных атак
Важно понимать, что характер атак изменился. Если раньше целью злоумышленников становилась в первую очередь продуктивная инфраструктура, то теперь все чаще удар наносят сначала по резервным копиям. Их шифруют, уничтожают или делают восстановление невозможным, и только потом атакуют рабочие системы. Поэтому безопасность самой резервной инфраструктуры выходит на первый план.
Здесь работает несколько уровней защиты. Внутреннюю инфраструктуру изолируют от внешней среды, на входящих контурах устанавливают средства защиты вроде чекпоинтов, а антивирус на серверах считается обязательной базой. Отдельного упоминания заслуживают отчуждаемые, или офлайн-копии, — физически отсоединенные от среды. Их принципиальное преимущество в том, что то, что «живет в шкафу» и не подключено к сети, невозможно атаковать из цифровой среды.
Дополнительно применяются программные средства защиты данных от изменения и перезаписи. Например, включается режим неизменяемости (immutable mode). В объектных хранилищах, таких как S3, эту защиту обеспечивает специальная функция Object Lock. Благодаря ей зашифровать или перезаписать резервную копию становится технически невозможно. Эта мера прямо отвечает современным требованиям к готовности против шифровальщиков. Готовность к требованиям защиты от программ-шифровальщиков поднимает планку еще выше: успешный тест восстановления должен подтвердить, что бэкапы неизменяемы, частично изолированы от продуктивного контура и привязаны к известной «чистой» точке восстановления. Иначе тест докажет, что восстановление технически возможно, но не подтвердит, что восстановленная копия безопасна для использования.
Административное разделение прав
Технические контуры стоит подкрепить административным разграничением. Распространенная, но рискованная ситуация — когда один администратор или одна группа администраторов имеет доступ сразу ко всем данным во всех системах. Гораздо безопаснее разграничить права так, чтобы каждый администратор отвечал за свой контур: кто-то за персональные данные, кто-то за коммерческие, кто-то за обычные.
При этом разделение на контуры не всегда означает обязательную покупку отдельной лицензи на СРК под каждый из них и раздувание штата. Современные системы умеют поддерживать разделение средствами мультитенантности: одна СРК делит хранилище на части, выстраивает отдельные стратегии, группы доступа и расписания, а разные администраторы работают каждый со своим сегментом данных. Это позволяет сохранить контроль и изоляцию без избыточных затрат, хотя серьезные вложения в инфраструктуру при защите по-настоящему критичных данных все равно остаются неизбежными.
Грамотная подготовка к обновлениям
Значительная доля проблем рождается не из атак, а из обычных рабочих операций — прежде всего обновлений. Перед любой потенциально деструктивной, а точнее, рискованной операцией нужно делать бэкап. Это распространенная и абсолютно нормальная практика: если после обновления что-то пошло не так, вы просто «откатываетесь» на сохраненную версию и спокойно продолжаете работу.
Помимо предварительного бэкапа, стоит заранее изучить процедуры отката (rollback), которые есть практически у любого продукта, и учитывать совместимость версий. Эту дисциплину разделяют и внешние эксперты: перед тестом восстановления следует подтвердить доступность бэкапов, определить целевые показатели RTO и RPO, подготовить тестовую среду и проверить процедуры отката. Отдельно важно помнить, что ИТ-ландшафт постоянно меняется. Бэкапы следует тестировать после крупных обновлений ПО, изменений оборудования, апгрейдов инфраструктуры или изменений в критичных системах данных, потому что такие изменения могут повлиять на то, насколько корректно продолжают работать копии и процедуры восстановления.
В конечном счете профилактика СРК — это инвестиция в спокойствие, которая окупается именно в тот момент, когда наступает «час Х». И заниматься ею, как и проверкой огнетушителя, нужно заранее, потому что во время пожара что-то менять уже поздно.