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

КОЛОНКА РЕДАКТОРА С читаю важным сразу обозначить ключевую мысль: на любом крупном рас- пределенном объ- екте, вне зависимо- сти от его отрасле- вой принадлежно- сти, СКУД в чистом виде, без интегра- ции (как минимум) с остальными подсистемами безопасности, является анахронизмом. В этом смысле неважно, о каком типе объекта идет речь: о банке, о транс- портном узле или о производственном пред- приятии с филиалами в разных городах, – общие требования будут во многом схожи. Можно также отметить, что в современном циф- ровом мире большинство систем безопасности, включая СКУД, давно стали неотъемлемым эле- ментом общей ИТ-инфраструктуры компании. Простой пример: думаю, что непросто будет найти большую компанию, где общая сеть и сеть, используемая для систем безопасности, являют- ся полностью автономными, несмотря на все благие пожелания экспертов и руководства служб безопасности. Это значит, что уже на физическом (транспортном) уровне коммуника- ции являются общими и данная реальность должна учитываться при создании новых и рас- ширении старых интегрированных систем без- опасности (ИСБ), включающих СКУД. Ниже дам некоторые общие ориентиры, на которые следу- ет обратить внимание специалистам в процессе проектирования и внедрения СКУД на крупных промышленных объектах в контексте масштаби- рования системы. Масштабирование системы Поскольку на распределенных объектах отдельные структурные единицы могут быть не только географически удалены от центра, но и иметь совершенно разный масштаб, важным свойством СКУД будет ее масштабируемость. Поясню, что имею в виду. Головное предприятие может быть большим, иметь строения как офисного, так и производ- ственного назначения и управлять системой с целого ряда терминалов в соответствии с пол- номочиями операторов. В свою очередь, филиалы могут быть как меньше, так и больше центра, обслуживаться местными подразделе- ниями службы безопасности, иметь или не иметь локальные терминалы управления ИСБ, включая СКУД. Крайним случаем будет установ- ка на автономной точке комплекса оборудова- ния, подключенного к ближайшему филиалу и не имеющего выделенного компьютерного тер- минала управления – действительно, зачем он там нужен, если персонала мало или вообще он там не предусмотрен. Если система грамотно масштабируется, будет просто оборудовать все указанные варианты с учетом их индивидуаль- ных особенностей. Рассмотрим немного под- робнее примеры развертывания комплекса. Необслуживаемый филиал и малая СКУД Для необслуживаемого филиала устанавли- ваются контроллеры с подключением по сети и возможностью автономной работы. Все идентификаторы и права доступа прописы- ваются в контроллеры либо из ближнего филиала, либо из центрального офиса в слу- чае жесткой вертикальной структуры систе- мы. В малом филиале, укомплектованном оператором СБ, все модули управляющего программного комплекса (сервер БД, ядро, функциональные модули, драйверы обору- дования и управляющая консоль) имеет смысл установить на одном компьютере, к которому подключается и оборудование всех подсистем безопасности. Подразумева- ется, что такой компьютер имеет достаточную вычислительную мощностью и память для работы всех этих модулей, а также достаточ- ное дисковое пространство для хранения базы данных. Базовый филиал – централизованная СКУД В филиале среднего масштаба для многополь- зовательской системы с выделенным цент- ральным сервером база данных (БД), ядро, драйверы оборудования и логики запускаются на нем, а запуск управляющей консоли возмо- жен на других компьютерах сети. Это грамотно распределит нагрузку на железо и операторов системы. В подобном случае оборудование обычно подключается к одному компьютеру, легко контролировать состояние линий связи. Кроме того, легко отслеживать состояние функциональных модулей и драйверов обору- дования, так как все они функционируют на данной машине. Крупный филиал – распределенная СКУД В крупном филиале сервер БД и ядро функ- ционируют на центральном сервере системы, а драйверы оборудования и логики можно распределить по всей сети. При этом запуск управляющих консолей возможен на любом компьютере сети, в том числе и на компьюте- рах, обслуживающих оборудование. Такая архитектура оправданна в случае установки комплекса на крупный филиал с большим количеством рабочих станций и обслуживае- мого оборудования. Поскольку часть моду- лей вынесена с центрального сервера систе- мы на другие компьютеры, нагрузка на цент- ральный сервер снижается. Кроме того, при- менение данной архитектуры оправданно в случае большой территории с распределен- ным по ней управляющим оборудованием. В этом случае нет необходимости проклады- вать коммуникации из всех точек к централь- ному серверу. Достаточно подключить обору- дование к ближайшему к нему компьютеру сети и запустить на этом компьютере обслу- живающий драйвер, причем требования к мощности данного компьютера могут быть относительно скромными. Сервис многофилиальности Говоря о многофилиальной СКУД, подразуме- вается наличие нескольких взаимодействую- щих филиалов, каждый из которых находится под управлением автономного программного комплекса (ПК), функционирующего в локаль- ной сети. Это значит, что в каждом из филиа- лов присутствует собственное ядро системы, драйверы оборудования и логики, а также база данных. При этом для каждого филиала может быть выбран любой из приведенных ранее вариантов развертывания ПК – малая, централизованная или распределенная систе- ма. Взаимодействие филиалов обеспечивается сервисом поддержки многофилиальной рабо- ты и заключается в: l синхронизации данных между филиалами; l обмене сообщениями между филиалами. Передача информации в процессе взаимодей- ствия между филиалами происходит с исполь- зованием шифрования. Сервис поддержки многофилиальной работы предназначен для построения систем, имеющих топологию дере- ва. При этом внутри системы выделяется один главный филиал (центральный офис), который соединяется каналами связи с подчиненными филиалами, у каждого из которых, в свою оче- редь, также могут иметься подчиненные филиалы, и т.д. Достоинства: 1. Центральный офис компании может полу- чать сообщения о событиях из удаленных филиалов как в реальном времени, так и в виде отчетов. 2. В центральном офисе можно вести выдачу карт сотрудникам для прохождения во все филиалы компании. 3. Возможна централизованная настройка систем, контролирующих удаленные филиалы. 4. Работа локальных подсистем безопасности каждого филиала не зависит от работоспособ- ности других филиалов многофилиальной системы. 5. Работа локальных подсистем безопасности каждого филиала не зависит от состояния канала связи между филиалами системы. Алексей Гинце Редактор раздела "Системы контроля и управления доступом", директор по связям с общественностью компании "ААМ Системз" С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 102 июнь – июль 2019 www.secuteck.ru СКУД на крупных распределенных промышленных объектах