Бэкап и восстановление в SaaS

С момента вступления в силу ФЗ-420 от 30.11.2024 техническая архитектура бэкапа в SaaS стала элементом правового комплаенса. CTO, ответственный за инфраструктуру, оказывается в точке пересечения требований ФСТЭК, ФЗ-152 и уголовного права: ст. 272.1 УК действует с 11.12.2024 и предусматривает до 10 лет лишения свободы за незаконное обращение с компьютерной информацией, содержащей ПДн. Этот материал описывает, как правильно выстроить бэкап-архитектуру в SaaS, чтобы она не создавала дополнительных правовых рисков.

Почему бэкап в SaaS — это вопрос 152-ФЗ?

Резервная копия базы данных, содержащая персональные данные пользователей или клиентов, является информационной системой персональных данных (ИСПДн) в части хранения и систематизации. Это прямо следует из ст. 3 ФЗ-152: обработка ПДн включает хранение, извлечение и систематизацию. Бэкап содержит весь набор операций.

Из этого вытекает обязанность оператора применять меры защиты, соответствующие уровню защищённости ИСПДн по ПП РФ №1119. На практике большинство SaaS-компаний определяют УЗ-3 или УЗ-4 для пользовательских данных, однако резервные копии нередко хранятся с более слабыми контролями, чем основная система.

Три практических следствия для CTO. Первое: хранилище резервных копий должно быть включено в модель угроз и в технический паспорт ИСПДн. Второе: набор мер по Приказу ФСТЭК №21 (группы ЗНИ, РСБ, АВЗ) обязателен для backup-инфраструктуры так же, как для производственной. Третье: факт хранения бэкапа в иностранном облаке требует отдельного анализа с позиции ч. 5 ст. 18 ФЗ-152 (локализация) и ст. 12 ФЗ-152 (трансграничная передача).

Как выбрать уровень защищённости для backup-хранилища SaaS?

Уровень защищённости резервного хранилища не может быть ниже уровня основной ИСПДн. Это базовое правило ПП РФ №1119: УЗ определяется характеристиками всей системы обработки, а не отдельных её компонентов.

Матрица определения УЗ для типичного SaaS выглядит следующим образом. Если в системе обрабатываются специальные категории ПДн (состояние здоровья, национальность, политические взгляды — ст. 10 ФЗ-152) более 100 000 субъектов и угрозы 1-го типа не исключены — минимально применим УЗ-1. Для общих ПДн свыше 100 000 субъектов и угроз 2-го типа — УЗ-2. Большинство B2B SaaS с числом субъектов менее 100 000 и общими ПДн попадают в УЗ-3 или УЗ-4.

Практическая сложность: мультиарендная SaaS хранит данные разных клиентов в одном физическом хранилище. Если среди клиентов есть медицинские организации или HR-системы — весь бэкап может потребовать УЗ-2. При проектировании backup-архитектуры это означает разделение хранилищ по клиентским сегментам или применение унифицированного высокого уровня защиты ко всему хранилищу.

Облако для бэкапа: требования локализации и трансграничной передачи

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

Позиция РКН, последовательно применяемая с 2023 года: резервная копия ПДн, хранящаяся за рубежом, — это хранение в базе данных за пределами РФ. Апелляция к тому, что это «только бэкап», в судебной практике не работает.

Для SaaS-платформ, использующих AWS, Azure или GCP: размещение backup-хранилищ в регионах ru-central (Яндекс.Облако), Moscow (ВК Облако) или аналогичных российских регионах — обязательно для соответствия ч. 5 ст. 18. Гибридная схема «основная БД в РФ, бэкап за рубежом» нарушение не исключает.

Отдельный вопрос — объекты КИИ. Для SaaS, работающих в финансовом, медицинском или транспортном секторах и подпадающих под ФЗ-187, требования к хранению резервных копий определяются ещё и требованиями к КИИ-объектам, которые накладываются поверх ФЗ-152.

Обезличивание для ML: как использовать бэкап без нарушений?

Частая практика в SaaS-компаниях: использование production-дампов для обучения ML-моделей или тестирования. С точки зрения ФЗ-152 это создаёт самостоятельный правовой риск — использование ПДн для целей, не заявленных при сборе согласия (ст. 5, принцип соответствия целям).

Решение — обезличивание до использования. Приказ РКН (действует с 01.09.2025) определяет 5 методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение (агрегация). Для ML-задач наиболее применимы введение идентификаторов (псевдонимизация) и обобщение.

Ключевой момент для архитектуры: обезличивание должно происходить до копирования данных в среду разработки или ML-пайплайн, а не после. Хранение необезличенного production-дампа в dev-среде — нарушение принципа минимизации ПДн (ст. 5 ФЗ-152) и потенциально ст. 272.1 УК РФ, если доступ к данным получают лица без надлежащего основания. При этом логирование как ПДн — самостоятельная проблема: если в логах системы присутствуют идентифицирующие данные пользователей (email, IP, идентификаторы сессий), такие логи также подпадают под режим ИСПДн.

Поручение обработки и ответственность при мультиарендности

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

На практике это означает: договор с каждым SaaS-заказчиком должен содержать раздел о поручении обработки с перечнем действий с ПДн, перечнем ПДн и требованием к мерам защиты. Без такого раздела вендор превращается в «несанкционированного оператора» с полной ответственностью по ст. 13.11 КоАП.

Для backup-архитектуры это означает: вендор обязан обеспечить разграничение доступа к резервным копиям разных клиентов и не вправе использовать данные одного клиента в интересах другого или для собственных целей (обучение ML на клиентских данных без согласия — типичное нарушение).

Типовые сценарии и их правовые последствия

Сценарий 1. Бэкап в S3-совместимом хранилище иностранного облака. CTO настроил автоматическое резервное копирование в иностранный S3-endpoint, считая это «техническим решением». РКН при плановой проверке квалифицирует как нарушение ч. 5 ст. 18 ФЗ-152. Доказательства: конфигурация backup-агента, DNS-записи endpoint, договор с облачным провайдером. Вероятный исход: протокол по ч. 8 ст. 13.11 КоАП, штраф 1–6 млн ₽. Стратегия: до проверки — переход на российский облачный провайдер; после возбуждения дела — документирование факта переноса как смягчающее обстоятельство по ст. 4.2 КоАП.

Сценарий 2. Утечка из резервной копии — источник установлен. Хакерская атака на backup-хранилище привела к компрометации 15 000 записей пользователей SaaS-платформы (ФИО, email, телефоны). CISO фиксирует инцидент в 09:00. Обязательства: первичное уведомление РКН через ЕСИА — до 09:00 следующего дня (24 часа по ч. 3.1 ст. 21 ФЗ-152). Через 72 часа — отчёт по Приказу РКН №187. Неуведомление — штраф 1–3 млн ₽ по ч. 11 ст. 13.11 плюс штраф за саму утечку по ч. 13 — 5–10 млн ₽. Стратегия: инцидент-план с заранее подготовленными шаблонами уведомлений; готовый доступ к ЕСИА для должностного лица.

Сценарий 3. ML-команда использует production-дамп без обезличивания. Data scientist запросил свежий дамп для обучения модели. ИБ-служба не включила ML-среду в периметр ИСПДн. Доступ к необезличенным данным получили 5 сотрудников без надлежащего основания в ОРД. Риски: нарушение ст. 5 ФЗ-152 (обработка сверх целей), риск квалификации по ст. 272.1 УК (незаконное хранение/использование компьютерной информации с ПДн). Стратегия: внедрение pipeline обезличивания до передачи данных в ML-среду; включение ML-инфраструктуры в модель угроз ИСПДн; разграничение доступа в ОРД.

Как это применяется на практике

Кейс 1. SaaS-платформа для HR-автоматизации (Уральский ФО, осень 2024) хранила резервные копии кадровых данных 80 000 сотрудников клиентов в S3-хранилище европейского облачного провайдера. При плановой проверке РКН было установлено нарушение ч. 5 ст. 18 ФЗ-152. Компания перевела backup-хранилище на российского провайдера в ходе проверки, что было учтено судом. Штраф по ч. 8 ст. 13.11 КоАП составил сумму ближе к нижней границе диапазона. Выводы: перевод хранилища до выдачи предписания — существенное смягчающее обстоятельство.

Кейс 2. IT-компания (Центральный ФО, начало 2025) использовала production-дампы SaaS-платформы для обучения рекомендательной модели. ИБ-аудит, проведённый перед сделкой M&A, выявил: 12 сотрудников ML-команды имели доступ к необезличенным данным 200 000 пользователей без отражения этого в модели угроз и без оснований в ОРД. Потенциальный риск квалифицирован по ч. 1 ст. 13.11 КоАП и ст. 272.1 УК. Компания в рамках due diligence внедрила pipeline псевдонимизации и переработала ОРД. Сделка состоялась после подтверждения комплаенса.

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

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

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

1. Какой УЗ выбрать для SaaS?

УЗ определяется по матрице ПП РФ №1119: категория ПДн (общие/специальные/биометрические) умножается на тип актуальных угроз (1–3) и число субъектов (порог 100 000). Для большинства B2B SaaS с общими ПДн менее 100 000 субъектов и угрозами 3-го типа — УЗ-3. Если среди клиентов есть медицинские или HR-системы — необходимо пересмотреть в сторону УЗ-2. Резервное хранилище получает УЗ не ниже основной ИСПДн.

2. Можно ли использовать иностранные облака для бэкапа?

По ч. 5 ст. 18 ФЗ-152 хранение ПДн граждан РФ в базах данных за пределами РФ запрещено. Резервная копия, содержащая ПДн, — это база данных в понимании закона. Исключений для «технических» копий нет. Иностранный S3-endpoint для backup — нарушение, штраф по ч. 8 ст. 13.11 КоАП 1–6 млн ₽. Допустима схема: основное и резервное хранилище — в российских ЦОД, дополнительный архив за рубежом — только из обезличенных данных, соответствующих Приказу РКН по методам обезличивания.

3. Что такое обезличивание для ML и как его применять?

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

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

Оператором остаётся компания-заказчик, чьи данные обрабатываются в SaaS. SaaS-вендор действует как лицо, осуществляющее обработку по поручению оператора (п. 3 ст. 6 ФЗ-152). Это требует оформления договора поручения обработки с перечнем действий, перечнем ПДн и требованиями к мерам защиты. Без такого договора вендор может быть квалифицирован как самостоятельный оператор со всеми вытекающими обязанностями по ст. 22 ФЗ-152 (уведомление РКН) и ответственностью по ст. 13.11 КоАП.

5. Какие СЗИ обязательны при хранении резервных копий ПДн?

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

Итог

Бэкап и восстановление в SaaS — это полноценная часть ИСПДн, подпадающая под требования ФЗ-152, ПП РФ №1119 и Приказа ФСТЭК №21. Хранение резервных копий ПДн граждан РФ в иностранных облаках нарушает ч. 5 ст. 18 ФЗ-152. Утечка из backup-хранилища влечёт те же штрафы, что и утечка из основной ИСПДн, — вплоть до оборотных по ч. 15 ст. 13.11 КоАП при повторности.

DATUM сопровождает IT-компании и SaaS-вендоров в части технического комплаенса по 152-ФЗ: от аудита backup-инфраструктуры до разработки pipeline обезличивания для ML и формирования пакета ОРД для мультиарендных платформ.

14 апреля 2029 года