Как устроена Единая биометрическая система (ЕБС) в России: архитектура, жизненный цикл данных, безопасность и сценарии применения

1. Введение

Единая биометрическая система (ЕБС) — государственная информационная система, предназначенная для удалённой идентификации и/или аутентификации физических лиц с использованием биометрических персональных данных. На практике ЕБС чаще всего рассматривают как инфраструктурный слой, который позволяет организациям подтверждать личность гражданина дистанционно, а гражданину — получать услуги без очного визита, когда это допускается регламентами.

Чтобы понимать устройство ЕБС, важно разделять:

• персональные данные (ФИО, паспортные сведения и т. п.);

• биометрические персональные данные (в контексте ЕБС — лицо и голос);

• биометрический шаблон (производный набор признаков, полученный обработкой исходных данных, который используется для сравнения).

2. Что такое ЕБС в юридическом и техническом смысле

2.1. Юридическая рамка

Ключевой нормативный акт, который прямо регулирует отношения по идентификации/аутентификации с применением биометрических персональных данных, — федеральный закон № 572-ФЗ от 29.12.2022.

2.2. Техническая роль системы

На прикладном уровне ЕБС решает задачу “подтверждения личности по биометрии” как сервис:

• принимает биометрические данные при регистрации (enrollment),

• формирует и хранит шаблоны,

• выполняет сравнение по запросу уполномоченных потребителей (организаций),

• возвращает результат проверки в рамках регламентированного сценария.

3. Какие биометрические данные используются в ЕБС

В ЕБС используются два вида биометрии:

• изображение лица,

• запись голоса.

При этом в документации и разъяснениях по ЕБС отдельно подчёркивается, что система работает с биометрией в виде преобразованных данных (шаблонов/векторов признаков), а не только как с “фото и аудио” в бытовом понимании.

4. Участники и роли в экосистеме ЕБС

4.1. Гражданин (субъект данных)

Роль гражданина включает:

• выбор — регистрировать биометрию или нет (в общем подходе система позиционируется как добровольная),

• управление статусом и согласиями через личный кабинет,

• удаление биометрии (что прекращает возможность пользоваться услугами через ЕБС до повторной регистрации).

4.2. Точки/каналы регистрации

Для регистрации в ЕБС используются:

• отделения уполномоченных организаций (на практике часто банки),

• мобильный канал через специализированное приложение (в связке с учётной записью).

4.3. Организации-потребители (банки/сервисы)

Потребители ЕБС — организации, которые по регламенту могут запрашивать проверку по биометрии для оказания услуг (например, в сценариях удалённой идентификации).

4.4. Оператор системы

Оператором ЕБС в публичных источниках называется АО «Центр Биометрических Технологий» (ЦБТ).

5. Жизненный цикл биометрии: от сдачи до результата проверки

Ниже — “техническая логика” жизненного цикла без привязки к конкретному поставщику ПО.

5.1. Регистрация (enrollment)

Этапы обычно включают:

1. привязку к учётной записи (как правило, через инфраструктуру цифровой идентификации/учётной записи),

2. съём лица и голоса,

3. контроль качества (чёткость, освещение, шум, длительность/разборчивость),

4. проверки антиспуфинга (в т. ч. “живость”, если применяется в конкретном сценарии),

5. формирование набора данных для дальнейшего создания шаблона.

5.2. Формирование шаблона (feature extraction)

Типовой принцип:

• из исходного изображения/аудио извлекаются признаки,

• признаки преобразуются в биометрический шаблон (вектор/набор параметров),

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

5.3. Хранение и разделение контуров

В разъяснениях Минцифры подчёркивается подход разнесения персональных данных и биометрических данных по разным системам, чтобы снизить риск “единой точки атаки”, а также использование криптографических механизмов для защиты данных.

5.4. Проверка личности: 1:1 и 1:N

В практике биометрических систем различают:

• аутентификацию (1:1): “человек заявляет, кто он, система проверяет соответствие шаблону профиля”;

• идентификацию (1:N): “человек не заявляет идентификатор, система ищет, кто это, по базе”.

Какая из моделей используется в конкретной услуге — зависит от регламента услуги и архитектуры интеграции. В сценариях удалённой идентификации в финтехе обычно важны процедуры подтверждения личности для предоставления услуг дистанционно.

6. Архитектура ЕБС на уровне компонентов

Ниже — расширенная модель “как это устроено” в терминах контуров, потоков данных и точек контроля. Описание дано на уровне архитектурных принципов: конкретные названия модулей и форматы сообщений могут отличаться в зависимости от версии регламентов и интеграционных спецификаций.

6.1. Укрупнённая компонентная схема

ЕБС удобно представлять как набор контуров, связанных защищёнными интерфейсами:

• Контур захвата (Capture/Client): получение фото/видео лица и записи голоса.

• Контур предварительной обработки (Pre-processing): нормализация, контроль качества, антиспуфинг.

• Контур извлечения признаков (Feature Extraction): формирование биометрического шаблона.

• Контур хранения (Template Storage): хранение шаблонов, управление версиями, привязки.

• Контур сравнения (Matching): сравнение “входного” шаблона с “эталонным” (1:1) или поиск (1:N).

• Контур управления доступом и аудитом (Security & Audit): авторизация потребителей, журналирование, контроль политик.

• Интеграционный контур (API Gateway/Adapter): точки интеграции для внешних сервисов (организаций-потребителей).

6.2. Потоки данных: enrollment и verification

6.2.1. Поток enrollment (регистрация биометрии)

Типовой поток выглядит так:

1. Инициация регистрации

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

   • формируется “контекст регистрации” (идентификатор процесса, требования к уровню, параметры качества).

2. Захват биометрии

   • камера: фото или видео (в зависимости от метода проверки “живости”);

   • микрофон: голосовой фрагмент(ы).

3. Контроль качества (quality gate)

   • оценка резкости/экспозиции/положения лица;

   • оценка шумов/уровня сигнала/разборчивости для голоса;

   • при низком качестве — запрос повторного съёма.

4. Антиспуфинг

   • проверки “живости” (liveness) и признаки подделки;

   • при подозрении — отказ или усиленный сценарий (зависит от политики).

5. Нормализация

   • выравнивание лица, приведение масштаба, устранение поворота, выделение области лица;

   • для голоса: фильтрация, нормализация уровня, сегментация.

6. Извлечение признаков

   • генерация биометрического вектора (шаблона) для лица и/или голоса.

7. Сохранение и версионирование

   • запись шаблонов в хранилище;

   • сохранение метаданных: время, уровень, канал регистрации, показатели качества, версия алгоритмов;

   • фиксация “активной” версии шаблона.

8. Фиксация результата

   • статус регистрации (успех/ошибка);

   • события в журнале аудита.

6.2.2. Поток verification (проверка по биометрии)

Вариант для 1:1 (аутентификация) в общем виде:

1. внешний сервис инициирует проверку (в рамках своей бизнес-операции);

2. формируется контекст проверки (какой уровень нужен, пороги, требования к liveness);

3. пользователь проходит захват биометрии;

4. система делает quality + антиспуфинг;

5. извлекается входной шаблон;

6. выполняется сравнение с эталонным шаблоном профиля;

7. возвращается результат (успех/неуспех) и служебные статусы;

8. всё логируется.

6.3. Разделение персональных данных и биометрии

Для снижения рисков обычно применяют принцип логического/организационного разделения:

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

• биометрические шаблоны — в другом;

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

Ключевая идея: даже при компрометации одного контура злоумышленник не должен автоматически получить “полную картину” (и биометрию, и персональные данные, и каналы доступа).

6.4. Управление версиями шаблонов и алгоритмов

Практически важно, что биометрия “стареет” не только из-за изменений внешности, но и из-за обновлений моделей:

• версия алгоритма извлечения признаков может меняться;

• новые версии могут давать более стабильное распознавание и антиспуфинг;

• система может хранить несколько шаблонов (или несколько представлений) и помечать один как основной.

Типовые стратегии:

• хранить активный шаблон + один/несколько резервных;

• обновлять шаблон при повторной регистрации или при успешных проверках (если политика это допускает);

• различать “канал регистрации” (очно/удалённо) и “уровень”, который влияет на допустимость использования.

6.5. Точки контроля и “политики” (policy enforcement)

В реальной эксплуатации ключевую роль играют политики:

• пороги совпадения для лица и голоса (они могут быть разными);

• правила повторных попыток (количество, задержки, условия);

• обязательность liveness и его тип (пассивный/активный);

• ограничения по устройству (камера/микрофон/среда);

• ограничения по сценарию (вход/подтверждение операции/удалённая идентификация).

Эти политики не равны “настройкам сервиса”; это механизм управления риском: чем выше цена ошибки, тем строже политика.

7. Уровни биометрии: упрощённая, стандартная, подтверждённая

Разделение по уровням удобно рассматривать как разный “гарантийный пакет”: как регистрировали, какие проверки применялись, насколько надёжно установлена связь между человеком и учётной записью, какие ограничения действуют.

7.1. Чем уровни отличаются по технике и процедурам

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

• Стандартная: больше требований к качеству съёма и проверкам, шире применимость.

• Подтверждённая: наличие очного компонента упрощает задачу “строгого установления личности” и снижает риск подмены на этапе регистрации.

7.2. Таблица: уровни как управление риском

7.3. Плюсы и минусы уровневой модели

Плюсы:

• позволяет “калибровать” требования под риск операции;

• снижает барьер входа (не всем нужен максимальный уровень);

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

Минусы:

• сложнее пользовательское понимание (“почему недоступно”);

• усложняется интеграция сервисов (нужно учитывать уровень);

• возникает “операционная цена” поддержки (ошибки качества, статусы, апгрейд уровня).

8. Где применяется ЕБС на практике

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

8.1. Дистанционная идентификация (как замена очного визита)

Сценарий: получить услугу, требующую подтверждения личности, без посещения офиса.

Типовые особенности:

• повышенные требования к liveness;

• усиленные пороги совпадения;

• более строгие правила повторных попыток;

• обязательная фиксация аудита (кто инициировал, когда, какой результат).

Риски:

• качество удалённого канала;

• ошибки из-за освещения/шума;

• попытки подделки (видео/аудио).

8.2. Аутентификация при входе (дополнительный фактор)

Сценарий: вход в сервис, где биометрия дополняет пароль/код или заменяет их при достаточном уровне.

Типовые особенности:

• часто применяют 1:1;

• допускаются более “быстрые” проверки при низком риске;

• возможна адаптивная политика (если риск повышен — усилить проверку).

8.3. Подтверждение операции (step-up authentication)

Сценарий: пользователь уже вошёл, но для критической операции требуется усиленное подтверждение.

Типовые особенности:

• политика “поднять уровень проверки” только на момент операции;

• привязка результата проверки к конкретной транзакции;

• строгие требования к журналированию и доказуемости.

8.4. Доступ к сервисам с повышенными требованиями

Сценарий: оформление, подписание или получение услуги, где важна минимизация ошибочной идентификации.

Типовые особенности:

• чаще требуется более высокий уровень биометрии;

• выше требования к непротиворечивости факторов (учётная запись, устройство, поведенческие сигналы).

8.5. Ограничения применимости

Ситуации, где биометрия может быть неэффективна или нежелательна:

• нестабильные условия (плохой свет/шум);

• нестандартные средства ввода (слабая камера/микрофон);

• юридические и организационные ограничения (если регламент требует иной способ идентификации);

• высокая цена ошибки при невозможности обеспечить строгий контроль канала.

9. Безопасность: как ЕБС снижает риски

Ниже — расширение раздела безопасности: угрозы, механизмы защиты, антиспуфинг, аудит, а также типовые статусы/ошибки, с которыми сталкиваются интеграции.

9.1. Модель угроз: что реально пытаются атаковать

1) Атаки на канал захвата

• подмена камеры (воспроизведение видео вместо “живого” лица);

• подмена микрофона (воспроизведение записи);

• использование синтетики (генеративное видео/аудио).

2) Атаки на учётную запись/контекст

• захват учётной записи, от имени которой запускают проверки;

• подмена устройства или перехват сессии.

3) Атаки на интеграцию

• попытки повторной отправки старого “успешного” результата (replay);

• подмена параметров запроса (уровень/порог/режим проверки);

• ошибки реализации на стороне потребителя (неверная обработка статусов).

4) Компрометация данных

• утечки шаблонов;

• утечки метаданных и журналов;

• компрометация ключей шифрования/подписи.

9.2. Антиспуфинг и liveness: как это обычно устроено

9.2.1. Пассивный liveness

Проверка “живости” по одному потоку данных без активных команд пользователю:

• анализ микродвижений, текстуры, отражений;

• детекция экрана/бумаги/маски;

• анализ несоответствий (например, “плоский объект” вместо лица).

Плюсы:

• быстрее и проще UX;

• подходит для массовых сценариев.

Минусы:

• сложнее устойчивость к сильным атакам;

• выше требования к качеству камеры.

9.2.2. Активный liveness

Проверка “живости” через действие:

• повернуть голову;

• моргнуть;

• произнести фразу;

• выполнить последовательность инструкций.

Плюсы:

• лучше против воспроизведения записи;

• повышает доказуемость.

Минусы:

• хуже UX, больше отказов из-за ошибок пользователя;

• зависит от корректности распознавания действий.

9.2.3. Голосовой антиспуфинг

Обычно включает:

• признаки воспроизведения через динамик;

• признаки синтетической речи;

• согласованность фразы/текста (если применяется).

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

9.3. Сравнение 1:1 и 1:N: технические и риск-различия

9.3.1. 1:1 (аутентификация)

“Проверить, что это пользователь X”.

Особенности:

• быстрее (сравнение с одним профилем);

• проще контролировать ложные совпадения;

• проще интерпретировать результат.

9.3.2. 1:N (идентификация)

“Найти, кто это”.

Особенности:

• существенно выше требования к точности и порогам;

• риск ложных совпадений растёт с размером базы;

• чаще требует дополнительных факторов или процедур подтверждения.

Практическое следствие: даже если технически возможно 1:N, для массовых сервисов обычно предпочтительнее 1:1, потому что это лучше контролируется с точки зрения рисков.

9.4. Криптография, ключи и контуры доверия

Типовые практики защиты в подобных системах:

• шифрование данных “на хранении” и “в передаче”;

• управление ключами в выделенном контуре (с разграничением доступа);

• принцип минимальных привилегий для сервисов и операторов;

• подпись/целостность критичных сообщений между контурами.

Здесь важен не сам факт “шифруем”, а архитектура ключей:

• кто имеет доступ к ключам;

• как происходит ротация;

• как обрабатываются инциденты (компрометация/подозрение).

9.5. Аудит и журналирование: что фиксируется

Для доказуемости обычно фиксируют:

• кто инициировал проверку (идентификатор потребителя);

• время, канал, уровень биометрии;

• результаты quality gate и liveness (в виде статусов/оценок);

• итоговый результат сравнения;

• технические идентификаторы процесса (корреляционные id).

Важно: журналы — это не “лог для разработчика”, а элемент расследований и комплаенса. Поэтому они должны быть защищены, неизменяемы в рамках политики и доступны только уполномоченным ролям.

9.6. Типовые статусы и ошибки в интеграции

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

9.6.1. Статусы “успех/неуспех”

• SUCCESS: проверка прошла, совпадение выше порога, liveness/качество выполнены.

• FAIL_NO_MATCH: совпадение ниже порога (человек не подтверждён).

• FAIL_LIVENESS: не пройдена проверка “живости”.

• FAIL_QUALITY: недостаточное качество данных (свет/резкость/шум/обрезка лица).

9.6.2. Ошибки “процесс/доступ”

• ERROR_NOT_ENROLLED: у пользователя нет биометрии нужного уровня или нет активного шаблона.

• ERROR_CONSENT_REVOKED: отсутствует согласие или оно отозвано/ограничено.

• ERROR_POLICY_DENIED: политика не разрешает сценарий (например, требуется подтверждённый уровень).

• ERROR_RATE_LIMIT: превышены лимиты попыток/частоты.

• ERROR_TIMEOUT: таймаут процесса (пользователь не завершил шаги).

• ERROR_INTEGRATION: ошибка запроса (неверные параметры, подпись, идентификаторы).

• ERROR_SERVICE_UNAVAILABLE: временная недоступность контура.

9.6.3. Как правильно обрабатывать статусы на стороне сервиса

Минимальная “правильная” модель:

• FAIL_QUALITY → предложить повторить съём, дать инструкции (свет/камера/тишина).

• FAIL_LIVENESS → предложить повторить; при повторных отказах — альтернативный канал.

• FAIL_NO_MATCH → не “мучить” повторами бесконечно; переходить к альтернативе.

• ERROR_NOT_ENROLLED / ERROR_POLICY_DENIED → показать путь повышения уровня/подключения.

• ERROR_TIMEOUT → позволить начать заново.

• ERROR_SERVICE_UNAVAILABLE → деградировать на альтернативный фактор (код/личный визит), если доступно.

Критически важно: не трактовать техническую ошибку как “пользователь не прошёл” и наоборот. Это влияет и на UX, и на юридическую корректность действий.

9.7. Плюсы и минусы биометрии как фактора безопасности (в инженерной логике)

Плюсы:

• снижает риск “передачи секрета” (пароль/код можно передать, биометрию — существенно сложнее);

• позволяет дистанционные сценарии, где иначе нужен очный визит;

• может быть частью многофакторной схемы (step-up по риску).

Минусы:

• качество и условия съёма напрямую влияют на отказоустойчивость;

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

• сложнее “перевыпустить фактор”, чем заменить пароль (поэтому важны политики и процессы).

10. Управление биометрией гражданином: статус, согласия, удаление

10.1. Проверка статуса

Проверка наличия биометрии и её статуса описывается как доступная через личный кабинет на Госуслугах (раздел профиля, связанный с биометрией).

10.2. Отзыв согласия

В справочных материалах ЕБС/Госуслуг указывается, что согласиями можно управлять через профиль/раздел согласий, где возможно отозвать согласие на обработку биометрии.

10.3. Удаление биометрии

В справке Госуслуг прямо фиксируется практическое следствие: после удаления биометрии получить услуги через ЕБС нельзя, а для восстановления доступа потребуется зарегистрировать биометрию заново.

Плюсы возможности удаления/контроля:

• пользователь сохраняет управляемость над инструментом идентификации,

• можно “закрыть канал” биометрической идентификации при смене предпочтений по риску,

• упрощается модель комплаенса “по запросу субъекта”.

Минусы практического характера:

• потеря доступа к биометрическим сценариям до повторной регистрации,

• необходимость заново проходить процедуру регистрации (в т. ч. очно для подтверждённого уровня),

• возможные неудобства при восстановлении доступа к услугам, где биометрия была настроена как основной фактор.

11. Интеграция ЕБС для бизнеса и сервисов: общая модель

С точки зрения архитектуры сервис-потребитель обычно строит интеграцию вокруг цепочки:

1. пользователь инициирует действие (вход, подтверждение, идентификация),

2. сервис формирует запрос на проверку по регламенту,

3. выполняется биометрическая проверка,

4. сервис получает результат и применяет бизнес-логику (разрешить/запретить/запросить альтернативный фактор),

5. события логируются (для расследований, разборов спорных ситуаций и комплаенса).

Плюсы для бизнеса:

• снижение количества очных визитов в сценариях, где это критично для экономики процесса,

• повышение конверсии в удалённых каналах при корректном UX,

• возможность “сильного фактора” в дополнение к паролям/кодам.

Минусы для бизнеса:

• интеграция и сопровождение (включая регламентные требования) сложнее, чем пароль/код,

• требуется работа с ошибками съёма и исключениями (камера, шум, освещение),

• нужны процессы по спорным случаям и альтернативные каналы подтверждения.

12. Типовые причины, почему проверка “не проходит”

На практике сбои чаще всего связаны не с “поломкой системы”, а с качеством входных данных и условиями.

12.1. Лицо

• недостаточное освещение или сильная засветка,

• тени, закрывающие ключевые зоны лица,

• сильный смаз (движение камеры),

• низкое качество фронтальной камеры.

12.2. Голос

• шум (улица, транспорт),

• эхо/плохой микрофон,

• слишком короткая/искажённая запись,

• попытка записывать “с динамика” вместо прямой записи микрофоном.

12.3. Организационные причины

• неверный уровень биометрии для требуемой услуги (например, сервис требует подтверждённый уровень),

• неактуальные согласия или ограничения на использование,

• неуспешная привязка к учётной записи/профилю в рамках сценария.

13. FAQ

Чем отличается идентификация от аутентификации

• Аутентификация отвечает на вопрос “это тот же человек, что и профиль X?” (1:1).

• Идентификация отвечает на вопрос “кто это из базы?” (1:N).

В ЕБС реально используются только лицо и голос?

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

Что произойдёт, если удалить биометрию?

Справочные материалы Госуслуг указывают: после удаления услуги через ЕБС становятся недоступны, и для возврата нужно регистрировать биометрию заново.