Интегрированные СБ

Интегрированные системы безопасности — это совокупность технических средств охраны и обеспечения безопасности объекта, объединенных на основе единого программного комплекса в общую информационную среду с единой базой данных.(см. схему — рис. №1 — пример интегрированной системы безопасности, построенной на ПАК Рубеж-08)

Глобальная система управления

НАЗНАЧЕНИЕ

Создание глобальной системы управления и защиты крупных предприятий, объектов транспортной инфраструктуры и стратегически важных объектов — задача, требующая решения на уровне государства. Достичь этого можно только пересмотром всей традиционной политики управления, базирующейся на использовании «живой силы» и переходом на новую концепцию. Новая концепция реализована в глобальных распределенных интеллектуальных системах управления — «ИНТЕЛЛЕКТ» компании ITV и SecurOS производств
а компании ISS . Системы, интеграцию которых производит РОССБ, представляют собой единую информационно-управляющую структуру, объединяющую сотни объектов. В основе системы — интеграция.

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

Рис. №1 — Пример интегрированной системы безопасности, построенной на программно-аппаратном комплексе (ПАК) Рубеж-08

Рис. №1 — Пример интегрированной системы безопасности, построенной на программно-аппаратном комплексе (ПАК) Рубеж-08

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

Интегрированная интеллектуальная система безопасности и управления объектом, как правило, включает:

  • Систему цифрового видеонаблюдения;
  • Систему контроля и управления доступом;
  • Охранно-пожарную сигнализацию;
  • Подсистемы безопасности и управления производственными процессами;
  • Системы жизнеобеспечения.
Рис №2. Наблюдение за важными участками через интегрированную систему безопасности

Рис №2. Наблюдение за важными участками через интегрированную систему безопасности

Зачем нужна интегрированная система безопасности?
Объединение различных систем в рамках единой ИСБ позволяет решать вопросы комплексного обеспечения безопасности объекта максимально эффективно и на самом современном уровне.

Централизованное управление (на примере ИСБ 777)

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

Рис №3. Пример работы интегрированной системы безопасности ИСБ 777

Рис №3. Пример работы интегрированной системы безопасности ИСБ 777

Пример (см. Рис. №3 — ИСБ 777): Сработала система охранной сигнализации. На управляющем мониторе выводится план объекта с указанием конкретного охранного датчика, который выдал сигнал. Оператор (на том же мониторе) выводит изображение от ближайшей камеры теленаблюдения и визуально контролирует ситуацию. В случае ложного срабатывания тревога отменяется. Получаем адекватную реакцию на конкретную тревожную ситуацию. Необходимо будет провести диагностику датчика и, в случае его неисправности, заменить.

Тесное взаимодействие между подсистемами(см. рис. №3)
Программирование логических связей между подсистемами позволяет существенно повысить эффективность работы и надежность интегрированной системы. В современной интегрированной системе безопасности можно запрограммировать логику работы системы с учетом сложных комбинаций сигналов от различных подсистем. За счет этого можно добиться существенного сокращения времени реакции на события – предоставив право решения в конкретных случаях электронике, а также – снижения влияния «человеческого фактора» за счет автоматизации действий и реакций.

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

Протоколирование событий

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

Рис №4. Пример интегрированной системы охраны «Орион»

Рис №4. Пример интегрированной системы охраны «Орион»

Экономическая эффективность

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

Масштабируемость

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

Надежность

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

Универсальность

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

Расширяемость

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

Открытость

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

Технологии.

Технологии модульного построения комплексов
Решение поставленных задач и удовлетворение постоянно возникающих новых требований к ПО возможно только в случае модульной организации программного комплекса. На сегодняшний день существует несколько конкурирующих технологий модульного построения ПО. Из наиболее распространенных на сегодняшний день можно привести Microsoft COM+ / .NET, J2EE (Java 2 Enterprise Edition) и CORBA. Все они позволяют создавать надежные, гибкие, расширяемые программные комплексы, однако у каждой из них есть своя специфика.

Microsoft COM+ / .NET

Несмотря на развитость сервисов платформы COM+ и, даже в большей степени, ее преемника – .NET, это семейство платформ Microsoft для создания распределенных объектных приложений доступно только на платформе Windows. Отсутствие процесса стандартизации как такового, тесная интеграция с операционной системой и, как следствие, закрытость этой платформы и отсутствие альтернативных реализаций, ограничивают применимость семейства платформ COM+ / .NET для создания прикладной инфраструктуры предприятия. С точки зрения ПК управления системой безопасности, данные технологии вполне можно применять, если, конечно, ставится задача построения комплекса исключительно для платформы Microsoft Windows. В этом случае упрощается задача поиска квалифицированных разработчиков, так как интерес к технологиям компании Microsoft традиционно высок. В качестве дополнительного плюса можно рассматривать, что данные технологии часто считаются бесплатными для пользователей, так как их стоимость скрыта в стоимости операционных систем компании Microsoft.

Java 2 Enterprise Edition (J2EE)

Платформа J2EE, развиваемая в рамках открытого процесса стандартизации JCP (Java Community Process), впервые предложила цельную компонентную модель — EJB (Enterprise JavaBeans), ориентированную на создание серверной бизнес-логики. Данная технология позволяет строить комплексы, функционирующие не только на платформе Microsoft Windows. Она использует парадигму сервера приложений, которая в настоящее время признана критически важной для развертывания компонентов бизнес-логики в распределенной среде. Однако данная технология также обладает рядом ограничений. Основное – это возможность использования только языка программирования Java. При построении ПК управления системой безопасности часто возникает необходимость решения не только информационных задач, но и задач оперативного управления оборудованием, передачей и отображением аудио и видео информации и пр. Данные задачи часто требуют тонкой оптимизации на уровне работы с оборудованием или с операционной системой, что не всегда удобно (хотя и возможно) делать в рамках данной технологии.
Что касается стоимости данной технологии для пользователей, то в ряде случаев она может быть достаточно ощутимой. Дело в том, что данная технология требует покупки лицензий на коммерческие J2EE-серверы приложений, стоимость которых может быть относительно высокой.

OMG CORBA

Технология CORBA, разрабатываемая с 1989 года консорциумом OMG (Object Management Group), является результатом работы ведущих специалистов из более чем 800 компаний и организаций. Четкий процесс стандартизации, включая аспекты взаимодействия реализаций CORBA от разных поставщиков (интероперабельность), независимость от языков программирования и операционных сред, фундаментальная поддержка ООП и многие другие уникальные характеристики, сделали CORBA ведущим стандартом в области инфраструктурного middleware.
Основой технологии CORBA являются:
IDL (Interface Definition Language) — язык, позволяющий описать все аспекты удаленного взаимодействия;
cхемы отображения IDL-объявлений на конкретные языки программирования;
ORB (Object Request Broker) — объектная магистраль, позволяющая передавать запросы от клиентов к серверам и обратно;
Сервисы (Common Object Services) CORBA;
GIOP — спецификация протокола (команды и форматы передаваемой информации)

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

Архитектура комплекса

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

Язык программирования

Технология CORBA позволяет вести разработку практически на любом языке программирования (C++, Java, Delphi и др.) и под любую аппаратно-программную платформу (Mi-crosoft Windows – Intel, Linux, Sun Microsystems Solaris – SPARC). Однако использование языка программирования Java позволяет получить дополнительное преимущество переносимости программного комплекса не только без его доработки, но даже и без его перекомпиляции.
Очень важным моментом является возможность использования других языков (например, C++) для некоторых модулей системы. Например, это может понадобиться для разработки модулей работы с цифровым потоковым видео или для реализации поддержки оборудования, драйвер которого поставляется только в виде COM-интерфейса.

Доступ к БД

В случае использования языка Java для разработки ПК разработчику доступна стандартная технология взаимодействия с различными серверами баз данных JDBC (Java DataBase Connectivity). Основными частями технологии JDBC являются JDBC API (набор классов и методов, к которым обращается прикладной программист) и JDBC-драйверы, которые транслируют эти вызовы в команды API конкретной СУБД. Используя данную технологию можно получить систему, независимую от используемого сервера БД и, соответственно, иметь возможность выбора сервера непосредственно для каждого заказчика в соответствии с особенностями объекта.

Хранение данных

Для хранения настроек объектов, конфигурации рабочих мест и прочей информации в БД можно применять стандартную реляционную модель, при которой данные объектов каждого типа сохраняются в отдельной таблице, содержащей набор колонок, соответствующих списку свойств этих объектов. Такой вариант хранения обеспечивает быстрые сохранение, поиск и выборку данных из БД, и удобен в информационных системах.
Системы безопасности же имеют свою специфику. С одной стороны, здесь нет острой необходимости в быстром поиске среди миллионов записей (количество обслуживаемых аппаратных объектов обычно все-таки существенно меньше). С другой стороны, при расширении системы может возникнуть необходимость в добавлении новых типов объектов, что часто приводит к перестройке структуры БД, что, в свою очередь, затрудняет процесс установки и поддержки системы. В качестве возможной альтернативы можно рассмотреть хранение настроек объектов системы в полях типа BLOB формате XML.
XML (eXtensible Markup Language) – стандарт структурного представления данных. Представляет из себя набор правил, которые позволяют определить структуру некоторого класса документов. Документ, созданный в соответствие с этими правилами, представляет собой текстовый файл, в котором присутствуют как собственно информация, так и теги ее разметки. Имея формально описанную структуру документа, можно проверить его корректность. Наличие тегов разметки позволяет анализировать документ как человеку, так и программе. XML-документы, в первую очередь, предназначены для программного анализа их содержимого.
При таком подходе можно свободно сохранять в существующей таблице любые XML документы без перестройки структуры БД, что позволяет проводить расширение системы в ‘горячем’ режиме без ее выключения.
Однако возникает необходимость в стандартном инструменте поиска среди документов (так как стандартные средства поиска среди реляционных данных работать не будут). Для поиска добнее всего использовать язык XPath, который предназначен для создания выражений для доступа на основании содержимого XML-документа, которые потом можно использовать в запросах к серверу БД. Некоторые серверы БД (например, Oracle Database) уже содержат встроенные средства поиска XML-документов по их содержимому. Другие же (например, Borland InterBase) обладают возможностью подключения к ним специальных модулей, реализующих данные функции.

Обмен данными с другими системами

На сегодняшний день для обмена данными с другими системами фактически все системы используют именно формат XML. При хранении конфигурации объектов в данном формате достаточно просто создать универсальную службу для обмена данными с внешними системами. Для этого достаточно экспортировать данные из БД в файлы на диск без их преобразования из реляционной формы в формат XML.
В ряде случаев может возникать необходимость преобразования данных перед их передачей другой системе. Это может быть как преобразование структуры XML документов, так и преобразование их в другой формат (например, текстовый с разделителями-табуляциями). Причем правила преобразования могут отличаться от одной внешней системы к другой. Данную задачу можно выполнить с помощью технологии XSL (eXtensible Style Language), которая представляет собой язык, позволяющий сформировать то или иное представление на базе XML-документа. Достаточно сформировать специальный документ, описывающий процесс преобразования исходного XML-документа в результирующий документ и воспользоваться существующими библиотеками преобразования.

Обмен сообщениями

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

Обеспечение безопасности

При построении системы безопасности на базе стандартных технологий необходимо особое внимание уделить безопасности самого комплекса. Для решения этой задачи создан специальный Сервис Безопасности (Security Service). Пожалуй, это один из самых важных сервисов CORBA. Он решает очень многие проблемы: идентификации пользователя, определения прав доступа к объектам, режимов делегирования полномочий при цепочке последовательных вызовов объектов друг другом, системы аудита, защиты информации при передаче, ведении достоверной истории взаимодействия объектов и многое другое. Это очень сложный сервис, спецификация его состоит почти из 300 страниц. Самое поразительное, что при всей его сложности и многочисленности решаемых им проблем, он практически не «виден» для прикладного программиста — все действия выполняются автоматически, в том числе и распространение контекста безопасности.
Разумеется, данная статья не покрывает всех возможных технологий и подходов к решению поставленных задач. Целью данной статьи было показать основные задачи, стоящие перед разработчиками программного обеспечения интегрированных систем технической безопасности, а также предложить возможные пути их решения. Автор надеется, что описанные в статье подходы и архитектурные решения могут быть полезны разработчикам программного обеспечения.

Комментирование запрещено