Контакты
Подписка
МЕНЮ
Контакты
Подписка

СКУД и системы защиты информации: перспективы нового качества

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

СКУД и системы защиты информации: перспективы нового качества

Постулат о том, что защита информации должна быть комплексной, уже давно ни у кого не вызывает сомнений. Путь к этому пониманию был долгим и сложным
Дмитрий Счастный
Заместитель генерального директора
ЗАО "ОКБ САПР"

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

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

Интеграция систем защиты информации и СКУД

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

Следующим шагом развития интеграции видится интеграция с СЗИ от несанкционированного доступа (НСД).

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

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

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

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

Действительно, логично строить комплексную систему защиты таким образом, чтобы запустить компьютер мог только тот пользователь, который:

  • а) зарегистрирован в СКУД;
  • б) имеет право входа в помещение, где установлен запускаемый АРМ;
  • в) уже вошел в помещение.

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

Типовые СКУД и СЗИ НСД

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

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

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

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

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

Первая предполагает расширение функциональности существующих систем в двух направлениях:

  1. СКУД должна "понимать", доступ к каким компьютерам контролируется каждым конкретным контроллером СКУД;
  2. СЗИ НСД должна "понимать", через какие контроллеры СКУД должен пройти пользователь, чтобы попасть туда, где установлен его компьютер.

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

Варианты структурной интеграции

Структурная интеграция возможна в нескольких направлениях:

  1. Объединение функций серверов СКУД и СЗИ НСД в одном.
  2. Взаимодействие серверов между собой (равноправное или подчиненное).
  3. Взаимодействие серверов с третьим управляющим сервером (соподчинение).

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

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


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


Кроме того, понятия и атрибуты, которыми оперирует каждая из систем, настолько различны, что процесс изучения разработчиком смежной предметной области может растянуться на значительное время. Еще одним из недостатков этого решения является уникальность разработки - интеграция с другой аналогичной системой будет новой работой практически без возможности использования наработок. Уникальность разработки затруднит и дальнейшее развитие системы: развитие и обновление каждого из продуктов будут требовать внесения изменений и в объединенный вариант. Но зато в случае правильной реализации степень интеграции будет максимальной, что позволит единообразно управлять обеими системами и более тонко осуществлять взаимодействие систем.


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

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

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

Опубликовано: Каталог "СКУД. Антитерроризм"-2013
Посещений: 11068

  Автор

Дмитрий Счастный

Дмитрий Счастный

Заместитель генерального директора
ЗАО "ОКБ САПР"

Всего статей:  1

В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций