аналитика 14 января 2029 По состоянию на 14 января 2029

Геораспределённое хранение: локализация

Геораспределённое хранение ПДн граждан РФ — это обработка, при которой первичная запись, систематизация и хранение должны происходить на серверах в России, независимо от того, сколько ещё регионов или облаков задействовано.

С 01.07.2025 требование ч. 5 ст. 18 ФЗ-152 ужесточено: запрещён первичный сбор данных граждан РФ в зарубежной инфраструктуре. Нарушение — штраф от 1 до 6 млн ₽ по ч. 8 ст. 13.11 КоАП, при повторности — от 6 до 18 млн ₽.

Если вы CTO и ваш SaaS-продукт хранит ПДн в мультирегиональном облаке — проверьте, где происходит первичная запись. Риск начисляется не с момента проверки, а с момента нарушения.

Геораспределённая архитектура — стандартная практика для SaaS, нагруженных платформ и корпоративных систем: данные реплицируются между зонами доступности, регионами облака или собственными ЦОДами. До 2025 года трактовка ч. 5 ст. 18 ФЗ-152 позволяла хранить копию в России при наличии зарубежных реплик. После ужесточения это уже не так: первичная запись должна происходить в российском сегменте. Ниже — как это работает в связке с уровнями защищённости УЗ-1..4 (ПП РФ №1119), требованиями ФСТЭК (Приказ №21), обезличиванием для ML и распределением ответственности в мультиарендной SaaS.

Что изменилось в требованиях локализации с 01.07.2025?

Норма ч. 5 ст. 18 ФЗ-152 существует с 01.09.2015, но трактовалась по-разному. Позиция Роскомнадзора и арбитражная практика до 2024 года допускали «зеркальную» схему: первичная запись в России, синхронизация за рубеж. ФЗ-233 от 28.06.2025 закрыл эту возможность. Теперь под запрет подпадает любая схема, при которой данные граждан РФ впервые оседают на зарубежных серверах — даже на миллисекунды до репликации в Россию.

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

На практике это означает: если ваш SaaS-продукт принимает запрос пользователя из России через endpoint в регионе EU-West (AWS, GCP, Azure) и там же делает первичную запись в БД — это нарушение, даже если через 100 мс данные реплицируются в moscow-region. Правильная архитектура: endpoint маршрутизирует российских пользователей в российский регион (или российского облачного провайдера), где происходит первичная запись. Репликация в зарубежные зоны — только после этого и при соблюдении требований к трансграничной передаче по ст. 12 ФЗ-152.

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

Как выбрать уровень защищённости УЗ-1..4 для геораспределённой системы?

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

«ПП РФ №1119 — УЗ-1 требуется при наличии угроз 1-го типа для любых категорий ПДн. УЗ-3 — при угрозах 3-го типа для специальных ПДн менее 100 000 субъектов или общих ПДн более 100 000. УЗ-4 — при угрозах 3-го типа для общих ПДн менее 100 000 субъектов.»

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

Типовая матрица для SaaS-платформы с российскими B2B-клиентами: арендатор А — HR-модуль с данными сотрудников (общие ПДн, до 50 000 субъектов, угрозы 3-го типа) — УЗ-4. Арендатор Б — медицинская организация, данные пациентов (специальные ПДн, состояние здоровья) — минимум УЗ-3, при угрозах 2-го типа — УЗ-2. Арендатор В — банк с биометрией — УЗ-2 или выше. Архитектурно это требует как минимум логической изоляции данных арендаторов, а в ряде случаев — физической сегрегации на уровне БД или кластера.

Провели аудит архитектуры — не уверены в соответствии УЗ?

Если CTO определил уровень защищённости самостоятельно, без формальной модели угроз по ПП РФ №1119, — существует риск занижения УЗ. При проверке РКН или ФСТЭК это фиксируется как отсутствие требуемых мер по Приказу №21. Юристы и технические эксперты DATUM проведут аудит соответствия 152-ФЗ по чек-листу из 38 пунктов и выдадут отчёт с приоритизированным планом устранения нарушений.

Заказать аудит 152-ФЗ

Ответим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru

Что требует Приказ ФСТЭК №21 для облачной и распределённой инфраструктуры?

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

РСБ — регистрация событий безопасности (логирование). Логи с идентификаторами пользователей, IP-адресами, действиями — это сами по себе ПДн по позиции РКН. Если сервис логирования (ELK, Datadog, Splunk) находится за рубежом, возникает двойная проблема: нарушение локализации по ч. 5 ст. 18 и потенциальная трансграничная передача без уведомления. Решение: либо российский инстанс лог-сервиса, либо обезличивание перед отправкой (замена реальных идентификаторов на псевдонимы, не позволяющие восстановить личность без ключа, хранящегося в РФ).

ЗСВ — защита среды виртуализации. Для облачных систем на УЗ-1 и УЗ-2 требуется применение сертифицированных средств защиты виртуальной среды. Большинство иностранных гипервизоров (VMware, Hyper-V иностранных сборок) не имеют сертификата ФСТЭК в актуальных версиях. Российские альтернативы: «Горизонт-ВС», vGate, «Брест» и другие. При использовании публичного облака (Yandex Cloud, VK Cloud, SberCloud) провайдер, как правило, предоставляет аттестованный сегмент — проверьте его уровень и убедитесь, что он покрывает ваш УЗ.

ЗИС — защита информационной системы. Межсетевое экранирование и сегментация между нодами геораспределённой системы. При репликации данных между ЦОДами требуется шифрование канала с использованием СКЗИ (средств криптографической защиты), сертифицированных ФСБ, — для УЗ-1 и УЗ-2. Для УЗ-3 и УЗ-4 требование СКЗИ не обязательно, если канал защищён иными сертифицированными средствами.

Что подготовить CTO для соответствия Приказу ФСТЭК №21

Модель угроз и нарушителя в соответствии с методикой ФСТЭК (2021), с явным определением типа угроз 1/2/3 для каждой ИСПДн
Перечень применяемых мер защиты в формате таблицы: группа меры — базовый набор по УЗ — фактический статус (реализована / компенсирующая / неприменима)
Сведения об используемых СЗИ: наименование, версия, реквизиты сертификата ФСТЭК/ФСБ, срок действия сертификата
Договор с облачным провайдером с указанием уровня аттестации его инфраструктуры и распределением ответственности за меры защиты
Политика обработки ПДн и поручение обработки (ст. 6 ч. 3 ФЗ-152) — если провайдер обрабатывает данные по поручению оператора

Как работает обезличивание для ML в распределённой среде?

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

«Ст. 13.1 ФЗ-152 — обезличенные ПДн могут передаваться в Единую информационную платформу НСУД по требованию Минцифры. Методы обезличивания — по приказу РКН. Оператор обязан обеспечить невозможность деобезличивания без ключа, который хранится отдельно от обезличенных данных.»

В геораспределённой среде это означает следующую схему: исходные ПДн хранятся в российском сегменте (соблюдение ч. 5 ст. 18). Перед передачей в pipeline обучения — обезличивание одним из утверждённых методов на российском сервере. Обезличенный датасет может передаваться в зарубежные вычислительные мощности для обучения без требования локализации — поскольку ПДн в юридическом смысле уже нет. Ключ деобезличивания (таблица соответствия идентификатор → реальное значение) остаётся в России. Если модель возвращает предсказания, раскрывающие ПДн конкретного субъекта, — необходимо дополнительно оценить риск реидентификации и применить дифференциальную приватность или агрегацию.

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

Если CTO выстраивает ML-пайплайн на данных пользователей и не уверен, прошло ли обезличивание по методам РКН — необходимо оценить схему до запуска. После утечки обезличенного датасета, если РКН установит возможность реидентификации, штраф применяется как за утечку реальных ПДн. Срок на уведомление РКН об инциденте — 24 часа с момента обнаружения (ч. 3.1 ст. 21 ФЗ-152).

Провести DPIA

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

В мультиарендной SaaS распределение ролей между платформой и арендатором (клиентом) — ключевой вопрос ответственности по ФЗ-152. Возможны три сценария.

Сценарий 1. Платформа — обработчик по поручению арендатора. Арендатор загружает своих клиентов в CRM/HRM на платформе и определяет цели обработки. Платформа только хранит и обрабатывает данные в рамках инструкций арендатора. По ч. 3 ст. 6 ФЗ-152 арендатор — оператор, платформа — лицо, осуществляющее обработку по поручению. Между ними обязателен договор поручения обработки с перечнем разрешённых действий. Ответственность за нарушение перед субъектом несёт арендатор-оператор; платформа отвечает за техническую безопасность в рамках договора.

Сценарий 2. Платформа — самостоятельный оператор. Если платформа собирает ПДн напрямую от пользователей (регистрация, профиль, транзакции) в своих целях — она самостоятельный оператор, обязана уведомить РКН по ст. 22 ФЗ-152 и нести полную ответственность. В этом случае вопрос о том, кто клиент платформы, не имеет значения для ответственности перед субъектами.

Сценарий 3. Совместная обработка. Если платформа использует данные арендаторов для обучения собственных моделей, улучшения сервиса или аналитики — она перестаёт быть чистым обработчиком и становится соопоратором в части этих целей. Это требует самостоятельного правового основания: либо согласия субъекта с явным указанием платформы и её целей, либо иного основания по ст. 6 ФЗ-152.

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

Кейс 1. IT-компания (Приволжский ФО, осень 2025) предоставляла B2B-SaaS для HR-служб. Первичная запись ПДн сотрудников клиентов происходила в регионе EU-Central облачного провайдера, реплика — в российский ЦОД. При плановой проверке РКН технические специалисты DATUM зафиксировали нарушение ч. 5 ст. 18 ФЗ-152 и помогли перестроить маршрутизацию до завершения проверки. Протокол был составлен по ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽); в ходе сопровождения компания представила доказательства устранения нарушения и проведённых технических мер, что суд учёл при назначении наказания.

Кейс 2. Финтех-платформа (Центральный ФО, начало 2026) обучала антифрод-модель на данных транзакций пользователей. Датасет передавался в зарубежный GPU-кластер без предварительного обезличивания по методам РКН. После консультации с DATUM компания применила метод введения идентификаторов в связке с обобщением транзакционных сумм до диапазонов. Таблица соответствия осталась в российской инфраструктуре. После внедрения схемы формальное требование ст. 13.1 ФЗ-152 было выполнено, а риск квалификации передачи данных как трансграничной передачи ПДн — исключён.

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

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

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

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

Единого УЗ для всей платформы недостаточно, если клиенты обрабатывают ПДн разных категорий. По ПП РФ №1119 УЗ определяется для каждой ИСПДн отдельно. На практике это означает: либо архитектурная изоляция данных арендаторов с присвоением УЗ каждому сегменту, либо применение наивысшего УЗ ко всей платформе. Второй путь проще документально, но дороже технически: меры по УЗ-2 или УЗ-1 требуют сертифицированных СЗИ в группах ЗСВ, ЗИС, ИАФ.

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

Для первичной записи ПДн граждан РФ — нет. Иностранные облака (AWS, GCP, Azure, зарубежные регионы) не могут быть точкой первичного попадания данных. После записи в российской инфраструктуре репликация в иностранное облако технически допустима при соблюдении требований к трансграничной передаче по ст. 12 ФЗ-152 и уведомлении РКН о трансграничной передаче. Для вычислений (обучение ML, аналитика) без хранения ПДн — допустимо при условии предварительного обезличивания по методам РКН.

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

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

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

Зависит от конструкции договора и фактической роли. Если платформа обрабатывает данные исключительно по инструкции клиента-арендатора — она обработчик по поручению (ч. 3 ст. 6 ФЗ-152), клиент — оператор. Если платформа самостоятельно определяет цели обработки (аналитика, обучение моделей, улучшение сервиса) — она оператор в этой части и обязана уведомить РКН по ст. 22. Неоформленные договоры поручения — самостоятельное нарушение, фиксируемое при проверке.

5. Какие СЗИ обязательны для ИСПДн на УЗ-3 в облаке?

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

Итог

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

DATUM сопровождает IT-компании и SaaS-платформы в вопросах соответствия 152-ФЗ: от модели угроз и выбора УЗ до оформления договоров поручения и подготовки к проверке РКН. Практика ведётся с 2014 года в рамках сети «Ветров и партнёры».

АГ

Антон Громов

Аналитик · Технологии и ИБ

Аналитик DATUM по технологиям и информационной безопасности. Специализация — УЗ-1..4 (ПП РФ №1119), Приказ ФСТЭК №21, обезличивание ПДн для ML, SaaS-инфраструктура, реагирование на утечки, ст. 272.1 УК.

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