Предлагаю рассматривать данную статью как приглашение к диалогу для профессионалов в области систем контроля и управления доступом (СКУД). Существующий ГОСТ P по данной теме устарел и требует полной переработки. За прошедшие годы появились не только новые, более совершенные устройства, возникли новые технологии и концепции построения СКУД. Можно сказать, что в значительной степени изменилась сама парадигма существующих практик и концепций построения систем доступа. Для удобной коммуникации профессионалов необходимо определиться с базовыми понятиями, куда входит прежде всего архитектура современных систем.
С момента появления первых систем контроля и управления доступом (СКУД) на отечественном рынке прошел не один десяток лет. Последняя версия стандарта на эту тему, а именно ГОСТ Р 51241–2008, датируется, как видно из номера, 2008 г. В настоящих реалиях развития данного технического направления это уже не просто древность, это, как писал незабвенный Александр Сергеевич, "дела давно минувших дней, преданья старины глубокой…". Я не про то, что стандарт плох, просто он безумно устарел. В соответствии с принципом "свято место пусто не бывает" в прессе, Интернете и просто в разговорах специалистов неизбежно появляются новые понятия, названия, определения и попытки классификации новых технологий, устройств, систем и пр. Некоторые из них я бы осторожно назвал "не совсем удачными" с самого начала, другие иногда трансформируются, уйдя в народ, и возвращаются обратно с искаженным смыслом. Плохо в этом то, что в процессе обсуждения СКУД заинтересованные стороны – заказчик, инсталлятор, разработчик, дистрибьютор, проектировщик, интегратор (недостающее вставить), оперируя в разговоре одинаковыми терминами и определениями, вкладывают в них порою разный смысл. Иногда сталкиваюсь с ситуацией, когда удачное и точное определение, название или классификация начинают использоваться всеми кому не лень просто по причине интереса со стороны заказчика. И вот уже "фотонные отражатели", встроенные в контроллеры, начинают бороздить "просторы Большого театра". Проблема серьезная и быстро не решается, но делать давно что-то надо. Предлагаю по крайней мере начать ее обсуждать. В качестве "затравки" представляю вам свое видение классификации архитектур сетевых СКУД (в терминах ГОСТа согласно п. 4.2.2) масштаба от среднего и выше.
В процессе классификации я специально разделю средства вычислительной техники (компьютеры, серверы, сетевое оборудование, программное обеспечение) и сами контроллеры СКУД с устройствами идентификации и управления (замки, турникеты, шлагбаумы, шлюзы и пр.). Каждая из этих двух частей требует отдельного внимания и имеет свои особенности. Итак, начнем снизу – с контроллеров СКУД.
Чтобы избежать возможного непонимания, сделаем отступление для уточнения некоторых терминов, используемых ниже. Существующий ГОСТ Р 51241–2008 "Средства и системы контроля и управления доступом", который устанавливает классификацию, общие технические требования и методы испытаний, подразделяет СКУД по:
По способу управления СКУД могут быть автономными, централизованными (сетевыми) и универсальными (сетевыми). Автономные системы как класс сейчас нас не интересуют, поскольку для средних и крупных объектов они не актуальны. Централизованные (сетевые) СКУД обеспечивают возможность оперативного контроля и управления исполнительными устройствами СКУД со стороны оператора (операторов) и осуществляют обмен информацией с центральным пультом, в качестве которого обычно выступает персональный компьютер. Термин "универсальные" введен ГОСТом для сетевых систем, способных переходить в режим автономной работы при возникновении отказов управляющих компьютеров, сетевого оборудования или обрыве связи с контроллером СКУД. Большинство существующих сетевых СКУД выполняют эту функцию по умолчанию (она давно стала базовой), и их можно назвать универсальными. Данный термин не прижился, и, говоря далее о сетевых системах, будем подразумевать универсальные. Для управления крупными объектами, имеющими большое количество точек контроля прохода и пользователей, применяются именно сетевые СКУД. Остановимся подробнее на вариантах построения их архитектуры и особенностях применения таких систем для объектов среднего и крупного масштаба. Следует также помнить, что сетевая СКУД и СКУД, управляемая по сети, – это не одно и то же, просто, на мой взгляд, не совсем удачно использовали слово, что может вызывать путаницу в умах потребителей. Надеюсь, эту коллизию в будущем из ГОСТа уберут и термин "сетевые" будет использоваться в общепринятом сегодня контексте!
Это одна из первых архитектур систем доступа, появившихся в России (рис. 1). Отличительная особенность СКУД с распределенной архитектурой состоит в том, что база данных идентификаторов (и событий в системе) содержится не в одном, а в нескольких контроллерах. Они, как правило, выполняют функции управления внешними устройствами и охранными шлейфами через реле и входы охранной сигнализации, расположенные непосредственно на плате самого контроллера. Ввиду невозможности удаленной установки от объекта управления данные контроллеры обычно устанавливаются внутри защищаемых ими помещений. Это имеет свои плюсы: при таком подходе некритично нарушение связи между контроллером и дверным интерфейсным модулем (как в централизованной системе), поскольку каждый контроллер управляет своей группой дверей напрямую, без посредников.
В случае обрыва линии связи между контроллерами и компьютером система продолжает выполнять основные функции управления процессом доступа в автономном режиме (на уровне каждого контроллера). Выведение из строя одного контроллера не повлияет на работу остальных.
Однако всю базу данных вышедшего из строя контроллера мы потеряем. Наиболее часто в системах с распределенной архитектурой один контроллер управляет проходом в две–четыре двери. При большем количестве дверей возникает проблема прокладки коммуникаций, поскольку к каждому замку надо проложить свою линию, подключить отдельно каждый считыватель (если используем Wiegand), протянуть свои линии к датчику двери и кнопке выхода. Больше проводов – выше затраты. Cледует также помнить: чем больше коммуникаций выходит за пределы охраняемого помещения, тем выше вероятность внешнего вмешательства. Лет 15 назад в таких системах часто использовались интерфейсы RS-485 и токовая петля 20-мА, сегодня "правит бал", безусловно, LAN, но и проверенный RS-485 не теряет своей актуальности.
Если перейти на строительную терминологию, то распределенная СКУД – это какое-то количество контроллеров-"прорабов", которые отвечают только за свой участок работ и сами же их выполняют. Они самостоятельно анализируют и хранят часть информации о функционировании только тех точек доступа, которые подключены к ним.
Достоинства:
Недостатки:
В системах данного класса (рис. 2) используются мощные центральные контроллеры, осуществляющие процесс управления с использованием удаленных дверных интерфейсных модулей не обладающих собственным буфером памяти. Именно центральный контроллер в таких системах хранит всю базу данных идентификаторов и событий, произошедших в системе. Располагается он обычно недалеко от управляющих компьютеров/сервера в местах наивысшей защищенности (комнаты охраны, серверные и пр.). Количество подключаемых считывателей на один центральный контроллер может быть очень существенным (до 100 и даже больше), поэтому емкости и мощности одного контроллера в большинстве случаев достаточно для создания СКУД отдельного объекта среднего масштаба. Контроллеры централизованных СКУД являются чисто логическими устройствами и не управляют дверями: не имеют релейных выходов управления замками, входов для подключения считывателей СКУД.
Функции управления дверями, другими внешними устройствами (в соответствии с ГОСТом "Устройства преграждающие управляемые – УПУ") выполняют внешние дверные модули и релейные блоки. Именно они устанавливаются недалеко от объектов управления (двери, охранные шлейфы и др.). Для обмена информацией между центральным контроллером и дверными модулями обычно используются интерфейсы RS-485 или LAN.
Аппаратное разделение функции принятия решений и непосредственно управления УПУ имеет свои достоинства и недостатки. Место установки центрального контроллера обычно хорошо защищено, но он удален от УПУ, управляя им через вынесенные дверные модули.
Такой подход помогает снизить стоимость крупных систем, поскольку цена контроллера "растворяется" в общей стоимости системы. Однако протяженные каналы коммуникаций между центральным контроллером и дверными модулями требуется хорошо защищать. Следует отметить, что сами центральные контроллеры способны объединяться в сети, позволяя тем самым создавать СКУД большого масштаба.
При нарушении связи центрального контроллера с компьютером система работает в автономном режиме, однако нарушение линии между центральным контроллером и дверными модулями приведет к частичному или полному зависанию системы. Другими словами, централизованная система – это жесткая властная вертикаль или пирамида, когда наверху руководящий контроллер ("начальник"), а ниже – обычные дверные интерфейсные модули ("работяги"), которые, собственно, и управляют дверями, имея необходимые входы/выходы для подключения считывателей и остальной "обвязки" точек доступа дверей (входы считывателей, кнопка выхода, геркон и пр.). Наличие центрального контроллера, управляющего всей системой или крупной ее частью, имеющего мощный процессор и развитую аппаратную логику (аппарат реакций), позволяет создавать сложные сценарии взаимодействия на крупном сегменте СКУД без участия компьютера и управляющего ПО. При этом важно, что такие алгоритмы будут работать в автономном режиме работы при выключенном или вышедшем из строя компьютере/сервере.
Достоинства:
Недостатки:
Обычно такие системы (рис. 3) получаются из СКУД с централизованной архитектурой путем добавления специализированных считывателей/контроллеров или дверных контроллеров с собственным буфером памяти идентификаторов и событий – "интеллектуальных интерфейсных модулей". Можно сказать, что каждый такой модуль/контроллер фактически является дверным контроллером СКУД, сравнимым с контроллером в распределенной (одноранговой) системе. Благодаря использованию такого технического решения достигается избыточное резервирование функций, резко повышающее степень безопасности и отказоустойчивости системы. Поскольку контроллер в СКУД с централизованной архитектурой управляет значительным количеством дверей, повреждение линии связи между ним и интерфейсными модулями управления оконечными устройствами способно привести к блокированию значительной части или даже всей системы. Локальный считыватель/контроллер или промежуточный дверной контроллер многоуровневой СКУД, обладающий встроенным буфером памяти, в этом случае переходит в автономный режим управления доступом (на своем участке). Системы, построенные с использованием такой архитектуры, обладают высокой степенью безопасности и исключительной надежностью функционирования. Наличие в таких системах дверных контроллеров с возможностью подключения к центральному контроллеру по LAN-интерфейсу добавляет системе полезные свойства. При наличии развитых сетевых коммуникаций на территории объекта дверные контроллеры с LAN устанавливаются в удаленных зданиях, что придает системе дополнительную гибкость и позволяет экономить значительные средства. Суммируя сказанное, можно сделать вывод, что смешанная система – это властная вертикаль или пирамида с возможностью передачи части функций управления на более низкий уровень в случае наступления экстренной ситуации. Наверху этой пирамиды контроллер-"начальник", который руководит, анализирует и хранит информацию, внизу дверные контроллеры-"прорабы", которые выполняют команды, но также могут самостоятельно действовать на своем участке даже тогда, когда "начальник" отсутствует, выполняя на своем участке его функции.
База данных в такой системе хранится не только в центральном контроллере, она также распределена по дверным контроллерам в соответствии с зоной ответственности каждого.
Фактически многоуровневые СКУД аккумулируют достоинства систем с распределенной и централизованной архитектурой и имеют один недостаток – более высокую стоимость.
Достоинства:
Недостатки:
СКУД с кластерной архитектурой (рис. 4) являются, пожалуй, наиболее продвинутым и современным вариантом в сравнении с указанными выше. В классическом варианте это одноранговые системы, их основное отличие – наличие прямого взаимодействия P2P (Peer-to-Peer) между входящими в них контроллерами. Однако распространенным решением является также вариант, когда выделяется master-контроллер, через который осуществляется управление системой (всеми остальными slave-контроллерами кластера). Такое решение позволяет организовать единую точку для входа в аппаратную часть системы (шлюз), что является более безопасным вариантом, чем индивидуальная связь с каждым контроллером. Типичная кластерная СКУД представляет собой группу одинаковых контроллеров, объединенных по сети, которая может рассматриваться как единый аппаратный ресурс. Эти контроллеры объединяются логически и могут обрабатывать идентичные запросы. Кластерные контроллеры обладают продвинутой и мощной аппаратной подсистемой встроенной автоматизации и позволяют программировать сложную логику работы на уровне всего кластера без участия управляющих компьютеров. В этом состоит их главное преимущество.
Если в ранних СКУД контроллеры являлись специализированными устройствами с собственной железной архитектурой и собственной прошивкой на ассемблере, то сегодня проще купить комплект из ядра на Linux с гораздо лучшими характеристиками, чем разрабатывать собственный аналог. Как результат, контроллер доступа становится не просто "ограниченной узкоспециализированной железякой", а фактически небольшим компьютером с полноценной операционной системой, мощным процессором, большим объемом памяти и развитой программируемой логикой. В контексте аппаратной структуры самих контроллеров распространенным приемом стало использование SOM-модулей, обеспечивающих снижение затрат и ускорение процесса разработки.
Еще одна особенность – гибко распределяемые ресурсы в контроллере. В ранних СКУД количество внутренних объектов контроллеров (временные зоны, уровни доступа и пр.) было жестко фиксировано, в современных с увеличением памяти и вычислительных возможностей контроллера стало возможным создание необходимого числа объектов нужного типа, ограниченного только общей емкостью памяти.
В качестве приятного бонуса для некоторых контроллеров может рассматриваться возможность запуска в них HTML-сервера. Это позволяет производить базовые операции администрирования и настройки контроллера без использования внешнего ПО, только при помощи стандартного веб-клиента. В результате значительно упрощается обслуживание и конфигурирование систем.
Достоинства:
Недостатки:
Прошедшие несколько лет показали, что человеческая фантазия практически неистощима. Появилось достаточное число систем, которые трудно однозначно отнести к какому-то из вышеуказанных типов архитектур. В простейшем варианте это использование на одном объекте в разных сегментах СКУД систем с разной архитектурой. Яркий пример: одна часть системы строится как кластерная (одноранговая), другая – как централизованная или многоуровневая (многоранговая). В совокупности получаем "смешанный" тип архитектуры, причем зачастую могут использоваться как различные контроллеры, так и одинаковые, отличающиеся только способом подключения и взаимодействия между собой. Все зависит от фантазии и предпочтений разработчика.
Другой вариант – гибридная архитектура, когда, к примеру, центральному контроллеру СКУД добавляют возможность напрямую управлять дверью (что изначально ему не свойственно). В принципе СКУД, отнесенные мной выше к "многоуровневым", когда центральный контроллер управляет не "тупыми" дверными интерфейсными модулями, а полноценными дверными контроллерами, можно также отнести к "гибридным", поскольку имеется четко прослеживаемое смешение характеристик централизованных и распределенных СКУД.
Преимущество таких систем прежде всего в том, что на территориях с объектами, существенно различающимися по требуемой емкости и применяемым каналам коммуникации, они позволят максимально полно учесть нюансы для каждого, одновременно объединив их под общим управлением.
Достоинства и недостатки таких систем зависят от индивидуальных характеристик конкретных подсистем, применяемых для конфигурирования СКУД отдельных объектов, входящих в общую систему. На иллюстрации данной архитектуры (рис. 5) нижний уровень считывателей и исполнительных устройств не указан в целях упрощения схемы.
Второй важнейшей частью любой СКУД являются программное обеспечение и технические средства (компьютеры, серверы), на которые оно устанавливается. Приведу наиболее типичные варианты развертывания программно-технических средств управления СКУД на различных объектах.
Одним из простейших вариантов развертывания комплекса на объекте является изолированная (малая) система (рис. 6). В этом случае все модули комплекса (сервер базы данных, ядро, функциональные модули, драйверы оборудования и управляющая консоль) устанавливаются и запускаются только на одном компьютере. К этому же компьютеру подключается и оборудование всех подсистем безопасности. Разумеется, данный компьютер должен обладать достаточной вычислительной мощностью и объемом памяти для функционирования всех этих модулей, а также дисковым пространством для хранения базы данных системы.
Достоинства:
Недостатки:
Например, оператор легко может выключить данный компьютер, и обслуживание оборудования прервется. При этом прекратится выполнение таких операций, как обработка программных реакций системы на возникающие события. В этом случае возрастает значимость внутренней аппаратной логики, которая сможет сохранить функционал даже при выключенном компьютере. Однако в большинстве случаев на малые системы мощное и дорогое оборудование не устанавливают, поскольку исчезнет такое достоинство, как низкая стоимость решения.
В случае большой емкости системы возможна медленная реакция СКУД на события и команды оператора в силу большой нагрузки на компьютер.
Рекомендации:
Данная конфигурация хорошо подходит для построения СКУД небольшого масштаба.
В данном случае все служебные модули комплекса (ядро, драйверы оборудования и логики) функционируют на одном компьютере – центральном сервере системы, а запуск управляющей консоли возможен не только на данном компьютере, но и на других машинах сети.
В такой системе (рис. 7) центральный сервер должен обладать вычислительной мощностью, объемом памяти и дисковым пространством еще большими, чем в случае применения однопользовательской системы. Однако в данной схеме появляется возможность задействовать не очень мощные компьютеры в качестве клиентских рабочих станций. Достоинства очевидны: простота установки, обслуживания и контроля линий связи, так как все оборудование подключено к одному компьютеру. В такой системе легко контролировать состояние функциональных модулей и драйверов оборудования, так как все они функционируют на одной машине.
Недостатки в значительной степени повторяют предыдущий вариант. Для распределенной системы главным отрицательным фактором будет необходимость подключения всего управляемого оборудования ко одному компьютеру (серверу), особенно в случае большой территориальной распределенности оборудования.
Достоинства:
Недостатки:
Рекомендации:
Данная конфигурация хорошо подходит для построения СКУД среднего размера.
В такой системе (рис. 8) сервер управления базой данных и ядро работают на центральном сервере, а драйверы оборудования и логики распределены по всей сети. Запуск управляющих консолей возможен на любом компьютере сети, что делает управление более гибким.
Необходимость распределения по сети драйверов оборудования и логики связана в основном с тем, что объект распределенный и часть оборудования может находиться достаточно далеко от центрального сервера.
Поскольку часть модулей вынесена с центрального сервера системы на другие компьютеры, нагрузка на центральный сервер снижается. Применение такой архитектуры выгодно при наличии большой территории с распределенным по ней управляющим оборудованием. В этом случае нет необходимости прокладывать коммуникации из всех точек к центральному серверу.
Достаточно подключить аппаратуру к ближайшему компьютеру сети и запустить на этом компьютере обслуживающий драйвер. При этом требования к мощности данного компьютера остаются относительно скромными. Надо отметить, что в случае распределенного запуска программных модулей встает задача контроля их состояния.
Для облегчения работы в ПК должны быть встроены специальные средства, позволяющие администратору со своего рабочего места контролировать работу модулей на других компьютерах, запускать или останавливать их.
Достоинства:
Недостатки:
Рекомендации
Данный вариант развертывания подходит для построения СКУД и интегрированных систем безопасности (ИСБ) крупных объектов, имеющих значительные территории с большим количеством отдельно стоящих зданий и сооружений.
Многофилиальная система (рис. 9) может объединять в сеть региональные офисы крупной компании, а также множество небольших отделений, подключенных, в свою очередь, к региональному центру. Такая система должна обеспечивать ряд важных функций: автоматическую синхронизацию базы данных сотрудников между объектами, мониторинг из центрального офиса всех удаленных филиалов, построение отчетов учета рабочего времени сотрудников независимо от того, в каком филиале они присутствовали, и пр. Кроме того, в связи с географической удаленностью филиалов друг от друга система должна гарантировать полнофункциональную работу в случае разрыва связи между ними.
Классическая многофилиальная система представляет собой несколько взаимодействующих филиалов, каждый из которых находится под управлением автономного программного комплекса (ПК), функционирующего в локальной сети, то есть в каждом филиале присутствуют собственное ядро системы, драйверы оборудования и логики, а также база данных. Фактически каждый филиал может функционировать как полностью автономная система безопасности. При этом для каждого филиала может быть выбран любой из вариантов развертывания ПК – изолированная, централизованная или распределенная система. Выбор зависит от размера системы безопасности конкретного филиала и задач, которые перед ней ставятся. Следует особо отметить, что многофилиальная система – это не просто репликация данных между базами. В случае нормального соединения филиалы функционируют как единая система: можно из любой точки изменять конфигурацию объектов филиалов, управлять аппаратурой филиалов, отслеживать их состояние; в одном филиале могут отрабатываться реакции по событиям из другого филиала. Если связь между ними рвется, то филиалы способны полноценно функционировать в автономном режиме, буферизируя пакеты для обмена. При использовании стандартного механизма репликации такие функции не могут быть реализованы.
Если филиал небольшой, при этом линии связи качественные и связь стабильна, можно осуществлять управление им из ближайшего более крупного филиала, при это не надо будет устанавливать в нем компьютеры и оплачивать услуги операторов. В конечно счете все зависит от требований к отдельным объектам и системе в целом.
Облачные технологии прочно обосновались в нашей жизни. Неважно, что мы делаем: пользуемся удобными банковскими сервисами на своем смартфоне или вместе с коллегами храним основную информацию на облачном сервере, – все это объединяется понятием "облачные технологии". Системы контроля и управления доступом не являются в этом плане исключением, хотя консерватизм не всегда сдает свои позиции. Не так давно появился даже термин ACaaS (Access Control as a Service, или СКУД как услуга). С развитием облачных технологий появились различные варианты их реализации, и, как следствие, специалисты выделяют несколько ключевых типов (классификация моделей). Общим в классификации является окончание аббревиатуры на "…as a Service", означающее "как услуга". Это следующие модели (подробнее в журнале "Системы безопасности" № 4/2021 г., стр. 60):
Если говорить об ACaaS, я бы выделил преобладание моделей PaaS и SaaS, которые, по сути, формируют новый характер взаимоотношений "потребитель – поставщик" на рынке СКУД. Несмотря на довольно динамичное развитие данной технологии, я в ближайшее время предполагаю замедление прогресса в этом сегменте рынка.
Опубликовано в журнале "Системы безопасности" № 5/2022
Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>
Источник фото: zabor.bz