Матрица доступа в СКУД: как связать зоны, группы сотрудников и исключения

Сначала опишите зоны, а не людей

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

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

Далее сопоставьте зоны с реальными точками доступа. Вход в помещение может существовать через основной коридор и через смежную комнату. Матрица, учитывающая только первый путь, создаёт видимость разграничения. При обследовании нужно проверить все штатные маршруты, не публикуя их подробную схему в открытом доступе.

Для каждой точки запишите понятное название, принадлежность зоне, контролируемые направления, владельца и назначение. Названия «Дверь 3» и «Контроллер 7» оставьте в технической части; согласующему проще работать с обозначением «Склад — вход из зоны приёмки».

Из чего состоит рабочая матрица

Минимальная запись должна описывать не только разрешение, но и основание его выдачи. Иначе таблица превращается в каталог галочек, который никто не может пересмотреть.

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

Документированная модель и настройки программы должны иметь связь. Например, у группы есть стабильный внутренний код, а у её версии — дата утверждения. Если название в интерфейсе поменялось, код позволяет сопоставить настройку с согласованием без догадок.

Группа доступа не равна подразделению

Подразделение описывает организационную структуру. Группа доступа описывает потребность в посещении определённых зон. Иногда они совпадают, но это не универсальное правило: бухгалтер склада, кладовщик и руководитель логистики могут числиться в одном блоке и иметь разные маршруты.

Разумно начать с базовых ролей: офисный сотрудник, персонал склада, эксплуатация, принимающий посетителей. Затем проверить, не скрывается ли внутри роли несколько разных функций. Чем больше дополнительных исключений приходится назначать каждой записи, тем хуже базовая модель отражает работу предприятия.

Обратная крайность — создать отдельную группу на каждого человека. Тогда увольнение или перевод потребуют ручного разбора десятков уникальных наборов. Система технически продолжит работать, но управлять ею станет сложно.

Практический ориентир — выдавать права в объёме рабочей необходимости. Это соответствует принципу минимальных привилегий из глоссария NIST. Это инженерный подход, а не обязательная российская форма документа.

Спросите владельца зоны: какое действие сотрудник должен выполнить внутри и почему оно требует самостоятельного доступа? Ответ «иногда бывает нужно» лучше превратить во временную процедуру, а не в бессрочное разрешение.

Как согласовать время и дополнительные условия

Расписание допуска определяет, когда разрешён проход, а рабочий график — когда сотрудник работает. Сотруднику может требоваться время на путь от входа до рабочего места. Но расширенное окно доступа не означает, что весь этот интервал автоматически считается рабочим временем или разрешённой сверхурочной работой.

В матрице указывают дни недели, интервалы и календарные исключения, если они нужны. Для смен, переходящих через полночь, заранее проверяют, как конкретная СКУД интерпретирует границу суток. Отдельно рассматривают выходные, переносы графика и временные изменения. Нельзя предполагать, что календарь системы сам совпадёт с календарём организации.

Правило «только с сопровождающим» тоже требует уточнения. Кто вправе сопровождать, через какие точки, в каком направлении и как фиксируется подтверждение? Простая надпись в инструкции не создаёт соответствующий алгоритм в контроллере. Например, Sigur описывает отдельные сценарии сопровождения и совместного прохода двух лиц; это разные логики, а не взаимозаменяемые названия. Возможности конкретной версии проверяют по описанию производителя.

Избегайте формулировок, которые программа не может проверить. «По производственной необходимости» — основание для согласования, но не техническое условие. В настройках ему должны соответствовать конкретные точки, срок и способ подтверждения.

Индивидуальное исключение: отдельная запись с окончанием

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

Для исключения достаточно короткой карточки: получатель, дополнительные права, причина, начало, окончание, согласующий, исполнитель и подтверждение применения. Если неизвестно, когда закончится работа, устанавливают дату обязательного пересмотра. Бессрочное поле «до завершения проекта» плохо подходит для автоматического отзыва.

Условный пример: офисному сотруднику нужно два дня участвовать в пересчёте товаров. Ему не копируют профиль кладовщика целиком. Владелец склада определяет нужную зону, период и условие сопровождения. После завершения временное назначение прекращается; базовый офисный доступ сохраняется.

Продление оформляют новым решением или изменением записи с историей. Автоматически переносить окончание на следующий месяц только потому, что никто не пожаловался, не следует. Отсутствие инцидента не доказывает, что право всё ещё нужно.

Что делать с пересекающимися разрешениями и запретами

У человека может быть несколько групп и индивидуальных режимов. Важно узнать, как система вычисляет итог: объединяет разрешения, применяет приоритет уровня или использует другую логику. Универсального правила «запрет всегда сильнее разрешения» для всех СКУД нет.

В разделах 4.3.3–4.4 руководства администратора Sigur описаны основной и дополнительные уровни режимов, а также решение с учётом точки, времени, направления и дополнительных проверок. Поэтому проверяют итоговые права человека после применения всех правил, а не одну выбранную строку.

На этапе настройки полезна небольшая таблица конфликтов: два пересекающихся расписания, временное исключение поверх базовой группы, истёкшая дата, изменение подразделения. Для каждого случая заранее записывают ожидаемый результат. Затем проверяют его на тестовой записи с разрешения ответственного за объект.

Не исправляйте конфликт выдачей максимального профиля. Если человеку не открывается нужная дверь, нужно найти причину: неверную группу, направление, срок или недоставленное изменение. Расширение всех прав делает проблему менее заметной, но не устраняет её.

Кто согласует, кто настраивает, кто проверяет

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

Особое внимание нужно правам самих операторов СКУД. Возможность редактировать расписание, выпускать идентификаторы, выгружать журнал и назначать администраторов — разные полномочия. Матрица прохода не заменяет матрицу доступа к программе.

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

Как проверить настройку перед вводом

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

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

Испытания проводят в согласованное окно, не блокируя реальные рабочие процессы. Если контроллер не получил изменения, проверка считается незавершённой. Успешное сохранение в интерфейсе ещё не доказывает, что правило уже действует на нужной двери.

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

Аудит прав: смотрите не только на неиспользуемые карты

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

Право может редко использоваться и оставаться обоснованным, например для дежурного специалиста. И наоборот: регулярные проходы не доказывают законность назначения, если человек давно переведён в другое подразделение. Поэтому итог подтверждает владелец доступа, а не только алгоритм поиска неактивных карт.

Сначала удобно разбирать наиболее заметные отклонения: права без согласующего, истёкшие исключения, доступ к нескольким чувствительным зонам, технические учётные записи и назначения у бывших сотрудников. Далее — обычные группы. Частоту проверки организация выбирает по изменениям и рискам, с учётом применимых к объекту требований.

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

Пример: как разобрать одну спорную группу

Предположим, на условном объекте есть группа «Администрация», которая открывает офис, склад и техническую комнату круглосуточно. В неё включены руководитель, офис-менеджер и специалист эксплуатации. При пересмотре выясняется, что общее название объединило совершенно разные задачи.

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

В этом условном примере неопределённое «администрации положено всё» заменили объяснимыми назначениями. Реальные зоны и расписания утверждают ответственные за объект. Дополнительное разрешение должно иметь собственную причину, а не наследоваться от названия должности.

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

После изменения проверяют, не осталась ли старая группа у кого-то через дополнительное назначение. Затем её выводят из обычной выдачи, чтобы оператор не выбрал привычное название при оформлении следующей карты. Старую версию сохраняют в предусмотренной истории, а действующую модель помечают однозначно. Иначе формально выполненный аудит не предотвратит повторное появление той же проблемы.

Частые вопросы

Можно вести матрицу в Excel?

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

Нужно ли перечислять в матрице всех сотрудников?

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

Как оформлять срочное разрешение?

Через заранее установленный канал с проверкой согласующего, минимальным объёмом и окончанием срока. Срочность может сократить маршрут обработки, но не отменяет фиксацию основания и результата.

Поможет ли матрица при передаче чужой карты?

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

Хорошая матрица позволяет объяснить любое действующее разрешение одной короткой цепочкой: рабочая задача, владелец зоны, правило, срок, проверка. Если цепочка обрывается, нужно уточнить назначение, а не добавлять ещё одну бессрочную галочку.