Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Непрерывность бизнеса и восстановление после катастроф

Введение

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

Что будет делать ваша организация? Кто принимает решения? Куда переезжают сотрудники? Когда восстановятся продажи?

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

Именно поэтому международная практика выработала два взаимодополняющих инструмента.

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

DRP — план восстановления после катастроф — технический документ, описывающий пошаговые процедуры восстановления ИТ-систем, данных и инфраструктуры после инцидента. DRP является частью BCM и активируется как один из его компонентов.

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

Эта тема замыкает технический блок курса. BCM опирается на оценку рисков из темы 5. Управление рисками , на криптографическую защиту резервных копий из темы 10. Аудит и криптография и является одним из обязательных контролей СУИБ, построение которой описано в теме 6. Создание СУИБ.

Ключевые понятия

BCP и DRP: в чём разница

Два термина, которые часто используют как синонимы, описывают разные, хотя и взаимосвязанные концепции.

Понятие Область Фокус Ключевой вопрос
BCP — план непрерывности бизнеса Весь бизнес Как организация продолжает работать во время и после инцидента Как сотрудники выполняют критические функции, пока ИТ-системы не восстановлены?
DRP — план восстановления после катастроф ИТ-инфраструктура Как технические системы возвращаются к нормальному состоянию Как и в какие сроки восстановить серверы, данные и приложения?

BCP — для бизнеса, DRP — для ИТ. BCP запускает DRP как один из своих компонентов, но не сводится к нему.

Целевые показатели восстановления

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

RTO — целевое время восстановления. Максимально допустимое время недоступности бизнес-процесса или ИТ-системы. RTO платёжной системы = 15 минут означает: если система не восстановится через 15 минут, ущерб становится неприемлемым.

RPO — целевая точка восстановления. Максимально допустимый объём потерянных данных, выраженный во времени. RPO = 1 час означает: система должна восстановить данные не старше одного часа. Это напрямую определяет максимальный интервал между резервными копиями — при RPO = 1 час резервирование раз в сутки недопустимо.

MAO — максимально допустимое время простоя с точки зрения бизнеса, после которого организация не сможет выжить. MAO всегда больше или равно RTO: RTO — технический показатель («когда система восстановлена»), MAO — бизнес-порог («когда уже слишком поздно»).

MTPD — максимальный допустимый период нарушения деятельности. Используется в стандарте ISO 22301 как аналог MAO.

Чем меньше RTO и RPO — тем дороже обходится обеспечение непрерывности. Горячий резерв с RTO = 5 минут требует полностью дублированной инфраструктуры, работающей постоянно. Выбор конкретных значений — бизнес-решение, основанное на оценке ущерба от простоя, а не техническое решение ИТ-отдела.

Цикл управления непрерывностью бизнеса

Управление непрерывностью — итеративный процесс. Стандарт ISO 22301:2019 описывает его как систему с шестью этапами, построенную по модели PDCA.

Этап 1. Политика и область применения

На этом этапе организация определяет цели программы BCM и её связь со стратегией бизнеса, область применения (какие подразделения и процессы охватываются), требования регуляторов и ключевых клиентов, а также назначает владельца программы — Business Continuity Manager.

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

Этап 2. Анализ влияния на бизнес (BIA)

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

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

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

Этап 3. Стратегия непрерывности

На основе BIA выбираются стратегии обеспечения непрерывности для каждого критического процесса. Подробное описание каждой стратегии — в разделе «Типы резервных площадок» ниже.

Стратегия Типичный RTO Относительная стоимость
Горячий резерв (Hot Standby) < 1 ч Очень высокая
Тёплый резерв (Warm Standby) 4–24 ч Средняя
Холодный резерв (Cold Standby) > 24 ч Низкая
Облачный резерв (Pilot Light / Multi-Region) Гибкий По факту использования
Ручные процедуры Немедленно Минимальная

Этап 4. Разработка планов BCP и DRP

На этом этапе стратегии превращаются в задокументированные процедуры.

BCP должен содержать критерии активации плана (кто и при каких условиях объявляет кризис), состав и полномочия кризисного штаба (Crisis Management Team), процедуры оповещения сотрудников и клиентов, порядок перемещения персонала на резервную площадку, ручные процедуры обхода недоступных ИТ-систем и список контактов — внешних и внутренних.

DRP должен содержать перечень систем в порядке приоритетности восстановления, пошаговые технические процедуры восстановления каждой системы, RPO и целевое время каждого шага, процедуру проверки работоспособности после восстановления и порядок возврата к штатному режиму работы (failback).

Критическое требование: планы должны быть доступны в офлайн-режиме. Если BCP и DRP хранятся только в системе, которая сама вышла из строя — их не существует. Всегда должны быть распечатанные экземпляры в защищённом месте и копии на изолированных носителях.

Этап 5. Тестирование и учения

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

Формат Суть Что выявляет Частота
Обзор документации Проверка актуальности планов без практики Устаревшие контакты, изменившаяся инфраструктура 2 раза в год
Настольные учения (Tabletop) Руководство разбирает сценарий инцидента в обсуждении Пробелы в процедурах, конфликты ответственности 1 раз в год
Функциональное тестирование Отдельные процедуры проверяются на практике: тест резервного копирования, тест оповещения Работоспособность конкретных технических механизмов Ежеквартально
Полноценные учения (Full-scale) Имитация реального инцидента с активацией резервных мощностей Реальное RTO, узкие места, человеческий фактор 1 раз в 1–2 года

После каждого тестирования составляется отчёт с выявленными проблемами и планом их устранения. Без этого тестирование теряет смысл.

Этап 6. Поддержание и улучшение

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

Типы резервных площадок

Выбор типа резерва определяется соотношением требуемого RTO и бюджета.

Горячий резерв (Hot Standby)

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

Архитектура. Основной и резервный ЦОД работают одновременно. Данные реплицируются синхронно — каждая транзакция подтверждается только после записи на обоих сайтах. Балансировщик нагрузки или DNS failover автоматически перенаправляет трафик на резервный сайт при недоступности основного.

В режиме Active-Active оба сайта одновременно обслуживают часть трафика — при отказе одного второй принимает весь объём. В режиме Active-Passive резервный сайт не обслуживает трафик, но готов принять его немедленно.

RPO и RTO. RPO = 0 при синхронной репликации, секунды — при асинхронной. RTO = секунды при автоматическом failover, минуты при ручном.

Стоимость. Максимальная — фактически удвоение всей инфраструктуры плюс выделенный канал с низкой задержкой (< 10 мс для синхронной репликации, что ограничивает расстояние между сайтами до 80–100 км).

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

Тёплый резерв (Warm Standby)

Тёплый резерв — промежуточный вариант. Резервная площадка оснащена оборудованием, системы запущены и частично настроены, но не принимают рабочий трафик.

Архитектура. Серверы запущены, ОС и СУБД работают, но актуальные данные загружаются из периодической асинхронной репликации или резервных копий. При активации DRP администраторы подключают последнюю резервную копию, переключают DNS и выполняют финальную проверку. Время активации — от 1 до 8 часов в зависимости от объёма данных и сложности конфигурации.

RPO и RTO. RPO — от 15 минут до нескольких часов. RTO — от 1 до 8 часов.

Стоимость. Средняя — оборудование резервной площадки может быть менее производительным, не требуется дорогостоящий канал с низкой задержкой.

Применение. Корпоративные ERP-системы, CRM, внутренние порталы.

Холодный резерв (Cold Standby / Cold Site)

Холодный резерв — площадка с базовой инфраструктурой (электропитание, охлаждение, сеть), где оборудование установлено, но не запущено. ПО не развёрнуто, данных нет.

Архитектура. При объявлении катастрофы команда восстановления разворачивает ПО из образов, восстанавливает данные из офлайн-резервных копий и последовательно запускает системы согласно DRP. Порядок критичен: сначала сетевая инфраструктура и Active Directory, затем СУБД, затем бизнес-приложения.

RPO и RTO. RPO — от нескольких часов до суток. RTO — от 24 до 72 часов и более.

Стоимость. Минимальная — оборудование может использоваться для других задач (тестирование, разработка) в штатном режиме.

Применение. Вспомогательные системы, внутренние инструменты, архивы.

Облачный резерв

Облачные провайдеры (AWS, Azure, Яндекс.Облако) радикально изменили экономику резервирования. Вместо постоянно работающей площадки организация хранит образы ВМ и реплики данных в облаке, а вычислительные ресурсы разворачивает только при активации DRP.

Pilot Light — только СУБД реплицируется в реальном времени, серверы приложений разворачиваются из образов при активации. RTO — 1–4 часа, стоимость значительно ниже тёплого резерва.

Multi-Region Active-Active — приложение работает в нескольких регионах одновременно. При отказе одного региона трафик автоматически перенаправляется. RPO = 0, RTO = секунды. Стоимость сопоставима с традиционным горячим резервом, но без капитальных затрат на оборудование.

Резервное копирование

Резервное копирование — фундамент DRP. Без актуальных резервных копий восстановление данных невозможно.

Типы резервных копий

Полная (Full) — копия всех данных. Долго создаётся, но быстро восстанавливается — достаточно одного файла.

Инкрементальная (Incremental) — только изменения с момента предыдущей резервной копии (полной или инкрементальной). Быстро создаётся, но долго восстанавливается: нужна полная копия плюс вся цепочка инкрементальных.

Дифференциальная (Differential) — изменения с момента последней полной копии. Компромисс: растёт со временем, но восстановление требует только полной копии и последней дифференциальной.

Снапшоты: особый случай

Снапшот (Snapshot) — мгновенный «слепок» состояния виртуальной машины, диска или базы данных. Снапшоты часто путают с резервными копиями, но между ними принципиальная разница.

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

Снапшот — инструмент быстрого восстановления от логических ошибок: «откатиться на 2 часа назад» можно за минуты. Но снапшот должен дополняться полноценным резервным копированием с выносом копий за пределы основной системы.

Защита резервных копий от ransomware

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

Защитные меры: неизменяемые резервные копии (immutable backups) с блокировкой удаления; офлайн-копии (air-gapped), физически или логически изолированные от сети; хранение резервных копий в отдельном tenant облака с независимыми учётными данными, не связанными с корпоративным каталогом.

Правило 3-2-1-1-0

Современный стандарт резервного копирования формулируется как правило 3-2-1-1-0:
  • 3 — три копии данных (основные данные + две резервные);
  • 2 — на двух разных типах носителей (например, SAN + объектное хранилище);
  • 1 — одна копия за пределами основной площадки (offsite);
  • 1 — одна копия в офлайне или в неизменяемом хранилище (air-gapped или immutable), недоступная через сеть — защита от ransomware;
  • 0 — ноль ошибок при проверке восстановления (копии верифицируются регулярно).

Последняя цифра — самая важная. Резервная копия, которую не проверяли — это не резервная копия, а иллюзия безопасности.

Криптографическая защита резервных копий

Резервные копии содержат те же данные, что и основные системы — часто это полные копии баз данных с персональными данными и коммерческой тайной. Требования: шифрование AES-256 для всех резервных копий, хранение ключей шифрования отдельно от зашифрованных данных, использование HSM для защиты ключей резервного копирования в критических системах.

С точки зрения 152-ФЗ, утечка данных с незашифрованной резервной копии — это та же утечка персональных данных, что и взлом основной системы.

Резервирование vs. резервное копирование

Это два разных механизма с разными целями. Их смешение приводит к опасным заблуждениям о реальном уровне защиты.

Характеристика Резервирование (Redundancy) Резервное копирование (Backup)
Цель Устранить единые точки отказа, обеспечить непрерывность при сбоях Восстановить данные после их потери или повреждения
Что защищает от Отказа оборудования, сетевых сбоев, потери питания Удаления данных, повреждения, шифрования ransomware, логических ошибок
Временной характер Работает постоянно, переключение автоматически Используется только при восстановлении
RPO Секунды или ноль Часы или сутки (зависит от расписания)
Защита от ransomware Нет — зашифрованные данные реплицируются мгновенно на все узлы Да — если копия создана до атаки и хранится изолированно
Защита от ошибок администратора Нет — удаление реплицируется немедленно Да — можно восстановить состояние до ошибки
Примеры RAID, кластер БД, балансировщик нагрузки, синхронная репликация Полная копия, инкрементальная копия, офлайн-лента

Почему кластер не заменяет резервную копию

Самая распространённая и опасная ошибка: «у нас кластер с синхронной репликацией — резервное копирование не нужно».

Ransomware. Шифровальщик запускается на одном узле. Синхронная репликация мгновенно распространяет зашифрованные данные на все узлы. Через минуты весь кластер зашифрован. Только изолированная резервная копия позволяет восстановиться.

Логическая ошибка. Разработчик выполняет `DELETE FROM orders WHERE status = 'cancelled'` на продакшн-базе вместо тестовой. Репликация немедленно распространяет удаление на все узлы. Кластер в идеальном состоянии — данных нет.

Повреждение данных (Corruption). Ошибка в коде приложения постепенно записывает некорректные данные на протяжении нескольких дней. Репликация добросовестно распространяет повреждение. Нужна копия из «точки до появления ошибки» — иногда недельной давности.

Уничтожение площадки. Если оба узла кластера находятся в одном здании, пожар или наводнение уничтожают всё.

Почему резервная копия не заменяет резервирование

Время восстановления. Восстановление данных объёмом несколько терабайт занимает часы. Если RTO = 15 минут — резервное копирование этого не обеспечит.

Доступность при сбоях оборудования. Если сервер вышел из строя, а замена оборудования займёт 4 часа, резервная копия не поможет сократить это время. Кластер с автоматическим failover продолжит обслуживать запросы секунды спустя.

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

Связь BCM с управлением рисками и СУИБ

BCM и управление рисками — взаимодополняющие, а не конкурирующие дисциплины. Риск-менеджмент отвечает на вопрос «что может пойти не так и насколько вероятно?», BCM — «что мы будем делать, когда что-то пошло не так?».

Результаты оценки рисков (ISO 27005) определяют сценарии для BIA: какие угрозы наиболее вероятны и критичны. BIA предоставляет данные для оценки ущерба от рисков — параметр воздействия в формуле риска из темы 5. Управление рисками . Планы BCP и DRP являются контролем 5.29 («Непрерывность информационной безопасности») в Приложении А ISO 27001. Инциденты ИБ — прежде всего ransomware, DDoS и целенаправленные APT-атаки — являются одним из основных триггеров для активации BCP.

Отсутствие BCP/DRP при прохождении сертификационного аудита ISO 27001 — это несоответствие (non-conformity), которое блокирует получение сертификата. Аудитор обязательно проверит наличие, актуальность и результаты тестирования планов непрерывности.

ISO 22301: международный стандарт BCM

ISO 22301:2019 — основной международный стандарт в области управления непрерывностью бизнеса. Определяет требования к BCMS и служит основой для сертификации.

Структура стандарта построена по модели PDCA: Plan (контекст, BIA, стратегия, планы), Do (реализация BCMS), Check (мониторинг, внутренний аудит), Act (анализ руководства, корректирующие действия).

Смежные стандарты: ISO 22317 (руководство по BIA), ISO 22318 (непрерывность цепочки поставок), ISO/IEC 27031 (непрерывность ИКТ-систем), ГОСТ Р 53647 (отечественный аналог).

Что дальше

Непрерывность бизнеса завершает блок управленческих и технических мер защиты. Последняя тема курса рассматривает ИБ в контексте разработки программного обеспечения — как выстроить защиту не вокруг готовой системы, а внутри неё на этапе проектирования.

Список литературы и стандартов

  • ISO 22301:2019 — Системы управления непрерывностью бизнеса. Требования
  • ISO 22317:2021 — Руководство по анализу влияния на бизнес
  • ISO/IEC 27031:2011 — Руководство по готовности ИКТ для обеспечения непрерывности бизнеса
  • ГОСТ Р 53647.1-2009 — Менеджмент непрерывности бизнеса. Практическое руководство
  • ГОСТ Р 53647.2-2009 — Менеджмент непрерывности бизнеса. Требования
  • NIST SP 800-34 Rev.1 — Contingency Planning Guide for Federal Information Systems
  • BCI Good Practice Guidelines — лучшие практики Business Continuity Institute
  • Snedaker S. — Business Continuity and Disaster Recovery Planning for IT Professionals. 2nd ed. Syngress, 2013

Обновлено С. Антошкин около 24 часа назад · 8 изменени(я, ий)