Логи и аудит действий с ПДн: что фиксировать, как хранить и как использовать при расследовании инцидентов

Полное руководство для операторов персональных данных в России — от требований ФСТЭК и 152-ФЗ до форензики и реагирования на утечки

Почему эта тема стала приоритетной в 2025 году

Ещё несколько лет назад вопросы журналирования действий с персональными данными касались преимущественно крупных банков, телекоммуникационных компаний и госструктур. Типичный штраф за нарушение обработки ПДн составлял символические 50–100 тысяч рублей, и компании воспринимали его как административный налог, а не как реальный риск.

Всё изменилось. В 2024 году Роскомнадзор зафиксировал 135 фактов утечек персональных данных, содержащих более 710 млн записей [6]. В первой половине 2025 года — ещё 35 фактов, 39 млн записей [6]. По данным компании InfoWatch, реальное число инцидентов в 2024 году превышало официальную статистику примерно втрое: по их оценкам, было похищено более 1,5 млрд записей, а информация о как минимум 60% инцидентов не разглашается [7].

Федеральный закон от 30 ноября 2024 года № 420-ФЗ перевернул экономику вопроса. С 30 мая 2025 года утечка данных 1 000–10 000 субъектов обойдётся юридическому лицу в 3–5 млн рублей, от 10 000 до 100 000 — в 5–10 млн рублей, более 100 000 — в 10–15 млн рублей. Повторная утечка — от 1% до 3% годовой выручки, но не менее 20 млн рублей и не более 500 млн рублей [1][2]. Одновременно введена уголовная ответственность по новой статье 272.1 УК РФ — до 10 лет лишения свободы за незаконное использование компьютерной информации, содержащей ПДн [8].

В этой системе координат журналы аудита и логи событий перестали быть техническим артефактом и стали юридически значимым инструментом. Они позволяют:

• доказать факт принятия мер безопасности и тем самым снизить или исключить административную ответственность;
• провести расследование инцидента в обязательные сроки (24 и 72 часа);
• установить виновных — как внешних атакующих, так и инсайдеров;
• подготовить доказательную базу для судебного разбирательства или передачи дела в правоохранительные органы.

Статья предназначена для специалистов по информационной безопасности, IT-директоров, DPO (ответственных за обработку персональных данных) и юристов компаний, обрабатывающих персональные данные в соответствии с российским законодательством.

Часть 1. Нормативная база: что и откуда требуют регуляторы

1.1. 152-ФЗ и статья 19: рамочные требования

Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» не содержит прямого требования вести конкретные журналы событий. Статья 18.1 обязывает оператора принять «правила внутреннего контроля и (или) аудита», а статья 19 — «принимать меры, необходимые и достаточные для обеспечения выполнения обязанностей» по защите ПДн [9]. Последняя редакция закона учитывает поправки, вступившие в силу в 2025 году [9].

Детализацию требований к регистрации событий берут на себя подзаконные акты ФСТЭК и ФСБ.

1.2. Приказ ФСТЭК России № 21: группа мер РСБ

Приказ ФСТЭК России от 18 февраля 2013 года № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» содержит специальный раздел V «Регистрация событий безопасности» (РСБ). Меры этого раздела обязательны для всех четырёх уровней защищённости [3][4]:

РСБ.1 — определение событий безопасности, подлежащих регистрации, и сроков их хранения. Перечень пересматривается не реже одного раза в год. Минимальный срок хранения — три месяца, если иное не установлено законодательством [4].

РСБ.2 — определение состава и содержания информации о событиях. Каждая запись должна как минимум содержать: тип события, дату и время, идентификационную информацию источника, результат события (успешно / неуспешно), субъекта доступа [4].

РСБ.3 — сбор, запись и хранение информации о событиях в течение установленного срока.

РСБ.4 — реагирование на сбои при регистрации событий, в том числе при переполнении буферов хранения.

РСБ.5 — мониторинг и анализ результатов регистрации событий, реагирование на выявленные признаки инцидентов. Для усиленных мер предусмотрена корреляция событий из разных источников [10].

РСБ.6 — генерация временны́х меток и синхронизация системного времени.

РСБ.7 — защита информации о событиях от несанкционированного доступа, уничтожения или модификации. Доступ к журналам — только уполномоченным должностным лицам. Усиленные меры требуют резервного копирования на носители однократной записи и применения криптографических методов для обеспечения целостности [4][10].

Важно: группа мер «Реагирование на инциденты» (ИНЦ.1–ИНЦ.6) строго связана с РСБ. Без журналов событий невозможно обнаружить инцидент (ИНЦ.2), провести его анализ (ИНЦ.4) и спланировать меры предотвращения (ИНЦ.6) [11].

Для государственных информационных систем применяется Приказ ФСТЭК России № 17 от 11 февраля 2013 года, который предусматривает аналогичную структуру мер РСБ с дополнительными требованиями к взаимодействию с ГосСОПКА [12].

1.3. Постановление Правительства № 1119 и уровни защищённости

Постановление Правительства РФ от 01.11.2012 № 1119 устанавливает четыре уровня защищённости персональных данных (УЗ-1 — УЗ-4). Требования к регистрации событий применяются на всех уровнях (РСБ.1, РСБ.2, РСБ.3 — базовые меры для УЗ-1 — УЗ-4). Чем выше уровень угроз и чувствительнее данные, тем более строгие требования предъявляются к составу фиксируемых событий, срокам хранения и защите самих журналов.

1.4. Международный контекст: GDPR и NIST SP 800-92

Российская практика аудита ПДн развивается параллельно с мировой, хотя и со своей спецификой. GDPR (статьи 5, 25, 32, 33) требует обеспечить целостность и конфиденциальность обработки ПДн, фиксировать доступ к данным и обеспечить доказательную базу для реагирования на инциденты в течение 72 часов [13]. NIST SP 800-92 (первоначально 2006 года, проект редакции 2023 года) формирует структуру управления журналами событий: генерация — передача — хранение — анализ — утилизация [14].

Принципиальное отличие российского подхода от GDPR — в конкретности требований приказов ФСТЭК: там прямо перечислены события, обязательные к регистрации, и атрибуты каждой записи. Это упрощает аудиторскую проверку, но иногда ограничивает гибкость.

Часть 2. Что логировать: типология событий и состав записей

2.1. Минимальный перечень событий по требованиям ФСТЭК

Согласно методическому документу ФСТЭК России от 11 февраля 2014 года «Меры защиты информации в государственных информационных системах», а также требованиям Приказа № 21, в ИСПДн как минимум подлежат регистрации следующие события [3][4][11]:

Аутентификация и доступ:

• успешные и неуспешные попытки входа пользователей в информационную систему с фиксацией предъявленного идентификатора, даты, времени, результата;
• загрузка и останов операционной системы;
• попытки удалённого доступа с фиксацией идентификатора устройства и используемого протокола;
• изменение привилегий учётных записей, в том числе действия администраторов.

Операции с данными:

• факт доступа к персональным данным — чтение, запись, изменение, удаление;
• подключение машинных носителей информации;
• вывод персональных данных на внешние носители или принтеры.

Системные события:

• запуск и завершение программ и процессов, связанных с обработкой ПДн;
• попытки доступа программных средств к защищаемым объектам (файлам, записям БД, портам, каналам связи);
• установка и обновление программного обеспечения;
• изменения в конфигурации информационной системы и системы защиты.

Инциденты и аномалии:

• срабатывание средств антивирусной защиты;
• события системы обнаружения вторжений;
• сбои и ошибки средств регистрации.

Требования к составу каждой записи (минимум) [4]:

• тип события;
• дата и время (с синхронизацией по единому источнику времени);
• идентификатор источника события;
• результат (успех / неуспех);
• субъект доступа — пользователь и/или процесс.

При регистрации попыток удалённого доступа дополнительно указываются используемый протокол и интерфейс доступа [4].

2.2. Дополнительные события для расширенной защиты

Помимо обязательного минимума, специалисты в области ИБ рекомендуют фиксировать ряд дополнительных событий, которые существенно облегчают расследование:

Со стороны приложений и баз данных:

• массовые выборки из БД, содержащих ПДн (выгрузка более N записей за сессию);
• изменения прав доступа к таблицам и представлениям с ПДн;
• выполнение административных команд (DDL, изменение схемы БД);
• факты обращения к API, возвращающим персональные данные.

Со стороны сетевой инфраструктуры:

• трансграничная передача данных (соединения с зарубежными адресами);
• аномально высокий объём исходящего трафика;
• обращения к ресурсам из нетипичных географических локаций или во внерабочее время.

Со стороны почтовых и коммуникационных систем:

• отправка писем с вложениями, содержащими ПДн, на внешние адреса;
• факты доступа к архивам переписки.

По данным компании Konfirmity, фиксация повторяющихся неудачных попыток входа, доступа к чувствительным данным в нерабочее время или резкого всплеска в объёме выгружаемых данных — именно это позволяет выявить угрозу до того, как она превратится в инцидент [15].

2.3. Проблема ПДн в самих логах

Один из самых недооценённых рисков — журналы событий нередко содержат сами персональные данные. Записи аутентификации могут содержать ФИО и учётные данные сотрудников; журналы приложений — параметры запросов с именами клиентов и их атрибутами; трассировки ошибок — фрагменты содержимого полей форм.

В этом случае сам журнал становится объектом, требующим защиты как источник ПДн. Практика GDPR и международных стандартов предлагает несколько подходов [13][15]:

Псевдонимизация полей: вместо реального имени пользователя в лог пишется его хеш или внутренний идентификатор, позволяющий идентифицировать субъекта при расследовании, но не несущий открытого ПДн.

Обезличивание на уровне источника: перед записью в лог параметры запроса маскируются — например, номер телефона заменяется на +7(9**)**-**-**.

Разделение журналов: технические события (IP-адреса, идентификаторы сессий) хранятся отдельно от бизнес-событий (какой клиент получил доступ к своей карте). Связывание осуществляется только при необходимости расследования.

Принцип минимизации данных в логах — аналог privacy-by-design применительно к системам журналирования — прямо вытекает из принципа минимизации обработки ПДн, закреплённого в статье 5 152-ФЗ [9] и статье 5 GDPR [13].

Часть 3. Как хранить: архитектура, сроки и защита журналов

3.1. Архитектурные решения

Централизованный сбор событий. Практика отдельных журналов на каждой системе устарела. Современный подход — централизованная платформа управления событиями (SIEM или специализированный log-коллектор), которая агрегирует события из всех источников: ОС, СУБД, веб-серверов, средств защиты, Active Directory, почтовых систем. Это позволяет проводить корреляцию событий между разными компонентами ИТ-инфраструктуры [16].

Для крупных инфраструктур используется многоуровневая архитектура: источники событий → агенты сбора (log forwarder) → промежуточные коллекторы → центральный SIEM. Каждый уровень обеспечивает буферизацию на случай сетевых сбоев и гарантированную доставку.

Синхронизация времени. Без единого источника точного времени (NTP-сервер) корреляция событий из разных систем теряет смысл. ФСТЭК выделяет это в отдельную меру РСБ.6. Расхождение временны́х меток даже в несколько секунд может исказить хронологию атаки при расследовании.

Разделение хранилищ. «Горячие» логи (последние несколько недель, к которым обращаются в реальном времени для мониторинга) хранятся на быстрых носителях. «Тёплые» (несколько месяцев) — на более дешёвых дисках или объектном хранилище. «Холодный» архив (свыше года) — на ленточных библиотеках или объектном хранилище с моделью write-once [17].

3.2. Сроки хранения: российские требования vs. практика

Минимальный срок хранения записей о событиях безопасности по Приказу ФСТЭК № 21 — три месяца [4]. Усиленные меры для высоких уровней защищённости увеличивают этот срок. Ряд отраслевых регуляторов (финансовый рынок, критическая информационная инфраструктура) устанавливают более длительные сроки: для субъектов КИИ — в соответствии с требованиями 187-ФЗ и нормативными актами ФСТЭК/ФСБ.

Международная практика (NIST SP 800-92, PCI DSS 4.0) рекомендует хранить журналы безопасности не менее года, из которых последние три месяца — в режиме оперативной доступности [14][17]. Мировой опыт расследований показывает, что многие атаки обнаруживаются спустя несколько месяцев после первоначального проникновения: в 2024 году среднее время обнаружения инцидента до его раскрытия составляло около 197 дней по различным оценкам.

Рекомендуемые практические сроки для России:

• Журналы аутентификации и доступа к ПДн — не менее 12 месяцев.
• Журналы изменений конфигурации и прав доступа — не менее 12 месяцев.
• Журналы сетевого трафика (netflow) — не менее 90 дней оперативно, до 12 месяцев в архиве.
• Журналы почтовых систем — не менее 90 дней.
• Журналы физического доступа (СКУД) — не менее 90 дней.

При определении сроков следует учитывать: срок исковой давности по административным делам (1 год по КоАП), срок исковой давности по гражданским делам (3 года), а также то, что срок давности по уголовным делам о нарушениях в сфере ПДн может быть значительно длиннее в зависимости от тяжести статьи.

3.3. Защита целостности и конфиденциальности журналов

Журналы аудита обладают ценностью только при условии их неизменности. Злоумышленник, получивший доступ к системам, первым делом стремится уничтожить следы своего присутствия в логах. ФСТЭК указывает на это в мере РСБ.7 и требует применения криптографических методов для обеспечения целостности [4].

Практические меры защиты журналов:

Разделение прав доступа. Администраторы систем, действия которых фиксируются, не должны иметь доступа к изменению или удалению журналов. Принцип разделения обязанностей (SoD) применяется здесь в полной мере.

Write-once хранилище. Запись журналов в хранилище с режимом WORM (Write Once, Read Many) — ленточные библиотеки, облачные объектные хранилища с иммутабельными корзинами — делает ретроактивное изменение записей технически невозможным [17].

Криптографическая цепочка. Каждая запись лога может быть связана с предыдущей через хеш-функцию (аналог blockchain), что позволяет обнаружить удаление или изменение любой записи в середине цепочки.

Резервное копирование. Приказ ФСТЭК № 21 (усиленные меры РСБ.7) требует обеспечивать резервное копирование записей регистрации, в том числе на носители однократной записи [4].

Изоляция хранилища журналов. SIEM или log-платформа должны быть размещены в отдельном сетевом сегменте с ограниченным входящим доступом: только с авторизованных источников.

Шифрование при хранении и передаче. Передача событий с источников на коллектор — по зашифрованному каналу (TLS). Хранение архивных журналов — с шифрованием на уровне тома или файловой системы.

Часть 4. Как использовать при расследовании инцидентов

4.1. Сроки реагирования: новые требования 152-ФЗ

Статья 21 Федерального закона № 152-ФЗ (в редакции, действующей с 2022 года) устанавливает двухэтапную процедуру уведомления Роскомнадзора [5][18]:

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

Второй шаг — не позднее 72 часов: расширенный отчёт о результатах внутреннего расследования с описанием: установленных причин, объёма и характера скомпрометированных данных, списка принятых мер по устранению последствий и уязвимостей.

Несоблюдение этих сроков с 30 мая 2025 года влечёт штраф: для юридических лиц — от 1 до 3 миллионов рублей [1]. Именно заблаговременно настроенные журналы аудита дают возможность уложиться в 72 часа с полным и достоверным отчётом.

Важно понимать: законодательство не даёт определения «утечке», но статья 21 152-ФЗ описывает её как «неправомерную передачу, предоставление, распространение или доступ» [18]. Это означает, что попытка несанкционированного доступа, даже не приведшая к реальному хищению данных, может потребовать уведомления.

4.2. Этапы расследования инцидента с ПДн

Расследование инцидента, связанного с ПДн, проходит несколько стандартных этапов. В российской практике их описывают специалисты таких компаний, как «Информзащита», F.A.C.C.T., Positive Technologies, ГК «Газинформсервис» и другие [19][20]:

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

Этап 2. Сохранение доказательств. Критически важный шаг, который часто пропускают. До начала анализа необходимо сделать криминалистически корректные копии журналов событий, образы оперативной памяти и дисков затронутых систем. Любые действия на исходных системах могут уничтожить доказательства.

Этап 3. Восстановление хронологии (timeline reconstruction). На основе журналов событий из разных источников строится единая временная шкала инцидента. Это возможно только при наличии синхронизированных временны́х меток. Журналы аутентификации позволяют установить первоначальную точку входа; журналы БД — какие таблицы и записи были прочитаны; сетевые журналы — куда и в каком объёме были переданы данные.

Этап 4. Идентификация субъекта действий. Установление того, кто совершил действия: внешний злоумышленник (по IP-адресам, индикаторам компрометации), скомпрометированная учётная запись внутреннего пользователя или намеренный инсайдер. Журналы AD/LDAP, VPN, аутентификации в приложениях — ключевые источники.

Этап 5. Оценка масштаба. Ответ на вопрос «какие ПДн и скольких субъектов были скомпрометированы». Журналы запросов к БД позволяют восстановить точный перечень обращений; журналы сетевого трафика — объём исходящих данных.

Этап 6. Подготовка отчёта. Результаты расследования оформляются в виде структурированного отчёта для Роскомнадзора (в рамках 72-часового требования), а также для внутреннего использования и, при необходимости, для правоохранительных органов.

4.3. SIEM и автоматизация анализа

Ручной анализ журналов при современных объёмах (сотни тысяч и миллионы событий в сутки) нереалистичен. SIEM-платформы (Security Information and Event Management) автоматизируют сбор, корреляцию и анализ событий [16].

Ключевые сценарии использования SIEM для защиты ПДн:

Обнаружение аномалий. Правила корреляции выявляют отклонения от нормального поведения: пользователь, впервые обращающийся к конфиденциальной таблице БД; множество неудачных попыток входа с последующей успешной аутентификацией; доступ к ПДн из нетипичной географической локации; массовая выгрузка данных за короткий период времени.

Агрегация для расследования. При возникновении инцидента SIEM позволяет за минуты собрать все релевантные события из десятков источников и выстроить хронологию, построение которой вручную заняло бы дни [15].

Автоматическое уведомление. Настроенные оповещения при срабатывании критических правил позволяют начать реагирование немедленно, не ожидая утреннего просмотра отчётов.

В российской практике среди SIEM-решений используются как зарубежные (IBM QRadar, Splunk — в тех организациях, где они ещё эксплуатируются), так и отечественные (MaxPatrol SIEM от Positive Technologies, R-Vision SIEM, «Юнит SIEM» и другие). Для форензических расследований применяются решения F.A.C.C.T. Managed XDR, Kaspersky Anti Targeted Attack и другие [21].

4.4. Форензика и цифровые доказательства

Компьютерная криминалистика (форензика) в части работы с ПДн решает задачу получения юридически значимых доказательств. В российском праве компьютерные доказательства принимаются арбитражными судами и судами общей юрисдикции при соблюдении ряда условий [19][20]:

Целостность и цепочка хранения доказательств. При изъятии журналов необходимо фиксировать хеш-суммы файлов, использовать блокираторы записи и документировать каждый шаг работы с носителем. Любое нарушение может привести к тому, что доказательство не будет принято судом.

Судебно-техническая экспертиза (СКТЭ). В случаях, когда компания планирует привлечь виновных к ответственности, к расследованию привлекаются лицензированные эксперты (ФСТЭК/ФСБ). Они проводят СКТЭ, результаты которой имеют доказательную силу.

Kill Chain и карта атаки. По итогам форензического расследования составляется описание цепочки атаки (Kill Chain): точка входа, горизонтальное перемещение, эскалация привилегий, доступ к ПДн, вывод данных. Эта карта является основой для рекомендаций по устранению уязвимостей и предотвращению повторных инцидентов [20].

Как отмечают эксперты российских ИБ-компаний, «ошибки часто начинаются до инцидента: когда нет логов, нет политик доступа, нет DLP — расследовать нечего» [21].

Часть 5. Практический чек-лист

5.1. Что проверить прямо сейчас

Организационные меры:

• Утверждён документ «Политика регистрации событий безопасности» с перечнем событий, составом атрибутов и сроками хранения.
• Назначено ответственное лицо за мониторинг журналов, которое не является администратором систем, чьи действия фиксируются.
• Проведена оценка уровня защищённости ИСПДн по ПП-1119; требования к логированию соответствуют установленному уровню.
• Перечень событий безопасности пересматривается не реже одного раза в год.

Технические меры:

• На всех ИСПДн настроена централизованная передача событий на SIEM или log-коллектор.
• Синхронизация времени настроена по единому источнику NTP на всех системах.
• Доступ к хранилищу журналов разграничен: администраторы систем не имеют прав на изменение или удаление логов.
• Срок хранения журналов — не менее трёх месяцев, для чувствительных данных — не менее 12 месяцев.
• Настроено резервное копирование журналов.
• Реализована защита передачи журналов по зашифрованному каналу.
• Настроены правила обнаружения аномалий и алерты для критических событий.

Процессы реагирования:

• Утверждён и протестирован план реагирования на инциденты с ПДн, включающий чёткий алгоритм уведомления Роскомнадзора в течение 24 и 72 часов.
• Известна контактная информация уполномоченного лица, имеющего УКЭП для подачи уведомлений через портал РКН.
• Проведено хотя бы одно учение (tabletop exercise) по сценарию утечки ПДн.

5.2. Типичные ошибки и как их избежать

Ошибка 1. Логи есть, но за ними никто не смотрит. Собранные и не просматриваемые журналы — это потенциальные доказательства без ценности для раннего обнаружения. Журналы ценны тогда, когда процесс их мониторинга систематизирован: ежедневный просмотр дашборда, еженедельные отчёты по аномалиям, ежеквартальный ретроспективный анализ.

Ошибка 2. Логируются только «успешные» события. Часто системы настроены на фиксацию успешных операций, тогда как именно неудачные попытки — множество неудачных авторизаций, отклонённые запросы к запрещённым ресурсам — сигнализируют о подозрительной активности.

Ошибка 3. Журналы хранятся там же, где и данные. Если злоумышленник получил доступ к серверу с ПДн, скорее всего, он получил и доступ к локальным журналам. Изолированное централизованное хранилище — обязательное условие.

Ошибка 4. Отсутствие синхронизации времени. Расследование, основанное на журналах с рассинхронизированными временными метками, может привести к ошибочным выводам о хронологии.

Ошибка 5. Журналы содержат незащищённые ПДн. Случайная или намеренная запись персональных данных (паролей, номеров карт, персональных атрибутов) в журналы создаёт дополнительный риск и расширяет периметр защиты. Псевдонимизация и маскирование полей в логах должны быть настроены проактивно.

Ошибка 6. Недооценка объёма хранилища. Журналы — это большие данные. Без предварительного расчёта объёма через несколько месяцев хранилище переполняется, система начинает перезаписывать старые события, и ценные доказательства теряются. Расчёт должен включать: число источников, среднее число событий в секунду, размер записи, срок хранения.

Ошибка 7. Разрыв между журналами и процессом расследования. Журналы собираются, но при реальном инциденте специалисты не знают, где искать, как выгрузить нужный фрагмент, в каком формате предоставить данные регулятору. Регламент расследования и тренировки — обязательны.

Часть 6. Кейсы и примеры из российской практики

Статистика Роскомнадзора за 2024 год показывает характерное отраслевое распределение: наибольшее количество утечек — у компаний в сфере торговли и оказания услуг. В 2023 году лидировали страхование, медицина и ритейл [6]. Это свидетельствует о системном дефиците зрелости процессов информационной безопасности именно в тех сегментах, которые обрабатывают наибольший объём клиентских данных.

Показательный аспект российской практики: представитель Роскомнадзора в начале 2024 года сообщил, что операторы персональных данных фактически не направляли регулятору уведомлений об утечках — при том что утечки происходили [18]. Это означало либо незнание требований о 24-часовом уведомлении, либо намеренное сокрытие инцидентов. В обоих случаях отсутствие выстроенных процессов расследования, основанных на журналах аудита, делало своевременное уведомление невозможным.

С 30 мая 2025 года за каждый такой случай неуведомления — от 1 до 3 миллионов рублей штрафа для юридических лиц [1].

Ещё один паттерн, который прослеживается в публичных отчётах российских ИБ-компаний: инсайдерский фактор. Форензические специалисты отмечают, что за значительной долей утечек стоит «мотивированный сотрудник» [21]. Журналы пользовательской активности в приложениях с ПДн, совмещённые с DLP-системой, — это первичная линия обнаружения подобных случаев.

Часть 7. Тренды и будущее аудита ПДн

Несколько направлений, которые будут определять развитие практики логирования ПДн в ближайшие годы:

Нейронные сети и UEBA. User and Entity Behavior Analytics (UEBA) использует алгоритмы машинного обучения для построения базовой модели поведения каждого пользователя и автоматического обнаружения аномалий. Это позволяет выявлять инсайдерские угрозы, которые не срабатывают по сигнатурным правилам SIEM [16].

Требования к взаимодействию с НКЦКИ и ГосСОПКА. Для субъектов КИИ обязательное взаимодействие с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак становится нормой, а не исключением. Это подразумевает стандартизацию форматов и протоколов передачи событий.

Обезличивание и передача данных в Минцифры. С 1 сентября 2025 года вступают в силу требования об обезличивании ПДн для отдельных категорий операторов. Это создаёт новые требования к аудиту: необходимо фиксировать не только факт доступа к «живым» ПДн, но и операции с обезличенными данными, с возможностью подтвердить их корректность.

Cloud-native логирование. Рост использования российских облаков (Yandex Cloud, SberCloud, МТС Cloud) и on-premise контейнерных платформ требует интеграции журналирования на уровне container runtime, Kubernetes и managed-сервисов в общую картину мониторинга ПДн.

Нормативная конкретизация. По ряду экспертных оценок, ФСТЭК и Роскомнадзор движутся в сторону более детальных требований к составу и форматам журналов — аналогично тому, как PCI DSS 4.0 обновил требования к логированию по сравнению с предыдущей версией. Организациям стоит готовиться к тому, что текущего минимума РСБ.1–РСБ.7 в будущем может стать недостаточно.

Заключение: выводы и что делать дальше

Журналы аудита действий с персональными данными — это не бюрократический артефакт и не только инструмент соответствия требованиям. В условиях, когда штрафы за утечки исчисляются миллионами и сотнями миллионов рублей, а уголовная ответственность стала реальностью, они превращаются в стратегический инструмент управления рисками.

Ключевые выводы:

Требования российского законодательства конкретны. Приказ ФСТЭК № 21 устанавливает минимальный обязательный состав событий, атрибуты записей и срок хранения не менее трёх месяцев. Но этого минимума недостаточно для реального расследования — нужен расширенный подход.

Ценность журналов определяется не их наличием, а их доступностью, полнотой и защищённостью. Журналы, которые не просматриваются, хранятся без защиты целостности или перезаписываются через две недели, не дают никакой защиты ни при инциденте, ни при проверке регулятора.

72 часа — очень мало. Уложиться в установленный срок расследования возможно только при заблаговременно выстроенных процессах: автоматизированном сборе событий, настроенных правилах корреляции и регламентах реагирования.

Журналы сами требуют защиты. Они содержат или могут содержать персональные данные, являются целью злоумышленников и требуют тех же мер защиты, что и основные источники ПДн.

Что сделать в первую очередь:

1. Провести инвентаризацию источников событий — какие системы генерируют события, связанные с ПДн, и куда эти события сейчас попадают.
2. Оценить полноту регистрации по чек-листу РСБ.1–РСБ.7.
3. Настроить или проверить синхронизацию времени.
4. Установить или подтвердить сроки хранения с учётом уровня защищённости и отраслевых требований.
5. Разработать (или актуализировать) план реагирования на инциденты с ПДн — с фокусом на 24- и 72-часовые обязательства перед Роскомнадзором.

Пятый фактор: непрерывный контроль ПДн как основа для аудита

Полноценная система логирования начинается с понимания того, где в организации вообще находятся персональные данные. Без актуальной карты ПДн невозможно ни корректно определить перечень событий, подлежащих регистрации, ни оценить масштаб инцидента при расследовании.

Именно эту задачу решает платформа «Пятый фактор» — on-premise решение для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, файловых хранилищах, почте, Active Directory/LDAP, CRM, системах 1С и API.

Ключевое преимущество, особенно актуальное в контексте логирования: «Пятый фактор» работает исключительно с метаданными, структурой и агрегатами — без передачи и хранения «сырых» персональных данных. Само решение не становится дополнительным источником риска.

Для построения системы аудита платформа решает две ключевые проблемы, которые обсуждались в статье. Во-первых, она даёт актуальную «карту ПДн»: где и какие данные обрабатываются, кто является владельцем каждого источника, что изменилось в инфраструктуре с момента последней проверки. На основе этой карты можно корректно настроить мониторинг событий именно там, где находятся ПДн. Во-вторых, она обнаруживает новые риски раньше, чем они становятся инцидентами: новые поля в базах данных, новые сервисы, новые интеграции с ПДн появляются непрерывно — платформа фиксирует их появление, не требуя ручного аудита.

В практическом смысле: когда у оператора есть 72 часа на расследование инцидента и подачу отчёта в Роскомнадзор, живая карта ПДн позволяет сразу ответить на вопрос «какие данные и каких субъектов могли быть скомпрометированы», а не тратить это время на поиск источников.

Подробнее о платформе: https://5factor.ru

Источники

[1] Консультант Плюс. Новые штрафы за персональные данные с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[2] data-sec.ru. Штрафы за персональные данные в 2026 году — https://data-sec.ru/personal-data/fines/

[3] ФСТЭК России. Приказ от 18 февраля 2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных» — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21

[4] fstec21.blogspot.com. РСБ: меры регистрации событий безопасности (РСБ.1, РСБ.2, РСБ.7) — https://fstec21.blogspot.com/2017/07/the-definition-of-security-events-to-be.html

[5] law.ru. Утечка персональных данных: штрафы в 2025 году, уведомление 24 и 72 часа — https://www.law.ru/article/28376-utechka-personalnyh-dannyh-shtrafy-v-2025-godu

[6] Хабр. В первой половине 2025 года РКН выявил 35 фактов утечек ПДн, 39 млн записей — https://habr.com/ru/news/924602/

[7] level-legal.com. Штраф за утечку личных данных вырастет до 500 млн руб. — https://www.level-legal.com/news/shtraf-za-utechku-lichnyh-dannyh-vyrastet-do-500-mln-rub-chto-eshe-izmenitsya

[8] Правовест Аудит. Изменения в обработке персональных данных с 30 мая 2025 года — https://pravovest-audit.ru/nashi-statii-nalogi-i-buhuchet/izmeneniya-v-obrabotke-personalnyh-dannykh-s-30-maya-2025-goda/

[9] Консультант Плюс. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (ред. от 24.06.2025) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[10] fstec21.blogspot.com. РСБ.5 Мониторинг результатов регистрации событий безопасности — https://fstec21.blogspot.com/2017/08/outcome-monitoring-security-events.html

[11] radium-it.ru. Регистрация событий безопасности в отношении персональных данных — https://www.radium-it.ru/brief/pd/security-events/

[12] ФСТЭК России. Приказ от 11 февраля 2013 г. № 17 — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-11-fevralya-2013-g-n-17

[13] NXLog Blog. GDPR compliance and log management best practices — https://nxlog.co/news-and-blog/posts/gdpr-compliance

[14] NIST. Special Publication 800-92 Rev.1 (Draft), Cybersecurity Log Management Planning Guide — https://csrc.nist.gov/pubs/sp/800/92/r1/ipd

[15] Konfirmity. GDPR Logging and Monitoring: A Practical Guide — https://www.konfirmity.com/blog/gdpr-logging-and-monitoring

[16] SearchInform. SIEM Compliance: How to Meet Regulatory Requirements — https://searchinform.com/articles/cybersecurity/measures/siem/management/compliance/

[17] Fortra. Audit Log Best Practices for Security & Compliance — https://www.fortra.com/blog/audit-log-best-practices-security-compliance

[18] blog.cortel.cloud. Как сообщить в Роскомнадзор об утечке персональных данных — https://blog.cortel.cloud/2024/01/18/kak-soobshhit-v-roskomnadzor-ob-utechke-persdannyh/

[19] securitymedia.org. Форензика: искусство расследования инцидентов ИБ — https://securitymedia.org/info/forenzika-iskusstvo-rassledovaniya-intsidentov-ib.html

[20] blog.infra-tech.ru. Форензика — виды, этапы, инструменты и технологии — https://blog.infra-tech.ru/forenzika-rf/

[21] axoftglobal.ru. Форензика: искусство расследования инцидентов ИБ в России — https://axoftglobal.ru/news/forenzika_iskusstvo_rassledovaniya_intsidentov_ib

[22] Exabeam. How Does GDPR Impact Log Management? — https://www.exabeam.com/explainers/gdpr-compliance/how-does-gdpr-impact-log-management/

[23] Sonar. Audit Logging Best Practices, Components & Challenges — https://www.sonarsource.com/resources/library/audit-logging/