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

Интеграция СКУД и системы управления предприятием

В рубрику "Директор по безопасности" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Интеграция СКУД и системы управления предприятием

 

Заинтересованные стороны, проблемы и подходы к их решению

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


C.A. Жук

Начальник управления информационной безопасности УК "Группа ГАЗ"

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

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

Зачем нужна интеграция?

Первый вопрос, с которого обычно начинается вся интеграция, - это вопрос: кому она нужна и что даст?

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

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

Хрестоматийные примеры

Рассмотрим пару примеров, которые можно считать в общем-то хрестоматийными.

Пример первый

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

Пример второй

Помимо контроля перемещения персонала на крупных предприятиях СКУД используется и для контроля перемещения через периметр, а также внутри предприятия транспорта и грузов. В этом качестве система контроля доступа становится эффективным источником информации для торгово-закупочных подразделений, транспортной службы, службы внутренней логистики. Логика развития подсказывает, что в перспективе СКУД может стать одним из элементов системы учета и контроля движения товарно-материальных ценностей (ТМЦ), который обеспечивает "обратную связь" в системе путем сбора информации о деятельности исполнителей. Становится очевидным, что в интеграции СКУД в систему управления предприятием заинтересованы различные функциональные подразделения компании, а не только СБ. Для СБ польза состоит в том, что при общей заинтересованности в использовании такой системы появляется возможность добиваться распределения затрат на ее создание и развитие по бюджетам всех заинтересованных подразделений, а не финансировать исключительно из бюджета СБ (ведь в условиях кризиса он и так подвергается значительному секвестированию). Более того, по крайней мере часть расходов можно отнести к категории производственных.

Как интегрировать?

Теперь вопрос второй: каким образом осуществить эту самую интеграцию? Несмотря на рекламные заявления разработчиков типа "Мы легко интегрируем свой продукт в вашу существующую автоматизированную систему предприятия", необходимо понимать, что вопрос интеграции является весьма сложным. Очень часто затраты на интеграцию могут оказаться сравнимыми с созданием новой системы с нуля.

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

Аппаратная интеграция

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

Программная интеграция

Второй уровень - интеграция на уровне платформы разработки1. Этот вид интеграции может применяться, когда мы создаем корпоративную систему или ее компонент (в данном случае - СКУД) с нуля.

Проектируя свою программную инфраструктуру, многие компании часто попадают в ловушку многоплатформенности, из которой бывает очень трудно выбраться. Дело в том, что покупка любой серьезной прикладной системы в настоящее время практически со 100%-ной вероятностью влечет за собой приобретение программной платформы, на которой она строится. А это - затраты на закупку лицензий, эксплуатацию разных платформ (растет штат сотрудников!), поиск (подготовку) специалистов по этим платформам, увеличение требований к производительности используемого оборудования и т.д. На этапе обоснования подобные статьи расходов зачастую не учитываются либо в силу некомпетентности персонала, либо умышленно. И обычно всплывают на той стадии реализации проекта, когда отступать, как говорится, уже поздно. Принимая решение об интеграции, помимо прикладного функционала необходимо внимательно учитывать системотехнические требования со стороны интегрируемых систем. Интеграция на уровне данных Третий уровень - интеграция на уровне данных. Одна из основных целей, ради которых чаще всего затевается построение корпоративной интегрированной системы, заключается в стремлении получить так называемый синер-гетический эффект - когда в интегрированной системе появляется дополнительный функционал или новые свойства, отсутствующие в интегрируемых компонентах. Интеграция на уровне данных очень часто позволяет добиться такого эффекта.

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

  • огромный объем повторного ввода данных в систему (требует соответствующего увеличения штата!);
  • высокий риск потери адекватности баз данных реальному положению дел - вследствие запаздывания с обновлением их содержимого, а также из-за увеличения вероятности возникновения ошибок при неоднократном вводе данных в различные системы.

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

Интеграция на уровне приложений Рассмотренные выше уровни интеграции в той или иной степени требуют вмешательства или, по крайней мере, знания внутреннего устройства интегрируемых систем. Четвертый уровень -интеграция на уровне приложений - избавляет нас от этого. Суть такой интеграции состоит в использовании специальных программных продуктов, интенсивно продвигаемых на рынке крупнейшими производителями ПО, такими как, например, IBM или Microsoft. Специализированное ПО обеспечивает взаимодействие интегрируемых систем на основе спецификаций протоколов такого взаимодействия. Безусловно, данный подход к интеграции является наиболее перспективным, но в настоящее время он доступен только крупным компаниям, способным делать значительные инвестиции в ИТ-проекты. Основные препятствия: довольно высокая стоимость владения такими продуктами, весьма высокая "прожорливость" с точки зрения вычислительных ресурсов, дорогостоящий консалтинг при внедрении. Компенсацией этих недостатков служит отсутствие необходимости "влезать внутрь" интегрируемых систем. А это, как говорится, дорогого стоит.                                

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

  Автор

Жук С. А.

Жук С. А.

Начальник управления информационной безопасности УК "Группа ГАЗ"

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

В рубрику "Директор по безопасности" | К списку рубрик  |  К списку авторов  |  К списку публикаций