Этика и безопасность при внедрении биометрии и поведенческой аутентификации: баланс удобства и риска

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

• Термины и классификация
• Архитектура внедрения
• Угрозы и уязвимости
• Право и регуляторика
• Этические риски
• Практики защиты
• Жизненный цикл данных
• Дорожная карта внедрения
• Выбор технологий

Термины и классификация

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

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

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

Архитектура внедрения

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

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

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

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

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

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

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

Угрозы и уязвимости

Одной из главных угроз для биометрии являются presentation attacks, то есть атаки, при которых злоумышленник пытается обмануть датчик во время предъявления биометрического признака. Сюда относятся поддельные отпечатки, маски, фото, экраны с воспроизведением изображения и иные способы обмануть сенсор; именно для таких случаев ISO/IEC 30107 описывает подходы к presentation attack detection, или PAD, то есть автоматическому обнаружению подделки при захвате признака.

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

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

Право и регуляторика

В российской модели регулирования биометрия рассматривается как особая область персональных данных, а если она используется для установления личности, то попадает под режим биометрических персональных данных по статье 11 152‑ФЗ. Практический вывод состоит в том, что для организации недостаточно просто «собирать фото или голос»: важно, используется ли эта информация именно для идентификации или аутентификации человека.



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

С 1 июня 2023 года в РФ действует специальный режим по идентификации и аутентификации с использованием биометрии в рамках закона № 572‑ФЗ, а также подзаконных актов об аккредитации и порядке обработки биометрических данных. Для практики это важно по двум причинам: во-первых, определён круг допустимых участников и процедур, во-вторых, часть биометрических сценариев теперь привязана к Единой биометрической системе и коммерческим биометрическим системам, работающим в установленном порядке.

Отсюда следует ключевое ограничение: не всякая обработка биометрии в коммерческой системе допустима в произвольном виде. Если организация строит сервис на фото лица или голосе для идентификации или аутентификации, она должна проверить, подпадает ли сценарий под требования закона 572‑ФЗ, нужен ли доступ через ЕБС (Единая биометрическая система), требуется ли аккредитация, и не относится ли обработка к исключениям, предусмотренным законом. Для архитектуры это означает, что юридическая проверка должна идти до технической реализации, а не после.

Отдельно следует учитывать позицию о том, что предоставление биометрии не должно становиться обязательным, если закон прямо не требует иного. В разъяснениях по 152‑ФЗ отмечается, что отказ гражданина предоставить биометрию или согласие на её обработку не должен автоматически влечь отказ в услуге, если для такой услуги нет специальной законной обязанности использовать биометрические данные. Для продуктовой команды это означает необходимость альтернативного сценария входа и равнозначного доступа к услуге.

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

Для работодателей и СКУД-сценариев это означает ещё более жёсткую проверку. Если фото сотрудника используется для контроля доступа, Роскомнадзор рассматривает такую информацию как биометрические персональные данные, и требуется письменное согласие по правилам статьи 9 и статьи 11 152‑ФЗ. Иными словами, фото на пропуске само по себе может быть обычным персональным данными, но как только оно начинает использоваться для автоматического установления личности, включается специальный режим.

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

Этические риски

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

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

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

Практики защиты

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

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

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

Метрики и качество

Оценивать такие системы нужно не только по удобству, но и по понятным метрикам безопасности. Для биометрии традиционно используют FAR — долю ложных допусков, FRR — долю ложных отказов и EER — точку равной ошибки, когда FAR и FRR приблизительно совпадают. Эти показатели помогают увидеть реальный компромисс между безопасностью и удобством, а не полагаться на субъективные впечатления.

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

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

Жизненный цикл данных

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



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

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

Дорожная карта внедрения

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



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

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

Выбор технологий

При выборе поставщика следует проверять, где именно хранятся шаблоны, как реализованы защита и удаление данных, поддерживаются ли стандарты вроде FIDO/WebAuthn и какие механизмы защиты от подделок доступны по умолчанию. Для биометрии желательно, чтобы были прозрачные материалы по testing and reporting PAD-механизмов и понятная политика хранения данных.

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

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

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