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

Д. Ю. Счастный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1 Типовая схема сетевой СКУД

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

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

Рис. 2. Типовая схема сетевой СЗИ НСД

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

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

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

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

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

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

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

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

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

Рис. 3. 1-й вариант интеграции СКУД и СЗИ НСД: единая система с общей базой данных

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

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

Рис. 4. 2-й вариант интеграции СКУД и СЗИ НСД: взаимодействие управляющих серверов (здесь — равноправное)

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

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

Рис. 5. 3-й вариант интеграции СКУД и СЗИ НСД: третий управляющий сервер (сервер интеграции и управления) с собственной базой данных (соподчинение)

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

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


ФорумФорум
Форум ОКБ САПР
Вопросы специалистовВопросы специалистов
Вопросы, которые нам присылают, и наши ответы на них
ЛичноеЛичное
Защита частной жизни