Логи Zabbix/Grafana

Логи Zabbix и Grafana воспринимаются как сугубо технические артефакты: метрики хостов, алерты, трейсы. Между тем регулятор рассматривает их иначе. Если в лог-строке зафиксированы IP-адрес пользователя, его логин или идентификатор сессии — это персональные данные по ст. 3 ФЗ-152. CISO первым оказывается под вопросом, когда РКН или прокуратура запрашивают подтверждение, что обработка таких данных ведётся законно. Статья разбирает: чем конкретно опасны логи мониторинга с правовой точки зрения, какой уровень защищённости (УЗ) применим, что требуют Приказ ФСТЭК №21 и ПП РФ №1119, как обезличить данные для ML-пайплайнов и что делать в мультиарендной SaaS-архитектуре.

Почему логи Zabbix и Grafana — это персональные данные?

Ст. 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся к прямо или косвенно определённому физическому лицу. IP-адрес рабочей станции сотрудника, его системный логин, уникальный идентификатор сессии — каждый из этих атрибутов в связке с другими данными позволяет идентифицировать конкретного человека. Zabbix фиксирует события аутентификации, имена хостов и IP в событийном журнале. Grafana хранит историю запросов пользователей к дашбордам с привязкой к учётным записям.

Позиция РКН по cookies и схожим идентификаторам однозначна: если данные связаны с устройством конкретного лица — они персональные. Тот же принцип применим к логам мониторинга. Аргумент «это технические логи, а не ПДн» не принимается при проверке, если в записи есть идентифицирующий атрибут.

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

Какой уровень защищённости (УЗ) применим к ИСПДн с логами?

ПП РФ №1119 от 01.11.2012 определяет четыре уровня защищённости в зависимости от категории ПДн, типа угроз и числа субъектов. Логи мониторинга, содержащие только общие ПДн (IP, логин, идентификатор), — это общая категория. При числе субъектов менее 100 000 и угрозах 3-го типа минимальный уровень — УЗ-4. При угрозах 2-го типа — УЗ-3. При угрозах 1-го типа или числе субъектов более 100 000 — УЗ-2 или УЗ-1.

На практике крупные IT-компании с парком в сотни серверов, мониторинг которых ведёт Zabbix, легко преодолевают порог 100 000 уникальных идентификаторов в логах за год. Это автоматически поднимает минимальный УЗ. Ошибка при определении УЗ — это неверный базовый набор мер по Приказу ФСТЭК №21 и потенциальное несоответствие при проверке.

Что требует Приказ ФСТЭК №21 применительно к логам?

Приказ ФСТЭК №21 от 18.02.2013 устанавливает 15 групп мер защиты. Для логов мониторинга наиболее критичны три группы.

РСБ — регистрация событий безопасности. Для УЗ-3 и выше обязательна регистрация событий доступа к ИСПДн, изменений конфигурации, привилегированных операций. Grafana и Zabbix имеют встроенный audit log — он должен быть включён, настроен и защищён от изменения. Хранение — не менее установленного для УЗ срока (обычно не менее 3 лет для УЗ-2).

УПД — управление правами доступа. Доступ к логам мониторинга должен быть разграничён по принципу минимальных привилегий. В Grafana — через roles и teams с явным назначением прав; в Zabbix — через user groups и permission levels. Интеграция с Active Directory или LDAP не снимает ответственность за актуальность матрицы доступа.

ЗНИ — защита носителей информации. Логи, выгружаемые во внешние S3-совместимые хранилища или на NFS-шары, требуют шифрования при хранении. Для УЗ-2 и выше — сертифицированными СКЗИ. Хранение в открытом виде в облачном бакете недопустимо, если там есть идентифицирующие атрибуты.

Типичная ошибка в крупных IT-командах: Zabbix развёрнут с дефолтными настройками, audit log отключён, права доступа к API-ключам shared. Это прямое несоответствие мерам группы РСБ и УПД — и самостоятельный состав для протокола по ч. 1 ст. 13.11 КоАП.

Как обезличить логи для ML-пайплайнов без нарушения 152-ФЗ?

Обучение ML-моделей на данных мониторинга — распространённая практика: anomaly detection, предсказание отказов, автоматическое построение бейзлайна. Проблема в том, что исходные логи содержат ПДн, а передача их в ML-систему без обезличивания — это новая обработка с иными целями, несовместимыми с первоначальными по ст. 5 ФЗ-152.

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

Псевдонимизация IP и логинов — замена реальных значений детерминированным хэшем (SHA-256 с солью) — позволяет сохранить уникальность идентификатора для ML-задачи, но исключает обратное восстановление без ключа. Ключ хранится отдельно, доступ к нему — только у операторов системы обезличивания.

Агрегация — замена точных значений диапазонами или усреднёнными метриками — применяется для временных рядов: вместо «пользователь X выполнил 1347 запросов в 14:22:07» — «в период 14:00–15:00 зафиксировано 1 200–1 400 запросов в сегменте N».

Кто оператор ПДн в мультиарендной SaaS с общим мониторингом?

В SaaS-архитектуре с мультиарендностью один стек Grafana/Zabbix нередко мониторит инфраструктуру нескольких клиентов (тенантов). Каждый тенант является самостоятельным оператором ПДн своих пользователей. SaaS-провайдер, получающий доступ к логам тенанта в рамках поддержки или мониторинга, действует как лицо, осуществляющее обработку по поручению (ст. 6 п. 3 ФЗ-152).

Это означает: договор между тенантом и провайдером должен содержать явное поручение на обработку ПДн с указанием перечня действий, целей, срока и мер защиты. Без такого поручения провайдер обрабатывает ПДн без законного основания — состав по ч. 1 ст. 13.11 КоАП (штраф 150–300 тыс. ₽ для юрлица в первый раз, 300–500 тыс. ₽ при повторном нарушении по ч. 1.1).

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

Облако в РФ и требования локализации: как это работает для логов?

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

Практическое следствие для логов Grafana и Zabbix: если метрики и события хранятся в облаке AWS, GCP или Azure (даже в европейском регионе) и содержат идентифицирующие атрибуты сотрудников или пользователей-граждан РФ — это нарушение требований локализации. Штраф по ч. 8 ст. 13.11 КоАП — от 1 до 6 млн ₽ для юрлица; при повторном нарушении по ч. 9 — от 6 до 18 млн ₽.

Допустимые варианты: перенос хранилища логов в российское облако (Яндекс Облако, SberCloud, VK Cloud, Selectel), развёртывание on-premise с репликацией в РФ, либо — при обязательном предварительном уведомлении РКН — трансграничная передача в страны из перечня адекватной защиты (ст. 12 ФЗ-152). Иностранные облака без уведомления РКН — прямой риск.

Если используется КИИ-инфраструктура (187-ФЗ), требования к размещению ещё жёстче: значимые объекты КИИ обязаны использовать только сертифицированные средства защиты информации и отечественное ПО на критических сегментах. Zabbix как open-source может применяться, но только в связке с сертифицированными СЗИ по Приказу ФСТЭК №21.

Практика: как разворачиваются типовые ситуации для CISO

Ситуация 1. Внешний подрядчик с доступом к Grafana-дашбордам. IT-компания (Центральный ФО, осень 2025) передала подрядчику доступ к Grafana для анализа производительности. Дашборды включали логи с IP-адресами и логинами сотрудников. Договор с подрядчиком не содержал поручения на обработку ПДн. При плановой проверке РКН инспектор запросил основания для передачи данных подрядчику. CISO не смог предъявить договор с обязательствами по ст. 6 п. 3 ФЗ-152. Протокол составлен по ч. 1 ст. 13.11 КоАП. Штраф в диапазоне сотен тысяч рублей. Стратегия: до передачи доступа — заключать соглашение об обработке ПДн как часть договора оказания услуг, прописывать конкретный перечень данных, действий и обязанности по ст. 19.

Ситуация 2. ML-команда тренирует модель на сырых логах. SaaS-провайдер (Северо-Западный ФО, начало 2026) выгружал исходные логи Zabbix (с IP и логинами) в S3-бакет для DS-команды. Бакет располагался в облаке вне РФ. При инциденте (несанкционированный доступ к бакету) CISO обнаружил: нарушена локализация (ч. 8 ст. 13.11), данные не обезличены (ст. 5 ФЗ-152 — несовместимость целей), утечка не уведомлена в РКН в 24 часа (ч. 11 ст. 13.11 — штраф 1–3 млн ₽). Совокупность нарушений. Стратегия: обезличивание логов перед выгрузкой по методам Приказа РКН, хранение бакета в РФ, регламент реагирования на инциденты с чётким таймером 24 ч.

Ситуация 3. УЗ занижен, проверка ФСТЭК выявила несоответствие. Промышленный холдинг (Уральский ФО, лето 2025) эксплуатировал ИСПДн с Zabbix, присвоив ей УЗ-4 без учёта числа субъектов. Реальное число уникальных идентификаторов в логах превышало 100 000, тип угроз соответствовал 2-му типу — итоговый УЗ должен был быть УЗ-2. Базовый набор мер по Приказу ФСТЭК №21 для УЗ-4 существенно уже: отсутствовала часть мер группы РСБ и ЗИС. Акт проверки содержал предписание переработать модель угроз и дополнить комплекс СЗИ. Штраф в десятки тысяч рублей по ч. 1 ст. 13.11, дополнительные расходы на внедрение СЗИ — существенно выше. Стратегия: пересматривать акт классификации ИСПДн ежегодно с учётом роста числа субъектов.

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

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

Определяется по ПП РФ №1119 исходя из трёх параметров: категории ПДн в логах (как правило — общая категория), типа актуальных угроз (определяется в модели угроз), числа субъектов. Если в логах только IP и логины сотрудников и их менее 100 000 при угрозах 3-го типа — минимально УЗ-4. Если субъектов более 100 000 или актуальны угрозы 2-го типа — УЗ-3 или УЗ-2. Ошибка при определении УЗ ведёт к неполному набору мер ФСТЭК и несоответствию при проверке. Рекомендация: заказывать классификацию ИСПДн у специалиста, имеющего опыт работы с Приказом ФСТЭК №21.

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

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

3. Что такое обезличивание для ML и какие методы признаёт РКН?

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

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

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

5. Какие СЗИ обязательны для ИСПДн с логами Zabbix/Grafana?

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

Итог

Логи Zabbix и Grafana — это персональные данные в понимании ФЗ-152, если содержат идентифицирующие атрибуты. Требования распространяются на весь цикл: от определения УЗ и выбора мер ФСТЭК до хранения в российском облаке, поручения подрядчикам и обезличивания перед ML-пайплайнами. Неправильно определённый УЗ, отсутствующее поручение обработки или хранение в иностранном облаке — каждый из этих пунктов является самостоятельным составом нарушения по ст. 13.11 КоАП с 30.05.2025.

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

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

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

22 октября 2028 года