План аварийного восстановления

План аварийного восстановления (Disaster Recovery Plan, DRP) — это документированный, формализованный набор процедур, политик и технических инструкций, определяющих порядок действий организации по восстановлению критически важных информационных систем, данных, инфраструктуры и бизнес-процессов после наступления чрезвычайной ситуации, сбоя, катастрофы или кибератаки. Основная цель плана — минимизировать время простоя (Downtime) и потери данных, обеспечив возврат к нормальному функционированию в заданные сроки (RTO и RPO).

Цели и ключевые метрики

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

• Целевая точка восстановления (Recovery Point Objective, RPO) — максимально допустимый период времени, за который могут быть потеряны данные в результате сбоя. RPO определяет, насколько «свежими» должны быть резервные копии. Например, RPO в 1 час означает, что резервное копирование должно производиться не реже одного раза в час.
• Целевое время восстановления (Recovery Time Objective, RTO) — максимально допустимое время, необходимое для восстановления работоспособности системы или сервиса после объявления катастрофы. RTO включает время на обнаружение проблемы, активацию плана, развертывание резервных мощностей и возврат к работе. Например, RTO в 4 часа означает, что система должна быть восстановлена в течение 4 часов с момента сбоя.

Эти метрики устанавливаются для каждого критического бизнес-процесса или информационной системы на этапе анализа бизнес-влияния (Business Impact Analysis, BIA).

Виды планов аварийного восстановления

Планы классифицируются по масштабу, объекту восстановления и стратегии:

По масштабу и объекту

• План восстановления центров обработки данных (Data Center DRP) — описывает восстановление физической или виртуальной инфраструктуры в случае полного отказа дата-центра (пожар, отключение электричества, затопление).
• План восстановления сетевой инфраструктуры (Network DRP) — фокусируется на восстановлении маршрутизации, коммутации, VPN-соединений и доступа в интернет.
• План восстановления приложений и баз данных (Application/DB DRP) — детализирует процедуры восстановления конкретных программных продуктов (ERP, CRM, 1С, Oracle, PostgreSQL) до работоспособного состояния.
• План восстановления облачных сервисов (Cloud DRP) — определяет порядок действий при сбое в облачной инфраструктуре (AWS, Azure, Яндекс.Облако), включая переключение на другой регион или провайдера.
• План восстановления рабочих мест (Workstation DRP) — описывает процедуры обеспечения сотрудников доступом к системам с резервных или удаленных рабочих мест.

По стратегии восстановления

• Холодное резервирование (Cold Standby) — резервная площадка не содержит активного оборудования. Для запуска систем требуется время на закупку, доставку и настройку. Минимальные затраты, максимальный RTO (дни или недели).
• Теплое резервирование (Warm Standby) — резервная площадка частично укомплектована оборудованием и сетевыми соединениями. Требуется ручная активация и синхронизация данных. RTO — от нескольких часов до суток.
• Горячее резервирование (Hot Standby) — резервная площадка полностью дублирует основную в реальном времени. Переключение происходит автоматически или за минуты. Максимальные затраты, минимальный RTO (минуты).
• Активно-активная схема (Active-Active) — нагрузка распределяется между двумя или более площадками, каждая из которых обрабатывает запросы. При отказе одной площадки нагрузка перераспределяется на оставшиеся. RTO стремится к нулю.

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

Типовой план аварийного восстановления включает следующие разделы:

1. Введение и цели: область действия плана, используемые термины (RPO, RTO), список критических систем.
2. Роли и ответственность: состав команды аварийного восстановления (DR Team), диспетчеры, технические специалисты (администраторы баз данных, сетевые инженеры), руководитель восстановления, ответственный за связь с руководством и внешними организациями. Указываются контактные данные и порядок эскалации.
3. Классификация инцидентов: критерии объявления катастрофы (например, отказ основного оборудования, потеря связи с дата-центром более чем на 30 минут, утечка данных с критическими последствиями). Описывается процедура принятия решения о запуске плана.
4. Процедуры уведомления: порядок оповещения членов команды, руководства, клиентов, партнеров и регуляторов (включая Роскомнадзор в случае утечки персональных данных). Может включать использование call-деревьев, SMS-рассылок, специализированных систем оповещения.
5. Пошаговые инструкции по восстановлению: детальные технические процедуры для каждого сценария (восстановление из резервной копии, переключение на резервную площадку, перезагрузка сервисов, восстановление сетевой топологии). Инструкции должны быть понятны дежурному персоналу и не требовать дополнительных разъяснений.
6. Инвентаризация ресурсов: перечень всего необходимого оборудования, программного обеспечения, лицензий, резервных копий, документации и контактов вендоров.
7. Процедуры тестирования и актуализации: регламент регулярных проверок плана (например, раз в квартал) и порядок внесения изменений при модернизации инфраструктуры.

Тестирование и актуализация

План аварийного восстановления не является статичным документом. Для поддержания его актуальности проводятся регулярные тестирования:

• Структурные проверки (Checklist Review): проверка полноты документации и контактов.
• Столкновение (Walkthrough): члены команды устно проходят по шагам плана, обсуждая возможные проблемы.
• Симуляция (Simulation): имитация катастрофы в учебном режиме, часто без реального воздействия на продуктивную среду.
• Параллельное тестирование (Parallel Test): восстановление систем на резервной площадке параллельно с основной, без переключения пользователей.
• Полномасштабное тестирование (Full Interruption Test): остановка основной системы и переключение всей нагрузки на резервную площадку. Наиболее рискованный, но и самый достоверный метод.

Результаты тестирования документируются, выявленные недостатки устраняются, а план обновляется.

Нормативное регулирование в России

В Российской Федерации разработка и наличие плана аварийного восстановления является обязательным или настоятельно рекомендуемым требованием для ряда организаций:

• Объекты критической информационной инфраструктуры (КИИ): в соответствии с Федеральным законом № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» субъекты КИИ обязаны обеспечивать непрерывность функционирования значимых объектов КИИ, что включает создание и поддержание планов восстановления.
• Операторы персональных данных: согласно требованиям Роскомнадзора и методическим рекомендациям ФСТЭК России, операторы должны иметь процедуры восстановления доступа к персональным данным и их защиты при инцидентах.
• Финансовый сектор: Банк России устанавливает требования к обеспечению непрерывности деятельности (ОНД) для кредитных и некредитных финансовых организаций, включая обязательное наличие планов аварийного восстановления и их регулярное тестирование.
• Государственные информационные системы (ГИС): для ГИС обязательна разработка планов восстановления работоспособности в соответствии с приказами Минцифры и ФСТЭК.

Примеры сценариев

1. Отказ основного сервера баз данных: план предусматривает автоматическое переключение на реплику (горячее резервирование) или ручное восстановление из последней резервной копии на резервном сервере (теплое резервирование). RTO — 15 минут, RPO — 5 минут.
2. Пожар в серверной: план инициирует переход на географически удаленную резервную площадку (холодное или теплое резервирование). RTO — 24 часа, RPO — 1 час. Включает процедуру закупки и доставки оборудования.
3. Кибератака (программа-вымогатель): план предписывает немедленное отключение зараженных систем от сети, запуск процедуры восстановления из изолированных (офлайн) резервных копий, а также уведомление правоохранительных органов (МВД, ФСБ).

Источники

• Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
• Методические документы ФСТЭК России по защите информации (в части обеспечения непрерывности работы и восстановления).
• Положение Банка России от 28.04.2021 № 757-П «Об обязательных резервах кредитных организаций» (в части требований к ОНД).
• Стандарт ISO/IEC 27031:2011 «Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity».
• NIST SP 800-34 Rev. 1 «Contingency Planning Guide for Federal Information Systems».
• ITIL (Information Technology Infrastructure Library) — раздел «Service Continuity Management».