Автор: Олег ГРУШИН, инженер технической поддержки, Nedap Security Management

Распределенные СКУД

Организация СКУД для распределенного объекта является, пожалуй, самым сложным классом задач в рамках СКУД и тем более, если задача масштабная. Крупные распределенные структуры стали возникать относительно недавно как в силу развития инфраструктуры передачи данных, так и в силу того, что ряд крупных многофилиальных компаний дорос до понимания необходимости стандартизации и объединения СКУД для всех своих филиалов. Если раньше таких решений можно было ожидать прежде всего от IT-ориентированных компаний (сотовые операторы, провайдеры различного рода IT-услуг), то теперь все чаще это становится нормой для производств, ритейла. Если раньше масштабными считались задачи, подразумевающие объединение в единую систему нескольких филиалов компании с общим количеством дверей на уровне нескольких сотен и числом сотрудников от нескольких сотен до нескольких тысяч человек, то сейчас уже не удивляют задачи с общим количеством дверей в 1000+ и числом сотрудников в десятки тысяч человек. Самые масштабные современные проекты, о которых можно найти информацию, объединяют в рамках одной системы уже десятки тысяч дверей и более 100 000 только постоянных сотрудников.

Чего же ждет заказчик, решивший объединить филиалы своей компании в рамках единой СКУД?

1) Единого идентификатора для своих сотрудников, особенно если они достаточно часто перемещаются из филиала в филиал. Сотрудник должен иметь возможность свободно перемещаться в рамках любого из филиалов по своему стандартному идентификатору согласно своим правам доступа и без получения идентификатора посетителя. Также желательно, чтобы система могла полноценно работать с современными идентификаторами, давно вышедшими за рамки просто набора цифр, приписанного к сотруднику компании. Современный идентификатор может быть также инструментом доступа к иным распределенным ресурсам и сервисам компании. К примеру, он одновременно может быть и идентификатором для систем доступа, и банковской картой, и пропуском в корпоративный фитнеc-центр или инструментом для получения доступа к компьютеру в корпоративной сети и т. д.

2) Глобальной отчетности для центра, в котором происходит анализ событий, связанных с сотрудниками. В этом контексте, например, очень важно, чтобы система умела работать с филиалами, расположенными в различных часовых поясах, автоматически делая все необходимые поправки на уровне расписаний, генерации отчетов, учета рабочего времени и прочих действий, жестко привязанных к местному времени. По понятным причинам это очень актуальная тема для крупных российских распределенных структур.

3) Автономности филиалов. Этого можно добиться как при помощи резервирования информационных каналов жестко централизованной односерверной системы, так и при помощи построения распределенной многосерверной системы, когда ее центральный элемент будет ориентирован скорее на аналитику и диспетчеризацию, синхронизацию баз данных остальных серверов. В данном случае нельзя назвать один из вариантов более прогрессивным. На деле, принимая решение о том, какой вариант будет оптимальным, надо исходить из того, какой функционал более критичен для ежедневной работы СКУД заказчика, насколько надежны каналы связи с центром и т. д. При этом если говорить о «железе», контроллеры, на которых строятся распределенные системы, должны обладать максимальным функционалом в автономном режиме. В частности, они должны уметь взаимодействовать с другими контроллерами своего филиала напрямую, а не только при посредстве сервера. Чем больше функционала они смогут взять на себя, тем в итоге лучше для системы, вплоть до взаимодействия со сторонними программно-аппаратными комплексами на уровне пересылки данных, связанных с важными событиями в системе напрямую на серверы, например, локальных видеоподсистем и т. д.

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

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

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

В этом контексте хотелось бы добавить несколько слов о современных решениях, которые все чаще возникают под названием Card Management System (CMS). Это альтернативное решение, обеспечивающее в итоге также распределенную СКУД, но с принципиально иной структурой. Подобное решение вызывает большой интерес прежде всего у заказчиков, на объектах которых уже установлены различные СКУД от разных производителей. Предположим, что заказчика во многом устраивает базовый функционал этих систем, и если даже он решил сменить основного поставщика или посчитал нужным выбрать вполне конкретную систему в качестве стандарта для всех новых филиалов компании, то у него нет желания начинать глобальную смену используемых программно-аппаратных комплексов, которые вполне возможно не являются устаревшими и продолжают локально решать основные задачи СКУД достаточно эффективно. Что делать в такой ситуации? Решением может стать программная надстройка верхнего уровня, которая свяжет локальные системы разных производителей в единую сеть и предоставит компании единый интерфейс и управление, а также возможность получения глобальных отчетов, внедрения единых процедур, правил для всей компании независимо от установленного на местах ПО и «железа». Локально на всех уже существующих серверах СКУД устанавливается дополнительное ПО, гарантирующее связь с новым сервером верхнего уровня, на который будет передаваться необходимая информация и со стороны которого будут производиться необходимые изменения на уровне локальных БД СКУД. Это решение гарантирует одновременно и оптимальный в смысле затрат переход на новый стандарт, так как все уже оборудованные СКУД филиалы можно до определенного момента оставить под управлением уже существующих систем, которые на деле будет работать под управлением CMS, а новые филиалы создавать уже на основе нового стандарта. При этом CMS зачастую обеспечивают более удобный и эффективный интерфейс для заказчика просто в силу того, что это исключительно программный продукт, уже ориентированный на использование именно в качестве надстройки над распределенной системой, изначально учитывающий специфику подобных заказчиков. При смене стандарта в будущем это также обеспечит максимально безболезненный переход к новой системе уже в силу того, что верхняя надстройка, с которой взаимодействует оператор системы, при этом никак не изменится. Независимо от используемого на местах «железа» и ПО интерфейс верхнего уровня, предоставляемый CMS, останется прежним. Также от производителей CMS в большей степени можно ожидать кастомизации продукта под конкретного заказчика, чем от крупного производителя СКУД, зачастую в большей степени сфокусированного на своем «железе».

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

Современный рынок предоставляет достаточно возможностей и различных решений. В итоге как и всегда главным вызовом остается четкое понимание и определение заказчиком своих целей, задач и качественная проработка проекта в связке с опытным интегратором, ориентированным на долгосрочное партнерство, а не на однократное получение прибыли.

NEDAP AEOS

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

Настройка контроллеров в удаленном режиме ничем не отличается функционально от локальной их настройки специалистом на объекте. Обновление прошивки «железа» также без труда осуществляется удаленно. Высокая надежность оборудования, подтвержденная трехлетней гарантией производителя, позволяет минимизировать визиты технических специалистов в каждый отдельно взятый филиал компании.

Nedap AEOS поддерживает все основные современные стандарты, связанные с информационной безопасностью, такие как SSL, интеграция с Active Directory, возможность выбора заказчиком как платформы на уровне операционной системы (сервер под управлением OS Windows или Linux), так и базы данных (MS SQL, Oracle, PostgreSQL, MySQL).

Деление на юниты, подразделения, различного рода фильтры и шаблоны, накладываемые как на сотрудников (как субъектов доступа), так и на операторов системы гарантируют сегментирование системы на всех уровнях. Каждый оператор видит только те функции системы, которыми ему позволено пользоваться, только те объекты, с которыми он имеет право взаимодействовать на уровне просмотра или редактирования.

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

Ниже представлены несколько решений распределенных СКУД различных производителей.

BioSmart

СКУД BioSmart позволяет осуществлять контроль доступа как по уже имеющимся картам доступа, так и по биометрическим параметрам. К параметрам биометрической идентификации относится: отпечатки пальцев или рисунок вен ладоней.

Для каждого контроллера BioSmart можно задать параметры доступа:
только карта, только отпечаток пальца, только рисунок вен ладони; карта и отпечаток пальца; карта и рисунок вен ладони.

Регистрация биометрических данных может осуществляться как с самих контроллеров доступа (некоторые модели позволяют это делать), так и со сканеров отпечатков пальцев, вен ладоней. Вся информация сохраняется в централизованной базе и синхронизируется с конечным идентификационным оборудованием. Например, терминал BioSmart-WTC2 автономно хранит в памяти устройства до 5000 идентификаторов карт и 4500 шаблонов отпечатка пальцев, а терминал PV-WTC автономно хранит в памяти устройства уже до миллиона идентификаторов карт и 300 000 шаблонов вен ладоней.

Централизованное решение позволяет не только оперативно управлять предоставлением доступа на любые удаленные объекты, но и контролировать перемещение сотрудников, вести учет их загрузки и отработанного ими времени.

СКУД BioSmart позволяет с минимальными затратами обеспечить полноценное централизованное управление контролем доступа.



Sigur

Основная особенность территориально распределенных объектов – их организационная структура, представляющая собой сеть географически удаленных подразделений с централизованным управлением.

Sigur предоставляет функционал, максимально учитывающий специфику таких объектов. Подразделения компании могут находиться на любом расстоянии – IP-контроллеры Sigur подключаются к локальной сети, а также могут работать через интернет.

Функционирующая СКУД может расширяться как аппаратно, так и функционально – к системе подключается до 65 000 точек доступа, дополнительные модули ПО устанавливаются в соответствии с актуальными задачами.

В системе может использоваться неограниченное количество рабочих мест – каждый оператор работает исключительно в своей зоне ответственности.

Контроль доступа и регистрация событий осуществляются даже при отсутствии связи с сервером – все контроллеры Sigur имеют автономную энергонезависимую память. Целостность БД СКУД поддерживается автоматически – при помощи встроенного инструмента настраивается диагностика, резервирование и экспорт базы.

Ввод и актуализация информации о персонале автоматизированы – база данных Sigur синхронизируется по одному или нескольким внешним источникам.

При формировании итоговой отчетности не требуется корректировка – регистрация событий производится по времени, соответствующему местоположению точки доступа. На базе Sigur возможно построение комплексной системы безопасности – реализована интеграция с большинством популярных российских СВН и ОПС.



ParsecNET 3

Данное решение, ориентированное на оборудование крупных территориально распределенных объектов, не имеет ограничений на количественный состав оборудования, точек прохода, персонала и других параметров.

В качестве идентификаторов используются карты Mifare. Для занесения идентификаторов в базу данных используются считыватели PR-P08. Турникетная группа оборудована считывателями PNR-P15, контроллерами NC-100K-IP и картоприемниками. Для фотофиксации и видеоверификации входящих посетителей на входе может быть установлена IP-камера.

Для въезда транспорта на территорию через КПП используется шлагбаум, считыватель PR-G07.N и контроллер NC-8000 с релейным расширителем NMO-04 для управления светофором. Офисы, лифтовые холлы, выходы на лестничные марши и специальные помещения здания оборудованы СКУД (считыватели PNR-P19, контроллеры NC-8000-D). Программное обеспечение: PNSoft-Pro – версия программного обеспечения, поддерживающая работу неограниченного числа точек прохода и включающая в себя дополнительные модули (видеоверификацию, интегрированные подсистемы, учет рабочего времени, АРМ бюро пропусков, модуль подготовки шаблонов пластиковых карт); PNSoft-WS (бюро пропусков, КПП, офисное здание, территориально удаленное производственное здание) – дополнительная рабочая станция; PNSoft-DS – модуль сканирования документов.

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



Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru