Бэкап в облаке: правовые риски

Облачный бэкап стал стандартной практикой для большинства IT-команд: дёшево, надёжно, масштабируется. Правовая сторона при этом остаётся в слепой зоне. С 30.05.2025 ст. 13.11 КоАП действует в редакции ФЗ-420 от 30.11.2024 — 18 частей вместо прежних семи, и несколько из них напрямую относятся к облачному хранению. В этой статье разберём, какие нормы применимы к бэкапу, как определить уровень защищённости по ПП РФ №1119, что обязателен при работе с иностранными облаками и где граница между поручением обработки и трансграничной передачей.

Почему бэкап с ПДн — это обработка, а не хранение «на всякий случай»?

Технический директор нередко полагает, что резервная копия — это просто копия, не «живые» данные, и требования ФЗ-152 к ней не применимы в полной мере. Это ошибочная позиция. Статья 3 ФЗ-152 определяет обработку как любое действие с персональными данными, включая накопление и хранение. Создание резервной копии — это накопление. Хранение бэкапа — хранение. Оба действия перечислены в определении обработки прямо.

Следствие первое: бэкап должен учитываться в уведомлении оператора в РКН по ст. 22 ФЗ-152. Если в уведомлении указаны одни места обработки, а реально данные хранятся ещё и в облаке — это расхождение между реестром и фактом. РКН в ходе проверки запрашивает точные адреса хранения, включая адреса дата-центров подрядчиков.

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

Следствие третье: категория ПДн в бэкапе определяет уровень защищённости всей системы резервного копирования. Если в бэкап попадают медицинские данные — это спецкатегория по ст. 10. Если попадают данные о сотрудниках с персональными идентификаторами — это биографические данные. Уровень защищённости определяется по наибольшей категории среди всех данных в резервируемой базе.

Как определить уровень защищённости для ИСПДн с облачным бэкапом?

Уровень защищённости (УЗ) определяется по ПП РФ №1119 от 01.11.2012. Матрица включает три переменные: категория ПДн (общие / специальные / биометрические / иные), тип актуальных угроз (1, 2 или 3) и число субъектов (пороговое значение — 100 000 человек). Для системы резервного копирования применяются те же правила, что и для основной ИСПДн — если бэкап содержит данные из неё.

Практически значимые сценарии для CTO:

• Общие ПДн, угрозы 3-го типа, менее 100 000 субъектов — УЗ-4. Минимальный набор мер по Приказу ФСТЭК №21, сертифицированные или прошедшие оценку соответствия СЗИ.
• Общие ПДн, угрозы 2-го типа или более 100 000 субъектов — УЗ-3. Добавляются меры по защите машинных носителей и контролю доступа на уровне СУБД.
• Специальные ПДн (здоровье, биометрия, судимости) при любом числе субъектов — не ниже УЗ-3, при угрозах 2-го типа — УЗ-2, при угрозах 1-го типа — УЗ-1.
• Биометрические ПДн — дополнительно регулируются ст. 11 ФЗ-152 и ФЗ-572, хранение в облаке вне ЕБС прямо ограничено.

Тип актуальной угрозы — ключевой параметр, который часто определяется формально. Угрозы 1-го и 2-го типа связаны с недокументированными возможностями в системном и прикладном ПО соответственно. Облачная инфраструктура общего пользования (AWS, GCP, OVH) по умолчанию не позволяет исключить угрозы 2-го типа — это напрямую повышает требуемый УЗ.

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

Облако в РФ или за рубежом: где граница и что говорит закон?

Российские облачные провайдеры (Яндекс.Облако, VK Cloud, SberCloud, ряд региональных) размещают данные в дата-центрах на территории РФ — требование локализации выполняется автоматически при условии, что договор это прямо фиксирует и в соглашении о поручении обработки указаны российские площадки. Если провайдер использует гео-репликацию на зарубежные точки — даже российский бренд не гарантирует соответствие ч. 5 ст. 18.

При использовании иностранного облака (AWS eu-central-1, GCP europe-west, Azure германские регионы и т. п.) ситуация квалифицируется по-разному в зависимости от конфигурации:

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

Для трансграничной передачи в страну без адекватной защиты (США, большинство азиатских юрисдикций) по ст. 12 ФЗ-152 требуется предварительное уведомление РКН. Перечень стран с адекватной защитой устанавливается приказом РКН — его актуальную редакцию следует проверять перед каждым изменением архитектуры хранения.

Поручение обработки, мультиарендность SaaS и логирование как ПДн

Когда оператор передаёт данные облачному провайдеру для резервного копирования, возникает отношение поручения обработки по п. 3 ст. 6 ФЗ-152. Оператор остаётся ответственным перед субъектом и РКН; провайдер обрабатывает данные строго в рамках полученного поручения. Договор должен содержать: цели обработки, перечень действий, обязанности по обеспечению конфиденциальности, меры защиты и условия уничтожения данных по окончании поручения.

В мультиарендной SaaS-архитектуре вопрос о том, кто является оператором, становится практически важным. Если SaaS-платформа хранит данные разных клиентов в общей облачной инфраструктуре:

• Каждый клиент — оператор в отношении своих данных.
• SaaS-провайдер — лицо, осуществляющее обработку по поручению (ст. 3 ФЗ-152).
• Договор с каждым клиентом должен содержать условия поручения — иначе провайдер фактически становится самостоятельным оператором без правового основания.

Логирование операций — отдельная зона риска. Системные логи содержат IP-адреса, идентификаторы сессий, временны́е метки действий конкретных пользователей. По позиции РКН, IP-адрес в совокупности с другими данными является персональным. Это означает, что логи — это ПДн, и к их хранению применяются все требования: локализация, уровень защищённости, срок хранения, поручение если логи передаются внешнему SIEM. Хранение логов в иностранном SIEM без уведомления РКН — потенциальное нарушение ч. 5 ст. 18.

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

Практические сценарии: как это работает

Сценарий 1. Бэкап в иностранном S3, оператор не уведомил РКН о трансграничной передаче. Ситуация: IT-компания Северо-Западного ФО, осень 2025 года, хранила резервные копии клиентской базы в AWS eu-central-1 (Франкфурт). Договор с AWS не содержал условий поручения обработки в смысле ФЗ-152. Внеплановая проверка РКН по жалобе бывшего сотрудника выявила несоответствие реестра фактическому расположению данных. Доказательства: выгрузка из системы резервного копирования, DNS-записи, договор с AWS. Вероятный исход: штраф по ч. 8 ст. 13.11 (1–6 млн ₽) плюс предписание привести данные в Россию в течение 30 дней. Стратегия на момент проверки: зафиксировать, что первичная база в РФ, оформить срочное уведомление о трансграничной передаче, заключить DPA с AWS в рамках ст. 12.

Сценарий 2. Мультиарендная SaaS, логи в иностранном SIEM, утечка через подрядчика. Ситуация: SaaS-провайдер Центрального ФО, первая половина 2026 года, передавал системные логи (включая IP пользователей) во внешний SIEM американского вендора без уведомления РКН. После инцидента с доступом к SIEM выяснилось, что логи 15 000 пользователей были скомпрометированы. Оператором перед клиентами является SaaS-провайдер. Исход: помимо штрафа по ч. 13 ст. 13.11 (5–10 млн ₽ за утечку данных 10 000–100 000 субъектов), возникает штраф по ч. 8 за локализацию и обязанность уведомить РКН за 24 часа по ч. 3.1 ст. 21 ФЗ-152. Стратегия: оперативное уведомление, перевод SIEM в российский сегмент, оформление поручения обработки задним числом — возможно только в части смягчения, но не устранения нарушения.

Сценарий 3. Обезличивание для ML выполнено методами, не соответствующими приказу РКН. Ситуация: компания из IT-сектора Уральского ФО, конец 2025 года, обезличила клиентскую базу хэшированием email-адресов и передала в облако для обучения модели. РКН при проверке установил, что хэши идентифицируемы при наличии исходной базы — обезличивание не соответствует методу «декомпозиция» или «изменение семантики». Данные квалифицированы как ПДн. Исход: обработка без правового основания — ч. 1 ст. 13.11 (150 000–300 000 ₽). Стратегия: применять методы обезличивания, утверждённые приказом РКН, документировать процедуру обезличивания и хранить подтверждение.

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

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

УЗ определяется по ПП РФ №1119 исходя из категории данных и типа актуальных угроз. Для большинства коммерческих SaaS с общими ПДн (имена, контакты, история заказов) и угрозами 3-го типа — УЗ-4. Если в данных есть специальные категории по ст. 10 ФЗ-152 (здоровье, биометрия) или число субъектов превышает 100 000 — не ниже УЗ-3. Для облачной инфраструктуры общего пользования без подтверждённого отсутствия недокументированных возможностей рекомендуется исходить из угроз 2-го типа — это автоматически повышает УЗ на один уровень.

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

Прямого запрета нет, но условия жёсткие. Первичное хранение ПДн граждан РФ должно быть в России по ч. 5 ст. 18 ФЗ-152. Зеркальная копия за рубежом — трансграничная передача, требующая уведомления РКН по ст. 12. Для стран без адекватной защиты (США, большинство азиатских юрисдикций) необходимо предварительное уведомление до начала передачи. Кроме того, облачный провайдер должен быть оформлен как лицо, осуществляющее обработку по поручению, с полноценным DPA в рамках российского права.

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

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

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

Оператором по ст. 3 ФЗ-152 является лицо, которое самостоятельно или совместно с другими определяет цели и способы обработки. В мультиарендной SaaS клиент определяет цели обработки своих данных — он оператор. SaaS-провайдер обрабатывает данные в рамках заданных клиентом целей — он лицо, осуществляющее обработку по поручению. Договор между ними должен явно фиксировать это разграничение и содержать условия из п. 3 ст. 6 ФЗ-152. При отсутствии такого договора РКН может признать SaaS-провайдера самостоятельным оператором со всеми вытекающими обязательствами.

5. Какие СЗИ обязательны для облачного бэкапа?

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

Итог

Бэкап с ПДн в облаке — это не технический вопрос, а правовой: три нормы (локализация по ч. 5 ст. 18, поручение обработки по п. 3 ст. 6, уровень защищённости по ПП РФ №1119) должны быть выполнены одновременно независимо от того, где физически находится облако. С 30.05.2025 цена ошибки измеряется миллионами рублей за каждый состав, а при повторном нарушении локализации — 6–18 млн ₽ по ч. 9 ст. 13.11 КоАП.

DATUM сопровождает IT-команды и технических директоров при аудите архитектуры хранения и резервного копирования, оформлении поручений с облачными провайдерами, определении УЗ и подборе мер по Приказу ФСТЭК №21. Практика по ФЗ-152 с 2014 года — без рейтингов, с конкретными результатами.

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

• Аудит соответствия 152-ФЗ — проверка архитектуры хранения, поручений и уровня защищённости
• DPIA (оценка воздействия) — для высокорисковой обработки в облачных системах
• Комплект ОРД под ключ — включая договор поручения с провайдером и политику бэкапа