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

С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 69 Ошибка 5. Считать отправленный запрос выполненным 1С может отправить сообщение об увольнении, но СКУД его не обработает из-за сбоя связи или внутренней ошибки. Для кадровой системы операция уже завершена, а карта сотрудника остается активной. Поэтому контроль обмена нельзя заканчивать на статусе "отправлено". Для критичных изменений нужна полная цепоч- ка: событие создано ➝ передано ➝ приня- то обработано ➝ результат зафиксирован . Ошибки должны попадать в журнал и к ответ- ственному сотруднику. После восстановления связи сообщение нужно передать повторно без дублей и потери последовательности операций. Полезна и периодическая сверка состояний. Она позволяет найти расхождение, даже если транспортный уровень интеграции не зафик- сировал ошибку: например, сотрудник уво- лен в 1С, но его профиль в СКУД все еще активен. Ошибка 6. Тестировать интеграцию только на небольшой выборке Обмен может стабильно работать на тестовой базе из нескольких десятков сотрудников и дать сбой при массовых изменениях данных. Пиковая нагрузка возникает при массовом приеме, реорганизации, подключении новой площадки или восстановлении обмена после простоя. В очередь одновременно попадают изменения сотрудников, прав и другие дан- ные. При нагрузочном тестировании важно прове- рять не только скорость. Нужно убедиться, что сообщения не теряются, зависимые операции выполняются в правильном порядке, повторы не создают дубли, а необработанные записи можно быстро найти. Для службы безопасности ключевой критерий прост: критичное изменение доступа должно выполняться и при пиковом объеме обмена. Ошибка 7. Оставлять критичные изменения доступа в ручном режиме Часто критичное кадровое событие не сразу отражается в СКУД. Например, сотрудник уже уволен, подрядчик завершил работу, срок пре- доставления повышенных прав доступа закон- чился, но идентификатор в СКУД остается активным или с расширенным набором прав. Причина обычно одна – изменение статуса передают вручную: письмом, заявкой или через ответственного сотрудника. Пока информация проходит по этой цепочке, между кадровой системой и службой безопасности возникает разрыв. Для таких событий нужен автоматический триг- гер. Например, при приеме сотрудника форми- руется учетная запись, а при его увольнении блокируется. Однако важно, чтобы служба безопасности сохраняла контроль над исключениями и спе- циальными случаями. Автоматизация здесь отвечает не за политику доступа, а за то, чтобы критичное изменение статуса вовремя дошло до СКУД. Ошибка 8. Не пересматривать права доступа при изменении роли сотрудника Активная учетная запись еще не означает, что набор прав остается актуальным. Сотрудник может перейти в другое подразделение, сме- нить должность, площадку или функциональ- ную роль. Если старые права не пересмотреть, человек остается с избыточными доступами или, наоборот, не получает необходимые. Эта задача отличается от блокировки учетной записи. Сотрудник продолжает работать, поэто- му его идентификатор остается активным. Меняется только состав разрешений. Типовые права можно связать с должностью, подразделением, площадкой или другой фор- мализованной ролью. Кадровая или учетная система передает изменение, а СКУД применяет предусмотренный набор правил. Но сами правила, их связь с должностью или ролью должна определять служба безопасно- сти, с жестким ограничением доступа на изме- нение этих данных и обязательно с журналиро- ванием изменений. Доступ в режимные зоны, временные расширения и исключения нельзя автоматически выводить только из кадровых данных. Ошибка 9. Интерпретировать события СКУД без контекста СКУД фиксирует факт: сотрудник использовал идентификатор в определенной точке и в определенное время. Этого достаточно для контроля проходов, но не для вывода о рабо- чем времени. Поздний вход не всегда означает опоздание, равно как и поздний выход – переработку. У сотрудника мог измениться график, быть оформлена командировка или другое отсут- ствие. Поэтому события СКУД нужно сопостав- лять с кадровым контекстом там, где решаются задачи учета рабочего времени. Граница здесь достаточно четкая: СКУД хранит факты доступа, кадровая система – графики, статусы и оформленные отклонения. Это разделение защищает и сам контур без- опасности от лишней бизнес-логики. СКУД не приходится превращать в кадровую систему, а кадровой системе – принимать решения о физическом проходе через точку доступа. Ошибка 10. Не развивать проект после запуска в промышленную эксплуатацию Интеграция продолжает меняться вместе с системами. Обновляется 1С, производитель СКУД выпускает новые версии, подключаются площадки, меняется оргструктура и политика доступа, появляются новые задачи бизнеса. Поэтому после запуска нужен владелец интег- рационного контура и понятный порядок сопро- вождения. Нужно заранее определить: l кто контролирует обмен; l кто получает уведомления об ошибках; l кто разбирает сбои; l как проверяются обновления; l кто отвечает за критичные инциденты; l как контролируются сроки восстановления; l кто отвечает за развитие. Отдельно стоит периодически проверять биз- нес-логику. Интеграция может работать техни- чески исправно, но применять правила, кото- рые компания уже изменила. Что в итоге нужно контролировать Интеграцию СКУД и 1С стоит оценивать по состоянию доступа, а не по количеству успешно переданных записей. Для службы безопасности важны несколько признаков: увольнение своевременно меняет доступ, перевод не оставляет лишних прав, ошибки обмена видны, состояние систем можно сверить, а историю изменений – восстановить. Для этого у каждой системы должна быть четкая роль. Кадровая система передает кадровое событие. СКУД управляет физическим досту- пом. Интеграция гарантирует передачу и конт- роль результата. Служба безопасности опреде- ляет правила и исключения. Кадры используют данные СКУД для учета рабочего времени и контроля трудовой дисциплины. Тогда кадровые изменения не зависят от цепоч- ки писем и ручных исправлений, а состояние доступа остается управляемым на всем жизнен- ном цикле сотрудника. n Иллюстрации компании Programming Store. www.secuteck.ru август – сентябрь 2026 СПЕЦПРОЕКТ СИСТЕМЫ УЧЕТА РАБОЧЕГО ВРЕМЕНИ Как график работы меняет смысл событий СКУД Ваше мнение и вопросы по статье направляйте на ss @groteck.ru