Биометрия и защита информации: человеческий признак vs человеческий фактор

Предпосылки

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

В настоящее время сложились все предпосылки для активного использования биометрических технологий: они существенно подешевели и применять их в СЗИ стало проще - сканеры отпечатка пальца стоят десятки долларов, есть SDK для различных ОС. Однако дуализм биометрического признака влечет за собой необходимость очень высокой степени самоконтроля разработчиков при встраивании этих технологий в свой продукт, чтобы вместо усиления защитных свойств, точности и надежности работы — не получалось смешения идентификации с аутентификацией и авторизацией (ошибки сколь очевидной, столь и распространенной).

Про идентификацию и аутентификацию

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

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

Все становится менее прозрачно, когда в системе появляется сущность, называемая «аппаратный идентификатор». Возьмем классический вариант — ТМ-идентификатор. Его использование основано на том, что у него есть память, и туда можно записать различные данные. И чем ТМ-идентификатор (!) будет являться — идентификатором или средством аутентификации — зависит от реализованного порядка его использования в системе. Например, в память устройства можно записать уникальный идентификатор, раздать пользователям, составить табличку вида {ФИО сотрудника; идентификатор}, и потом потребовать, чтобы при входе в систему они предъявляли «таблетку». Если хранящийся в ней номер (или даже — в простейшем случае — собственный ID ТМ-идентификатора) зарегистрирован в системе, то пользователю доступ разрешается, если нет — то нет. В этом случае есть только идентификация, а никакой аутентификации (тем более — двухфакторной) нет и в помине, хотя налицо «предмет», которым «владеет» пользователь.

Другая ситуация — если в ТМ-идентификатор записывать набор данных, связанный с именем пользователя, зарегистрированного в системе, и требовать ввода имени пользователя с последующим прикладыванием зарегистрированной «таблетки», которая в данном случае будет являться фактором аутентификации (двухфакторной, если помимо этого вводить пароль с клавиатуры или что-нибудь еще по еще какому-либо отдельному каналу, а в противном случае — однофакторной, несмотря на «владеть», которое зачастую вызывает твердую уверенность, что факторов уже точно два).

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

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

Про биометрию

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

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

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

• процесс получения параметра,
• процесс получения эталона,
• процесс сравнения,
• процесс предъявления результата.

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

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

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

1. «все в одном» — в одном приборе объединены все сущности (считыватель, верификатор, работа с эталоном)
2. «эталон передается снаружи» — прибор считывает биометрический параметр и верифицирует его с переданным в него эталоном
3. «эталон в базе» — прибор считывает биометрический параметр и передает его в верификатор, функционирующий в ОС, для поиска соответствующего эталона в базе эталонов.

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

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

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

1. системы, не предполагающей авторизации (то есть системы уровня 2 по ФСТЭК — в которой пользователи характеризуются равными полномочиями и задачи идентификации/аутентификации сводятся исключительно ко входу в систему;
2. применения крайне «интеллектуального» считывателя, в функции которого входит помимо считывания параметра и его верификации — также формирование некоего информационного набора, выполняющего в дальнейшем роль логического (а не физического) уникального идентификатора.

Но и в перечисленных случаях необходимо отдавать себе отчет в том, что критичность канала «считыватель — СЗИ» (где под «СЗИ» понимается активная составляющая, принимающая решение) существенно возрастает по сравнению с ситуацией, когда идентификатором пользователя является отдельный параметр, данные о котором поступают в СЗИ по другому, независимому каналу. Например, тот же ТМ-идентификатор.

Во втором из рассматриваемых вариантов («эталон передается снаружи») помимо подмены прибора возможна и подмена эталона. Таким образом, наряду с идентификацией прибора (она актуальна, так как от него зависит корректность считывания и сравнения) СЗИ должно проводить проверку эталона и передавать в прибор для верификации только те эталоны, которые связаны именно с этим конкретным СЗИ и для которых, возможно, опять же, в зависимости от модели угроз, подтверждена неизмененность. При том, что объектов для контроля становится больше, есть и обратный эффект — становится менее привлекательной для злоумышленника реализация атаки на эти компоненты, ведь атаковать их по отдельности становится менее эффективным.

Проблема диверсификации источников данных в этом варианте снимается автоматически, поскольку эталон поступает «снаружи», что и является независимым каналом. Эталон, поступающий, например, из ТМ-идентификатора или из смарт-карты, это и есть идентифицирующие данные, в отличие от аутентифицирующего предъявляемого параметра (самой руки, пальца, глаза).

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

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

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

Использовать ли биометрию?

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

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

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

Пример системы, или «Основано на реальных событиях»

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

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

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

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

1. Ввод в действие и первоначальная настройка системы,
2. Мониторинг и аудит,
3. НШС разных типов,
4. Ввод в систему нового пользователя,
5. Изменение прав существующему пользователю,
6. Существенные изменения системы или требований к ней.

Очевидно, что все работы из данного списка тем менее хлопотны, чем более централизовано управление системой. Именно это является одной из наиболее существенных причин развития от автономных АРМ через классические терминальные системы к терминальным системам с централизованным управлением образами ОС терминальных станций. Для того чтобы не администрировать ОС терминальных станций на рабочих местах пользователей, используется загрузка по сети — в простейшем случае это использование обыкновенного ftp-сервера, а в защищенном исполнении — решения «КАМИ-терминал», ПАК «Центр-Т» или другие альтернативные решения, обязательно предполагающие формирование образов и их доставку на рабочие станции пользователей без физического посещения рабочих мест администраторами. Дальнейшее развитие систем, как правило, заключается в разработке и внедрении разнообразных средств централизованного мониторинга и управления различными подсистемами, чтобы и эти действия не требовали «хождений по коридорам».

Казалось бы, в системе, где образы ПО терминальных станций загружаются по сети[1], действия, которые необходимо производить на клиентских рабочих станциях (как пользователям, так и администраторам) стремятся к нулю.

Пользователь подключает свое персональное устройство — ШИПКУ и вводит PIN-код.

Администратор, если ему необходимо изменить состав поддерживаемого оборудования, терминальных протоколов, адрес терминального сервера — практически любой параметр ПО терминальной станции - изменения эти производятся на специальном АРМе и затем доставляются пользователю без участия администраторов и без работ с терминальной станцией как таковой. Даже журнал работы терминального клиента до старта терминальной сессии — ведется (и, соответственно, анализируется) централизовано — на Сервере хранения и сетевой загрузки, а в рамках сессии — в СЗИ НСД на терминальном сервере.

Естественно, и к таким системам появляются замечания в части недостаточной централизации: эксплуатирующие организации хотели бы, чтобы образы ОС терминальной станции от АРМ сборки образов на Сервер хранения и сетевой загрузки попадали тоже без физического участия персонала, а on-line, прямо во время работы сервера, чтобы журналы с Сервера хранения и сетевой загрузки автоматически отправлялись на какой-то специально назначенный АРМ, и тому подобное. Разработчики по мере возможностей идут навстречу.

Однако, поскольку в обязанности АИБа входит ряд таких вещей, как

— разблокировка сессии пользователя после неверного ввода последним пароля,

— разблокировка ШИПОК после превышения допустимого количества вводов неверного пароля,

— смена паролей, когда пользователь их просто забыл и вспомнить не может, а работать ему надо, и так далее, — на деле оказывается, что АИБы постоянно заняты. Причем для оказания помощи пользователю (разблокировать ШИПКУ или прислонить «таблетку» администратора, если в качестве терминального клиента используется ПЭВМ), зачастую им нужно отправляться физически в другое здание, которое, возможно, существенно удалено. И хорошо, если не в другой населенный пункт.

Казалось бы, нагрузку такого рода снизить невозможно, и остается только пренебречь ею, поскольку, в конце концов, действия это не слишком сложные и не требуют значительной квалификации. Сейчас эти задачи решаются организационно. Например, установкой предельно большого количества попыток неверных вводов PIN-кода ШИПКИ (32 раза). По рассказам АИБов — это не помогает, ШИПКИ все равно блокируют.

Однако это негативно сказывается на продуктивности использования рабочего времени — уже не только АИБами, но и пользователями. А в случае с недобросовестными пользователями возможен и осознанный саботаж — заблокировал ШИПКУ и можешь не работать на законных основаниях, терминальная станция не загружается. Именно в этом, собственно причина того факта, что по регламенту большинства организаций АИБы не могут просто сообщать пользователям PUK-коды для разблокировки их устройств и поручать разблокировать их самостоятельно, ведь в ходе «ошибок» при разблокировке можно заблокировать устройство безвозвратно.

Человеческий признак против человеческого фактора

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

В качестве конкретной реализации изменения подсистемы аутентификации в этом направлении можно предложить интеграцию в ПАК "Аккорд TSE«[2] биометрической аутентификации на основе сканирования сосудистого русла ладони руки.

Технология построена на методе верификации, классифицированном выше как «второй способ» — сравнении предъявленного рисунка сосудистого русла с предъявленным же эталоном, который записан в персональный идентификатор пользователя (в зависимости от необходимой архитектуры это может быть ТМ-идентификатор, ШИПКА, смарт-карта).

Пользователь подносит руку к сканеру и совмещает идентификатор со считывателем (прислоняет ТМ-идентификатор, подключает ШИПКУ или устанавливает смарт-карту в считыватель). Из идентификатора система получает эталон, со сканера — предъявляемый биометрический признак, производится верификация, результат которой обрабатывается Аккордом как пароль пользователя (а как идентификатор пользователя, как и прежде, обрабатывается идентификатор).

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

Однако единственной возможностью компрометации этих данных представляется их подмена или считывание в канале между сканером и ПК. Реализация такой угрозы крайне маловероятна, так как для нее потребовалась бы атака с использованием не только глубоких и специфических знаний и навыков, но и сложной измерительной аппаратуры. Для тех рабочих мест, атака на которые злоумышленника, обладающего необходимыми характеристиками, возможна (то есть угроза утечки по этому каналу признается актуальной), следует использовать «первый способ» -комбинированный считыватель, совмещающий сканер сосудистого русла со считывателем контактной смарт-карты. В этом случае верификация производится самим считывателем и биометрические данные по соединительному кабелю не передаются. Логика поступления данных (эталона и параметра) из разных источников по разным каналам тут сохраняется, но поступают они уже не в СЗИ, а в считыватель, которому в такой системе отводится существенно более критичная с точки зрения безопасности роль.

Это означает, что должна быть обеспечена доверенность и целостность внутреннего ПО считывателя и его идентификация/аутентификация относительно СЗИ при старте работы. Это задача нетривиальная, но решаемая.

В предлагаемом решении применяется технология сканирования сосудистого русла PalmSecure фирмы Fudjitsu, реализованная на двух типах устройств:

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

2) сканер сосудистого русла, совмещенный со считывателем контактной смарт-карты (PalmSecure);

Характеристики сканера:

Способ сканирования — Бесконтактный

Время аутентификации — менее 1 с

Коэффициент ложного отказа — 0.01%.

Вероятность допуска «чужого» — 0.00008%

Объем эталонного образца — 860 байт/3,5 КБайт

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

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

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

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

1. Ввод в действие и первоначальная настройка системы — существенно не отличаются, меняется просто процесс регистрации пользователей (на не более и не менее сложный).
2. Мониторинг и аудит — может существенно выиграть, если совместить СЗИ НСД со СКУДом: в этом случае существенно меньшая нагрузка будет на видеонаблюдение. С точки зрения протоколирования событий все останется так же.
3. НШС разных типов — количество НШС снизится за счет случаев блокировки.
4. Ввод в систему нового пользователя — так же, как и в первом пункте, незначительное изменение процедуры, не влияющее на трудозатраты ни положительно, ни отрицательно. Не требует посещения управляющим персоналом рабочего места пользователя.
5. Изменение прав существующему пользователю — в описанной схеме не требует посещения управляющим персоналом рабочего места пользователя.
6. Существенные изменения системы или требований к ней. Изменения системы могут быть совершенно различными, в том числе и вовсе не связанными с процессами идентификации/аутентификации. Поэтому одним словом определить, каким образом, и повлияет ли вообще внедрение биометрических технологий на трудоемкость изменения системы — невозможно. Важно, однако, что сам процесс ввода в систему этой технологии — в описанной схеме — не травматичен для системы и не требует ее перепроектирования, что, конечно, могло бы свести на нет все плюсы.

Какие еще возможности?

Перспективы, которые открывает применение описанной схемы, в первую очередь связаны с возможностью интеграции СЗИ НСД со СКУД[3]. Если эталон сосудистого русла будет записываться в карту СКУД, которая должна быть, в свою очередь, поддержана в СЗИ НСД в качестве идентификатора пользователя, то возможно логичное и целесообразное развитие системы безопасности, которое способно существенно повысить эффективность как СКУД, так и СЗИ НСД.

---

[1] Логику работы комплексов, обеспечивающих защищенную загрузку ОС терминальных станций по сети, кратко обозначим на примере ПАК «Центр-Т», применяемого, например, с СТД одного из российских финансовых регуляторов. Комплекс состоит из трех функциональных компонентов: АРМ конструирования образов ОС (АРМ «Центр») — на нем администратор создает образы (на базе ОС Linux) и устанавливает на них Коды Аутентификации (КА) для подтверждения их подлинности; Сервер хранения и сетевой загрузки — с которого терминальные станции получают образы для работы; персональные клиентские устройства ШИПКА-К, которые служат пользователям клиентских рабочих мест персональными идентификаторами, устройствами начальной загрузки терминала и инструментами проверки (КА) под полученным образом. Для понимания материала статьи этого описания достаточно, а подробнее о комплексе можно узнать на сайте производителя — /support/compatible/center-t/.

[2] ПАК СЗИ НСД «Аккорд TSE» — это обобщающее наименование для терминальных версий (Terminal Server Edition) комплексов «Аккорд-Win32» и «Аккорд-Win64». Они состоят из аппаратных и программных компонентов, устанавливаемых на терминальный сервер и программных агентов, устанавливаемых в ОС терминальных клиентов. Последние осуществляют защищенное взаимодействие по виртуальному каналу, создаваемому комплексом в рамкам терминальных протоколов ICA или RDP, между аппаратным идентификатором пользователя на терминальном клиенте и СЗИ НСД на терминальном сервере. Подробнее о комплексе — не в рамках данной статьи, например, на сайте производителя .

[3] Счастный Д. Ю., Конявская С. В.
Интегрированная система контроля доступа и защиты информации на основе
биометрической аутентификации сотрудников // Первая миля. М., 2013. N 2. С. 90 97.

Авторы: Конявская С. В.; Счастный Д. Ю.; Лыдин С. С.

Дата публикации: 01.01.2013

Библиографическая ссылка: Конявская С. В., Счастный Д. Ю., Лыдин С. С. Биометрия и защита информации: человеческий признак vs человеческий фактор // Защита информации. Inside. СПб., 2013. № 6. С. 52–57.

---