Serverless и 152-ФЗ

Serverless убирает из зоны контроля CTO управление серверами, но не убирает ответственность оператора за персональные данные. Функция, запускающаяся на чужой инфраструктуре за 50 миллисекунд, может создавать нарушение ч. 5 ст. 18 ФЗ-152, если регион её выполнения — Франкфурт или Вирджиния. В этом материале разобраны ключевые точки соответствия: выбор уровня защищённости (УЗ-1..4), локализация при мультирегиональном деплое, обезличивание данных для ML-пайплайнов, поручение обработки облачному провайдеру и логирование как источник ПДн.

Какой уровень защищённости нужен serverless-системе по ПП РФ №1119?

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

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

Практическая проблема serverless: границы ИСПДн размыты. Функция в AWS Lambda, очередь в SQS, БД в RDS и логи в CloudWatch — это одна ИСПДн или несколько? По позиции ФСТЭК система должна быть описана как единое целое с указанием всех компонентов. Декомпозиция на микросервисы не снижает УЗ — он определяется по максимальной категории ПДн, обрабатываемой хотя бы в одном компоненте системы.

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

Что нарушает требования локализации при serverless-деплое в иностранных облаках?

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

В serverless-архитектуре нарушение возникает в нескольких типичных сценариях. Первый: функция-обработчик запускается в регионе eu-west-1 и записывает профиль пользователя (ФИО, email, телефон) в DynamoDB в том же регионе. Второй: данные пишутся в российский регион, но репликация через Aurora Global Database копирует их в зарубежный регион для disaster recovery. Третий: функция записывает ПДн в объектное хранилище S3, настроенное на cross-region replication.

Штраф за нарушение локализации по ч. 8 ст. 13.11 КоАП составляет от 1 до 6 млн ₽ для юридических лиц. При повторном нарушении по ч. 9 — от 6 до 18 млн ₽. Факт нарушения устанавливается через технический анализ инфраструктуры: РКН вправе запросить у оператора подтверждение местонахождения баз данных.

Облако в РФ — не автоматическое решение проблемы. Yandex Cloud, VK Cloud, SberCloud и другие российские провайдеры предоставляют serverless-функции (Yandex Cloud Functions, VK Cloud Serverless) с гарантированным расположением данных в России. Однако оператор обязан зафиксировать это в договоре поручения обработки по п. 3 ст. 6 ФЗ-152 и убедиться, что провайдер не реплицирует данные за рубеж без уведомления РКН по ст. 12 ФЗ-152.

Как оформить поручение обработки ПДн облачному провайдеру?

Использование serverless-платформы облачного провайдера для обработки ПДн — это поручение обработки по п. 3 ст. 6 ФЗ-152. Оператор остаётся ответственным перед субъектом и РКН; провайдер действует только в рамках полученного поручения. Это ключевое разграничение для мультиарендной SaaS: провайдер (AWS, Yandex Cloud, VK Cloud) — лицо, осуществляющее обработку по поручению; SaaS-компания — оператор.

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

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

Обезличивание для ML: как законно обучать модели на персональных данных?

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

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

Логирование в serverless-системах — отдельный источник риска. Стандартные логи AWS CloudWatch или Yandex Cloud Logging могут содержать ПДн: IP-адреса пользователей (которые РКН квалифицирует как ПДн при привязке к конкретному лицу), фрагменты запросов с email или номером телефона, идентификаторы сессий. Если логи хранятся в иностранном регионе или передаются в систему мониторинга за рубежом — возникает вопрос локализации и трансграничной передачи по ст. 12 ФЗ-152.

Как это выглядит на практике: три сценария для CTO

Сценарий 1. SaaS с деплоем в AWS eu-central-1 (Франкфурт). CTO компании (Центральный ФО, лето 2025) при подготовке к проверке РКН обнаружил: функции AWS Lambda записывают профили российских пользователей в DynamoDB в регионе eu-central-1. Данные: ФИО, email, телефон, история действий — общие ПДн, около 80 000 субъектов. Нарушение ч. 5 ст. 18 ФЗ-152. Стратегия: миграция хранилища пользовательских данных в Yandex Cloud (Москва), переконфигурация функций на российский регион, заключение DPA с провайдером. Срок миграции — 6 недель. Уведомление РКН обновлено до начала проверки. Административного дела не возбуждалось.

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

Сценарий 3. Логи с ПДн в системе мониторинга. IT-компания (Приволжский ФО, начало 2026) использовала Datadog с регионом обработки в США для мониторинга serverless-функций. В логах обнаружены IP-адреса и фрагменты email из запросов. Квалификация: трансграничная передача ПДн в страну без адекватной защиты без уведомления РКН по ст. 12 ФЗ-152. Штраф по ч. 1 ст. 13.11 КоАП — в диапазоне от 150 тыс. до 300 тыс. ₽. Стратегия выхода: переход на российский провайдер мониторинга либо настройка фильтрации ПДн из логов до отправки в Datadog.

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

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

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

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

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

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

Хранение и первичная запись ПДн граждан РФ должны быть в российских базах данных по ч. 5 ст. 18 ФЗ-152. Использование AWS, Google Cloud или Azure допустимо только если функции не записывают ПДн в хранилища вне России. Вычислительная обработка (stateless-функции без записи ПДн) теоретически не нарушает локализацию — но граница размыта, и позиция РКН по stateless-обработке в иностранных облаках официально не зафиксирована. Безопасная стратегия — первичное хранение и запись в российском облаке.

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

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

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

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

5. Какие СЗИ обязательны для serverless-ИСПДн по Приказу ФСТЭК №21?

Приказ ФСТЭК №21 от 18.02.2013 определяет меры защиты по 15 группам; конкретный набор зависит от УЗ. Для УЗ-3 обязательны меры из групп ИАФ (многофакторная аутентификация для привилегированных пользователей), УПД (управление правами доступа к функциям и хранилищам), РСБ (регистрация событий ИБ), ЗИС (защита взаимодействия компонентов). В serverless-среде часть мер реализуется инструментами провайдера (IAM-роли, шифрование at rest и in transit, CloudTrail/Audit Log), но оператор обязан задокументировать их применение в модели угроз и отчёте о соответствии.

Итог

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

DATUM сопровождает IT-команды и CTO при аудите serverless-ИСПДн: определение УЗ по ПП РФ №1119, проверка соответствия Приказу ФСТЭК №21, оценка договоров поручения с облачными провайдерами, разработка политики обезличивания для ML. Практика — с 2014 года, специализация по техническому блоку 152-ФЗ.

12 февраля 2029 года