Идентификация и доступ

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

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

СКУД контролирует физический доступ пользователей в помещения к материальным ресурсам, СЗИ НСД контролирует доступ к информационным ресурсам: дискам, каталогам, файлам. Инструментом контроля является некий обобщенный замок: контроллер СКУД, установленный на дверях, или турникет, или шлюзовая кабина в СКУД или аппаратный модуль доверенной загрузки, установленный в ПЭВМ — тоже замок, но электронный. Пользователи получают доступ к необходимым ресурсам после успешной процедуры идентификации/аутентификации, предъявив аппаратный идентификатор — RFID-карту, смарт-карту, контактный ключ (Touch Memory, ТМ-идентификатор), токен — и подтвердив легальность обладания этим идентификатором, обычно паролем, PIN-кодом, но, возможно, и другими методами аутентификации.

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

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

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

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

В качестве примера рассмотрим вариант интеграции сетевых СКУД и СЗИ НСД.

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

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

Типовая сетевая СЗИ НСД выглядит так: на подконтрольных компьютерах установлен АМДЗ (например, Аккорд-АМДЗ), который на основании предъявленных идентификатора и аутентифицирующих данных и в соответствии с правилами, описанными в собственной базе данных, принимает решение о старте компьютера. Далее в ОС запускается программная часть СЗИ НСД (наример, Аккорд-Win32 или Аккорд-Win64), которая осуществляет разграничение доступа пользователя к информационным ресурсам. Программная часть СЗИ НСД осуществляет и взаимодействие с сервером управления, который выполняет следующие функции:

• сбор событий с подконтрольных объектов;
• ведение архива произошедших событий;
• ведение базы данных пользователей, идентификаторов, правил разграничения доступа к информационным ресурсам;
• собственно управление СЗИ НСД на подконтрольных объектах.

Интеграция систем возможна по всем четырем путям, описанным выше.

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

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

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

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

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

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

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

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

4. Интеграция технологий взаимодействия в данном случае — это взаимодействие серверов (так как мы рассматриваем вариант взаимодействия сетевых систем). Оно может производиться тремя способами.

• подчиненное взаимодействие серверов;
• равноправное взаимодействие серверов;
• взаимодействие серверов с третьим управляющим сервером (соподчинение).

Каждый вариант имеет свои преимущества и недостатки.

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

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

Рис. 1. Соподчиненное взаимодействие серверов СКУД и СЗИ НСД

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

Приведем пример сценария развития событий при попытке сотрудника приступить к работе в начале дня в такой системе на базе ПАК СЗИ НСД «Аккорд» с интегрированным биометрическим считывателем (сканером сосудистого русла PalmSecure):

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

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

У ОКБ САПР есть опыт построения такой системы. Мы готовы им делиться.

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

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

Библиографическая ссылка: Счастный Д. Ю., Конявская С. В. Идентификация и доступ // Information Security/Информационная безопасность. М., 2013. № 5. С. 12–13.

---