DATUM-аудит облачной инфраструктуры

Облачная инфраструктура стала стандартом для IT-команд: Kubernetes-кластеры, мультиарендные SaaS-платформы, ML-пайплайны на основе персональных данных. Каждый из этих слоёв создаёт самостоятельную точку правового риска по 152-ФЗ. Для CTO вопрос уже не в том, нужен ли аудит, — а в том, что именно он охватывает и какой уровень защищённости назначить конкретной информационной системе. Материал разбирает методологию DATUM-аудита облака: от классификации ИСПДн до поручения обработки подрядчику.

Почему облачная архитектура создаёт отдельные риски по 152-ФЗ?

Стандартный on-premise периметр чётко разделяет оператора и его ИСПДн. В облаке граница размыта: физические серверы принадлежат провайдеру, ПО развёрнуто клиентом, данные обрабатываются в общей инфраструктуре. Это порождает три правовые проблемы одновременно.

Первая — неопределённость роли облачного провайдера. Если провайдер только предоставляет вычислительные мощности и не имеет доступа к данным, он не является лицом, осуществляющим обработку по поручению в смысле п. 3 ч. 3 ст. 6 ФЗ-152. Если же провайдер администрирует платформу, выполняет резервное копирование или имеет техническую возможность доступа к данным — договор поручения обязателен. Без него оператор нарушает ч. 5 ст. 6 ФЗ-152, что квалифицируется по ч. 1 ст. 13.11 КоАП с санкцией 150 000–300 000 ₽ за первичное нарушение.

Вторая — локализация. Требование ч. 5 ст. 18 ФЗ-152 распространяется на операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан РФ: эти операции должны выполняться только в базах данных на территории России. Облако с нодами в Европе или США — типовое нарушение по ч. 8 ст. 13.11 КоАП, санкция 1–6 млн ₽.

Третья — мультиарендность. В мультиарендной SaaS несколько клиентов-операторов хранят ПДн своих субъектов в одной инфраструктуре. Разработчик платформы при этом сам становится лицом, осуществляющим обработку по поручению каждого клиента. Если SaaS-провайдер не осознаёт эту роль и не заключает договоры поручения, каждый клиент-оператор несёт риск ч. 1 ст. 13.11 КоАП.

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

Уровень защищённости (УЗ) назначается по матрице ПП РФ №1119 от 01.11.2012. Три параметра: категория ПДн, тип угроз (1–3) и количество субъектов (порог 100 000). Для облачных систем ключевое значение имеет тип угроз.

Угрозы 1-го типа актуальны, если в ИСПДн есть недокументированные возможности в системном ПО. Угрозы 2-го типа — при недокументированных возможностях в прикладном ПО. Угрозы 3-го типа — без таких допущений. На практике большинство коммерческих облачных систем получают УЗ-3 или УЗ-4. УЗ-1 и УЗ-2 применяются в государственных ИСПДн или при обработке спецкатегорий с высоким числом субъектов.

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

Что проверяет DATUM-аудит в облачной инфраструктуре?

Аудит структурирован по семи блокам. Каждый соответствует отдельной точке правового риска для CTO.

Блок 1. Реестр ИСПДн и классификация. Составляется перечень всех информационных систем, обрабатывающих ПДн: продуктовые базы, CRM, аналитические хранилища, логи, ML-датасеты. Для каждой — категория ПДн, число субъектов, тип угроз, итоговый УЗ. Типовая проблема: облачные среды разработки (dev/staging) содержат копии продуктовых данных, но не включены в реестр.

Блок 2. Договоры поручения. Проверяется наличие договоров с облачными провайдерами, CDN, мониторинговыми сервисами, CI/CD-платформами. Предмет договора должен ограничивать перечень допустимых действий с ПДн и обязывать провайдера соблюдать конфиденциальность. Отсутствие договора при фактическом доступе провайдера — нарушение ч. 1 ст. 13.11 КоАП.

Блок 3. Локализация. Анализируется размещение нод, репликаций, резервных копий. Для каждой операции по ч. 5 ст. 18 ФЗ-152 устанавливается физическое расположение. Трансграничная передача обезличенных данных в рамках ML-пайплайнов — отдельная точка: обезличивание должно быть реальным (не псевдонимизация), методы — по Приказу РКН о методах обезличивания (введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение).

Блок 4. Технические меры по Приказу ФСТЭК №21. Для назначенного УЗ проверяется выполнение базового набора мер. Типовые пробелы в облаке: отсутствие сегрегации трафика между арендаторами (ЗСВ), логирование на уровне СУБД не включено (РСБ), доступ сервисных аккаунтов к ПДн не разграничен (УПД), сертифицированные СЗИ не применяются там, где они обязательны по УЗ-1/2.

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

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

Блок 7. ОРД. Организационно-распорядительная документация для IT: политика обработки ПДн (ст. 18.1 ФЗ-152), приказ о назначении ответственного (ст. 22.1), регламент реагирования на инциденты (Приказ РКН №187), инструкция для администраторов ИСПДн. Отсутствие регламента реагирования — типовое нарушение: при инциденте команда тратит первые часы на выяснение, кто и что делает, вместо того чтобы уведомить РКН в 24-часовой срок.

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

Обезличенные данные, от которых невозможно обратное восстановление, выходят из-под режима ФЗ-152 — они перестают быть ПДн по ст. 3 ФЗ-152. Это ключевое преимущество для ML-команд: обученная на обезличенных данных модель не создаёт правовых рисков для оператора в части передачи третьим лицам или хранения за рубежом.

На практике большинство IT-команд применяют псевдонимизацию: заменяют прямые идентификаторы (ФИО, email) на хэши или токены. Это не обезличивание. Хэш от email при наличии исходной таблицы восстанавливается за секунды. РКН и ФСТЭК расценивают псевдонимизированные данные как ПДн со всеми последствиями.

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

Типовые сценарии при проверке облачной инфраструктуры

Сценарий 1. SaaS-провайдер без договора поручения. CTO передал обработку аналитических данных клиентов в SaaS-платформу (мониторинг, BI). Договор с провайдером — лицензионный, без упоминания ПДн. РКН при плановой проверке запрашивает перечень лиц, которым поручена обработка. Лицензионный договор не является основанием по п. 3 ч. 3 ст. 6 ФЗ-152. Протокол по ч. 1 ст. 13.11 КоАП — 150 000–300 000 ₽. Стратегия: заключить договор поручения до проверки; типовой срок оформления с провайдером-нерезидентом — 2–4 недели, что делает подготовку срочной при любом сигнале о проверке.

Сценарий 2. Облачные ноды за пределами РФ. Компания использует облачного провайдера с основными нодами в Германии и репликацией в Сингапуре. Первичный сбор и запись ПДн российских пользователей выполняются там. Это нарушение ч. 5 ст. 18 ФЗ-152. Санкция по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽; при повторном нарушении по ч. 9 — 6–18 млн ₽. Доказательства: DNS-трассировка, договор с провайдером, архитектурная схема. Стратегия: перенести операции первичной обработки в российский регион облака или на собственные мощности в РФ; трансграничная передача после первичной записи в РФ допустима при соблюдении ст. 12 ФЗ-152.

Сценарий 3. ML-эксперименты на продуктовых данных. Data-команда скачивает дамп продуктовой БД в среду разработки для обучения модели рекомендаций. Дамп содержит ФИО, email, историю покупок. Среда разработки — в облаке за рубежом, без договора поручения с провайдером, без включения в реестр ИСПДн. Одновременно три нарушения: обработка без основания (ч. 1 ст. 13.11), нарушение локализации (ч. 8 ст. 13.11), отсутствие договора поручения. При инциденте — дополнительно ч. 12–14 ст. 13.11 в зависимости от числа субъектов. Стратегия: обезличить датасет до выгрузки, переместить среду ML в российский регион, оформить регламент работы с данными в R&D.

Как это работает на практике

Кейс 1. IT-компания (Сибирский ФО, осень 2025), SaaS-продукт для HR-автоматизации с клиентской базой около 80 000 субъектов. При DATUM-аудите выявлено: облачная инфраструктура размещена в мультиарендной среде европейского провайдера без договора поручения, модель угроз не составлена, УЗ не определён, логи приложения содержат email-адреса и хранятся бессрочно. По результатам аудита компания перевела первичную обработку в российский регион, заключила договоры поручения с тремя подрядчиками, установила срок хранения логов 90 дней с автоочисткой. При последующей плановой проверке РКН нарушений по ч. 8 ст. 13.11 КоАП не зафиксировано.

Кейс 2. Финтех-стартап (Центральный ФО, начало 2026), ML-скоринг на основе транзакционных данных. Датасет формировался из продуктовой БД прямой выгрузкой: 250 000 субъектов, поле с ФИО и телефоном. Обучение модели выполнялось в облаке с нодами в Нидерландах. После обращения в DATUM разработана схема обезличивания (введение случайных идентификаторов + удаление прямых атрибутов), ML-среда перемещена в российский облачный регион, подписан договор поручения с провайдером. Обращений РКН не последовало; компания прошла DPIA перед запуском обновлённой модели.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Облачная инфраструктура генерирует правовые риски по 152-ФЗ в нескольких точках одновременно: локализация первичной обработки, договоры поручения с провайдерами, классификация ИСПДн по УЗ, статус логов и ML-датасетов. Отсутствие аудита означает не просто административные штрафы — при повторном инциденте с 30.05.2025 применяется оборотный штраф по ч. 15 ст. 13.11 КоАП. DATUM-аудит облачной инфраструктуры охватывает все семь блоков и даёт CTO конкретный план устранения с приоритизацией по уровню риска.

Практика DATUM по технической стороне 152-ФЗ включает аудиты IT-инфраструктуры, SaaS-платформ, ML-систем и КИИ. Специалисты DATUM работают на стыке права и архитектуры: юридическая квалификация совмещается с анализом реальной инфраструктуры заказчика.

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