Логи Active Directory как ПДн

Логи Active Directory годами воспринимались как инструмент ИТ-мониторинга, а не как массив персональных данных. Роскомнадзор и ФСТЭК квалифицируют иначе: запись о входе пользователя в домен — это обработка ПДн с момента создания. С 30.05.2025 ст. 13.11 КоАП действует в расширенной редакции ФЗ-420, и любая утечка журналов AD от 1 000 субъектов влечёт штраф от 3 млн ₽. Для CISO это означает конкретную задачу: определить категорию ПДн в логах, выбрать уровень защищённости, закрыть технические меры по Приказу ФСТЭК №21 и выстроить процесс уведомления за 24 часа. Ниже — разбор каждого шага.

Что именно в логах AD квалифицируется как персональные данные?

Персональные данные по ст. 3 ФЗ-152 — любая информация, относящаяся прямо или косвенно к определённому физическому лицу. Журнал событий AD фиксирует: логин (samAccountName или UPN), отображаемое имя, принадлежность к группам безопасности, время и дату входа, IP-адрес рабочей станции, идентификатор сессии, имя компьютера. Каждый из этих атрибутов в отдельности может указывать на конкретного сотрудника — значит, вся запись является ПДн.

Категория ПДн определяет уровень защищённости. Стандартные журналы входа содержат общие ПДн. Если в AD хранятся атрибуты о состоянии здоровья, национальности, политических взглядах или биометрические данные (например, хеш отпечатка пальца в атрибуте altSecurityIdentities) — это специальные категории по ст. 10 ФЗ-152, режим защиты ужесточается.

Отдельного внимания требуют служебные учётные записи (service accounts) и машинные аккаунты. Формально они не относятся к физическому лицу. Но если имя сервисной учётной записи совпадает с именем сотрудника или содержит его инициалы — запись снова становится ПДн. Это типичная ошибка при именовании аккаунтов: svc_ivanov_sql идентифицирует конкретного человека.

Как определить уровень защищённости ИСПДн для журналов AD?

Уровень защищённости (УЗ) устанавливается по ПП РФ №1119 от 01.11.2012 на пересечении трёх параметров: категория ПДн, тип актуальных угроз, количество субъектов. Для большинства корпоративных AD с общими ПДн сотрудников матрица выглядит так:

• УЗ-4 — общие ПДн, угрозы 3-го типа, число субъектов не ограничено. Минимальный набор мер.
• УЗ-3 — общие ПДн, угрозы 2-го типа (недекларированные возможности в прикладном ПО) или число субъектов более 100 000.
• УЗ-2 — общие ПДн, угрозы 1-го типа (недекларированные возможности в системном ПО), или специальные ПДн при угрозах 3-го типа и субъектах более 100 000.
• УЗ-1 — специальные или биометрические ПДн при угрозах 1-го или 2-го типа.

Порог 100 000 субъектов критичен для крупного бизнеса: холдинг с персоналом свыше 100 тысяч человек автоматически повышает УЗ на одну ступень. Для SaaS-платформ с мультиарендной архитектурой, где в одном AD Forest объединены клиентские тенанты, число субъектов суммируется по всем арендаторам — УЗ-3 или УЗ-2 становится нормой.

Какие меры защиты требует Приказ ФСТЭК №21 для журналов AD?

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

РСБ — регистрация событий безопасности. Базовый набор для УЗ-4: регистрация входов и выходов, попыток несанкционированного доступа, изменений прав. УЗ-3 добавляет требование централизованного сбора и защищённого хранения журналов. УЗ-2 и УЗ-1 — автоматический анализ событий в реальном времени. Хранение журналов на контроллере домена без репликации во внешнее защищённое хранилище не удовлетворяет требованиям УЗ-3 и выше.

УПД — управление правами доступа. Принцип минимальных привилегий применительно к AD: административные аккаунты не используются для ежедневной работы, Tier Model разделяет управление лесом, доменом и рабочими станциями. Нарушение Tier Model — типичная находка при аудите.

АНЗ — анализ защищённости. Периодическое сканирование контроллеров домена на уязвимости, проверка конфигурации GPO на соответствие baseline, контроль делегированных прав. Для КИИ дополнительно применяется ФЗ-187 в части категорирования объектов.

ЗИС — защита информационной системы. Сегментация сети: контроллеры домена в выделенном VLAN, доступ к ним только от привилегированных рабочих станций PAW. Для облачных развёртываний Azure AD DS или AWS Managed AD — отдельная оценка: зарубежное облако создаёт риск нарушения требований о локализации.

Обезличивание логов AD для ML: что требует Приказ РКН?

Команды data science используют журналы AD для обнаружения аномалий поведения (UEBA) и обучения моделей машинного обучения. Передача реальных ПДн в ML-пайплайн без обезличивания — нарушение принципа минимизации из ст. 5 ФЗ-152: объём обрабатываемых данных должен соответствовать заявленным целям.

С 2025 года действуют требования к методам обезличивания, установленные подзаконным актом РКН. Регулятор закрепил пять методов: введение идентификаторов (псевдонимизация), изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для логов AD наиболее применимы два: псевдонимизация (замена samAccountName на случайный идентификатор с сохранением связности для временного ряда) и обобщение (замена точного IP-адреса на подсеть /24 или геолокацию).

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

Мультиарендная SaaS: кто оператор ПДн в журналах AD?

В мультиарендной SaaS-архитектуре один лес или один Azure AD tenant обслуживает несколько клиентских организаций. Журналы AD содержат ПДн сотрудников всех арендаторов. Разграничение ролей критично.

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

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

Типовые сценарии нарушений и их последствия

Сценарий 1. Утечка журналов AD через скомпрометированный SIEM-агент. Злоумышленник получает доступ к агенту на контроллере домена и выгружает журналы за последние 90 дней. В базе — 15 000 учётных записей сотрудников и подрядчиков. Ситуация: утечка от 10 000 до 100 000 субъектов. По ч. 13 ст. 13.11 КоАП штраф для юрлица — от 5 до 10 млн ₽. Дополнительно: неуведомление РКН за 24 часа — ещё от 1 до 3 млн ₽ по ч. 11. Если CISO не организовал поручение обработки с SIEM-провайдером — параллельно протокол по ч. 1 ст. 13.11. Стратегия: немедленное уведомление РКН в течение 24 часов, сохранение доказательств принятых мер защиты для применения ст. 4.1 КоАП при назначении штрафа.

Сценарий 2. Передача журналов AD в ML-платформу облачного провайдера без обезличивания и поручения. Команда безопасности строит UEBA-модель на реальных данных из production AD. Данные уходят в облако за рубежом. Ситуация: нарушение одновременно ст. 5 (минимизация), ч. 3 ст. 6 (поручение), ч. 5 ст. 18 (локализация). Три самостоятельных протокола. Штраф только за локализацию — до 6 млн ₽ по ч. 8. Стратегия: перенести ML-инфраструктуру в облако в РФ, псевдонимизировать данные до передачи, оформить поручение обработки с провайдером облака.

Сценарий 3. Проверка РКН при жалобе уволенного сотрудника. Бывший работник требует уничтожения своих ПДн по ст. 21 ФЗ-152. Оператор не реагирует в установленный срок. РКН проводит внеплановую проверку и обнаруживает: журналы AD хранятся 5 лет без правового основания, модель угроз не актуализировалась с 2019 года, поручение с SIEM-подрядчиком отсутствует. Исход: предписание + протоколы по ч. 1 и ч. 5 ст. 13.11. Суммарный штраф — в диапазоне от нескольких сотен тысяч до более чем 1 млн ₽. Стратегия: регламент хранения журналов с обоснованием срока, процесс обработки запросов субъектов, ежегодная актуализация документации.

Как это выглядит на практике

Кейс 1. IT-компания (Северо-Западный ФО, лето 2025) передавала журналы AD корпоративной сети в облачный SIEM зарубежного провайдера без поручения обработки и без уведомления РКН о трансграничной передаче. При внутреннем аудите выявлено 12 000 субъектов в реплицируемых журналах. CISO инициировал переход на отечественный SIEM с размещением в ЦОД в РФ, оформил поручение обработки, подал уведомление в реестр по форме Приказа РКН №180. Протокол по ч. 8 ст. 13.11 был составлен, однако суд снизил штраф, приняв во внимание добровольное устранение нарушений и представленный план мероприятий.

Кейс 2. Производственный холдинг (Уральский ФО, осень 2025) с числом сотрудников более 120 000 человек. Аудит выявил: ИСПДн с журналами AD классифицирована по УЗ-4, тогда как число субъектов и тип актуальных угроз требовали УЗ-3. Меры группы РСБ по централизованному хранению журналов не реализованы. После аудита DATUM компания актуализировала модель угроз, переклассифицировала систему в УЗ-3, внедрила централизованное Log Management решение в защищённом периметре. Проверка РКН, инициированная по жалобе, завершилась предписанием без штрафа — документация соответствовала требованиям на момент проверки.

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

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

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

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

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

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

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

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

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

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

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

5. Какие СЗИ обязательны для ИСПДн с журналами AD?

Приказ ФСТЭК №21 не обязывает использовать конкретные СЗИ — он задаёт меры, которые оператор реализует любыми подходящими средствами. Для УЗ-4 достаточно встроенных механизмов Windows (аудит событий, RBAC, групповые политики). Для УЗ-3 требуется централизованный сбор журналов в защищённое хранилище (SIEM или выделенный Log Management) и средства контроля целостности. Для УЗ-2 добавляется автоматический анализ событий в реальном времени и применение сертифицированных ФСТЭК СЗИ в части, критичной для защиты ПДн. Конкретный набор определяется в плане мероприятий по реализации мер защиты.

Итог

Журналы Active Directory — полноценный массив персональных данных, подпадающий под требования ФЗ-152 с момента записи первого события. Выбор уровня защищённости по ПП РФ №1119, закрытие мер по Приказу ФСТЭК №21, оформление поручений обработки с SIEM и облачными провайдерами, соблюдение требований о локализации с 01.07.2025 — это не опциональные улучшения, а обязательные элементы комплаенса. Каждый пробел создаёт самостоятельный состав нарушения по ст. 13.11 КоАП.

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