Логи EDR на рабочих станциях

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

Являются ли логи EDR персональными данными по 152-ФЗ?

Ст. 3 ФЗ-152 определяет персональные данные как любую информацию, относящуюся к прямо или косвенно определённому физическому лицу. EDR-журнал, содержащий имя учётной записи, hostname, временну́ю метку и команду, однозначно позволяет идентифицировать сотрудника. Это означает, что система сбора и хранения таких журналов является информационной системой персональных данных (ИСПДн) и подпадает под требования ФЗ-152 в полном объёме.

Исключение возможно только при корректном обезличивании: если из записи удалены или заменены все прямые и косвенные идентификаторы, обработка выходит за пределы ст. 3. Однако в большинстве промышленных EDR-развёртываний обезличивание на уровне агента не применяется — данные поступают в SIEM или облачный backend в сыром виде.

Важный нюанс: если EDR развёрнута в организации, отнесённой к субъектам КИИ по 187-ФЗ, требования к защите информации накладываются поверх 152-ФЗ, а не вместо него. Совместное выполнение обоих регуляторных треков обязательно.

Как определить уровень защищённости ИСПДн с EDR-логами?

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

Для EDR-журналов, содержащих только сведения о действиях учётных записей работников без медицинских, биометрических или иных специальных категорий, исходная категория — иные ПДн (не специальные, не биометрические). При угрозах 2-го типа (недекларированные возможности в системном ПО) и числе субъектов менее 100 000 система получает УЗ-3. Если угрозы 1-го типа (НДВ в прикладном ПО, задействованном в ИСПДн) — УЗ-2. Для организаций с более чем 100 000 учётными записями в области мониторинга верхняя планка сдвигается до УЗ-2 при угрозах 2-го типа.

На практике CISO часто присваивают ИСПДн EDR самый низкий уровень, чтобы снизить объём обязательных мер. Это допустимо только при задокументированном моделировании угроз, подтверждающем отсутствие угроз 1-го и 2-го типа. Без такого документа РКН при проверке вправе переоценить класс системы.

Какие меры ФСТЭК обязательны при УЗ-3 и УЗ-4 для систем логирования?

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

Для УЗ-3 базовый набор включает обязательные меры из групп ИАФ, УПД, РСБ, АВЗ, СОВ, ОЦЛ. Именно группа РСБ — регистрация событий безопасности — напрямую касается EDR: оператор обязан определять перечень регистрируемых событий, защищать журналы от несанкционированного изменения и удаления, устанавливать сроки хранения. При УЗ-4 перечень мер короче, однако группа РСБ остаётся обязательной.

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

Как правильно оформить поручение обработки для облачного EDR или SIEM?

Если журналы EDR обрабатываются облачным вендором — российским или иностранным — оператор обязан оформить поручение обработки по ч. 3 ст. 6 ФЗ-152. Поручение должно содержать: перечень действий с ПДн, которые разрешены вендору; цели обработки; обязанность по конфиденциальности; требование обеспечить меры защиты по ст. 19 ФЗ-152; запрет передачи ПДн третьим лицам без согласования; условия уничтожения после завершения обработки.

Без поручения любая передача журналов вендору является несанкционированной передачей ПДн третьему лицу. При использовании иностранного облака (например, European или US datacenter) дополнительно возникают требования ст. 12 ФЗ-152 о трансграничной передаче: до начала передачи необходимо уведомить РКН.

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

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

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

Для ML-пайплайнов на основе EDR-данных наиболее применимы два метода. Первый — введение идентификаторов: имена учётных записей и hostname заменяются псевдонимами; таблица соответствия хранится отдельно с ограниченным доступом. Второй — обобщение: временны́е метки округляются до часа или суток, IP-адреса заменяются подсетью. Сочетание обоих методов снижает риск реидентификации при обучении модели.

Критически важно: обезличенные данные перестают быть ПДн только при необратимости преобразования. Если модель может восстановить исходные записи (например, через атаку на инверсию модели), данные по-прежнему считаются ПДн. Юридическое обоснование необратимости должно быть задокументировано до начала обучения.

Типовые сценарии нарушений при работе с EDR-логами

Сценарий 1. EDR-агент отправляет события в зарубежное облако без локальной записи. Крупная производственная компания (Уральский ФО, лето 2025) развернула облачный EDR с европейским датацентром. Журналы поступали напрямую в облако без промежуточного хранения на российских серверах. При плановой проверке РКН установил нарушение ч. 5 ст. 18 ФЗ-152. Составлен протокол по ч. 8 ст. 13.11 КоАП. Штраф — в нижней части диапазона (несколько миллионов рублей). Стратегия: развернуть российский on-premise коллектор как промежуточный узел до передачи данных в облако; оформить поручение обработки и уведомление о трансграничной передаче.

Сценарий 2. EDR-данные переданы в ML-конвейер без обезличивания. IT-компания (Центральный ФО, осень 2025) обучала модель обнаружения аномалий на сырых EDR-журналах с именами учётных записей. При внутреннем аудите выявлено: в обучающей выборке содержались ПДн более 3 000 работников. Правового основания для такой обработки в согласии не было. Риск — штраф по ч. 1 ст. 13.11 КоАП (до 300 000 ₽) и, при утечке модели, по ч. 12 (3–5 млн ₽). Стратегия: применить введение идентификаторов и обобщение на этапе предобработки, зафиксировать метод обезличивания в техническом задании.

Сценарий 3. SaaS-мультиарендная архитектура без разграничения данных арендаторов. Поставщик SaaS-SIEM (Северо-Западный ФО, начало 2026) хранил журналы нескольких клиентов в одной базе данных с разграничением только на уровне приложения. При инциденте (SQL-инъекция) данные одного арендатора стали доступны другому. Квалификация — нарушение ч. 3 ст. 6 ФЗ-152 (отсутствие изоляции при поручении обработки) + ч. 12 ст. 13.11 КоАП (утечка от 1 000 до 10 000 субъектов). Штраф — в диапазоне 3–5 млн ₽. Стратегия: физическое или логическое разделение баз данных на уровне СУБД; отдельные поручения обработки для каждого арендатора.

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с EDR-логами при УЗ-3?

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

Итог

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

Практика DATUM охватывает технический аудит ИСПДн всех уровней защищённости, подготовку моделей угроз для EDR-инфраструктуры и сопровождение проверок РКН в IT-компаниях и SaaS-поставщиках.

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

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

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