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

С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 68 Р азберем 10 частых ошибок при настройке обмена и принципы, которые помогут их избежать. Ошибка 1. Заниматься интеграцией после запуска СКУД Компания сначала внедряет СКУД, заносит карточ- ки сотрудников, выдает карты и выстраивает рабо- ту бюро пропусков. Об интеграции с кадровой системой учета 1С задумываются сильно позже. К этому времени обе системы уже содержат собственные справочники. Сотрудников вводят дважды, изменения передают заявками, как правило это ведет к сильному расхождению данных и требует ручных сверок при любой задаче сопоставления данных из СКУД, напри- мер уточнения данных по событиям прохода сотрудников и плановых графиков работы. Интеграция такого контура требует сначала разобраться с накопленными расхождениями: сопоставить сотрудников и идентификаторы, определить актуальный источник данных, решить, что делать с дублями и устаревшими учетными записями. Поэтому обмен лучше проектировать вместе с внедрением или модернизацией СКУД. До запуска стоит описать карту интеграции и опре- делить потоки данных: прием, перевод, изме- нение данных, работу подрядчиков, временные права и поведение системы при увольнении сотрудников либо расторжении договоров. Для каждого события нужно определить источник, действие в СКУД и ответственного за разбор исключений. Ошибка 2. Не определить, какая система за что отвечает Проблемы быстро появляются, если одни и те же данные можно менять одновременно в СКУД и 1С. Возникают две версии профиля сотрудника, разные статусы и непонятный приоритет при конфликте. До разработки интеграции нужно распределить ответственность за данные. Если кадровые процессы ведутся в 1С, модель может выглядеть так: l 1С – сотрудник, должность, подразделение, кадровый статус и кадровые события; l СКУД – идентификаторы, зоны и правила физического доступа, события проходов; l интеграция – передача изменений, контроль обработки и журнал ошибок; l служба безопасности – политика доступа, специальные права и исключения; l ИТ-отдел – мониторинг интеграции, отслежи- вание работы и исправление конфликтов интеграции. Такая схема сразу отвечает на два вопроса: где должен появиться исходный факт и какая систе- ма должна выполнить действие? Например, увольнение возникает в кадровой системе. СКУД получает этот факт и меняет состояние доступа. Система отправляет уведом- ление ответственным за СКУД информацию о совершенных действиях. Ошибка 3. Выбирать технологию до описания процессов Интеграцию можно разработать самостоятель- но, построить на инструментах и готовых моду- лях вендора СКУД или использовать отдельный интеграционный слой. Выбирать подход только по цене и сроку первого запуска рискованно. Сначала нужно понять нагрузку и сценарии: 1. Сколько сотрудников и площадок участвует в обмене? 2. Есть ли подрядчики? 3. Сколько кадровых изменений происходит ежедневно? 4. Какая задержка допустима для блокировки доступа? 5. Что происходит при недоступности одной из систем? 6. Нужно ли хранить историю изменений? Как будет подключаться новая СКУД? Ответы определяют архитектуру лучше, чем сравнение функций отдельных решений. Важно учитывать и развитие системы. Решение, рассчитанное на один объект и одну СКУД, может потребовать полной переработки при расширении инфраструктуры. Ошибка 4. Записывать данные напрямую в базу СКУД Прямая работа с базой кажется простым спосо- бом интеграции: известна таблица – можно сразу изменить нужное поле. Проблема в том, что база данных хранит состояние системы, но не описывает всю логику работы с ней. При штатной операции СКУД может выполнять дополнительные проверки, обновлять связанные объекты и вести собствен- ный журнал изменений. Прямая запись способ- на сломать эти механизмы. Есть и второй риск: производитель обновляет структуру базы и интеграция перестает рабо- тать или начинает изменять данные некор- ректно. Поэтому для обмена лучше использовать офи- циально поддерживаемые интерфейсы про- изводителя: REST или SOAP API, SDK и другие предусмотренные сервисы. Для высоконагруженных систем рекомендуется использовать шины данных с гарантированной доставкой сообщений и балансировкой нагруз- ки между узлами, которые участвуют в обмене. Для критичных операций важно фиксировать результат: что отправили, что приняла СКУД, выполнила ли она изменение и какую ошибку вернула. август – сентябрь 2026 www.secuteck.ru СПЕЦПРОЕКТ СИСТЕМЫ УЧЕТА РАБОЧЕГО ВРЕМЕНИ Игорь Уласевич Менеджер продукта PROSTO:СКУД компании Programming Store Отправленное изменение ≠ измененный доступ Интеграция СКУД и 1С: 10 ошибок, которые создают риски для безопасности Интеграция СКУД и 1С связывает кадровые события с организацией доступа, а также преобразует отметки сотрудников в СКУД в легитимную базу для контроля дисцип- лины и учета рабочего времени. Если этой связки нет или она настроена некорректно, в периметре безопасности появляются уязвимости (например, активные пропуски у уволенных), а рутина кадровиков кратно растет.