В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
1. Зрелость выбранной платформы, то есть количество различных готовых решений, реализованных на ее основе к моменту ее рассмотрения. Большее количество различных решений говорит о множестве функций платформы, об универсальности и гибкости. Чем более зрелая платформа, тем легче подобрать готовый набор и избежать переплаты за "нестандартные" функции или свести эту переплату к минимуму.
2. Легкость масштабирования. Если одно и то же оборудование подходит для небольших офисов и крупных филиалов, то это упрощает проектирование, облегчает логистику и монтаж.
3. Возможность составить "типовые монтажные наборы" для каждого типа офиса. Такой подход упрощает процесс монтажа, повышает его надежность и снижает сроки.
4. Мультивендорность системы. Если платформа позволяет подключать периферийное оборудование от разных производителей, то это снизит не только стоимость проекта, но и издержки на обслуживание. В будущем такую систему будет легче сменить или дополнить. Не секрет, что, например, при одном и том же качестве извещателей "протокольные" обходятся дороже аналогичных, выпускаемых компаниями, специализирующимися только на извещателях.
5. Однотипность и взаимозаменяемость оборудования, применяемого для разных задач. Снижается количество ЗИПа, повышается "живучесть" системы (при отсутствии ЗИПа возможно более важные модули системы отремонтировать путем замены их снятыми на том же объекте и менее критичными в данный момент). Однотипность оборудования и его простота снижают требования к персоналу на этапе монтажа и эксплуатации.
Эффективное объединение разрозненных территориально распределенных объектовых систем и средств безопасности в единую информационную систему – непростая задача. В филиалах, скорее всего, уже развернуты какие-то средства и системы, причем зачастую – совершенно разных моделей и производителей. Для многих интеграционных платформ на рынке реклама лукаво заявляет поддержку "всего и вся", но на практике такая интеграция оказывается поверхностной, ограниченной по возможностям, например, транслируются не все возможные события или отсутствует поддержка функций управления (только однонаправленное взаимодействие). Потому возможность глубокой, с сохранением максимума функциональных возможностей интеграции объектовых систем и средств в единое информационное пространство напрямую определяет эффективность создаваемого интегрированного решения и степень контроля потребителя над конечной системой.
В интегрированной суперсистеме между филиалами будет циркулировать большой объем данных: события, пропуска, видео, метаданные. Таким образом, системы филиалов должны быть подключены к сети с высокой пропускной способностью и возможностью двустороннего информационного обмена, то есть к IP-сети. Географическая распределенность филиальной сети обычно обуславливает невозможность создания полностью своей сетевой инфраструктуры и, как следствие, ведет к необходимости использования общих проводных и беспроводных каналов и сетей, таких как сеть Интернет и сети сотовых операторов. В связи с этим интеграционная платформа должна не только выполнять эффективную маршрутизацию данных в такой гетерогенной сети, но также и обеспечивать необходимый уровень защиты информационного обмена с применением современных и/или сертифицированных алгоритмов и средств.
Необходимость использования ненадежных, неконтролируемых каналов между филиалами диктует несколько серьезных требований к интеграционной платформе. Во-первых, в отсутствие связи с "внешним миром" объектовая система должна сохранять свою работоспособность и продолжать функционировать автономно. Во-вторых, платформа должна гарантировать доставку данных (возможно, с задержкой на время потери связи), обеспечивать их целостность, разрешать коллизии в данных (при независимой модификации одних и тех же данных). Представим систему распределенного доступа, в которой два оператора в двух разных филиалах вносят изменения в права доступа одного и того же сотрудника. И в это время из-за аварии на магистрали отсутствует связь между филиалами. По тому, как поведет себя платформа по факту восстановления связи, каким образом и как быстро она "справится" с возникшей коллизией в данных, можно судить о ее эффективности.
В-третьих, платформа должна работать на IP-каналах любого качества сервисов, с гибкой адаптацией к пропускной способности и приоритизацией видов передаваемой информации. Наконец, обязательной является поддержка резервных и альтернативных типов каналов связи на случай сбоев. Платформа должна обеспечивать прозрачный или облачный доступ ко всем данным в интегрированной системе. Пользователь не должен задумываться о том, на каком конкретно физическом сервере какого филиала хранится интересующая его информация. Если он хочет построить отчет по доступу сотрудника на все филиалы сети, то платформа должна автоматически агрегировать все необходимые данные с различных серверов, пользователю же интегрированная система должна представляться единым целым. Конечно, при этом платформа должна позволять администратору определить виртуальную структуру системы (которая может не совпадать с физической), разграничив права на доступ к разным частям единого информационного пространства.
И последнее, самое главное свойство – возможность организации единой системы управления инцидентами. Такую систему характеризуют:
У таких платформ можно выделить целый ряд ключевых свойств. Если начать с самого очевидного, то это поддержка многофилиальной структуры. Платформа должна не только развертываться на локальных объектах, но и собирать все филиалы в единый ситуационный центр, обеспечивая верхний уровень управления и контроля.
Для оперативного реагирования в случае нештатной ситуации платформа должна быстро справляться с обработкой большого количества поступающей информации. Из этого вытекает следующее свойство – наличие возможности приоритизации сигналов, тревог и ошибок. Система должна распознавать, какую именно информацию нужно эскалиро-вать в ситуационный центр, а какую необходимо оставить на локальном уровне. Кроме того, платформа должна иметь максимальный набор готовых интеграционных модулей с разными системами безопасности (системы контроля и управления доступом, тревожная и охранная сигнализации, видеонаблюдение и т.д.) наиболее распространенных производителей. Отдельно замечу, что решение, использующее различный состав вендоров на разных объектах, обязательно должно быть проработано. В противном случае его реализация может оказаться очень дорогой.
Если говорить о каких-то более формальных вещах, то здесь важно наличие сертификации и поддержки в России, в том числе с возможностью сервисного обслуживания компаниями-интеграторами.
Надежность и масштабируемость. Не любая система, обеспечивающая надежность в масштабах малого объекта, "потянет" крупный холдинг с филиалами в десятках разных городов. Поэтому следует выбирать ту, которая уже зарекомендовала себя в соответствующей нише. Система также должна быть способна, следуя за развитием бизнеса, наращивать мощности: от малой системы до многофилиальной с территориально удаленными друг от друга объектами.
Можно выделить три большие задачи, которые решаются при построении единой системы безопасности распределенного предприятия.
Первая и самая очевидная – создание единого поста охраны, который бы обрабатывал все тревожные сообщения и управлял службами физической защиты объектов. Фактически это задача создания собственного ПЦО. Вторая тоже сводится к созданию системы мониторинга, однако не столько тревог, сколько неисправностей. В этом случае заказчик может значительно оптимизировать обслуживание систем безопасности и автоматики, если предприятие представляет собой сеть небольших и средних магазинов. Сюда же можно отнести мониторинг состояния камер видеонаблюдения и регистраторов, установленных в банкоматах. Функционал системы в данном случае будет развиваться в сторону учета и контроля фактов выезда обслуживающего персонала на объекты и своевременного устранения неисправностей.
Третья задача – интеграция системы безопасности и системы кадрового учета (ERP-систе-мы управления предприятием). Такая интеграция дает возможность вести единую базу данных пользователей систем контроля доступа и охранной сигнализации, добавлять новые и редактировать существующие записи сотрудников сразу в нескольких локальных системах различных филиалов. При внедрении подобной системы ответственный работник центрального аппарата всегда сможет иметь доступ на любой удаленной объект организации. Горизонтальные связи между филиалами в части перемещения персонала будут строиться намного проще. Мониторинг же сведется к централизованному получению отчетов по учету рабочего времени и нарушениям трудовой дисциплины.
Таким образом, ключевое свойство локальных систем безопасности – максимальная открытость. Они должны не только иметь возможность передавать максимум данных о своем состоянии на верхний уровень и получать оттуда команды управления, но и изменять свою конфигурацию для решения третьей задачи.
Ввиду того что интеграция в современном понимании – это не только стабильные и непрерывные каналы связи, но и возможность передачи сложных вычислений между сервисными приложениями, ключевыми свойствами интеграционных платформ являются:
Базовой технологией построения интеграционных платформ на текущем этапе развития является гибридная интеграция с привлечением облачных технологий. В случае профессиональной реализации это лучший способ оптимизировать существующие ресурсы ИСБ и обеспечить связность "всего и вся". После внедрения гибридная интеграционная платформа позволяет быстро и легко интегрировать приложения, данные и процессы, без пространственных ограничений. Что это дает пользователю? В совокупности с широким функционалом визуализации предоставляется возможность идеальной настройки интерфейса от всех систем ИСБ филиальной сети на централизованных рабочих местах с дополнительной функцией машинного обучения интеграционного ядра и гибкой корректировки экранных форм в процессе повседневной работы системы и, как итог, удобство и эффективность применения при минимальных затратах.
Чтобы выделить ключевые свойства платформ, давайте сначала обратимся к наиболее частым вопросам, которые хотят решить заказчики при построении таких систем, порой инвестируя ради этого значительные средства:
В современном мире начинают размываться границы между ИСБ, ССОИ, SCADA, PSIM и BMS. Кроме того, все больший акцент делается на синергию Information и Physical Security, безусловными драйверами данной философии выступают крупные ИТ-интегра-торы, которые имеют достаточно ресурсов и компетенций для внедрения подобных комплексных решения Enterprise-класса.
Параллельно с этим передовые технологии, которыми мы уже привыкли активно пользоваться в повседневной жизни, набирают популярность и в промышленных решениях, связанных с безопасностью. Например, серьезным импульсом для применения систем распознавания лиц в рамках крупных распределенных объектов стала популяризация данной технологии в смартфонах.
Все это ложится в основу тех требований, которые сегодня предъявляются к платформам для территориально распределенных объектов с филиальной структурой. Основываясь на нашем многолетнем опыте построения систем безопасности для корпоративных заказчиков в России и СНГ, мы можем сделать заключение, что для интеграционной платформы основными сегодня являются следующие свойства:
На наш взгляд, в силу большого количества нюансов, связанных со стандартизацией в области протоколов обмена данными в системах безопасности, до сих пор преимущество на стороне тех производителей, которые имеют ресурсы не только разрабатывать и поддерживать программные продукты для интеграции, но и могут предложить заказчику полный набор аппаратных компонентов и дополнительных сервисов.
Одно из ключевых свойств любой платформы для ИСБ – это возможность интеграции всех систем безопасности: СКУД, ОПС, ТСН. Кроме того, к современным ИСБ зачастую предъявляется требование интеграции и с системами автоматизации зданий, такими как вентиляция, кондиционирование, отопление, освещение и др.
Считаю особо важным, чтобы распределенная ИСБ имела мультисерверную архитектуру, потому что в этом случае каждый объект клиента может работать автономно и независимо от центрального сервера при потере связи с ним. При этом системой будет управлять региональный сервер на локальном объекте, все рабочие станции сохранят работоспособность, в обычном режиме будет выполняться мониторинг и выдача пропусков. Когда связь с центром будет восстановлена, БД регионального сервера реплицируется с БД центрального.
Я бы выделил также как необходимое свойство для ИСБ ее масштабируемость, поскольку клиент должен иметь возможность подключить к уже существующей системе свои новые подразделения.
Кроме того, в рамках ИСБ должна быть реализована единая интегрированная база данных и параллельное лицензирование в отношении клиентских станций, то есть лицензия привязывается к учетной записи, а не к конкретной машине.
Поскольку крупные распределенные системы создаются для больших корпораций с региональными офисами в разных странах, ИСБ должна поддерживать мультиязычность и одновременную работу в нескольких часовых поясах.
Отмечу, что основные современные платформы для интегрированных систем безопасности (Bosch, Honeywell, Lenel) могут обслуживать неограниченное число пользователей, входов/выходов и периферийных устройств, а также имеют широкий набор инструментов для интеграции со сторонним оборудованием и ПО, при этом каждая из этих систем уже имеет огромный набор готовых интеграций. Хочу отметить еще одно важное свойство современной ИСБ – это полноценное резервирование серверов БД системы, когда при выходе из строя какого-либо из них система продолжает полноценно функционировать.
Николай Татарченко:
Возможны:
Такие структуры имеют разные показатели "надежность/цена". Выбор структуры зависит от минимального необходимого уровня надежности комплекса, наличия кадров в каждом регионе и бюджета проекта.
Управлять этой структурой нужно исходя из выбранного варианта ее организации и наличия кадров в каждом регионе. При использовании аутсорсинга для этих целей необходимо учитывать, наряду с квалификацией персонала, опытом работы, наличием соответствующих сертификатов и разрешений, значимость данного проекта для подрядчика. В любых условиях эксплуатации наличие многоранговой системы оповещения о нештатной работе системы является обязательным условием успешного функционирования объектов.
Глеб Рыбаков:
Выбор структуры, которая будет эффективна в каждом конкретном случае, напрямую зависит от специфики объектов, решаемых задач, выполняемых в организации процессов и требований заказчика.
В общем случае мы рекомендуем сохранять достаточную автономность объектовых систем, оставляя их владельцами своих данных и конфигураций. Это позволит сохранить работоспособность системы филиала при отсутствии связи с "внешним миром". Взаимодействие филиалов и подключение их к центральной части должно осуществляться по стандартизованным, открытым протоколам (вроде ONVIF) на принципах равноправного двунаправленного обмена данным. Части интегрированной системы должны периодически обновлять сведения (данные, конфигурацию) от других филиалов. Таким образом, несмотря на то что каждая филиальная система администрируется независимо, благодаря единым "правилам игры" сохраняется целостность и актуальность информации в едином пространстве. В части вопроса управления задачу следует рассматривать в контексте и с увязкой с задачами управления всей информационной инфраструктурой предприятия, вовлекая соответствующие ИT-ресурсы и структурные подразделения предприятия.
Иван Царев:
Чтобы эффективно организовать единое информационное пространство территориально распределенного объекта, необходимо правильно выстроить как кадровую, так и аппаратно-техническую структуры. Распределение должностных обязанностей происходит на основании созданной модели угроз. Она представляет собой целый перечень возможных негативных событий, которые варьируются в зависимости от таких факторов, как назначение объекта, его местоположение и т.д. В итоге выстраивается организационная система, в которой четко установлено, кто, на каком уровне и за что отвечает. То есть, другими словами, обуславливаются зоны ответственности конкретного филиала, вышестоящего объекта, ситуационного центра системы. Затем, уже на локальных уровнях, происходит распределение ролей сотрудников на той или иной позиции и, соответственно, определяется информация, которая необходима каждой роли для принятия решения.
Если говорить об аппаратно-технической структуре, то на каждом локальном объекте нужно организовать отдельное диспетчерское место и отдельный диспетчерский центр. В этот диспетчерский центр должен сводиться максимум информации о подохранном объекте – от систем контроля и управления доступом до системы охранного видеонаблюдения, которая может быть построена в том числе на основе аналитики. Далее в этой структуре выделяются основные сигналы, которые в дальнейшем транслируются в единый ситуационный центр распределенных объектов. Его расположение заказчик выбирает на свое усмотрение. Зачастую важным критерием является равноудаленность остальных объектов от этого центра.
Таким образом, информационное пространство должно учитывать логику деления ролей, логику распределения оборудования и градацию ситуации. Должно быть четко определено, какие угрозы безопасности можно решить на локальном, местном уровне своими силами, а какие необходимо эскалировать дальше, например на региональный или федеральный уровни.
Марина Казарицкая:
Информационное пространство ИСБ состоит из:
Необходимо обеспечить актуальность и надежность передачи различных видов информации между территориально удаленными друг от друга филиалами, а также возможность удаленного управления подсистемами.
Для эффективного управления территориально распределенным объектом также необходимы механизмы, позволяющие как оперативно реагировать на ситуацию в реальном времени, так и проводить ее анализ для принятия стратегических решений. Можно сказать, что важнейшая функция любой платформы для крупной ИСБ – предоставление статистики для принятия верных управляющих решений руководством во всех звеньях компании. Подразумеваем прежде всего богатые возможности различных отчетов: по событиям, по сообщениям, по учету рабочего времени, списки людей на территориях и др.
При решении второй и третьей задач большого смысла организовывать трехзвенную структуру нет. Главная причина – отсутствие необходимости обработки массы поступающих данных в реальном времени, ибо задачи по мониторингу в большей степени сводятся к аналитике и формированию различных отчетов.
Алексей Марков:
Наиболее широко применяемой в крупных территориально распределенных компаниях является 3-уровневая структура информационного пространства ИСБ:
Она хорошо себя зарекомендовала в связи с высокой эффективностью дежурного контроля и мониторинга объектов, но практика показала, что в случае ЧС ключевые решения принимались "на местах", хотя и не всегда правильно. Большие перспективы сулит развитие Интернета вещей, который может взять на себя часть рутинных дежурных функций, при этом сдерживающим фактором выступает высокий уровень ответственности принимаемых по первичным данным ИСБ-решений. Готовы ли мы сделать этот процесс полностью автоматическим, пока до конца не ясно.
Поэтому в настоящее время оптимальным видится построение единого информационного пространства, позволяющего на базе облачных сервисов оперативно предоставлять пользователю любую запрашиваемую информацию, а также делать требуемые расчеты в пределах разрешенного ему подсистемой аутентификации доступа к данным и ресурсам (индивидуальное ранжирование).
В этом случае большое внимание следует уделять вопросу надежности и безопасности аутентификации пользователей для работы в системе, так как любая интеграционная платформа обладает возможностью контролировать, а также модифицировать и управлять работой всех интегрированных в ней ИСБ филиальной сети. Конечно же, во всех платформах предусмотрены системы ограничения доступа и разграничения полномочий, но гораздо надежнее попросту не допускать к работе с ИСБ нежелательных сотрудников и нарушителей, а у пользователей формировать ответственное отношение к работе с ИСБ.
Дмитрий Пехов:
Важно понимать, что единое информационное пространство объекта с сетью филиалов представляет собой не только совокупность ИТ-ресурсов и программно-технических средств, например серверов управления, баз данных, сетевых контроллеров и т.д., но также организационных структур, которые регулируют все информационные процессы, и организационно-нормативных документов. Вся система должна функционировать на базе единых принципов и по общим правилам.
В современном мире, когда общество становится все более информационным, интегрированная система безопасности компании уже не может эффективно работать в изоляции от других служб и информационных активов. Ее структура должна так же органично вписываться в общую ИT-парадигму заказчика, как и остальные компоненты. При построении системы безопасности на распределенных объектах, как правило, используется принцип иерархичности, когда на уровне филиалов остаются механизмы оперативного контроля и администрирования, а центральный офис отвечает за систематизацию данных и общее управление.
Приведем несколько практических примеров такого подхода: небольшие филиалы, которые не подразумевают необходимость локального мониторинга службой безопасности, оснащаются только пожарной сигнализацией, системой оповещения, универсальными сетевыми контроллерами СКУД/СОТС и небольшими видеорегистраторами, обычно со встроенными PoE-коммутаторами. Мониторинг, управление и администрирование осуществляются из центрального офиса. При этом, когда канал связи с головным офисом практически не используется, осуществляется копирование видеоархива в СХД центрального офиса для долговременного хранения.
Крупные филиалы имеют свои локальные коммуникационные серверы и серверы баз данных регионального уровня для обеспечения автономной работы филиала при отсутствии связи с центральным сервером. Кроме этого, структура с локальными базами данных позволяет гибко настраивать передачу в центральную БД только событий с высоким уровнем приоритета, снижая при этом нагрузку на центральный сервер. Разделенные базы данных также могут быть настроены на работу только с конкретными подсистемами (АПС, СКУД, СОТС и т.д.), позволяя оптимально спланировать разделение ИT-ресурсов.
Вячеслав Петин:
Для структурирования единого информационного пространства в современных ИСБ применяется сегментирование базы данных (мультисерверная архитектура), причем каждый сегмент – это отдельная региональная база данных, которая может работать автономно, а сегментирование может быть мнгоуровневым. Необходимое условие эффективной работы такой структуры – это синхронизация данных между множеством сегментов.
Благодаря такой архитектуре сотрудники службы безопасности и ИТ-менеджеры могут централизованно управлять всей интегрированной системой, но при этом каждое региональное отделение компании сохраняет возможность автономного контроля над своей подсистемой.
Николай Татарченко:
Если платформа соединяет в себе зрелость с возможностью работы с периферийными устройствами различных вендоров, то она обеспечивает максимально широкий перечень запросов заказчика. Мультивендорность позволяет не только удовлетворить запросы заказчика, но и подобрать оборудование на любой вкус, обеспечить для него лучшее соотношение цены/качества.
Глеб Рыбаков:
Во-первых, интеграционная платформа должна быть исходно спроектирована и создана для комплексного решения задач безопасности – и видеонаблюдения, и контроля и управления доступом, и охранной сигнализации, и т.д. Выбор продукта, изначально специализированного в какой-то конкретной области, например видеонаблюдении (а именно таких продуктов на рынке большинство), существенно ограничивает заказчика в эксплуатационных возможностях создаваемого решения.
Во-вторых, платформа должна обеспечивать глубокую интеграцию широкого набора систем и средств с поддержкой максимума их функциональных возможностей. На практике многие продукты на рынке могут получить от интегрируемых средств только часть информации, не поддерживают управление такими средствами и т.д. Кроме того, платформа должна обеспечивать возможность интеграции со смежными системами, такими как системы автоматизации зданий и др. Только тогда на базе платформы можно будет автоматизировать действительно комплексные бизнес-процессы. Для обеспечения таких богатых интеграционных возможностей платформа должна реализовывать широкий набор стандартных протоколов и спецификаций – OPC, ONVIF и др.
Поддержка стандартов, модульная структура платформы, гибкая архитектура и наличие элементов "конструктора" (с возможностью конструировать из компонентов платформы различные конфигурации и автоматизировать работу с помощью скриптов поведения) делают решения на базе платформы устойчивыми к новым вызовам, изменениям со временем требований и бизнес-процессов.
Наконец, платформа должна позволять эффективно (в том числе по экономическим метрикам) решать задачи различного масштаба. Например, бизнес может со временем расти: на раннем этапе заказчик не хочет делать большие вложения в платформу, а на более поздних от платформы потребуется способность эффективно масштабироваться в соответствии с ростом бизнеса.
Иван Царев:
Интеграционная платформа обеспечивает максимально широкий перечень запросов в том случае, когда заказчик понимает, что он хочет получить в итоге, то есть точно ставит задачи и определяет необходимый функционал для интегрированной платформы систем безопасности. Наиболее эффективным решением является привлечение специалистов еще на этапе проработки вопросов внедрения интеграционной платформы. При таком подходе уже на этапе проектирования можно понять реальный спектр задач и возможные способы их реализации. Исходя из опыта многочисленных комплексных проектов, отмечу, что оптимальный выход – выбор одной компании, которая привлечет всех необходимых специалистов, разработает модель угроз, проведет анализ бизнес-процессов. Последнее необходимо для того, чтобы понять, какие из них могут быть оптимизированы с помощью внедрения интеграционной платформы и каким образом. Затем на основании проведенного аудита разработает техническое задание и согласно ему выполнит все необходимые работы по обеспечению безопасности территориального объекта и его интеграции в единый ситуационный центр средствами интеграционной платформы.
Марина Казарицкая:
Лучше отдать предпочтение той платформе, которая с наименьшими затратами позволит при необходимости масштабировать ИСБ, а также интегрировать новые виды оборудования, добавлять в систему новые логические модули. Важным плюсом может быть широкий перечень уже поддерживаемого оборудования, готовность поддержать новые типы и модификации устройств, а также возможность заказной разработки аппаратных и функциональных драйверов.
Максим Горяченков:
Можно попробовать представить себе универсальную интеграционную платформу, решающую все три описанные в п. 1 задачи. Однако почти сразу становится понятно, что возможность создания такой платформы – утопия. Главная проблема будет лежать не в технической, но организационной плоскости. Задачи относятся к компетенции различных структур и служб заказчика, редко глубоко связанных между собой на горизонтальном уровне. Только решения первой и второй задач могут как-то сочетаться. При этом вторая задача будет зачастую решаться на самом верхнем уровне такой системы.
Алексей Марков:
Вначале необходимо отметить, что переход к широкому применению интеграционных платформ был в первую очередь связан с острой необходимостью преодоления информационного разрыва между бизнес-подразделениями и ИТ-отделами компаний, который не давал возможности широкого внедрения интеграционных механизмов во всех сферах.
Сегодня в связи с бурным ростом вычислительных возможностей и применением их при создании ИСБ объектов происходит непрерывное усложнение процессов взаимодействия ИСБ объектов филиальной сети, однако именно это делает возможным реализацию качественно нового этапа развития интеграционных платформ в сторону применения машинного обучения и облачных сервисов.
Таким образом, масштабное усложнение самой интеграционной платформы должно привести к упрощению взаимодействия пользователей с интерфейсом системы и одновременному расширению функциональных возможностей ИСБ.
Дмитрий Пехов:
В случае, когда архитектура платформы может быть полностью адаптирована под ИT-структуру клиента, при этом позволяя взаимодействовать с полным спектром технических средств безопасности и, кроме этого, имея возможности гибко взаимодействовать с системами верхнего уровня, например с ERP-системами.
Интеграционная система должна предоставлять заказчику все необходимое, чтобы обеспечить на разнородных объектах высокий уровень защищенности, оптимизировать управление всей системой, получить единый интерфейс для оперативного реагирования на нештатные ситуации. Именно такой подход к созданию единого аппаратно-программного комплекса позволяет системе эффективно и эргономично функционировать как единый организм.
Правильно выбранная платформа надежно защищена от компрометации и внутреннего саботажа. Как мы знаем, зачастую именно территориально распределенные объекты предъявляют повышенные требования к функционалу системы, будь то интеграция периметральной охраны, систем сканирования днищ автомобилей или получение информации о состоянии вентиляционных установок.
Платформа должна одинаково успешно работать как в условиях небольшого офиса, так и в условиях ситуационного и мониторингового центра вплоть до системы класса "Безопасный город". Важно помнить, что каждый объект имеет свой класс защиты в зависимости от модели угроз и возможных последствий, но все объекты холдинга должны быть защищены надежной безотказной системой, которая отвечает самым жестким корпоративным стандартам.
Вячеслав Петин:
Во-первых, я считаю, что для максимального удовлетворения потребностей клиента все его запросы необходимо отразить в техническом задании, а затем тщательно спланировать и спроектировать комплексную систему.
Во-вторых, со временем потребности заказчика могут измениться, поэтому предпочтение следует отдавать гибким ИСБ с возможностью наращивания функционала, например за счет приобретения дополнительных лицензий.
В-третьих, я бы отметил, что, кроме базовых возможностей, для кастомизации и расширения круга решаемых задач система должна иметь набор уже готовых интеграций со сторонним оборудованием и ПО. Такие интеграции помогут решить задачи, возникающие в ходе реализации и эксплуатации системы.
Николай Татарченко:
Альтернативой всегда являются ближайшие стандартные решения. Очень важно, чтобы продающие специалисты их знали. Счет стандартных решений, проверенных на практике в зрелой системе, идет не на десятки, а на сотни. Неплохая альтернатива разработке узкоспециализиронного решения (когда приходится создавать "железо" и софт) – использование настоящей платформы, то есть одного "железа" для решения разных задач. При этом в случае необходимости дополняются/исправляются только микропрограммы, программы или просто пишутся скрипты. В таком случае снижается стоимость разработки (в два и более раза), увеличивается надежность системы и снижаются сроки реализации проекта. Такой подход есть не у всех, однако количество правильных платформ растет. Их предлагают, например, "Семь печатей", Octagram, Appolo и др.
Глеб Рыбаков:
В такой ситуации мы вместе с заказчиком изучаем возникшую потребность, предпосылки и специфику задачи. На самом деле уникальных потребностей почти не бывает. Но понять, какая исходная проблема скрывается за узкоспециализированным запросом, бывает очень трудно. В процессе тесного взаимодействия с заказчиком чаще всего удается найти решение, не требующее специализированной разработки.
Для обеспечения быстрой и гибкой адаптации наших продуктов к требованиям заказчика мы реализуем в них принцип "конструктора": поведение или состав большей части платформы можно изменить с помощью скриптов-сценариев, шаблонов и ресурсов, для создания которых не требуется специальной квалификации. С одной стороны, специалисты заказчика могут внести соответствующие изменения самостоятельно. С другой – при заказе таких работ у нас их себестоимость (и, соответственно, стоимость для заказчика) оказывается значительно ниже.
Иван Царев:
На мой взгляд, здесь все обстоит с точностью до наоборот. На рынке в принципе не существует таких готовых универсальных интеграционных платформ, которые устроили бы любого заказчика. Для максимально эффективного использования системы, напротив, нужно дорабатывать базовый функционал под конкретные задачи конкретного заказчика. На это как раз будут влиять составленная модель угроз, требования по безопасности для определенных бизнес-процессов.
Кроме того, мне кажется, неверно говорить о дороговизне внедрения дополнительного функционала. На фоне стоимости внедрения интеграционной платформы для территориально распределенного многофилиального объекта стоимость адаптации под конкретные требования (если речь не идет о полном изменении конфигурации этой самой интеграционной платформы) не будет существенной.
Марина Казарицкая:
Используемая платформа должна быть открыта для интеграции, иметь доступный и качественный SDK для интеграции с каким-либо оборудованием или программными средствами силами сторонних разработчиков.
Платформа должна обладать богатыми возможностями автоматизации, позволяющими настроить связь между самыми разными (не только базовыми, но и сторонними) подсистемами.
Максим Горяченков:
Чудес не бывает. Любая серьезная интеграционная платформа для мониторинга большого количества распределенных объектов фактически создается индивидуально под конкретного заказчика, часто с привлечением к процессу его собственных ресурсов по разработке ПО. В качестве основы могут браться готовые продукты. Но обычно это бывают решения, позволяющие получать данные от систем различных производителей и выдавать их наверх в некоем унифицированном виде. Пользовательский интерфейс, отчеты и т.д. чаще создаются с нуля или сильно перестраиваются под существующие и работающие бизнес-процессы соответствующих служб заказчика.
Алексей Марков:
По моему мнению, внедрение современной ИСБ – это всегда разработка индивидуального (узкоспециализированного) решения даже для небольших, казалось бы, объектов.
В связи с этим выбор функционала ИСБ, который будет реализован, стоит перед заказчиком всегда, и это необязательно разработка чего-то дополнительного. В ряде случаев принимается решение о сокращении и уменьшении числа решаемых ИСБ задач для оптимизации работы системы безопасности и ее стоимости.
Если же заказчик требует от ИСБ выполнения специфических или "нестандартных" функций, то проводится анализ причин, которые формируют у заказчика такую позицию, затем в процессе дискуссии выбирается оптимальное решение и на этой основе корректируется функционал внедряемой ИСБ, при этом сначала предлагаются такие технические решения, где эти функции уже реализованы, с приоритетным использованием оборудования и программных комплексов вендоров из состава существующей ИСБ.
При необходимости разработки дополнительного функционала для платформы ИСБ заказчику предлагаются такие аппаратно-программные решения, которые содержат стандартные средства разработки, встроенные в ядро информационной платформы. Таким образом, стоимость этих работ для заказчика определяется стоимостью привлечения соответствующих специалистов или обучения собственных.
Дмитрий Пехов:
Прежде всего мы предлагаем нашим заказчикам использовать мощный механизм стандартизированных протоколов, например OPC и Onvif.
В случаях, когда средств стандартных протоколов недостаточно, используются SDK и API. Новый BIS Client SDK, который базируется на фреймворке WCF, предназначен в первую очередь именно для разработчиков, если требуется подключить программную платформу BIS к стороннему ПО или создать собственный BIS GUI.
Для обеспечения всесторонней поддержки партнеров в сложных проектах в Bosch Security создано особое подразделение инженерных решений (Engineered Solutions Business), которое помогает системным интеграторам эффективно решать нетиповые задачи от момента проектирования до этапа пусконаладки, обеспечивая максимальный уровень адаптации платформы под задачи конкретного клиента.
Вячеслав Петин:
Когда решается задача подобного рода, то первое, что, на мой взгляд, надо сделать, – это проанализировать интеграции, которые уже существуют для выбранной платформы ИСБ, возможно, среди них найдется решение под конкретные требования заказчика. Если таким способом не удается полностью реализовать необходимый функционал, то можно пойти путем модификации готовых интеграций и добиться соответствия системы поставленным задачам.
Кроме того, можно предоставить заказчику SDK или API для самостоятельной доработки системы, во многих случаях это обойдется дешевле, чем заказ реализации дополнительного функционала у стороннего исполнителя.
Николай Татарченко:
Дополнительно к указанному в п. 1:
Глеб Рыбаков:
В первую очередь следует ознакомиться с портфолио и реальным опытом (историями успеха) компании – производителя интеграционной платформы. Бывает так, что компания А громко заявляет о себе, участвует в выставках, "давит" маркетингом, но на практике оказывается, что на реальных объектах выбирают и устанавливают продукты компании Б, которая просто "хорошо делает свое дело".
Во-вторых, мы рекомендуем выбирать поставщика, который не только обеспечивает в своей платформе интеграцию широкого набора сторонних систем, но также предоставляет полный набор функциональных средств (СКУД, ОТС, ОПС, видеорегистраторов и др.) собственного производства. С одной стороны, это хорошо характеризует практические компетенции компании в соответствующих областях. С другой – выбор решения одного поставщика при прочих равных позволяет снизить как начальную стоимость системы, так и совокупную стоимость владения впоследствии.
Иван Царев:
Важно выбрать такую платформу, которая была бы открыта для масштабирования, добавления дополнительного функционала. Например, если заказчик планирует дальнейшее развитие предприятия, нужно понимать, что количество филиалов будет только увеличиваться. Таким образом, ему будет необходимо иметь возможность без особого труда добавлять объекты (без необходимости полной замены существующей инфраструктуры), наращивать как локальные системы, так и систему ситуационного центра. Если же заказчик не планирует расширение сети, то ему все равно необходимо понимать,
что технологии меняются. В настоящее время активно происходит цифровая трансформация бизнеса, что позволяет решать новые дополнительные задачи и касается в том числе систем безопасности. Постоянно внедряются новые технологии, набирают обороты биометрия, видеоаналитика, появляются доступные системы позиционирования персонала, учета и контроля за перемещением материальных ценностей. Все это также может являться составным компонентом интеграционной платформы систем безопасности и эффективно решать широкий спектр бизнес-задач.
Марина Казарицкая:
Надо обратить внимание на надежность и мощность аппаратной части. Мощная программная платформа со слабеньким и ненадежным оборудованием – это колосс на глиняных ногах.
Оборудование для систем серьезных масштабов следует подбирать с особой тщательностью. Особенно те его части, которые составляют костяк ИСБ. Рекомендуется внимательно изучить варианты, предлагаемые на рынке, и сделать выбор прежде всего в пользу качества, мощности и защищенности, так как скупой платит дважды.
Максим Горяченков:
Немаловажным фактором в выборе базовой программной платформы для создания крупной распределенной системы мониторинга будет являться наличие у нее сертификатов соответствия различным требованиям по защите персональных данных пользователей, хранения ДСП и секретных данных (ФСТЭК), соответствия ведомственным и внутрикорпоративным нормативным документам (постановление Правительства РФ о транспортной безопасности, перечни крупных госкорпораций и т.д.).
Алексей Марков:
Очень важным моментом является ресурсное обеспечение проектов по внедрению интеграционных платформ. Привлечение внешних специалистов – это практически обязательное условие, так как в интеграционный процесс вовлечены многие службы компании с различными внутренними установками, поэтому в проектной команде должны быть эксперты, находящиеся "вне схватки". Кроме того, технологически внедрение интеграционной платформы требует специалистов высокой квалификации по широкому спектру весьма специфических программных решений. Иметь их в штате компании невыгодно, а общей технической квалификации собственных сотрудников для этого, как правило, недостаточно, поэтому использование внешних высококлассных ресурсов более предпочтительно.
При внедрении единой интегрированной ИСБ необходимо также понимать принципы построения архитектур комплексных систем безопасности, основы бизнес-анализа, чтобы понять, как надо строить взаимодействие всех ИСБ филиальной сети. Такое понимание очень важно для достижения положительного результата.
Если говорить о проблемах интеграционных платформ, то следует в первую очередь отметить, что главной ахиллесовой пятой многих решений является наличие в их составе компонентов с различной историей развития, являющихся при этом продуктами разных компаний, когда-то приобретенных основным вендором. Часто новый хозяин решает обойтись "малой кровью" и вместо глубокой интеграции нового компонента ограничивается его подключением в качестве внешнего модуля, а это со временем приводит к резкому росту дополнительных вычислений со всеми вытекающими ресурсными издержками, включая увеличение стоимости серверного оборудования и т.д.
Дмитрий Пехов:
Выбор корпоративной платформы безопасности всегда является сложным вопросом, требующим тщательного всестороннего анализа и глубокого предварительного аудита. Важным фактором при выборе той или иной системы является точное понимание потребностей и задач большого количества подразделений заказчика. Для распределенных объектов не следует забывать про перечисленные ниже параметры.
Вячеслав Петин:
Одна из важных рекомендаций при построении ИСБ – это использовать хорошо зарекомендовавшее себя оборудование и ПО от известных производителей, потому что реализация многофилиальной структуры требует немалых затрат и важно не ошибиться с выбором платформы. Лучше всего строить распределенную ИСБ на базе компонентов одного бренда, поскольку такой подход позволит получить на 100% рабочую систему, состоящую из полностью совместимых элементов. Моя рекомендация – это проверенные опытом инсталляторов во всем мире территориально распределенные ИСБ Bosch, Honeywell и Lenel.
Из конкретики при реализации ИСБ я бы рекомендовал обратить внимание на следующие свойства системы:
Опубликовано: Журнал "Системы безопасности" #1, 2018
Посещений: 5174
Автор
| |||
Автор
| |||
Автор
| |||
Автор
| |||
Автор
| |||
Автор
| |||
Автор
| |||
Автор
| |||
В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
