Логи СУБД и ПДн

Журналы СУБД — это не технический артефакт, это доказательная база и потенциальный вектор утечки одновременно. Каждый запрос к таблице с персональными данными оставляет след: идентификатор сессии, параметры запроса, иногда — сами значения полей. По данным РКН за 2024 год, зафиксировано более 135 случаев утечек с общим объёмом свыше 710 млн записей. Значительная доля инцидентов происходит через скомпрометированные логи или недостаточно защищённые журналы аудита. Эта статья разбирает, когда логи СУБД становятся персональными данными, какие требования применяются к их защите по УЗ-1..4 и Приказу ФСТЭК № 21, как выстроить обезличивание для ML-пайплайнов и что проверить CISO в первую очередь.

Когда логи СУБД становятся персональными данными?

Персональные данные по ст. 3 ФЗ-152 — любая информация, относящаяся прямо или косвенно к определённому физическому лицу. Журнал СУБД соответствует этому определению, если в нём фиксируются значения полей с именами, телефонами, идентификаторами пользователей, IP-адресами или иными атрибутами, позволяющими идентифицировать субъекта. Это касается slow query log, general log, журнала аудита и бинарного лога репликации.

Особую опасность представляют три сценария. Первый: лог уровня DEBUG в development-среде, куда реплицированы production-данные без обезличивания. Второй: бинарный лог репликации, который передаётся на резервные серверы и хранится отдельно от основной ИСПДн. Третий: лог медленных запросов, в котором в параметрах видны реальные значения — номер паспорта, дата рождения, телефон. Во всех трёх случаях оператор обязан применять к лог-файлам те же организационно-технические меры, что и к основным базам ПДн.

Логирование как ПДн — это не позиция регулятора «в теории». Это основание для включения лог-хранилища в модель угроз и в уведомление РКН по ст. 22 ФЗ-152. Если в реестре операторов у вас указана одна ИСПДн, а логи хранятся в другом месте — это несоответствие, которое инспектор зафиксирует при проверке.

Какие требования ФСТЭК и УЗ применяются к лог-файлам с ПДн?

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

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

УЗ-4

Иные ПДн, угроза типа 3, менее 100 000 субъектов. Базовый набор мер. Для логов: ведение журнала доступа, защита от несанкционированного изменения, сроки хранения.

УЗ-3

Иные ПДн, угроза типа 2 или специальные с угрозой типа 3. Добавляются требования к средствам защиты информации (СЗИ), прошедшим оценку соответствия ФСТЭК. Логи должны храниться с контролем целостности.

УЗ-2

Специальные или биометрические ПДн при угрозах типа 2 или иные при угрозах типа 1. Обязательны сертифицированные СЗИ. Журналы аудита должны передаваться в SIEM или аналогичную систему с защищённым хранилищем.

УЗ-1

Специальные или биометрические ПДн при угрозах типа 1. Максимальные требования. Лог-инфраструктура выделяется в отдельный контур с усиленным контролем доступа и шифрованием хранилища.

Практическая ошибка: команды часто устанавливают уровень защищённости для основной ИСПДн, но не пересматривают его при добавлении новых компонентов — резервных серверов, ETL-пайплайнов, S3-хранилищ для логов. Каждый новый компонент, обрабатывающий ПДн, требует обновления модели угроз и актуализации комплекса мер.

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

Обезличивание ПДн для задач машинного обучения — это не просто удаление имени и телефона из датасета. Регулятор с 2025 года нормировал 5 методов обезличивания (Приказ РКН, вступивший в силу в 2025 году): введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание и обобщение. Для ML-пайплайнов наиболее применимы первый и пятый методы.

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

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

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

Требование локализации по ч. 5 ст. 18 ФЗ-152 распространяется на запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ — и всё это происходит при логировании СУБД. Если лог-файлы с ПДн россиян реплицируются на сервер в иностранном ЦОД или в облако с инфраструктурой за рубежом — это нарушение требования локализации.

Иностранные облачные провайдеры — AWS, GCP, Azure, а также ряд SaaS-платформ мониторинга (Datadog, Splunk Cloud) — размещают инфраструктуру в европейских или американских регионах по умолчанию. Если через них проходят или хранятся логи с ПДн российских пользователей — требование ч. 5 ст. 18 нарушается даже при наличии шифрования в канале. КИИ 187-ФЗ добавляет ещё один слой: для субъектов критической информационной инфраструктуры требования к размещению данных и СЗИ ещё жёстче.

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

Как утечка через лог-файл квалифицируется по ст. 13.11 КоАП и ст. 272.1 УК?

С 30.05.2025 ответственность за утечку ПДн напрямую привязана к масштабу инцидента. Если из лог-файла утекли данные от 1 000 до 10 000 субъектов — штраф составит от 3 до 5 млн ₽ по ч. 12 ст. 13.11 КоАП. От 10 000 до 100 000 субъектов — от 5 до 10 млн ₽ по ч. 13. Более 100 000 субъектов — от 10 до 15 млн ₽ по ч. 14. При повторном нарушении — оборотный штраф по ч. 15: от 1 до 3% совокупной годовой выручки, не менее 20 млн ₽ и не более 500 млн ₽.

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

Угроза уголовной ответственности касается не только внешних злоумышленников. Если сотрудник скачал лог-файл с ПДн и передал его третьим лицам — это состав ст. 272.1 УК. По данным СерчИнформ (июль 2025, анализ более 100 решений), 55% уголовных дел об утечках связаны с сотрудниками телекоммуникационных компаний. Контроль доступа к лог-хранилищам — не только ИБ-практика, но и уголовно-правовая необходимость.

Практические сценарии для CISO: утечка через логи

Сценарий 1. Dev-среда с production-данными без обезличивания. Ситуация: разработчики скопировали дамп с реальными ПДн в тестовую среду. В general log зафиксированы запросы с параметрами — именами, телефонами, email-адресами клиентов. Среда доступна широкому кругу разработчиков. Доказательства: журнал доступа, история запросов, отсутствие документированного обезличивания. Вероятный исход: при проверке РКН — предписание, штраф по ч. 1 ст. 13.11 КоАП (150–300 тыс. ₽). При реальной утечке из dev-среды — ч. 12–14 ст. 13.11 в зависимости от масштаба. Стратегия: немедленно изолировать dev-среды, применить обезличивание по методам приказа РКН, задокументировать процедуру в ОРД.

Сценарий 2. Бинарный лог репликации уходит на зарубежный сервер. Ситуация: архитектура репликации предусматривает резервный сервер в европейском ЦОД. Бинарный лог содержит все транзакции, включая INSERT/UPDATE с ПДн. Документация на трансграничную передачу отсутствует. Доказательства: конфигурация репликации, IP-адреса резервных серверов, отсутствие уведомления РКН по ст. 12. Вероятный исход: штраф по ч. 8 ст. 13.11 КоАП за нарушение локализации (1–6 млн ₽). Стратегия: перенести резервный сервер в российский ЦОД или настроить фильтрацию бинарного лога с исключением ПДн до репликации.

Сценарий 3. ML-пайплайн без поручения обработки. Ситуация: дата-инженеры выгружают логи СУБД в S3-хранилище стороннего ML-провайдера для обучения модели. Поручение обработки по п. 3 ст. 6 ФЗ-152 не оформлено. Данные не обезличены. Доказательства: договор с ML-провайдером без условий о защите ПДн, отсутствие документов ОРД на ML-процессинг. Вероятный исход: нарушение ст. 6 и ст. 19 ФЗ-152 — предписание РКН, штраф по ч. 1 ст. 13.11. При утечке у ML-провайдера — ответственность оператора по принципу ВС РФ об ответственности за действия подрядчика. Стратегия: заключить соглашение о поручении обработки, применить обезличивание, включить ML-среду в состав ИСПДн.

Практика: как это происходит в реальных инцидентах

Кейс 1. В компании финтех-сектора (Центральный ФО, лето 2025) аудит выявил, что slow query log PostgreSQL содержал параметры запросов с данными клиентов — номерами карт в маскированном виде и суммами операций. Лог ротировался, но архив за 90 дней хранился на NAS без контроля доступа. После аудита DATUM компания обновила модель угроз, применила к лог-хранилищу меры УЗ-3, настроила маскирование параметров на уровне СУБД. Предписание РКН по итогам последующей проверки не вынесено.

Кейс 2. В деле об утечке данных пользователей IT-платформы (Северо-Западный ФО, осень 2025) источником стал агрегированный лог-файл, выгруженный дата-инженером в корпоративный мессенджер для отладки. Файл содержал около 15 000 идентификаторов с email-адресами. CISO направил первичное уведомление в РКН в течение 20 часов. По итогам расследования к компании применили ч. 12 ст. 13.11 КоАП. В арбитражном суде размер штрафа был снижен с учётом оперативности уведомления и принятых мер. Смягчение обеспечили документальное подтверждение инвестиций в ИБ за предшествующие три года в соответствии с примечанием к ст. 4.1 КоАП.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Логи СУБД содержат персональные данные — и это технический факт, а не правовая метафора. Требования ФЗ-152, ПП РФ № 1119 и Приказа ФСТЭК № 21 распространяются на лог-хранилища в той же мере, что и на основные базы данных. С 30.05.2025 штрафы за утечки составляют от 3 до 15 млн ₽, а при повторности — оборотный штраф до 500 млн ₽. Уголовная ответственность по ст. 272.1 УК с 11.12.2024 применяется к лицам, незаконно получившим или передавшим данные из лог-файлов.

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