В рубрику "Комплексные системы безопасности" | К списку рубрик | К списку авторов | К списку публикаций
Часть 2
A.M. Омельянчук
Технический директор ЗАО "Компания Безопасность"
В первой части этой статьи были описаны причины, по которым было необходимо разработать стандарт на интерфейс взаимодействия подсистем в составе интегрированной технической системы безопасности (ИТСБ). Кроме того, был определен интерфейс, который предпочтительно стандартизовать, и введены понятия "техническая подсистема" (ТПС) и "управляющая подсистема" (УПС).
Напомним, что в существующих реализациях интегрированных систем безопасности УПС, как правило, входит в состав одной из подсистем (обычно это системы контроля доступа - СКУД) или в состав системы управления доступом и охранной сигнализации (СУДОС) и неравномерно интегрирована с аппаратурой - наиболее тесно с "родной" подсистемой и в минимальном объеме с подсистемами сторонних производителей.
Именно интерфейс между ТПС и УПС и предполагается стандартизовать (с целью обеспечения достаточно высокого уровня интеграции УПС), а также с подсистемами сторонних - по отношению к УПС - производителей.
Требования к предполагаемому стандарту
Стандарт должен описывать:
Взаимодействие ТПС и УПС в составе ИТСБ
Соответствующий раздел должен описывать используемые протоколы связи и форматы данных, передаваемых в реальном времени между УПС и ТПС.
Здесь же необходимо описать варианты состава ТПС, исполнения и особенности связи с ТПС в каждом случае.
К этому же разделу относятся способы представления информации о составе данного экземпляра ТПС, адресах связи с отдельными составными частями ТПС. Должны быть доступны информация о настройке и текущих параметрах всех элементов ТПС и конкретные параметры связи с нею.
Типовые (базовые) возможности ТПС
В самом стандарте, а также в качестве дополнений к нему должны иметься описания базовых понятий, заведомо известных разработчикам всех УПС и ТПС. Именно за счет наличия таких понятий все УПС смогут работать с любой ТПС почти без настройки.
Такие описания предлагается называть профилями: базовый профиль, описанный в составе самого стандарта и включающий в себя самые основные понятия, и тематические профили -отдельные для каждого вида подсистем (например, системы контроля доступа, охранной сигнализации, телевидения и др.).
Что же касается дополнительных понятий (возможностей), введенных в ТПС сверх описанных ранее в профилях, их эффективное использование возможно только при условии ручной настройки конкретной системы администратором, так как семантика данных возможностей может быть описана лишь человеческими понятиями и не может быть легко подвергнута автоматическому анализу.
Описание возможностей ТПС
Каждая конкретная ТПС должна иметь и предоставлять для УПС (как минимум на этапе настройки) информацию, описывающую ТПС, общую для всех подсистем данного типа (описание типа ТПС).
Следует отметить, что общая (типовая) информация может быть предоставлена производителем ТПС разработчику УПС заблаговременно и использована для ручной оптимизации взаимодействия конкретной УПС с ТПС данного типа. Однако для универсальной УПС неприемлемо, если она (без такой оптимизации непосредственно разработчиком УПС) не сможет реализовать базовой достаточной функциональности взаимодействия с ТПС. То есть "хорошая" универсальная УПС, соответствующая предполагаемому стандарту, обязана уметь сама настраиваться на новые ТПС после развертывания, совершенно без участия разработчика УПС и с минимальным участием администратора (наладчика) ИТСБ.
Способ подключения новых ТПС и УПС
Стандарт должен описывать предполагаемую процедуру, последовательность действий при развертывании и подключении новых ТПС или УПС.
Кстати, именно на этом этапе наиболее сложно решаются проблемы защиты информации. Кроме того, функции типа "plug-n-play", конечно, удобны для инсталлятора, но довольно трудоемки в реализации, а потому на первом этапе не представляются злободневными.
Тем не менее процедура подключения ТПС к УПС (вручную или автоматически) должна пройти успешно под управлением инженера-установщика должной квалификации, причем требуемая квалификация не должна быть слишком высокой. Например, вполне достаточно квалификации системного администратора или старшего технического специалиста в службе безопасности целевого объекта. При этом необходимо четко описать, какая информация и в каком виде должна присутствовать в ТПС.
Функциональные требования к разделу стандарта "Описание ТПС"
В данном разделе дается подробное описание требований, используемых при разработке проекта стандарта. Наиболее сложными вопросами оказались способы описания ТПС, которые бы не ограничивали общность и возможность дальнейшего развития и притом не требовали бы чрезмерной работы от разработчиков как ТПС, так и УПС.
С учетом того, что разработчики ТПС (занимающиеся периферийной аппаратурой), как правило, обладают меньшими возможностями по созданию программного обеспечения, а также того, что предположительно различных ТПС будет использоваться намного больше, чем УПС, особое внимание было уделено снижению требований к сложности ТПС.
Описание типа подсистемы
Описание типа ТПС - фактически "математическая модель ТПС", или, иначе говоря, модель предметной области.
Наиболее общим способом описания модели предметной области является, пожалуй, язык UML. Однако отчасти вследствие своей общности, отчасти из-за ориентации на графическое представление для людей он не слишком удобен для создания описания ТПС, которое должно по возможности автоматически восприниматься УПС - программно-аппаратным комплексом, без участия человека.
Ниже мы расскажем об основных понятиях, которые необходимо описать в модели предметной области (типа ТПС). Наиболее полно эти понятия реализованы в терминологии, принятой в объектно-ориентированном проектировании и стандартизованной OMG в виде языка UML.
Необходимо упомянуть, что в той или иной мере средствами формального построения модели предметной области являются все формализованные языки - начиная от классических языков программирования (таких, как C или Java) и включая различные языки описания моделей или языки метаданных (такие, как CIM или IDL).
Описание типа ТПС, то есть описание общих характеристик всех экземпляров подсистем данного типа, включает в себя:
1.Выделение типов сущностей (например, "считыватель", "контроллер", "датчик"), которые можно рассматривать внутри ТПС, при этом для каждой сущности следует определить:
2.Взаимосвязи между типами сущностей, например, датчик Протва является частным случаем охранного датчика.
3.Взаимосвязи между экземплярами сущностей; например, "считыватель номер 17" ведет в "область номер 3".
В терминах UML это означает, что в общем случае в состав существенных метаданных, описывающих ТПС, включены классы, их параметры, методы и события, а также опционально ассоциации между классами и категоризация классов, параметров классов, их методов и событий определенными ранее стереотипами.
К числу сущностей, выделяемых внутри ТПС, как правило, относятся элементы аппаратуры ТПС, подлежащие настройке или контролю: контроллеры, датчики; порты или линии связи -иногда. Для простой ТПС на этом список сущностей может закончиться.
Кроме того, к числу выделяемых в ТПС сущностей могут относиться логические понятия, такие как "точка прохода" и "шлюз". В некоторых ТПС они могут являться физическими, а в некоторых могут не иметь прямого соответствия "один в один" с конкретной аппаратурой. Например, понятие "точка прохода" может объединять в себе физически различные считыватель и датчик открывания двери, в том числе подключенные к разным контроллерам. Либо наоборот, один физический контроллер может реализовывать несколько логических точек прохода.
Наконец, к числу сущностей могут относиться и понятия, вовсе не имеющие прямых аналогов в аппаратуре. Например, в СКУД это временной график (временная зона), уровень доступа, маршрут (область доступа), а в системе видеонаблюдения это может быть "область детектирования движения", видеопоток (видеоролик), схема трансляции (компрессии) видеопотока. В терминологии UML сущности называются классами.
Параметры - это характеристики сущностей, набор которых одинаков у всех экземпляров сущностей одного типа, однако у разных экземпляров значения могут отличаться и меняться в течение всего времени их существования.
Для параметров, особенно оперативного управления, желательно иметь возможность получать извещения об их изменении, инициированном иными операторами.
Для некоторых параметров конфигурационной настройки (изменяемых редко, как правило, только при первоначальной настройке системы) желательно иметь возможность:
1)настраивать их off-line (до включения аппаратуры ТПС или установления связи с ней);
2)одной командой синхронизировать (загрузить) настроенные параметры класса в экземпляр класса;
3)независимо получать значения "параметров из базы данных" и "фактических текущих значений параметров" для экземпляра класса.
Стереотипы - метод разметки определенных в описании ТПС понятий по категориям. Например, классы могут быть помечены признаком "датчик охранный", независимо от вида и изготовителя, а в целях описания использования сущностей в АРМ "оперативное управление" классы могут помечаться стереотипами: "отображаемый на плане", "самостоятельно отображаемый в дереве сущностей".
Типичным пользовательским требованием является дополнительное категорирование (группирование) экземпляров и типов системы на месте понятиями, специфическими для конкретного экземпляра развертывания системы. Такое категорирование может (и должно) осуществляться средствами УПС, а потому в рамках предполагаемого стандарта не рассматривается.
Важнейшим способом применения стереотипов является разработка специализированных профилей (наборов стереотипов), описывающих специфику конкретного вида подсистем, или оборудования, описывающего понятия, типичные для некоторого класса подсистем. Например, профиль СКУД должен описывать ключевые для СКУД понятия (выбираем на основе ГОСТ 51241-98): идентификатор, считыватель, точка прохода, санкционированный/несанкционированный доступ.
Специализированные профили не должны быть частью основного стандарта, хотя тоже должны устанавливаться управляемым образом, как приложения к стандарту. Они будут добавляться по мере появления новых широко признанных типовых понятий, применимых ко многим реализациям подсистем. Так, например, по мере расширения области применения биометрических систем к профилю СКУД может быть добавлен еще более специализированный биометрический профиль, определяющий такие понятия, как "биометрический идентификационный признак", понятия "идентификация", "верификация", "вероятность совпадения" и т.п.
Такие профили должны являться файлами, заранее доступными всем разработчикам, но тем не менее пригодными и для автоматизированного подключения к любой УПС, даже если на момент ее разработки данного профиля не существовало (или он не был доступен разработчикам УПС).
То есть специализированные профили, по сути, являются частью описания ТПС, доступного разработчикам УПС и рекомендованного для использования всеми разработчиками сходных ТПС.
Аналогично базовые стереотипы, важные для первоначальной функциональности стандарта, можно выделить в набор под названием "базовый профиль". Второе название того же набора стереотипов - "профиль интеграции", так как основные входящие в него понятия не относятся к какому бы то ни было виду или типу оборудования, а устанавливают именно понятия, существенные для успешной интеграции. Например, понятие "подсистема", "точка доступа к ТПС", "сущность", "реестр сущностей" и т.д.
Сводный список требований к описанию типа ТПС
Описание типов сущностей (классов), входящих в ТПС, включает в себя в том числе следующие характеристики: параметры; методы; события; категоризация типа класса.
Описание параметров классов и параметров методов классов должно дополнительно предоставлять:
Возможные значения параметров, в случае перечислимого множества, также могут быть категоризованы.
Описание событий должно позволять указывать их категоризацию, которая в любом случае должна строиться в иерархическую систему, восходящую к определенным ранее (в описании специализированного профиля) понятиям. При этом отнесение сообщения, параметра, класса к некоей категории должно означать возможность использования этого параметра, сообщения, класса в качестве вышестоящей категории (совместимость сверху вниз). В связи с этим категорирование предполагается производить исключительно на этапе разработки ТПС.
Вся информация о возможных типах и их категоризации должна быть доступна off-line (на этапе конфигурирования системы на месте до ее запуска), но может быть недоступна на этапе разработки программного обеспечения (ПО).
Информация о специальных профилях предположительно может быть (но не обязательно) доступна на этапе разработки ПО.
Опционально следует предусмотреть возможность указания рекомендаций по оптимальному отображению событий в пользовательском интерфейсе (с параметрами) и объектов (с параметрами), а также отображению и настройке параметров методов.
Описание экземпляра подсистемы
Информация об экземпляре ТПС предоставляется уже на месте, в зависимости от фактической комплектации и настройки ТПС на объекте. Изменения от экземпляра к экземпляру заведомо не должны требовать вмешательства разработчика УПС (доработок собственно программного обеспечения). Адаптация к экземпляру ТПС должна осуществляться на месте простыми настройками УПС, доступными сотрудникам эксплуатирующей или иной организации, на основании открытых данных.
Для конкретного экземпляра ТПС должна предоставляться информация о составе данного экземпляра ТПС (список экземпляров сущностей с указанием их типов и их идентификаторов), о настройке и текущих параметрах всех элементов ТПС, об адресах и параметрах связи с ТПС в целом.
Функциональные требования к разделу стандарта "Процесс взаимодействия"
В данном разделе необходимо описать не только собственно процесс обмена сообщениями (например, PPP, modbus или http-протоколы), но и процедуры инсталляции, модернизации, восстановления после сбоев.
В частности, в процессе инсталляции и первичной конфигурации ТПС и УПС, они обмениваются основной информацией, необходимой для связи.
Защита информации
Уровень интерфейса УПС-ТПС характеризуется малым количеством клиентов у сервера ТПС и редким установлением/переустановлением связи. Список возможных контрагентов сервера ТПС меняется крайне редко (только при существенном изменении центральной УПС ИТСБ). Таким образом, достаточной является реализация простых механизмов защиты информации, а именно:
В рамках разграничения доступа к информации ТПС может осуществлять лишь следующие простые функции:
В качестве расширенных функций ТПС может предоставить возможность для каждого контрагента перечислить явно доступные:
Механизм дистанционного распределения ключей и настройки списка авторизации может быть определен в дальнейших дополнениях к стандарту.
До такого определения ТПС следует гарантировать невозможность изменения настроек авторизации без физического доступа к оборудованию ТПС. В противном случае необходимо организационно-техническими мерами обеспечить защиту канала связи УПС-ТПС. Такими мерами могут являться физически отдельный аппаратный брандмауэр/шлюз VPN либо иным образом физически локализованная и защищенная от физического доступа подсеть связи.
Нефункциональные требования
К числу существенных нефункциональных требований отнесем:
Эффективность
Производительность интерфейса связи должна быть достаточной для работы в самом худшем случае. К счастью, самый худший предполагаемый случай для существующих систем ИТСБ -не более 100 событий/с.
Требования исходят из одного из предполагаемых силовых сценариев вторжения (см. рисунок).
Противник осуществляет постановку помех, в результате чего, например, все датчики первой линии периметра дают ложную тревогу. На фоне этих сигналов надо заметить единственный сработавший по делу датчик второй линии (мы надеемся, что датчики устроены по разным физическим принципам и не будут одновременно выведены из строя). При наличии 1000 датчиков (реальные объекты имеют на порядок меньше) и постоянной времени датчика 1 с (реальные датчики имеют на порядок больше) получаем 1000 событий/с (для реальных объектов - 10 событий/с).
Второй типичный сценарий - события прохода на предприятии, в котором 10 000 человек проходят на смену за полчаса. Пиковая скорость прохода - 1000 чел/мин (16 событий/с).
Много или мало - 100 событий/с? Много, если связь по каналу 9600 бод. А если используется уровень межкомпьютерной связи, 100 Мбит или 1 Гбит Ethernet, то 100 событий в секунду -это мелочи, это значит, что допускается до 30 кбайт на сообщение при 100 Мбит.
Кроме того, 100 событий/с - это много, если используется микропроцессор 8 бит 2 МГц. А если Пентиум4 на 3 ГГц, то обработка одного сообщения может содержать миллионы операций.
Простота реализации
На первом этапе внедрения стандарта разработчики ТПС будут мало в нем заинтересованы. Они любят лишь те стандарты, которые уже широко признаны и которые позволяют легко расширять рынки сбыта.
Поэтому, чтобы этап первичного внедрения прошел легко, нужно, чтобы разработчикам было легко реализовать требования стандарта. Нужны инструментальные средства (готовые библиотеки алгоритмов), литература, учебные курсы, доступные готовые специалисты. Стандарт не должен требовать существенной переквалификации от действующих сейчас разработчиков.
Переносимость
Наиболее интересным вопросом в переносимости является использование БЗКТ (базовых защищенных компьютерных технологий), то есть фактически систем на базе Linux.
Кроме того, могут возникнуть задачи реализации стандарта на встроенных контроллерах, в том числе безоперационных систем вообще. Для такой реализации существенно наличие библиотек с открытым кодом на универсальных языках типа ANCI-C.
Масштабируемость
Еще одно требование к эффективности реализации - возможность масштабирования на длинные дистанции. В частности, на связи разнесенных на километры многих зданий, на связи разбросанных по странам и континентам филиалов с центральным офисом в Москве. Фактически сейчас известна одна технология, пригодная для такого масштабирования, - Интернет.
Таким образом, можно сделать вывод, что современные технологии компьютерных сетей (локальных и глобальных) - это правильный выбор для стандарта.
Поскольку мы говорим об интеграции подсистем в целом, то требование наличия в ТПС одного мощного устройства класса персонального компьютера - вполне приемлемо.
Это не означает, что каждая ТПС должна иметь в своем составе компьютер. Хотя почти всегда так и есть. Просто для каждой ТПС должен быть разработан "драйвер ТПС", после чего, вероятно, на одном компьютере будут размещены несколько драйверов разных ТПС. Впрочем, стоимость одного компьютера - самое меньшее из зол в цене системы.
Опубликовано: Журнал "Системы безопасности" #1, 2006
Посещений: 11169
Автор
| |||
В рубрику "Комплексные системы безопасности" | К списку рубрик | К списку авторов | К списку публикаций
