Журнал "Системы Безопасности" № 1‘2018

w w w . a l l - o v e r - i p . r u n С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 127 Максим Горяченков: При создании ПЦН для сотен и тысяч объектов зачастую бывает целесообразно организовы- вать 3-звенную архитектуру. В этом случае вто- рой региональный уровень, контролирующий объекты одной области или макрорегиона, будет заниматься непосредственным управле- нием локальными службами безопасности с получением большинства событий с объектов. А ситуационный центр самого верхнего уровня получает только информацию об инцидентах в критически важных зонах (например, кассовые узлы и т.д.) и общую статистику о количестве неисправностей и тревог, причинах их возник- новения, способах и сроках решения. Подоб- ный подход обусловлен невозможностью "переварить" одним ситуационным центром огромное количество поступающих с объектов событий. При решении второй и третьей задач большого смысла организовывать трехзвенную структуру нет. Главная причина – отсутствие необходимо- сти обработки массы поступающих данных в реальном времени, ибо задачи по мониторингу в большей степени сводятся к аналитике и фор- мированию различных отчетов. Алексей Марков: Наиболее широко применяемой в крупных тер- риториально распределенных компаниях является 3-уровневая структура информацион- ного пространства ИСБ: l информация для руководства компании; l информация для центральной диспетчерской службы; l информация для служб безопасности объ- ектов. Она хорошо себя зарекомендовала в связи с высокой эффективностью дежурного контроля и мониторинга объектов, но практика показала, что в случае ЧС ключевые решения принима- лись "на местах", хотя и не всегда правильно. Большие перспективы сулит развитие Интерне- та вещей, который может взять на себя часть рутинных дежурных функций, при этом сдер- живающим фактором выступает высокий уро- вень ответственности принимаемых по первич- ным данным ИСБ-решений. Готовы ли мы сде- лать этот процесс полностью автоматическим, пока до конца не ясно. Поэтому в настоящее время оптимальным видится построение единого информационного пространства, позволяющего на базе облачных сервисов оперативно предоставлять пользова- телю любую запрашиваемую информацию, а также делать требуемые расчеты в пределах разрешенного ему подсистемой аутентифика- ции доступа к данным и ресурсам (индивиду- альное ранжирование). В этом случае большое внимание следует уде- лять вопросу надежности и безопасности аутен- тификации пользователей для работы в систе- ме, так как любая интеграционная платформа обладает возможностью контролировать, а также модифицировать и управлять работой всех интегрированных в ней ИСБ филиальной сети. Конечно же, во всех платформах пред- усмотрены системы ограничения доступа и раз- граничения полномочий, но гораздо надежнее попросту не допускать к работе с ИСБ нежела- тельных сотрудников и нарушителей, а у поль- зователей формировать ответственное отноше- ние к работе с ИСБ. Дмитрий Пехов: Важно понимать, что единое информационное пространство объекта с сетью филиалов пред- ставляет собой не только совокупность ИТ- ресурсов и программно-технических средств, например серверов управления, баз данных, сетевых контроллеров и т.д., но также органи- зационных структур, которые регулируют все информационные процессы, и организацион- но-нормативных документов. Вся система должна функционировать на базе единых прин- ципов и по общим правилам. В современном мире, когда общество стано- вится все более информационным, интегри- рованная система безопасности компании уже не может эффективно работать в изоляции от других служб и информационных активов. Ее структура должна так же органично вписы- ваться в общую ИT-парадигму заказчика, как и остальные компоненты. При построении системы безопасности на распределенных объектах, как правило, используется принцип иерархичности, когда на уровне филиалов остаются механизмы оперативного контроля и администрирования, а центральный офис отвечает за систематизацию данных и общее управление. Приведем несколько практических примеров такого подхода: небольшие филиалы, которые не подразумевают необходимость локального мониторинга службой безопасности, оснащают- ся только пожарной сигнализацией, системой оповещения, универсальными сетевыми конт- роллерами СКУД/СОТС и небольшими видео- регистраторами, обычно со встроенными PoE- коммутаторами. Мониторинг, управление и администрирование осуществляются из цент- рального офиса. При этом, когда канал связи с головным офисом практически не используется, осуществляется копирование видеоархива в СХД центрального офиса для долговременного хранения. Крупные филиалы имеют свои локальные ком- муникационные серверы и серверы баз данных регионального уровня для обеспечения авто- номной работы филиала при отсутствии связи с центральным сервером. Кроме этого, структу- ра с локальными базами данных позволяет гибко настраивать передачу в центральную БД только событий с высоким уровнем приоритета, снижая при этом нагрузку на центральный сер- вер. Разделенные базы данных также могут быть настроены на работу только с конкретны- ми подсистемами (АПС, СКУД, СОТС и т.д.), позволяя оптимально спланировать разделение ИT-ресурсов. Вячеслав Петин: Для структурирования единого информацион- ного пространства в современных ИСБ приме- няется сегментирование базы данных (мульти- серверная архитектура), причем каждый сег- мент – это отдельная региональная база дан- ных, которая может работать автономно, а сег- ментирование может быть мнгоуровневым. Необходимое условие эффективной работы такой структуры – это синхронизация данных между множеством сегментов. Благодаря такой архитектуре сотрудники службы безопасности и ИТ-менеджеры могут централизованно управлять всей интегриро- ванной системой, но при этом каждое регио- нальное отделение компании сохраняет воз- можность автономного контроля над своей подсистемой. www.secuteck.ru февраль – март 2018 www.massiveit.com Дмитрий Пехов: В современном мире, когда общество становится все более информа- ционным, интегрированная система безопасности компании уже не может эффективно работать в изоляции от других служб и информа- ционных активов. Ее структура должна так же органично вписываться в общую ИT-парадигму заказчика, как и остальные компоненты