Liveness в Кыргызстане: как выполнить требования к проверке живого человека

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

Порядок НБКР для банков также требует риск-соразмерной комбинации факторов, внутреннего документа с порогами и допустимой точностью, проверки ПО не реже одного раза в полгода и подтверждения результатов в рамках периодического внешнего аудита информационных систем. Значит, liveness нельзя принять один раз по презентации поставщика: его работоспособность должна оставаться измеримой после запуска.

Коротко

• Face Match один к одному устанавливает сходство, liveness/PAD ищет признаки атаки предъявления; результаты не взаимозаменяемы.

• Механизм должен защищать не только от распечатанной фотографии, но и от релевантных атак через экран, видео и изменённый поток.

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

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

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

Что прямо следует из порядка НБКР

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

Пункты 46–49 действующего порядка НБКР образуют четыре контрольных требования:

• комбинация факторов аутентификации соразмерна риску неточной идентификации;

• оценка риска и внутренний документ фиксируют пороги и допустимый уровень точности;

• ПО проверяется не реже одного раза в полгода, а результаты подтверждаются внешним аудитом информационных систем;

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

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

Liveness и Face Match отвечают на разные вопросы

Высокий similarity score не компенсирует провал liveness. И наоборот, живой человек может не совпасть с фотографией документа. Финальная система хранит оба результата и причину решения отдельно.

Что означает «точность» для PAD

Одного процента «успешности» недостаточно. Для liveness есть как минимум две конкурирующие ошибки: пропуск атаки и отклонение добросовестного пользователя. Улучшение одного показателя ценой другого может сделать систему либо небезопасной, либо непригодной.

ISO/IEC 30107-3:2023 задаёт основу для отчётности испытаний presentation attack detection. В практике полезно оценивать APCER — долю атак, ошибочно принятых как добросовестная попытка, и BPCER — долю добросовестных предъявлений, ошибочно классифицированных как атака. Конкретные допустимые значения определяются риск-моделью организации и требованиями применимого порядка; сам стандарт не назначает универсальный порог для каждого банка.

Полугодовая проверка — не повтор одного демо

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

Воспроизводимый протокол содержит:

• версию SDK, модели и конфигурации;

• даты и среду испытания;

• классы bona fide и атак;

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

• пороги и метрики по каждому типу атаки;

• различия с прошлой проверкой;

• найденные ограничения, компенсирующие меры и решение владельца риска.

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

Пять уровней доказательства в рабочей сессии

Результат liveness=true слишком беден для расследования. Минимальная цепочка выглядит так:

• сессия создана сервером и имеет ограниченное время жизни;

• захват связан с этой сессией и защищён от простого повторного использования;

• сохранены версия модели и технические индикаторы без избыточного хранения биометрии;

• результат сравнен с действовавшим порогом;

• правило явно показывает: допуск, повторная попытка или ручная проверка.

Liveness Biometric.Vision проверяет живость по изображению лица и может использоваться в Web SDK, Mobile SDK или REST-процессе, в облаке либо On-Premise. Организация должна проверить решение на собственном канале, установить пороги и включить его в предусмотренные НБКР процедуры контроля и аудита; наличие продукта само по себе не доказывает соответствие.

Когда отправлять на ручную проверку

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

Ручной оператор не должен видеть только итоговый цвет. Ему нужны причина эскалации, качество, результат PAD, Face Match, источник эталона и история попыток. При этом оператор не должен получать больше биометрических данных, чем необходимо для его роли.

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

Источники

• НБКР: Порядок идентификации и верификации клиентов в удалённом режиме, пункты 46–49.

• НБКР: порядок для пользователей мобильных приложений платёжных организаций, пункты 41-3–41-7.

• ISO/IEC 30107-3:2023, Biometric presentation attack detection — Testing and reporting.