Логирование и УЗ ИСПДн

Логирование событий безопасности в информационных системах персональных данных — не организационная формальность, а техническое требование, прямо закреплённое в Приказе ФСТЭК № 21 от 18.02.2013. Состав обязательных мер зависит от уровня защищённости (УЗ-1, УЗ-2, УЗ-3, УЗ-4), который определяется по матрице ПП РФ № 1119 от 01.11.2012. В этой статье — как правильно определить УЗ, что именно логировать и как это стыкуется с мультиарендными SaaS-платформами, ML-пайплайнами и облаком в РФ.

Как определить уровень защищённости ИСПДн — и почему ошибка здесь дороже всего?

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

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

Для системы с иными ПДн сотрудников менее 100 000 человек и угрозами 3-го типа — УЗ-4. Если субъектов больше 100 000 — УЗ-3. Для специальных категорий ПДн даже при угрозах 3-го типа — минимум УЗ-3. Ошибка в сторону занижения: при проверке РКН инспектор потребует документы о присвоении УЗ и сопоставит их с реальными мерами. Расхождение — основание для предписания и протокола по ст. 13.11 КоАП.

Что требует Приказ ФСТЭК № 21 в части логирования для каждого УЗ?

Приказ ФСТЭК № 21 структурирован по 15 группам мер. Группа РСБ (регистрация событий безопасности) содержит меры от РСБ.1 до РСБ.8. Базовый набор определяется уровнем УЗ.

Для УЗ-4 и УЗ-3 обязательны: определение событий, подлежащих регистрации (РСБ.1), сбор и хранение журналов (РСБ.2), защита журналов от изменения и удаления (РСБ.5), мониторинг и анализ событий (РСБ.6). Для УЗ-2 добавляются: управление конфигурацией регистрации (РСБ.3) и синхронизация системного времени (РСБ.4). Для УЗ-1 — дополнительно защита журналов средствами криптографии (РСБ.7) и проведение анализа уязвимостей по результатам журналирования (РСБ.8).

Отдельная проблема — что именно считать событием, подлежащим регистрации. Приказ ФСТЭК № 21 не приводит закрытый список, но практика проверок показывает минимально ожидаемый набор: входы и выходы пользователей, попытки несанкционированного доступа, изменения прав доступа, запуск и завершение процессов обработки ПДн, обращения к базам данных с ПДн, изменения конфигурации СЗИ, сигналы от средств обнаружения вторжений.

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

Логирование как персональные данные: когда журнал событий сам становится ИСПДн?

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

Следствие: к журналам событий применяются требования ФЗ-152 в части хранения, доступа и уничтожения. Хранение журналов — это обработка ПДн, которая должна быть отражена в уведомлении оператора в реестре РКН (ст. 22 ФЗ-152) и в политике обработки ПДн (ст. 18.1 ФЗ-152). Доступ к журналам — только у авторизованного персонала с задокументированными правами. Выгрузка журналов в стороннюю SIEM-систему за рубежом — трансграничная передача ПДн с обязательным уведомлением РКН по ст. 12 ФЗ-152.

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

Как обезличивание для ML снижает требования к логированию — и когда не снижает?

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

Для ML-пайплайнов это означает: если обучающая выборка прошла полное обезличивание, журналы обращений к этой выборке не содержат ПДн и могут храниться без требований Приказа ФСТЭК № 21. Однако в практике большинства ML-систем используется псевдонимизация, а не полное обезличивание: данные заменены идентификаторами, но таблица соответствий хранится отдельно. Такая система в целом остаётся ИСПДн, поскольку идентификация субъекта возможна через соединение частей.

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

Облако в РФ, мультиарендный SaaS и поручение обработки: кто несёт ответственность?

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

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

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

Практические сценарии: что происходит, когда требования нарушены

Сценарий 1. IT-компания занижает УЗ и не ведёт полный журнал событий. Ситуация: SaaS-провайдер в Центральном ФО обрабатывает ПДн сотрудников клиентов (иные ПДн, более 100 000 субъектов), присваивает УЗ-4 вместо требуемого УЗ-3 и не реализует меры РСБ.5–РСБ.6 (защита и анализ журналов). Доказательства: при проверке РКН инспектор запрашивает приказ о присвоении УЗ и техническую документацию SIEM. Разрыв между заявленным УЗ-4 и фактическим составом субъектов выявляется на месте. Вероятный исход: предписание об устранении, протокол по ч. 1 ст. 13.11 КоАП, штраф 150 000–300 000 ₽. Стратегия: до проверки — пересмотр матрицы УЗ, внедрение недостающих мер группы РСБ, обновление технической документации.

Сценарий 2. Журналы событий передаются в зарубежную SIEM без уведомления РКН. Ситуация: компания (Северо-Западный ФО, конец 2025) использует облачную SIEM-систему с серверами в Нидерландах. Журналы содержат имена пользователей и IP-адреса. Уведомление о трансграничной передаче по ст. 12 ФЗ-152 не подавалось. Доказательства: при внутреннем аудите CISO выявил маршруты передачи через трейс сетевых соединений. Вероятный исход: при выявлении РКН — штраф по ч. 8 ст. 13.11 за нарушение локализации (от 1 000 000 ₽) и по ч. 10 за неуведомление о намерении обрабатывать (100 000–300 000 ₽). Стратегия: перевод SIEM на российский облачный сервис или настройка маршрутизации только в пределах РФ, подача уведомления в реестр РКН.

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

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

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

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

1. Какой УЗ выбрать для SaaS?

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

2. Можно ли использовать иностранные облака?

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

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

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

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

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

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

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

Итог

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

DATUM сопровождает IT-компании и SaaS-провайдеров при определении УЗ, выстраивании технической документации и прохождении проверок Роскомнадзора. Практика «Ветров и партнёры» по 152-ФЗ с 2014 года охватывает как организационный, так и технический периметр соответствия.