Технический отдел
+7 (343) 350-76-88
+7 (343) 355-19-21
Отдел физической охраны
+7 (343) 355-02-42
Торговый дом
+7 (343) 350-60-42
+7 (343) 355-47-20

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

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

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

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

Анализ тенденций развития всех перечисленных выше систем показывает, что их развитие происходит в двух основных направлениях: 

  1. расширение и совершенствование собственных возможностей;
  2. интеграция с другими смежными системами безопасности. 

Так, например, в системах видеонаблюдения постоянно повышается качество передаваемой «картинки», а в СКЗИ создаются и внедряются более совершенные алгоритмы. С другой стороны происходит объединение систем видеонаблюдения и СКУД, а криптографии с СЗИ НСД. 

Но пока что интеграция наблюдается только «смежных» систем безопасности, таких как уже упомянутые выше СКУД и видеонаблюдение или криптография и СЗИ НСД. Примеры интеграции ТСБ (технических средств безопасности) и СЗИ практически отсутствуют. Хотя периодически встречаются случаи их механического объединения: например, СЗИ НСД иногда применяют в СКУД, а при передаче данных, поступающих с видеокамер, нередко используются VPN-решения (то есть технологии, позволяющие обеспечивать несколько сетевых соединений). 

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

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

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

  • СКУД работает с физическими сущностями (шлюзовые кабины, турникеты, двери);
  • СЗИ НСД — с программами, файлами, каталогами, томами, записями и полями записей. 

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

Рассмотрим основные моменты функционирования двух упомянутых выше типовых систем и выделим те общие черты, которые присущи им обеим. 

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

Пользователям предоставляется доступ лишь, например, после предъявления аппаратного идентификатора:  

  • RFID-карты,
  • смарт-карты,
  • контактного ключа (ТМ-идентификатора, типа «Touch Memory»),
  • USB-ключа (токена).  

Одновременно при этом часто требуется и подтверждение легальности обладания этим идентификатором путем введения либо пароля, либо PIN-кода или другим способом. 

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

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

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

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

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

  1. идентификаторов;
  2. объектов доступа;
  3. баз данных;
  4. технологий взаимодействия.  

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

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

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

Например, доступ к ЭВМ будет разрешаться только, если работник прошел в помещение, где она находится. С другой стороны, выход из помещения будет разрешен контроллером СКУД только в случае, если пользователем заблокирован доступ компьютеру, то есть работник или выключил компьютер, или включил скринсейвер. 

Объединять базы данных можно двумя способами: 

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

Объединением баз данных можно обеспечить централизованное и единообразное управление параметрами доступа каждой системы. 

Объединение технологий взаимодействия может производиться: 

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

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

Такое объединение позволит своевременно реагировать на сигналы безопасности смежной системы и предотвращать возможный несанкционированный доступ. 

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


Типовая сетевая система СКУД (рис. 1):

контроллеры СКУД, установленные в местах входа, взаимодействуя со считывателями, управляют замками, принимая решение в случае предъявления идентификатора на их открытие в соответствии со своей базой данных и правилами разрешения доступа. 

Управление всеми контроллерами производится по командам удаленного сервера СКУД, выполняющего следующие функции:  

  1. сбор данных о событиях, происходящих на подконтрольных контроллерах СКУД;
  2. ведение архива всех происходящих событий;
  3. учет всей информации о пользователях и правилах разграничения доступа;
  4. ведение базы данных идентификаторов;
  5. непосредственное управление контроллерами СКУД.


     

 

Типовая сетевая система СЗИ НСД описана ниже (рис. 2).

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

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

  1. сбор данных о событиях на подконтрольных объектах;
  2. ведение архива происходящих событий;
  3. учет информации о пользователях и правилах разграничения доступа;
  4. ведение базы идентификаторов;
  5. собственно управление всей системой СЗИ НСД. 

Интеграцию систем можно осуществлять различными способами по всем описанным выше четырем путям. 

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

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

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

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

В случае если в СКУД применяются радиокарты, в то время как в СЗИ НСД используются ТМ-идентификаторы, ясно, что заменить одно на другое не получится. Проведение интеграции на уровне идентификаторов выльется в организацию поддержки радиокарт системой, ее не имеющей. 

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

Кстати, дополнить биометрической аутентификацией можно и СКУД, а не только СЗИ, чтобы пользователь, желая войти в помещение, мог предъявлять и руку. Это позволило бы исключить возможность передачи карт «по дружбе», чтобы кто-то, используя карту коллеги, не мог выйти из комнаты «на минутку», не блокируя свое рабочее место. 

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

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

 

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

При всей схожести рассматриваемых систем они все-таки значительно отличаются в деталях. Прежде всего, протоколами взаимодействия серверов с конечным оборудованием. Так, например, стандартом взаимодействия сервера СКУД с контроллерами является протокол RS-485 (EIA-485), а компоненты системы СЗИ НСД, как правило, связаны через локальную вычислительную сеть на Ethernet. К тому же протоколы взаимодействия часто бывают проприетарными и закрытыми, да и регулирующие органы также нередко предъявляют к ним различные требования. 

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

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

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

Взаимодействие серверов (рассматриваются именно сетевые системы) может осуществлять в трех вариантах:  

  1. с подчиненным взаимодействием серверов;
  2. с равноправным взаимодействием серверов; (рис. 4)

  3. с взаимодействие серверов, использующим третий (дополнительный) управляющий сервер. (рис.5)

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

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

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

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

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

  1. Он прикладывает руку и радиокарту на КПП, желая попасть на территорию предприятия.
  2. На мониторе компьютера охранника появляется фото сотрудника, владельца данной карты, и результат верификации сосудистого русла предъявленной ладони с эталоном, находящимся на карте.
  3. Охранник сравнивает фото на мониторе с лицом сотрудника, одновременно оценивая результат верификации сосудистого русла.
  4. Сотрудник проходит на предприятие.
  5. Информация о том, что данный сотрудник прошел через проходную, передается в управляющий модуль контроля доступа интегрированной системы для учета ее при попытке этого сотрудника пройти в какое-нибудь помещение предприятия.
  6. Возможно (при необходимости) установление правил, регламентирующих время, необходимое на то чтобы после прохода на территорию предприятия достичь места входа в конкретное помещение, и предписывающих действия охраны в случае нарушения продолжительности этого времени.
  7. В случае, если работник входит в помещение, то также осуществляется как его идентификация по карте, так и аутентификация с помощью биометрической верификации, и далее система контроля доступа начинает ждать включения компьютера на рабочем месте сотрудника.
  8. Непосредственно на рабочем месте также может запрашиваться карта и рука для осуществления контрольных процедур, на основании которых будет загружаться профиль данного пользователя.
  9. Кроме того работа может быть разрешена на конкретном рабочем месте только при условии присутствия карты в считывателе.
  10. В случае если карта изымается из считывателя пользователем, желающим выйти из помещения, его рабочее место блокируется, а разблокировка возможна только при повторном предъявлении карты и руки.  

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

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

Развитие первоначально выбранного интегрированного решения может осуществляться в двух упомянутых ранее направлениях: 

  1. совершенствование созданного решения и расширение его возможностей;
  2. интеграция с другими смежными системами безопасности. 

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

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