VВЫВЕРЕНОинженерные системы безопасности

Интеграции · Москва и МО

Биометрия в системе контроля доступа

Биометрический терминал сам по себе не делает СКУД биометрической. Нужно связать идентификацию, права, контроллер, исполнительное устройство, журнал и резервный сценарий.

Начинаем не с модели терминала, а с вопросов:

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

Когда биометрия оправдана

Биометрия имеет смысл, если важно:

  • связать право доступа с конкретным человеком;
  • снизить риск передачи карты другому сотруднику;
  • работать с уже существующим биометрическим контуром;
  • выполнить отдельные требования конкретного объекта;
  • убрать постоянную выдачу физических идентификаторов там, где это разумно.

Если задача решается обычной картой или QR без дополнительных рисков, биометрия не должна добавляться только ради технологии.

Три архитектуры

Терминал принимает решение сам

В терминале находятся:

  • пользователи;
  • шаблоны;
  • правила;
  • выход управления.

Это компактная схема, но нужно понимать резервирование и журнал.

Терминал передаёт идентификатор в СКУД

Биометрический терминал подтверждает личность, а право прохода остаётся у контроллера.

Так легче сохранять единую матрицу доступа.

Интеграция через сервер/API

Биометрическая платформа и СКУД синхронизируют:

  • пользователей;
  • права;
  • события;
  • идентификаторы.

Это самый функциональный вариант, но он сильнее зависит от совместимости платформ и лицензий.

Сначала проверяем существующую СКУД

До закупки терминалов фиксируем:

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

Если текущая система может принять новый способ идентификации, полная замена не требуется автоматически.

Свет и геометрия

Для распознавания лица на точность влияют:

  • высота терминала;
  • расстояние;
  • встречный свет;
  • стекло;
  • движение;
  • рост пользователей;
  • головные уборы/очки — где это существенно;
  • фактическая скорость потока.

Поэтому демонстрация терминала на столе не считается приёмкой.

Ложный отказ

Система должна заранее отвечать: что делает пользователь, если он имеет право на вход, но терминал его не распознал?

Возможны:

  • карта;
  • QR;
  • оператор;
  • другой согласованный идентификатор.

Резервный сценарий обязателен до масштабирования.

Ложное разрешение

Отдельно важен риск ошибочного допуска.

Проверяем:

  • режим распознавания;
  • порог распознавания;
  • защиту от подмены и проверку присутствия живого человека — если платформа поддерживает;
  • качество шаблона;
  • освещение.

Нельзя переносить заявленный производителем процент точности на любой объект без реального теста.

Биометрические данные

Технический проект должен чётко показать:

  • где формируется шаблон;
  • где он хранится;
  • кто администратор;
  • как пользователь удаляется;
  • как отзывается доступ;
  • какие данные уходят за пределы объекта;
  • кто имеет доступ к журналу.

Юридическое основание обработки биометрических данных определяется владельцем системы и ответственными специалистами. Инженерный проект не заменяет юридическую оценку.

ЕБС и специальные контуры

В Москве существуют проекты, где СКУД работает с внешними биометрическими системами и реестрами.

Это отдельная интеграция:

  • с собственным API;
  • требованиями;
  • сертифицированными/совместимыми компонентами;
  • организационными процедурами.

Наличие Face ID в терминале не означает автоматическую совместимость с ЕБС или другим государственным контуром.

Пилот на одной точке

Перед масштабированием:

  1. Выбираем типовой вход.
  2. Настраиваем несколько пользователей.
  3. Проверяем разрешённый проход.
  4. Проверяем запрещённый.
  5. Проверяем человека с отказом распознавания.
  6. Проверяем резервный идентификатор.
  7. Проверяем отзыв права.
  8. Смотрим журнал.
  9. Повторяем в реальном освещении/потоке.

Как принимаем систему

Не «лицо появилось на экране», а полный результат:

  • пользователь распознан;
  • применено правильное право;
  • дверь/турникет реально открыт;
  • событие записано;
  • запрещённый пользователь не проходит;
  • удалённый пользователь больше не проходит;
  • резервный сценарий понятен;
  • отказ сервера/сети ведёт себя согласно проекту.

Что прислать

  • модель текущей СКУД;
  • тип точки: дверь/турникет;
  • число пользователей;
  • способ доступа сейчас;
  • фото входа;
  • ограничения сети/сервера;
  • требуется ли внешняя биометрическая система;
  • допустимый резервный идентификатор.

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

Биометрия полностью заменяет карты?

Не обязательно. Резервный способ часто нужен для отказных ситуаций.

Можно добавить терминал к старой СКУД?

Иногда да — после проверки интерфейсов, контроллера и программной логики.

Нужен интернет?

Зависит от архитектуры. Локальная биометрия и облачная/внешняя платформа — разные решения.

Можно гарантировать точность заранее?

Нет. Реальный результат подтверждается пилотом на конкретной точке.

Нужно менять контроллер?

Только если существующий контроллер не поддерживает требуемую схему.

Связанные решения

ПозвонитьРассчитать