Журнал "Директор по безопасности" Сентябрь 2020 | Page 16
ЕСТЬ РЕШЕНИЕ
Как организовать
систему контроля
доступа в крупной
многофилиальной
организации?
ВЛАДИМИР ЗАЙЦЕВ,
руководитель учебного центра Parsec
Вопрос организации единой СКУД с
синхронизацией данных особенно
актуален для владельцев крупных,
многофилиальных объектов. При сложном
структурном и административном
устройстве разворачивать СКУД с
единым сервером и централизованным
управлением либо невозможно,
либо трудно реализуемо. При этом
накладываются ограничения, связанные
с особенностью территориальнораспределенных
топологий.
Третья версия профессиональной
СКУД ParsecNET изначально
создавалась для решения задач
контроля доступа в том числе и на
крупных территориально распределенных
объектах. Эта задача была решена
посредством распределенной
клиент-серверной архитектуры: сервер
с центральной БД и дополнительные
рабочие станции с локальными
БД. Такая архитектура принципиально
является моносерверной, а система
контроля доступа (вне зависимости от
количества рабочих станций и их удаленности
друг от друга) – централизованной:
с единой базой персонала,
расписаний, групп доступа, единой отчетностью
и управлением.
Такая архитектура хорошо себя
зарекомендовала при построении
больших и очень больших централизованных
систем контроля и управления
доступом. Так, сегодня на базе
ParsecNET 3 построены и успешно
функционируют системы с более чем
50 удаленными объектами, распределенными
по территории страны, но
работающими в рамках единой СКУД.
Однако, существуют и другие задачи,
когда требуется построить не единую
систему, а объединить ряд отдельных
самостоятельных слабосвязанных
систем. При этом каждая из них может
быть весьма крупной и распределенной,
имея в составе десятки рабочих
станций. Решение этой задачи легло в
основу новой архитектуры.
Начиная с версии 3.7 в СКУД
ParsecNET появился режим многосерверности.
Это означает, что в крупной
территориально распределенной организации
можно установить несколько
серверов ParsecNET и организовать
между ними синхронизацию некоторых
данных для выполнения следующих
общих задач:
обеспечение сквозного доступа
сотрудников компании на территории
филиалов;
получение бесшовных кумулятивных
отчетов УРВ по подразделениям
компании вне зависимости от фактических
перемещений (командировок);
обеспечение единообразной
структуры данных (правила наименования,
структура подразделений,
праздники и т. д.) всех филиалов;
облегчение разворачивания СКУД
в новых точках.
Связанные сервера объединяются
в кластер, между ними настраивается
синхронизация, но при этом они остаются
самостоятельными системами с
собственным управлением.
Связанные сервера кластера могут
обмениваться следующими данными:
персонал;
идентификаторы;
группы доступа;
события доступа.
Помимо равнозначных серверов, в
составе кластера может быть выбран
мастер-сервер. Мастер-сервер – это
обычный связанный сервер, имеющий
дополнительные права на передачу
данных в кластер. В кластере может
быть только один мастер-сервер, но
кластер может функционировать и
без него. Роль мастер-сервера может,
при необходимости, передаваться
между серверами кластера.
Мастер-сервер, в дополнение к
данным, которыми обмениваются
сервера может рассылать другим связанным
серверам:
расписания;
праздники;
шаблоны печати;
шаблоны дополнительных полей.
Наиболее типичный пример работы
многосерверной системы – многофилиальная
федеральная структура
с региональными и областными
центрами. Дальневосточный федеральный
округ обслуживается одним
сервером с подчиненными ему рабочими
станциями, а Южный федеральный
округ – другим сервером.
Сервера объединены в кластер, в системе
настроен мастер-сервер, расположенный,
например, в Москве и обслуживающий
ЦФО. С мастер-сервера
разосланы политики – стандартные
расписания, праздники, дополнительные
поля и шаблоны печати на картах.
Это обеспечивает унификацию
учета персонала, стандартизацию печати
на картах, сокращение ручных
операций по созданию однотипных
расписаний, исключает необходимость
заполнять на каждом сервере
календарь праздничных дней и т. п.
Наиболее типичный пример
работы многосерверной
системы – многофилиальная
федеральная структура
с региональными и
областными центрами.
Дальневосточный
федеральный округ
обслуживается одним
сервером с подчиненными
ему рабочими станциями,
а Южный федеральный
округ – другим сервером
Предположим, администратору
сервера, расположенного в Санкт-Петербурге,
необходимо «направить»
сотрудника из Петрозаводска в командировку
в Тюмень. Администратором
сервера, отвечающего за
Уральский Федеральный Округ и расположенного
в Екатеринбурге, заранее
была подготовлена публичная
группа доступа «Филиал_Тюмень»,
которая доступна всем серверам кластера.
Администратор из Санкт-Петербурга
выбирает среди персонала Петрозаводского
филиала сотрудника,
использует команду «Направить», выбирает
сервер УФО и одну из опубликованных
этим сервером публичных
групп доступа – «Филиал_Тюмень».
Идентификатор сотрудника будет отправлен
на сервер УФО, оттуда – на
рабочую станцию в Тюменском филиале
и далее – во все контроллеры,
включенные в состав публичной группы
доступа. Сотрудник из Петрозаводска
приедет в командировку, уже
имея доступ на территорию филиала
по своей карте. В конце месяца можно
построить отчет по учету рабочего
времени, в котором будет присутствовать
информация в том числе и
по тому периоду, который сотрудник
провел в командировке – с временем
начала и окончания рабочего дня,
подсчетом отработанных часов, учетом
праздников и т. п.
Для таких слабосвязанных структур
нет необходимости строить централизованную
систему. При этом обмен
только наиболее важными данными
накладывает минимальные требования
на каналы связи между серверами
и сильно повышает отказоустойчивость
системы.
Связанный сервер можно создать
только на том ПК, на котором
стоит аппаратный ключ защиты лицензии
PNSoft-Standart или PNSoft-
Professional. Мастер-сервером можно
назначить только тот сервер, который
установлен на ПК с аппаратным ключом
лицензии PNSoftProfessional.