Контейнеризация (Docker, K8s) и 152-ФЗ

Для технического директора вопрос «какой УЗ у нашей системы?» часто стоит ниже вопросов производительности и отказоустойчивости. Однако с 30.05.2025 ответ на него напрямую определяет риск штрафа от 3 до 500 млн ₽. Ниже — как требования ФЗ-152 проецируются на контейнерные среды: выбор уровня защищённости, меры ФСТЭК, обезличивание для ML, мультиарендность SaaS и сценарии, где ошибки стоят дороже всего.

Как ПП РФ №1119 и Приказ ФСТЭК №21 распространяются на контейнеры?

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

На практике это означает следующее. Для контейнерной среды группы мер из Приказа ФСТЭК №21 реализуются специфическими инструментами: управление привилегированным доступом (УПД) — через RBAC Kubernetes и политики Pod Security Admission; защита носителей информации (ЗНИ) — через шифрование Persistent Volumes и Container Storage Interface с поддержкой шифрования at rest; регистрация событий безопасности (РСБ) — через централизованный сбор логов из контейнеров и оркестратора в SIEM. Мера ОПС (ограничение программной среды) в контейнерах закрывается политиками image signing, запретом privileged-контейнеров и ограничением capabilities. Каждая из этих мер должна быть задокументирована в модели угроз и в плане реализации мер защиты.

Отдельного внимания требует группа ЗТС (защита технических средств) применительно к узлам кластера (worker nodes). Физический контроль хостов, на которых работает Kubernetes, — ответственность оператора или его обработчика (провайдера). Если кластер размещён у облачного провайдера по договору поручения обработки (ст. 6 ч. 3 ФЗ-152), провайдер обязан соответствовать требованиям того же УЗ, что и сам оператор.

Что такое обезличивание для ML и как его применить в контейнерной среде?

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

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

В архитектуре Kubernetes это выглядит следующим образом: пайплайн обезличивания должен быть отделён от основной ИСПДн (отдельный namespace или кластер), результаты обезличивания не должны содержать первичных идентификаторов (ИНН, СНИЛС, email, телефон), а операции по обезличиванию — фиксироваться в логах (группа РСБ). Логи контейнеров, фиксирующие обработку ПДн, сами по себе содержат персональные данные (см. ниже) и требуют отдельного режима хранения.

Являются ли логи контейнеров персональными данными?

Этот вопрос CTO задают реже всего — и именно здесь возникает скрытый риск. Логи Kubernetes и Docker могут содержать: IP-адреса пользователей, токены сессий, email-адреса, имена пользователей, фрагменты запросов с ПДн. По позиции РКН, IP-адрес в сочетании с иными данными о конкретном пользователе — это персональные данные. Следовательно, централизованное хранилище логов (ELK, Loki, любой SIEM) становится компонентом ИСПДн.

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

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

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

Для контейнерной среды это влечёт конкретные архитектурные требования. Если Kubernetes-кластер развёрнут в AWS, GCP или Azure без российских регионов — первичная запись ПДн в такой кластер нарушает ч. 5 ст. 18. Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽ за первое нарушение, 6–18 млн ₽ при повторном (ч. 9). РКН вправе также ограничить доступ к ресурсу. Реплицировать данные за рубеж после первичной записи в РФ — допустимо при соблюдении порядка трансграничной передачи по ст. 12 ФЗ-152.

Провайдеры с российскими регионами (Yandex Cloud, VK Cloud, SberCloud, российские дата-центры гиперскейлеров при их наличии) формально соответствуют требованию локализации при условии, что договор явно фиксирует расположение данных в РФ. Однако «российский регион» у иностранного провайдера не означает автоматического соответствия: нужно убедиться, что репликация данных не уходит в зарубежные регионы автоматически.

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

В мультиарендных (multi-tenant) системах один Kubernetes-кластер обслуживает нескольких клиентов-операторов. Каждый клиент обрабатывает ПДн своих конечных пользователей. Вопрос о распределении ответственности — один из ключевых при взаимодействии с РКН.

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

В архитектуре Kubernetes изоляция арендаторов (tenant isolation) должна быть реализована на уровне сетевых политик (NetworkPolicy), отдельных namespace с RBAC, а при УЗ-1/УЗ-2 — на уровне отдельных кластеров или физической изоляции. Смешение данных разных арендаторов в одной базе данных без явного разделения — это нарушение принципа несовместимости целей (ст. 5 ч. 1 п. 5 ФЗ-152), если у клиентов разные цели обработки.

Какие сценарии приводят к штрафу по новым нормам ст. 13.11 КоАП?

Сценарий 1. Утечка через misconfiguration. Kubernetes-кластер с открытым API-сервером (порт 6443) без аутентификации или с дефолтным ServiceAccount позволяет злоумышленнику получить доступ к Secret-объектам, содержащим учётные данные для БД с ПДн. Утечка затрагивает 15 000 субъектов. Квалификация: ч. 13 ст. 13.11 КоАП — штраф 5–10 млн ₽. Если уведомление РКН направлено позже 24 часов — ещё ч. 11, штраф 1–3 млн ₽. Стратегия: обязательный hardening кластера (CIS Kubernetes Benchmark), автоматическое сканирование конфигурации в CI/CD-пайплайне.

Сценарий 2. Реестр образов в иностранном облаке. CTO использует Docker Hub или GitHub Container Registry как основной реестр. В образах — environment variables с реальными connection strings к базе ПДн. Образы собираются и временно хранятся за рубежом. При этом оператор не уведомил РКН о трансграничной передаче по ст. 12 ФЗ-152. Квалификация: нарушение ч. 5 ст. 18 (локализация) — ч. 8 ст. 13.11, штраф 1–6 млн ₽; нарушение порядка трансграничной передачи. Стратегия: перенос реестра образов в российскую инфраструктуру (Yandex Container Registry, Harbor on-premise), очистка secrets из образов.

Сценарий 3. ML-пайплайн на реальных данных. Data science команда запустила Jupyter-контейнер с доступом к production-БД через Kubernetes ServiceAccount с широкими правами. Датасет для обучения — реальные ПДн 50 000 пользователей без обезличивания. РКН фиксирует это при проверке по жалобе субъекта. Квалификация: ч. 1 ст. 13.11 (обработка ПДн в несовместимых с изначальными целях) — штраф до 300 000 ₽; при повторности — ч. 1.1, штраф до 500 000 ₽. Дополнительный риск: ст. 272.1 УК РФ (незаконное использование ПДн), действует с 11.12.2024. Стратегия: отдельный namespace для ML с минимальными правами, обезличивание перед передачей в датасет.

Связанные услуги DATUM

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

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

1. Какой УЗ выбрать для SaaS с общедоступными ПДн и более 100 000 пользователей?

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

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

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

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

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

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

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

5. Какие технические меры (СЗИ) обязательны для УЗ-3?

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

Итог

Контейнеризация не создаёт особого правового режима для ПДн: те же УЗ, тот же набор мер ФСТЭК, та же ответственность по ст. 13.11 КоАП. Специфика — в реализации мер на уровне Kubernetes (RBAC, NetworkPolicy, image signing, шифрование PV) и в скрытых рисках: логах как ПДн, ML-пайплайнах на реальных данных, иностранных реестрах образов и отсутствии договоров поручения с облачными провайдерами.

Юристы и технические аналитики DATUM сопровождают IT-команды при классификации ИСПДн, составлении плана мер Приказа ФСТЭК №21 применительно к контейнерным средам, подготовке ОРД для SaaS-операторов и прохождении проверок РКН.