Биометрическая идентификация и аутентификация в Казахстане: в чём разница

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

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

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

Коротко

• Совпадение селфи с фотографией документа решает только задачу проверки 1:1.

• Для поиска повторной регистрации нужен отдельный поиск 1:N по базе фотографий.

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

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

1:1, 1:N и аутентификация отвечают на разные вопросы

Термины пересекаются, но не являются взаимозаменяемыми. NIST разделяет оценку верификации 1:1 и идентификации 1:N. В казахстанском праве биометрическая аутентификация означает сравнение и проверку соответствия биометрических данных для цели установления личности. Однако даже её положительный результат не объясняет, какое действие должен совершить банк или сервис: это определяет отдельная политика доступа или операции.

Верификация 1:1 подтверждает заявленную связь

В сценарии 1:1 пользователь сначала сообщает системе, с какой записью его нужно сравнить: предъявляет документ, вводит сведения учётной записи или начинает сессию ранее зарегистрированного клиента. Система сравнивает признаки лица на текущем изображении с одним эталоном — заранее сохранённой фотографией, происхождение которой организация может подтвердить.

Результат выражается числом — оценкой сходства, или similarity score. Организация задаёт порог: результат выше него считается совпадением, ниже — несовпадением. Эта оценка не равна вероятности того, что перед камерой находится конкретный человек, если поставщик отдельно не доказал такую интерпретацию.

NIST оценивает системы 1:1 через две связанные ошибки:

• FMR, false match rate — доля сравнений разных людей, которые достигли или превысили порог;

• FNMR, false non-match rate — доля сравнений одного человека, которые оказались ниже порога.

Повышение порога обычно уменьшает ложные совпадения, но увеличивает ложные отказы. Поэтому фраза «точность 99%» почти ничего не сообщает покупателю системы: нужны рабочий порог, обе ошибки, характеристики данных и условия теста. ISO/IEC 19795-1:2021 требует описывать тестовые данные, протокол и границы применимости результата именно для того, чтобы лабораторную цифру не выдавали за универсальное свойство системы.

Поиск 1:N меняет масштаб ошибки

При поиске 1:N новое изображение сравнивается с галереей — базой сохранённых эталонов. Система может вернуть одного кандидата, несколько наиболее похожих записей или сообщить, что совпадений нет. Организация заранее определяет, что делать с результатом: использовать его как один из сигналов, передать сотруднику на проверку или считать совпадение неустановленным.

Для 1:N нельзя ограничиваться показателями 1:1. В оценке NIST FRTE 1:N используются, в частности:

• FPIR — доля поисков, при которых система ошибочно возвращает кандидата из галереи;

• FNIR — доля поисков зарегистрированного человека, в которых правильный кандидат не был возвращён по заданному правилу;

• rank — место правильного кандидата в списке, отсортированном по сходству.

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

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

Правила Казахстана разделяют проверку изображения и сличение

Пункт 1 статьи 46 Цифрового кодекса Казахстана определяет цифровую аутентификацию как процедуру подтверждения личности физического лица или правоспособности юридического лица при доступе к услугам в цифровой среде и объектам — в случаях, предусмотренных законодательством Казахстана или соглашением сторон. Пункт 4 статьи 48 определяет биометрическую аутентификацию как процесс сравнения и проверки соответствия биометрических данных для цели установления личности. В той же статье биометрические данные, используемые для цифровой аутентификации, отнесены к персональным данным; обязательная обработка биометрии допускается только в случаях, установленных законами.

Для банков, организаций, осуществляющих отдельные виды банковских операций, и МФО действует постановление АРРФР № 54 от 3 апреля 2026 года. Оно задаёт последовательность биометрической аутентификации по изображению лица:

• Получить достоверное текущее изображение лица.

• Получить идентификационные сведения человека.

• Получить эталонное изображение.

• Сопоставить текущее и эталонное изображения.

• Принять итоговое решение по результатам проверки достоверности, сличения и критериям заказчика, как предписывают Правила № 54.

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

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

По итогам проверки достоверности и сличения формируются отдельные электронные документы. В них входят результат, идентификационные данные, реквизиты заказчика, дата и время; документ удостоверяется ЭЦП провайдера. Итоговое решение и результаты хранятся заказчиком по правилам той финансовой услуги, в рамках которой проводилась аутентификация.

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

Сравнение лиц и проверка подделки закрывают разные угрозы

Face Match сравнивает признаки двух лиц. Liveness проверяет признаки живого предъявления, а PAD означает обнаружение атак предъявления — например, фотографии или маски перед камерой. В продуктовых описаниях эти понятия часто стоят рядом, хотя их область различается. Проверка документа, защита канала камеры и анализ сессии остаются самостоятельными уровнями контроля.

Исследование Face Flashing, представленное на NDSS, прямо разделяет модуль liveness и модуль распознавания лица. Оно также показывает, почему любой PAD нужно оценивать в границах конкретной модели угроз: результаты менялись при освещении и вибрации, а авторы описали классы оборудования и масок, которые могли бы обойти их прототип.

ISO/IEC 30107-3:2023 описывает испытание и отчётность о работе механизмов PAD при заданных типах атак. Область такого испытания уже, чем оценка безопасности всей биометрической системы. Поэтому отчёт о PAD сам по себе не подтверждает защиту от захвата аккаунта, подмены мобильного приложения или классов атак, не вошедших в протокол.

Онбординг, повторный вход и дедупликация

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

Удалённое открытие продукта

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

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

Повторный вход или подтверждение операции

учётная запись и сессия
→ текущее изображение и проверка живого присутствия
→ сравнение один к одному с зарегистрированным эталоном
→ оценка устройства, операции и аномалий
→ разрешить / запросить дополнительный фактор / отклонить

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

Поиск повторных регистраций

новая проверенная регистрация
→ поиск один ко многим по допустимой клиентской галерее
→ анализ ближайших кандидатов и порога
→ сопоставление дополнительных данных
→ подтвердить уникальность / передать на разбор

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

Порог выбирают по цене двух ошибок

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

Для рабочей проверки порога организация выполняет следующие действия:

• Определение цены ложного совпадения и ложного отказа для конкретной операции.

• Отдельную оценку 1:1, 1:N и PAD на соответствующих метриках.

• Проверку качества на используемых устройствах, при реальном освещении и компрессии.

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

• Теневой запуск без автоматических отказов.

• Выделение пограничной зоны для повторной попытки или ручного разбора.

• Мониторинг доли отказов, атак, повторных попыток и решений операторов после запуска.

В отчёте поставщика следует искать рабочий порог и показатели ошибок при нём, состав тестового набора, размер базы, проверенные типы атак, число попыток и доверительные интервалы. Общая «точность» без этих условий не даёт возможности сравнить два решения.

Правила № 54: результаты и основание решения

Для расследования недостаточно сохранить финальный ответ true или false. Запись должна позволять установить, какой процесс выполнялся и почему система выбрала маршрут.

Состав записи зависит от применимых требований. Для каждой сессии полезно связать:

• идентификатор сессии и операции;

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

• источник эталонного изображения;

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

• версию модели и идентификатор применённой политики;

• причину повторной попытки или ручной проверки;

• итоговое решение и сведения о том, кто его принял;

• электронные документы и подписи, предусмотренные правилами процесса.

Срок хранения нельзя назначить общей фразой «для биометрии». Казахстанские правила № 54 связывают его с требованиями к документам той финансовой услуги, в рамках которой проходила аутентификация.

Что запросить у поставщика до пилота

• Какие отдельные результаты возвращают Face Match, 1:N и liveness.

• Какими метриками измерен каждый модуль и при каком пороге.

• Каков размер тестовой галереи для 1:N и какие типы изображений использованы.

• Какие атаки предъявления перед камерой и атаки с внедрением изображения в видеопоток входили в испытание PAD.

• Где заканчивается проверка поставщика и начинается решение заказчика.

• Как защищены камера, SDK, транспорт и серверные ключи.

• Какие версии модели и правил сохраняются в журнале.

• Как обрабатываются пограничные результаты, повторные попытки и технические ошибки.

• Как проводится теневой пилот и калибровка на собственном потоке.

• Какие сведения сохраняются, где они размещаются и как исполняются сроки удаления.

Face Match Biometric.Vision сравнивает лицо с фотографией документа в режиме 1:1 и возвращает числовую оценку сходства; заказчик настраивает порог под свой сценарий. На той же странице отдельно описан Face Search 1:N для поиска повторных регистраций. За проверку живого присутствия и известных способов подделки отвечает отдельный модуль Liveness.

Эти модули закрывают конкретные технические этапы. Источник эталона, правовое основание обработки, критерии итогового решения, ручной разбор и доказуемость операции остаются частью процесса заказчика. Именно эта граница превращает биометрию из обещания «узнать человека по лицу» в управляемый контроль.