Логи СКУД: специфика

Логи СКУД фиксируют время прохода каждого сотрудника через точку контроля. Это не технические метаданные — это персональные данные, позволяющие идентифицировать конкретного человека и восстановить его маршруты, режим присутствия, паттерны поведения. С 30.05.2025 штраф за утечку таких данных по ч. 12 ст. 13.11 КоАП начинается от 3 млн ₽ и при повторности превращается в оборотный по ч. 15 — до 3% годовой выручки. Для CISO вопрос правового статуса логов СКУД — это вопрос бюджета и репутации.

Чем логи СКУД отличаются от обычных системных журналов?

Системные журналы сервера содержат технические идентификаторы: IP-адреса, UID сессий, коды ошибок. Они могут не относиться к персональным данным, если не позволяют идентифицировать конкретного человека без дополнительных усилий. Логи СКУД устроены иначе.

Запись в журнале СКУД, как правило, содержит: идентификатор карты или биометрии, привязанный к сотруднику; временну́ю метку; идентификатор считывателя (точки прохода); результат события (проход разрешён/отказано). В связке с кадровой базой такая запись мгновенно раскрывает личность субъекта.

Если СКУД использует считыватели отпечатков пальцев, геометрии ладони, распознавание лица или радужки — обрабатываемые данные переходят в категорию биометрических персональных данных по ст. 11 ФЗ-152. Для них требуется письменное согласие работника, а утечка квалифицируется по ч. 17 ст. 13.11 КоАП — штраф 15–20 млн ₽ за факт.

Отдельный вопрос — логи, содержащие сведения о состоянии здоровья: факт прохождения медицинского контроля перед допуском к смене. Такие записи могут попасть в категорию специальных персональных данных по ст. 10 ФЗ-152, обработка которых по умолчанию запрещена вне исключительных оснований.

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

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

Для типового СКУД крупного предприятия алгоритм выглядит так:

• Если СКУД не использует биометрию и не содержит сведений о здоровье — категория «иные ПДн» (не специальные, не биометрические).
• Число субъектов: до 100 000 — одна ветка матрицы, свыше 100 000 — другая.
• Тип угроз (1, 2 или 3) определяется наличием недекларированных возможностей в системном ПО и прикладном ПО. Угрозы 1-го типа — наличие НДВ в системном ПО; 2-го — в прикладном; 3-го — только внешние и внутренние атаки без НДВ.

Большинство корпоративных СКУД попадают в УЗ-3 или УЗ-4. УЗ-3 применяется, если выбраны угрозы 3-го типа и обрабатываются иные ПДн свыше 100 000 субъектов или специальные категории — до 100 000. УЗ-2 возникает при биометрических ПДн и угрозах 2-го типа. УЗ-1 — наиболее жёсткий, встречается редко в контексте СКУД.

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

Какие меры защиты ФСТЭК обязательны для логов СКУД?

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

Для СКУД наиболее значимы следующие группы мер:

• ИАФ (идентификация и аутентификация) — управление учётными записями администраторов СКУД, требования к паролям, многофакторная аутентификация для доступа к серверу логов.
• УПД (управление доступом) — разграничение прав: кто из персонала ИБ и HR может читать журналы, кто — изменять или выгружать.
• РСБ (регистрация событий безопасности) — ведение журнала аудита самого сервера СКУД: кто, когда и какие данные запрашивал. Логи о логах — отдельное требование.
• ЗНИ (защита носителей информации) — шифрование данных на носителях, где хранятся архивы СКУД; контроль вывода данных.
• АНЗ (анализ защищённости) — периодическое сканирование уязвимостей серверного ПО СКУД.

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

Как обезличивать логи СКУД для передачи в ML и аналитику?

Использование данных СКУД для анализа паттернов присутствия, предсказания нагрузки на помещения или обучения моделей поведенческой аналитики — законная задача. Но передача необезличенных логов в аналитическую систему или ML-пайплайн — это отдельная обработка персональных данных, требующая самостоятельного правового основания.

С 2025 года в России действует регулирование обезличенных персональных данных (ст. 13.1 ФЗ-152, введена ФЗ-233 от 08.08.2024). Приказ РКН закрепил пять допустимых методов обезличивания: введение идентификаторов, изменение состава или семантики, декомпозиция, перемешивание, обобщение (агрегация).

Для логов СКУД на практике применяются два подхода:

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

Псевдонимизация не равнозначна обезличиванию в смысле ст. 13.1 ФЗ-152: такие данные всё ещё считаются персональными и требуют правовой основы для обработки. Подлинное обезличивание — необратимое, без возможности повторной идентификации — снимает требования ФЗ-152, но на практике достигается только при агрегации с достаточной степенью обобщения.

Кто оператор при SaaS-СКУД и мультиарендной архитектуре?

Рынок систем контроля доступа движется к облачным и SaaS-решениям. Контроллеры установлены у клиента, но сервер событий, база карт и аналитика работают на стороне вендора. Это классическая схема поручения обработки по ст. 6 ФЗ-152.

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

В мультиарендной архитектуре возникает дополнительный риск: данные нескольких операторов-арендаторов хранятся в единой базе. Если вендор не обеспечивает физическое или логическое разделение баз и не может гарантировать отсутствие смешения — это нарушение принципа несовместимости целей (ст. 5 ФЗ-152) и потенциальное нарушение требований к локализации.

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

Типовые ситуации: как это выглядит на практике

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

Ситуация 2. Передача логов СКУД в ML-платформу без обезличивания. IT-компания (Центральный ФО, осень 2025) настроила передачу сырых журналов СКУД — с ФИО сотрудника, временной меткой и точкой прохода — в платформу поведенческой аналитики у внешнего подрядчика для обучения модели предсказания загруженности офиса. Соглашения о поручении обработки с подрядчиком не было. После инцидента (несанкционированный доступ к платформе аналитики) CISO зафиксировал потенциальную утечку данных более 1 200 сотрудников. Первичное уведомление РКН было направлено в течение 20 часов. Отчёт о расследовании — через 68 часов. Размер итогового административного штрафа по ч. 12 ст. 13.11 КоАП составил несколько миллионов рублей; применение ст. 4.1.1 КоАП для смягчения было недоступно — нарушение не являлось первичным для оператора. ⚠️ Конкретный номер дела и точная сумма штрафа — менеджер уточняет при публикации.

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

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

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

1. Какой УЗ выбрать для SaaS-СКУД с биометрическими считывателями?

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

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

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

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

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

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

Оператор — клиент (работодатель), поскольку именно он определяет цели обработки данных своих сотрудников. Вендор SaaS-СКУД — обработчик по поручению (ч. 3 ст. 6 ФЗ-152). Обязанность заключить договор поручения с перечнем разрешённых действий лежит на операторе. Если вендор нарушит требования ФЗ-152 — юридическая ответственность перед субъектом и РКН всё равно будет у оператора-клиента (ч. 5 ст. 6 ФЗ-152).

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

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

Итог

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

DATUM сопровождает CISO и технических директоров в оценке соответствия ИСПДн на базе СКУД: от определения УЗ и аудита мер ФСТЭК до формирования ОРД и разработки регламентов обезличивания для ML-задач.