Edge computing и ПДн

Edge computing в 2025–2026 годах активно применяется в промышленном IoT, ретейле, телемедицине и финтехе: данные обрабатываются там, где они возникают, — на камерах, POS-терминалах, медицинских устройствах. Для технического директора это означает распределённую архитектуру с десятками узлов, каждый из которых потенциально обрабатывает ПДн. Российское законодательство не делает исключений для периферийных вычислений: требования ФЗ-152, Приказа ФСТЭК №21 и ПП РФ №1119 распространяются на любую информационную систему персональных данных (ИСПДн), в том числе распределённую. Ниже — разбор ключевых норм, практика применения и конкретные шаги для CTO.

Как edge-архитектура меняет правовой периметр ИСПДн?

По ст. 3 ФЗ-152 обработка персональных данных — это любое действие с ними, включая сбор, запись, хранение, извлечение. Как только edge-узел записывает биометрические данные с камеры видеонаблюдения, журнал транзакций с POS-терминала или телеметрию пациента с медицинского сенсора — он становится частью ИСПДн. Оператор обязан распространить весь комплекс организационных и технических мер на каждый такой узел.

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

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

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

Какой уровень защищённости (УЗ) выбрать для edge-архитектуры?

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

Для edge-систем определение типа угроз — наиболее сложная задача. Тип 1 предполагает актуальность угроз, связанных с недокументированными возможностями системного ПО; тип 2 — с недокументированными возможностями прикладного ПО; тип 3 — только прочие угрозы. На периферийных устройствах зачастую используется стороннее встроенное ПО (firmware), проверить которое на отсутствие недокументированных функций затруднительно. Формально это толкает к типу 1 или 2, что повышает УЗ.

Типовые сочетания для edge-сценариев:

• Камеры видеонаблюдения с распознаванием лиц (биометрия, тип 3, до 100 000 субъектов) — УЗ-3, при превышении порога — УЗ-2.
• Медицинские сенсоры (специальные категории — состояние здоровья, тип 3, до 100 000) — УЗ-3.
• POS-терминалы (общие ПДн — ФИО, телефон, карта, тип 3, более 100 000 субъектов) — УЗ-3.
• Промышленный IoT с идентификацией работников (общие ПДн, тип 2, любое число субъектов) — УЗ-2.

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

Практическая сложность: для edge-устройства с ограниченными ресурсами развернуть сертифицированный СЗИ в полном объёме технически невозможно. Решение, которое используется на практике, — выносить хранение и обработку ПДн в центральный узел, оставляя на периферии только обезличенные или агрегированные данные. Это меняет классификацию периферийного узла: он перестаёт быть ИСПДн и выходит из периметра ПП №1119.

Как применять обезличивание для ML и аналитики на edge?

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

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

Логирование событий на edge-узлах создаёт отдельный правовой риск. Технические журналы, содержащие IP-адреса, идентификаторы пользователей, геолокацию, временные метки вместе с действиями — это ПДн. Хранение таких логов на edge-узле вне РФ нарушает ч. 5 ст. 18 ФЗ-152. Хранение без определения целей и сроков нарушает принцип ограничения хранения (ст. 5 ФЗ-152). Минимизация: логи уровня устройства должны либо не содержать идентификаторов субъектов, либо агрегироваться и передаваться в российский контур немедленно, без промежуточного хранения на узле.

Кто отвечает при утечке через edge-узел или подрядчика?

По принципу, закреплённому судебной практикой, оператор отвечает за утечку вне зависимости от того, произошла ли она на его оборудовании или через подрядчика. Договор поручения обработки по п. 3 ч. 1 ст. 6 ФЗ-152 не снимает ответственности оператора перед субъектом и регулятором — он лишь создаёт механизм регрессного требования к обработчику.

При обнаружении утечки с edge-узла — вне зависимости от причины — оператор обязан уведомить РКН в течение 24 часов с момента обнаружения (ч. 3.1 ст. 21 ФЗ-152). Через 72 часа — направить отчёт о результатах внутреннего расследования в соответствии с Приказом РКН №187 от 14.11.2022. Неуведомление влечёт штраф 1–3 млн ₽ по ч. 11 ст. 13.11 КоАП.

Размер штрафа за саму утечку зависит от числа затронутых субъектов: от 1 000 до 10 000 — ч. 12 ст. 13.11 (3–5 млн ₽); от 10 000 до 100 000 — ч. 13 (5–10 млн ₽); свыше 100 000 — ч. 14 (10–15 млн ₽). При повторной утечке применяется оборотный штраф по ч. 15: 1–3% совокупной годовой выручки, но не менее 20 млн ₽ и не более 500 млн ₽.

С 11.12.2024 действует ст. 272.1 УК РФ (введена ФЗ-421 от 30.11.2024): незаконное использование, передача, сбор или хранение компьютерной информации с ПДн влечёт уголовную ответственность. По ч. 5 — тяжкие последствия — до 10 лет лишения свободы. Для CTO, который своей подписью утвердил архитектуру с заведомо незащищённым edge-узлом, эта норма создаёт личный уголовный риск при наступлении тяжких последствий.

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

Три типовые ситуации, с которыми сталкиваются технические директора при масштабировании edge-архитектур в российских регуляторных условиях.

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

Сценарий 2. ML-модель на edge обучается на сырых ПДн. Ситуация: система компьютерного зрения на производственном объекте обучается на видеозаписях с изображениями лиц работников. Обезличивание не применяется. Доказательства: данные обучения хранятся на локальных серверах объекта без сертифицированных СЗИ. Вероятный исход: нарушение ст. 11 ФЗ-152 (биометрия без письменного согласия) + несоответствие УЗ по ПП №1119. Стратегия: применить метод введения идентификаторов или обобщения до начала обучения; получить отдельные письменные согласия работников на обработку биометрии; выполнить классификацию ИСПДн и внедрить меры по Приказу ФСТЭК №21.

Сценарий 3. Подрядчик предоставляет edge-оборудование без договора поручения. Ситуация: вендор промышленного IoT разворачивает edge-шлюзы на производстве клиента. В контракте — только поставка оборудования, доступ вендора к данным на шлюзах не ограничен. Доказательства: при проверке РКН выясняется, что вендор имеет технический доступ к ПДн работников и телеметрии. Вероятный исход: отсутствие договора поручения — нарушение п. 3 ч. 1 ст. 6 ФЗ-152; ответственность оператора за действия подрядчика. Стратегия: заключить договор поручения с вендором, ограничить технический доступ вендора к данным, включить требования ФЗ-152 в сервисный контракт.

Из практики DATUM. Технический директор розничной сети (Сибирский ФО, лето 2025) обратился после того, как в ходе технического аудита выяснилось: POS-терминалы в торговых точках сохраняли фрагменты платёжных данных и идентификаторы программы лояльности в локальных логах вне центрального ЦОД. Данные более 150 000 покупателей хранились без сертифицированной защиты. Мы провели классификацию ИСПДн (УЗ-3), сформировали пакет ОРД, ограничили хранение логов на терминалах и настроили немедленную агрегацию в российский ЦОД. До инициирования проверки РКН ситуация была урегулирована.

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

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

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

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

Уровень защищённости определяется отдельно для каждой ИСПДн. В мультиарендном SaaS каждый клиент-оператор несёт ответственность за классификацию своих данных — SaaS-провайдер как обработчик обязан обеспечить технические условия, позволяющие выполнить меры для самого высокого УЗ среди арендаторов. На практике это означает, что провайдер должен уточнять у клиентов категории обрабатываемых ими ПДн и фиксировать это в договоре поручения. Если хотя бы один арендатор обрабатывает специальные категории — платформа должна соответствовать не ниже УЗ-3.

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

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

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

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

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

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

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

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

Итог

Edge computing не создаёт исключений из ФЗ-152: каждый узел, обрабатывающий ПДн, — часть ИСПДн с соответствующим УЗ, набором мер ФСТЭК и требованием локализации. Ключевые точки принятия решений для CTO — классификация системы до развёртывания, архитектурное решение по обезличиванию на границе периметра и договоры поручения со всеми участниками цепочки обработки.

DATUM сопровождает технические команды на всех этапах: от классификации ИСПДн и моделирования угроз до формирования ОРД и подготовки к проверке Роскомнадзора. Опыт работы с распределёнными системами, IoT и мультиарендными SaaS-платформами позволяет сопоставить архитектурные решения с требованиями регулятора до возникновения нарушения.