Disaster recovery и 152-ФЗ

С 30.05.2025 действует новая редакция ст. 13.11 КоАП: штраф за утечку от 100 тыс. субъектов — 10–15 млн ₽ (ч. 14), за повторную утечку — оборотный штраф до 500 млн ₽ (ч. 15). DR-план перестал быть только вопросом RTO и RPO. Для IT-команды это документ, который проверяет Роскомнадзор в рамках плановой и внеплановой проверки. В этом материале — как правильно встроить требования 152-ФЗ в архитектуру disaster recovery: уровни защищённости, резервное копирование ПДн, локализация резервных баз, поручение обработки облачному провайдеру и порядок уведомления при инциденте.

Какие требования 152-ФЗ и ФСТЭК определяют архитектуру DR?

Статья 19 ФЗ-152 требует от оператора применять организационные и технические меры для обеспечения безопасности ПДн. Конкретный состав мер зависит от уровня защищённости информационной системы персональных данных (ИСПДн), который определяется по ПП РФ №1119 от 01.11.2012. Чем выше уровень — тем жёстче требования к непрерывности и резервированию.

Уровни защищённости устанавливаются в зависимости от трёх факторов: категория ПДн (специальные, биометрические, иные), тип угроз (1, 2 или 3) и количество субъектов (пороговое значение — 100 тыс. человек). УЗ-1 — самый жёсткий: специальные категории + угрозы 1-го типа. УЗ-4 — базовый: иные ПДн, менее 100 тыс. субъектов, угрозы 3-го типа.

Приказ ФСТЭК №21 содержит 109 мер в 15 группах. Для DR-архитектуры критичны три группы: ОДТ (обеспечение доступности технических средств), РСБ (регистрация событий безопасности) и ЗИС (защита информационной системы). Меры группы ОДТ включают резервирование технических средств и данных, восстановление ПДн при отказах и уничтожении носителей. На УЗ-1 и УЗ-2 эти меры обязательны в базовом наборе; на УЗ-3 и УЗ-4 — применяются исходя из модели угроз.

Важный момент для SaaS и мультиарендных систем: если в одной ИСПДн обрабатываются данные нескольких клиентов-операторов с разными уровнями защищённости, система в целом должна соответствовать наивысшему уровню среди всех арендаторов. Это требование напрямую влияет на проектирование резервного сайта и DR-процедур.

Как локализация ПДн ограничивает выбор DR-площадки?

Часть 5 ст. 18 ФЗ-152 обязывает записывать, систематизировать, накапливать, хранить, уточнять и извлекать персональные данные граждан России в базах данных, расположенных на территории РФ. Это требование распространяется на резервные копии: резервная база данных, содержащая ПДн граждан РФ, должна храниться на российской площадке.

С 01.07.2025, согласно ФЗ-233, ужесточение локализации исключает схему, при которой первичная запись происходит за рубежом с последующей репликацией в Россию. Теперь первичная запись обязана осуществляться в российской базе. Это меняет DR-топологию: основной и резервный сайты должны располагаться в РФ; зарубежный сайт, если он используется, может быть только для данных, не являющихся ПДн граждан РФ (или для обезличенных данных).

Облачные провайдеры — AWS, GCP, Azure — имеют регионы в России, однако нужно проверять актуальный статус их доступности и договорные условия. Отечественные облака (Яндекс Облако, SberCloud, МТС Cloud, Selectel, Облако.ру) по умолчанию соответствуют требованию локализации. При использовании любого облачного провайдера для хранения резервных копий ПДн необходимо заключить договор поручения обработки по п. 3 ст. 6 ФЗ-152 и убедиться, что провайдер обеспечивает меры защиты не ниже требуемого УЗ.

Трансграничная передача ПДн (в том числе репликация резервной копии в зарубежный датацентр) до начала передачи требует уведомления РКН по ст. 12 ФЗ-152. Если страна назначения не включена в перечень адекватной защиты — нужно пройти процедуру оценки РКН. Штраф за нарушение локализации — ч. 8 ст. 13.11 КоАП, 1–6 млн ₽; повторно — 6–18 млн ₽ по ч. 9.

Что входит в DR-документацию по требованиям 152-ФЗ?

Статья 18.1 ФЗ-152 обязывает оператора обеспечить документальное подтверждение принятых мер защиты. Для DR-систем обработки ПДн минимальный комплект организационно-распорядительной документации (ОРД) включает несколько обязательных документов.

Отдельного внимания требует логирование. По Приказу ФСТЭК №21, группа мер РСБ предусматривает регистрацию событий безопасности: доступ к ПДн, изменения конфигурации, попытки несанкционированного доступа. Логи, содержащие идентификаторы пользователей и записи о доступе к ПДн, сами по себе могут являться персональными данными — это нужно учитывать при проектировании хранилища логов в DR-инфраструктуре. Хранение логов с ПДн за рубежом также подпадает под требование локализации.

Для объектов критической информационной инфраструктуры (КИИ) по 187-ФЗ действуют дополнительные требования к непрерывности и восстановлению — они накладываются поверх требований 152-ФЗ и в случае пересечения применяются оба режима.

Как обеспечить соответствие DR обезличиванию данных для ML и резервных копий?

Часть ML-систем обучается на исторических данных, которые выгружаются из production-баз, содержащих ПДн. Если эти данные не обезличены до выгрузки, резервная копия датасета является базой ПДн со всеми вытекающими требованиями: локализация, УЗ, поручение обработки, согласие субъектов.

С 01.09.2025 действует Приказ РКН №140 (5 методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация). Обезличенные данные по ст. 13.1 ФЗ-152 выходят из-под режима персональных данных при условии необратимости обезличивания — то есть невозможности идентификации субъекта без дополнительной информации. Это позволяет хранить датасеты для ML в зарубежных облаках без нарушения локализации.

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

Как действовать при инциденте в DR-цепочке: уведомление РКН за 24 и 72 часа

Инцидент, при котором возникла угроза или факт утечки ПДн в ходе DR-переключения или сбоя резервного сайта, требует немедленного запуска процедуры по ч. 3.1 ст. 21 ФЗ-152. Порядок уведомления определён Приказом РКН №187 от 14.11.2022.

Первичное уведомление направляется в РКН в течение 24 часов с момента обнаружения инцидента. В нём указываются: дата и время обнаружения, предположительная причина, категории и объём затронутых ПДн, предпринятые меры. Через 72 часа — отчёт о результатах внутреннего расследования с уточнёнными данными о субъектах, причинах и принятых корректирующих мерах.

Типичная ошибка в DR-сценариях: команда ИБ фиксирует инцидент как технический сбой и не квалифицирует его как утечку ПДн до завершения расследования. Если за это время истекают 24 часа — РКН квалифицирует просрочку как нарушение ч. 11 ст. 13.11 независимо от итогов расследования. Регламент DR должен содержать явный критерий: при любом неконтролируемом доступе к резервной копии с ПДн или нештатном переключении на резервный сайт — автоматически запускается процедура уведомления с одновременным продолжением расследования.

Практика: как нарушения DR-архитектуры проявляются при проверках

Кейс 1. IT-компания (Сибирский ФО, осень 2025) хранила резервные копии ПДн клиентов в объектном хранилище европейского облачного провайдера. При плановой проверке РКН затребовал договор поручения обработки с провайдером и уведомление о трансграничной передаче. Договор был, уведомление — нет. Компания получила предписание об устранении и протокол по ч. 8 ст. 13.11 (хранение в иностранном облаке как нарушение локализации). Штраф составил несколько миллионов рублей. После публикации предписания компания перенесла бэкапы на отечественный облачный провайдер в течение 30 дней.

Кейс 2. SaaS-платформа (Центральный ФО, начало 2026) при DR-переключении на резервный сайт допустила кратковременный доступ подрядчика к базе ПДн пользователей (около 15 тыс. субъектов). Инцидент был обнаружен через 6 часов, но в РКН уведомили только через 31 час — из-за внутренних согласований. РКН возбудил дело по ч. 11 ст. 13.11 (несвоевременное уведомление об инциденте). В арбитражном суде компания представила доказательства оперативности расследования и применения корректирующих мер; штраф был снижен, однако производство по делу не было прекращено. Регламент DR был переработан — порог запуска уведомления снижен до первых признаков инцидента.

Типовые сценарии нарушений при DR и стратегии защиты

Сценарий 1. Резервные копии хранятся в иностранном облаке без уведомления РКН. Ситуация: бэкапы ПДн граждан РФ реплицируются в AWS eu-west-1 или аналогичный иностранный регион. Доказательства нарушения: инвентаризация облачных ресурсов в ходе проверки или аудита — обнаруживается хранение без уведомления о трансграничной передаче. Вероятный исход: ч. 8 ст. 13.11 КоАП, штраф 1–6 млн ₽. Стратегия: перенос резервных копий на российские площадки или немедленное уведомление РКН с оценкой страны, оформление договора поручения обработки. Обезличенные данные могут оставаться за рубежом при соблюдении методов по Приказу РКН №140.

Сценарий 2. Отсутствует договор поручения обработки с облачным провайдером DR-сайта. Ситуация: компания использует отечественное облако для резервного сайта, но договор с провайдером не содержит положений о поручении обработки ПДн по п. 3 ст. 6 ФЗ-152. Доказательства: при проверке РКН запрашивает договор — в нём нет перечня ПДн, целей и мер защиты. Вероятный исход: ч. 1 ст. 13.11 КоАП (обработка ПДн без надлежащего основания), штраф 150–300 тыс. ₽; при повторности — ч. 1.1, до 500 тыс. ₽. Стратегия: добавить в договор с провайдером приложение о поручении обработки с обязательными реквизитами; зафиксировать меры защиты, которые провайдер обязуется применять.

Сценарий 3. При DR-восстановлении нарушена целостность журналов событий ИБ. Ситуация: в ходе катастрофического отказа основного сайта и переключения на резервный логи РСБ за период инцидента утеряны или недоступны. Доказательства нарушения: меры группы РСБ по Приказу ФСТЭК №21 не выполнены — нет защищённого внеплощадочного хранилища логов. Вероятный исход: предписание ФСТЭК и РКН, штраф по ч. 1 ст. 13.11 за несоответствие мерам ст. 19 ФЗ-152. Стратегия: вынести SIEM и хранилище логов на отдельный независимый сегмент с репликацией на резервный сайт; протестировать доступность логов в DR-учениях.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка DR-архитектуры, УЗ, ОРД, договоров с облачными провайдерами по чек-листу из 38 пунктов.
• DPIA (оценка воздействия) — оценка рисков обработки ПДн в DR-системах, включая трансграничные сценарии и ML-датасеты.
• Комплект ОРД под ключ — модель угроз, акт классификации, договор поручения, регламент DR, журналы — под конкретный УЗ.

Частые вопросы

1. Какой УЗ выбрать для SaaS с данными нескольких клиентов-операторов?

Уровень защищённости мультиарендной SaaS-системы определяется по наивысшему УЗ среди всех арендаторов. Если хотя бы один клиент обрабатывает специальные категории ПДн (например, медицинские данные) — вся система должна соответствовать УЗ, применимому к спецкатегориям по ПП РФ №1119. Это означает обязательную реализацию мер ФСТЭК Приказа №21 для этого УЗ в полном объёме, включая DR-компоненты. Альтернатива — изолировать арендаторов с разными категориями данных в отдельные ИСПДн с независимой классификацией.

2. Можно ли использовать иностранные облака для резервных копий ПДн граждан РФ?

С 01.07.2025 — нет. Требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на хранение ПДн граждан РФ, включая резервные копии. Хранение бэкапов в иностранном облаке без перемещения первичной базы в РФ нарушает ч. 5 ст. 18 и квалифицируется по ч. 8 ст. 13.11 КоАП — штраф 1–6 млн ₽. Исключение: если данные необратимо обезличены по методам Приказа РКН №140 до выгрузки в иностранное хранилище — локализация не требуется, так как обезличенные данные не являются ПДн по ст. 13.1 ФЗ-152.

3. Что такое обезличивание для ML и как это связано с DR?

Обезличивание для ML — применение одного из 5 методов Приказа РКН №140 к production-данным перед их выгрузкой в обучающий датасет: введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение. Обезличенный датасет выходит из режима ПДн по ст. 13.1 ФЗ-152 и может храниться без требований к локализации и УЗ. В DR-контексте: резервные копии обезличенных датасетов можно размещать в иностранных облаках; резервные копии необезличенных данных — только в РФ. Этот статус каждой резервной копии должен быть явно задокументирован в регламенте DR.

4. Кто является оператором ПДн в мультиарендной SaaS?

Оператором ПДн конечных пользователей является клиент SaaS (арендатор), который определяет цели и способы обработки. SaaS-провайдер в общем случае является лицом, осуществляющим обработку по поручению оператора (п. 3 ст. 6 ФЗ-152). Это означает: договор между арендатором и провайдером должен содержать поручение обработки с перечнем ПДн, целями и мерами защиты. В DR-сценарии провайдер несёт ответственность за соблюдение условий поручения в том числе при переключении на резервный сайт — если провайдер нарушает условия поручения (например, реплицирует данные за рубеж без уведомления), ответственность может быть возложена и на него как на нарушителя условий договора.

5. Какие средства защиты информации обязательны для ИСПДн с DR?

Конкретный состав сертифицированных СЗИ зависит от УЗ. По Приказу ФСТЭК №21, для УЗ-1 и УЗ-2 ряд мер требует применения СЗИ, прошедших оценку соответствия: средства защиты от несанкционированного доступа, межсетевые экраны, средства антивирусной защиты и обнаружения вторжений. Для DR-инфраструктуры это означает: канал репликации должен быть защищён сертифицированными СКЗИ при передаче по открытым каналам; резервный сайт должен иметь тот же набор сертифицированных СЗИ, что и основной. Перечень сертифицированных СЗИ — Государственный реестр ФСТЭК.

Итог

Disaster recovery для систем с ПДн — это пересечение двух регуляторных режимов: требований 152-ФЗ к безопасности ПДн и требований ФСТЭК к мерам защиты ИСПДн. Конкретный состав мер определяется УЗ, который нужно корректно рассчитать по ПП РФ №1119 с учётом мультиарендности. Резервные копии ПДн граждан РФ обязаны храниться на российских площадках; облачный провайдер DR-сайта должен быть оформлен как обработчик по п. 3 ст. 6 ФЗ-152. При инциденте в DR-цепочке — 24 часа на первичное уведомление РКН без права на согласование.

DATUM сопровождает IT-команды при построении DR-документации по 152-ФЗ: от классификации ИСПДн и модели угроз до договоров поручения с облачными провайдерами и регламентов реагирования на инциденты. Аудит DR-архитектуры выявляет несоответствия до проверки РКН.

14 января 2029 года