Статьи

інтегровані СБ

  1. Глобальна система управління
  2. Централізоване управління (на прикладі ІСБ 777)
  3. протоколювання подій
  4. Економічна ефективність
  5. масштабованість
  6. надійність
  7. універсальність
  8. Можливість розширення
  9. Відкритість
  10. Технології.
  11. Microsoft COM + / .NET
  12. Java 2 Enterprise Edition (J2EE)
  13. OMG CORBA
  14. архітектура комплексу
  15. Мова програмування
  16. Доступ до БД
  17. зберігання Даних
  18. Обмін даними з іншими системами
  19. Обмін повідомленнями
  20. забезпечення безпеки

Інтегровані системи безпеки - це сукупність технічних засобів охорони і забезпечення безпеки об'єкта, об'єднаних на основі єдиного програмного комплексу в загальну інформаційну середу з єдиною базою даних. (Див. Схему - рис. №1 - приклад інтегрованої системи безпеки, побудованої на ПАК Рубіж-08 )

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

ПРИЗНАЧЕННЯ

Створення глобальної системи управління і захисту великих підприємств, об'єктів транспортної інфраструктури і стратегічно важливих об'єктів - завдання, що вимагає рішення на рівні держави. Досягти цього можна лише переглядом всієї традиційної політики управління, що базується на використанні «живої сили» і переходом на нову концепцію. Нова концепція реалізована в глобальних розподілених інтелектуальних системах управління - "ІНТЕЛЕКТ" компанії ITV і SecurOS виробництв
а компанії ISS. Системи, інтеграцію яких виробляє Россби, являють собою єдину інформаційно-керуючу структуру, яка об'єднує сотні об'єктів. В основі системи - інтеграція.

Інтеграція - якісно новий стрибок в побудові систем безпеки та управління об'єктом. Основна перевага полягає в тому, що всі підсистеми взаємопов'язані, і у відповідь на подію в одній підсистемі відбувається відповідна дія в іншій. Можна задати необхідні сценарії реакції будь-якої складності на різні події. При цьому немає ніяких обмежень на опис логіки взаємодії - все, що може знадобитися на конкретному об'єкті, можна описати засобами інтегрованої системи безпеки.

При цьому немає ніяких обмежень на опис логіки взаємодії - все, що може знадобитися на конкретному об'єкті, можна описати засобами інтегрованої системи безпеки

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

Система має свого роду інтелектом, який дозволяє виявляти потенційно небезпечні ситуації і залучати до них увагу оператора. Це забезпечує ефективний захист, мінімізацію впливу людського фактора і знижує витрати на впровадження і експлуатацію комплексу.

Інтегрована інтелектуальна система безпеки та управління об'єктом, як правило, включає:

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

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

Навіщо потрібна інтегрована система безпеки?
Об'єднання різних систем в рамках єдиної ІСБ дозволяє вирішувати питання комплексного забезпечення безпеки об'єкта максимально ефективно і на найсучаснішому рівні.

Централізоване управління (на прикладі ІСБ 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) - мова, яка дозволяє описати всі аспекти віддаленого взаємодії;
Схема відображення 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 сторінок. Найдивовижніше, що при всій його складності і численності розв'язуваних їм проблем, він практично не "видно" для прикладного програміста - всі дії виконуються автоматично, в тому числі і поширення контексту безпеки.
Зрозуміло, дана стаття не покриває всіх можливих технологій і підходів до вирішення поставлених завдань. Метою даної статті було показати основні завдання, які стоять перед розробниками програмного забезпечення інтегрованих систем технічної безпеки, а також запропонувати можливі шляхи їх вирішення. Автор сподівається, що описані в статті підходи і архітектурні рішення можуть бути корисні розробникам програмного забезпечення.