comibank.

Анатомия цифрового банкинга и финтех-трендов

Безопасность и идентификация

Биометрическая идентификация: риски утечки и защита шаблонов

Биометрическая идентификация в банке закрывает одну уязвимость и создаёт другую. Пароль можно отозвать. PIN-код можно заменить.

Биометрическая идентификация: риски утечки и защита шаблонов

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

В 2024 году в России зарегистрировали свыше 5 тысяч инцидентов несанкционированного доступа к банковским и государственным услугам с использованием фальшивых удостоверений личности. Это оценка Т-Банка. На этом фоне биометрия используется как средство усиления KYC и защиты от фрода. Но сама по себе она не устраняет риск. Она меняет точку атаки: вместо кражи пароля атакуется процесс снятия биометрии, канал передачи, шаблон или механизм принятия решения.

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

Неизменяемость профиля — главный риск

Классическая схема аутентификации строится вокруг секрета. Пользователь доказывает право доступа знанием пароля, PIN-кода или одноразового кода. При компрометации секрет отзывается. Выпускается новый.

Биометрия работает иначе. Система сопоставляет предъявленный признак с ранее зарегистрированным шаблоном. Лицо и голос выступают не как пароль, а как устойчивые характеристики субъекта. В этом и состоит практическая ценность технологии. Одновременно это ограничивает процедуру восстановления.

Если пароль попал в утечку, последствия локализуются:

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

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

Особенно критична разница между идентификацией и аутентификацией.

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

Аутентификация отвечает на другой вопрос: имеет ли уже известный субъект право выполнить конкретное действие? Например, войти в приложение, изменить номер телефона, оформить кредит или вывести средства.

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

Где возникает компрометация

Утечка может произойти не только из центрального хранилища. Архитектура удалённой верификации включает несколько зон риска:

1. Камера и микрофон устройства. На этом этапе формируется исходный сигнал. Вредоносное ПО или подменённый программный интерфейс могут передать системе не то, что получает физический датчик.

2. Клиентское приложение. Ошибка в SDK, слабая защита от отладки или некорректное управление сессией создают условия для инжекции.

3. Канал передачи. Требуются шифрование, проверка сертификатов, защита от повторной отправки и привязка запроса к конкретной сессии.

4. Шлюз удалённой идентификации. Здесь обрабатываются атрибуты пользователя, метаданные устройства, результаты liveness-проверки и ответ внешнего сервиса.

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

6. Слой принятия решения. Ошибка в пороге совпадения или в правилах исключений может превратить корректную биометрию в разрешение на мошенническую операцию.

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

Математический вектор вместо фотографии

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

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

При повторной проверке система получает новый сигнал и также преобразует его в вектор. Затем вычисляется степень близости между новым и зарегистрированным шаблонами. Если значение выше заданного порога, проверка считается пройденной. Если ниже — отклонённой или переданной на дополнительный контроль.

Упрощённо процесс выглядит так:

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

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

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

Почему шифрования недостаточно

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

Рабочая архитектура обычно разделяет:

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

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

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

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

Математический слепок снижает риск раскрытия исходной фотографии. Он не превращает биометрию в отзывной пароль.

Атака смещается к моменту снятия биометрии

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

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

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

Основные классы атак распределяются следующим образом:

Класс атакиМеханикаЧто требуется от защиты
Подмена изображенияПеред камерой используется фотография, экран или другой носительАнализ глубины, движения, текстуры и реакции на случайные команды
ВидеоповторСистема получает заранее записанный роликНепредсказуемые задания, синхронная проверка движения и контроль временных признаков
ДипфейкЛицо или голос синтезируются нейросетью в реальном времениАнализ артефактов генерации, согласованности мимики, голоса и контекста
ИнжекцияПоддельный сигнал поступает в обход камеры или микрофонаАттестация приложения, контроль источника данных, защита SDK и устройства
Атака на сессиюРезультат одной проверки повторно используется в другой операцииОдноразовые токены, привязка результата к операции и защита от replay
Социальная инженерияПользователь сам передаёт доступ или проходит проверку под давлениемПоведенческий анализ, задержки, лимиты и независимые факторы подтверждения

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

Liveness Detection: что именно проверяет система

Liveness detection — проверка того, что перед системой находится живой человек, а не запись, изображение или сгенерированный поток. Термин часто воспринимается как единый механизм. На практике это набор тестов и сигналов.

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

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

Для удалённой верификации важна не только реакция, но и временная связь между командой, ответом и сеансом:

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

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

Почему liveness не даёт гарантии

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

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

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

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

ЕБС и регуляторная модель хранения

Российская модель регулируется Федеральным законом № 572-ФЗ и нормами 152-ФЗ. Для коммерческих организаций установлено ограничение на хранение биометрических персональных данных для целей идентификации вне Единой биометрической системы.

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

Практически схема разделяет несколько ролей:

1. Клиентский канал собирает биометрический сигнал.

2. Банковское или финтех-приложение организует сессию и передаёт запрос.

3. Внешний контур выполняет необходимые процедуры идентификации и сопоставления.

4. Банк получает результат, а не исходную биометрическую запись.

5. Внутренний риск-движок принимает решение по операции с учётом дополнительных факторов.

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

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

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

По данным, приведённым в отраслевых материалах, после подключения к ЕБС снижение мошеннических заявок в МФО может достигать 97%. Такой показатель нельзя переносить на любой банк, продукт или сценарий. Результат зависит от качества интеграции, состава дополнительных проверок и того, какие заявки система вообще считает мошенническими.

Что должен контролировать банк

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

Минимальный набор контрольных зон выглядит так:

  • Регистрация. Кто и как создаёт первичный шаблон. Проверяется ли подлинность документа, живость лица, целостность устройства и соответствие данных?
  • Передача. Защищён ли канал от повторной отправки, подмены сертификата и перехвата сессии?
  • Шаблонизация. Где формируется вектор. Остаётся ли исходный сигнал в памяти, логах, кэше или системе мониторинга?
  • Хранение. Как разделены вектор, идентификатор клиента и ключ шифрования?
  • Сравнение. Где выполняется матчинг. Есть ли ограничения на массовые запросы и перебор?
  • Результат. Можно ли повторно использовать положительный ответ в другой сессии?
  • Администрирование. Кто имеет доступ к шаблонам, журналам и настройкам порогов?
  • Реакция. Как система блокирует подозрительную активность и переводит операцию на дополнительную проверку?

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

Сегментация должна распространяться и на подрядчиков. Банковский процесс часто включает провайдера KYC, поставщика liveness-модуля, облачную инфраструктуру и внешние шлюзы. Каждый новый компонент расширяет цепочку доверия. Если результат внешней проверки принимается без верификации подписи, срока действия и контекста операции, атака на интеграцию становится атакой на весь процесс идентификации.

Компрометация профиля и восстановление доступа

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

Поэтому компенсация строится вокруг отзыва доверия к конкретному сценарию:

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

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

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

Итог

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

Основные риски находятся в трёх местах:

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

2. атаки на момент снятия биометрии — дипфейки и инжекция в обход сенсора;

3. ошибки интеграции между клиентским приложением, шлюзом, ЕБС и внутренним риск-движком.

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

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

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

Почему биометрию нельзя считать полноценной заменой паролю?
Биометрический профиль невозможно изменить или перевыпустить после компрометации, так как лицо и голос являются устойчивыми характеристиками человека, а не секретной информацией.
Что такое математический вектор и зачем он нужен?
Это цифровой слепок признаков, в который система преобразует биометрический сигнал. Использование вектора вместо исходной фотографии или аудиозаписи снижает последствия утечки, так как из него нельзя восстановить оригинальные данные.
Что такое liveness detection и гарантирует ли он безопасность?
Это набор тестов для проверки того, что перед системой находится живой человек, а не запись или подделка. Liveness является лишь вероятностным фильтром и не дает абсолютной гарантии безопасности, поэтому должен дополняться другими мерами контроля.
В чем заключается риск инжекционной атаки?
При инжекции поддельный сигнал поступает в систему в обход физического датчика, например, напрямую в программный контур приложения. Это позволяет злоумышленникам передать системе сгенерированные данные, минуя проверку камеры или микрофона.
Как российские банки должны хранить биометрические данные?
Согласно закону, коммерческие организации не должны создавать собственные хранилища биометрии для идентификации. Данные должны передаваться в Единую биометрическую систему (ЕБС) и храниться там исключительно в виде математических векторов.