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

ПО для распределенных многофункциональных объектов: ключевые особенности и отличия от обычного ПО

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

ПО СКУД
РАСПРЕДЕЛЕННЫЕ ОБЪЕКТЫ

ПО для распределенных многофункциональных объектов:ключевые особенности и отличия от обычного ПО

Что такое многофункциональный распределенный объект и какова его специфика с точки зрения ПО СКУД? В общем случае это ряд физически разделенных филиалов одной организации, перед которыми могут стоять принципиально разные задачи и которые могут функционировать в совершенно разном режиме. Эти задачи, как и режим работы, накладывают свои требования в отношении ПО
Олег Грушин
Специалист службы технической поддержки, Nedap Security Management

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

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

Многосерверный и односерверный подход

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

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

Компромиссный вариант

Существует и третий вариант, когда в едином дата-центре возникает несколько серверов, что позволяет:

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

Исходя из этого, можно сформулировать требования к ПО для подобного класса объектов.

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

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

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

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

Гибкость

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

  1. видеонаблюдение;
  2. ОПС;
  3. лифты;
  4. интеркомы;
  5. системы хранения;
  6. ключницы и т.д.

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

Соответствие корпоративным стандартам

Система, интегрированная в корпоративное ИТ-пространство, должна более или менее соответствовать корпоративным стандартам безопасности:.

  1. на уровне интеграции с Active Directory;
  2. на уровне кросс-платфоменности системы, возможности организации сервера на базе альтернативной ОС;
  3. на уровне определенных БД, используемых для хранения данных, шифрования части или даже всех данных, передающихся от одного компонента системы к другому, и т.д.
Если крупная распределенная компания доросла до идеи единого пространства на уровне СКУД, то можно быть уверенным, что у руководства уже есть свое понимание единых стандартов безопасности для каждого филиала

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

Ориентированность производителя на задачи распределенных объектов

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

Успех – в сотрудничестве

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

Худший вариант для заказчика – когда его объект становится полигоном для испытаний пригодности конкретной системы для задач определенного класса. В подобном случае в какой-то момент можно натолкнуться на неразрешимую проблему

Для эффективного построения системы требуется, чтобы в единой связке работали:

  1. Заказчик с четким пониманием желаемого результата.
  2. Опытный интегратор, готовый на всех уровнях поддержать и скорректировать идеи заказчика, перевести их в стадию серьезного, продуманного и обоснованного проекта.
  3. Производитель СКУД, имеющий серьезный опыт реализации задач необходимого класса.

Опубликовано: Журнал "Системы безопасности" #5, 2018
Посещений: 2426

  Автор

Олег Грушин

Олег Грушин

Инженер технической поддержки компании Nedap Security Management

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

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