Автоматизированные системы контроля и управления доступом (СКУД) в современных режимных учреждениях призваны обеспечивать высокий уровень безопасности, оперативности пропускного режима и защиты информации. ФКУ «Центр инженерно‑технического обеспечения и вооружения Управления ФСИН России по ХМАО–Югре» (далее – Центр) в силу специфики своей деятельности предъявляет особо жёсткие требования к надежности и отказоустойчивости технологических и программных решений, используемых в СКУД. Внедрение и совершенствование таких систем позволяет снизить риск несанкционированного доступа, автоматизировать рутинные процедуры пропуска и минимизировать человеческий фактор при эксплуатации режимного оборудования.
Актуальность темы обусловлена:
Рост требований ФСИН и ФСТЭК к уровню информационной и физической безопасности, а также ужесточение режимных регламентов требует постоянного обновления и адаптации СКУД на объектах исполнения наказаний;
Наличием на предприятии устаревших или частично централизованных систем «Стилпост» обуславливает необходимость анализа их текущего состояния и разработки предложений по модернизации;
Практическая значимость заключается в снижении эксплуатационных рисков, повышении эффективности работы пропускных пунктов и обеспечении соответствия системы действующим нормативам.
Объект исследования – автоматизированная система контроля и управления доступом на базе «Стилпост», установленная в ФКУ «ЦИТОВ УФСИН России по ХМАО–Югре».
Предмет исследования – методы и средства анализа, модернизации и интеграции программно‑аппаратных компонентов СКУД «Стилпост» с учётом требований режимного учреждения ФСИН.
Цель работы – разработка комплекса рекомендаций и технических решений по развитию и совершенствованию АС КУД «Стилпост» в режиме́ном предприятии ФКУ «ЦИТОВ УФСИН России по ХМАО–Югре» для повышения уровня безопасности, отказоустойчивости и оперативности пропускного режима.
Задачи работы:
Провести обзор нормативно‑правовой базы и регламентов ФСИН, ФСТЭК и ФЗ‑152 в части требований к СКУД;
Проанализировать текущую конфигурацию и бизнес‑процессы СКУД «Стилпост» (аппаратная архитектура, ПО, процедуры выдачи и изъятия пропусков, учёт посетителей);
Выявить узкие места, ограничения и потенциальные риски существующей системы;
Сформулировать технические и организационные требования к модернизации СКУД;
Разработать предложения по оптимизации структуры точек доступа, расширению функциональности ПО и интеграции с другими системами безопасности;
Оценить затраты на реализацию предложенных мероприятий и рассчитать экономическую эффективность проекта (CAPEX, OPEX, срок окупаемости);
Разработать рекомендации по обеспечению информационной безопасности и созданию организационно‑распорядительной документации для операторов системы.
В работе применяются методы системного и сравнительного анализа, функционально‑стоимостного анализа, проектных расчётов, моделирования и экспериментального тестирования, а также процедуры статистической обработки результатов испытаний.
Основными источниками служат:
нормативные акты (ФЗ‑152, руководящие документы ФСТЭК, ведомственные приказы ФСИН),
техническая документация и отчёты Центра,
результаты экспериментов и исследований, выполненных в рамках ВКР,
сведения от разработчика ПО «Стилпост» и данные производителей оборудования.
Работа состоит из четырёх основных разделов, заключения и списка использованных источников.
Раздел 1 рассматривает общую характеристику объекта исследования, режимные требования и обоснование выбора СКУД «Стилпост».
Раздел 2 описывает организационно‑технологическую часть: анализ текущего состояния, выявление недостатков и разработку технических предложений.
Раздел 3 посвящён безопасности решений проекта: соответствию ИБ‑требованиям, анализу угроз и мерам защиты.
Раздел 4 содержит экономический анализ: оценку затрат, расчёт эффективности и окупаемости модернизации.
В заключении подводятся основные итоги и формулируются рекомендации по внедрению разработанных решений.
Список использованных источников включает нормативные документы, научные публикации и технические материалы, применённые при подготовке работы.
ОБЩАЯ ХАРАКТЕРИСТИКА ОБЪЕКТА
Наименование, структура, основные функции и назначение ФКУ «ЦИТОВ УФСИН России по ХМАО – Югра».
Полное наименование учреждения – федеральное казённое учреждение «Центр инженерно‑технического обеспечения и вооружения Управления Федеральной службы исполнения наказаний России по Ханты‑Мансийскому автономному округу – Югра» (сокращенно – ФКУ «ЦИТОВ УФСИН России по ХМАО – Югра», далее в тексте - Центр) [1].
Историческая справка о Центре приведена ниже (рисунок 1):
Рисунок 1 – Историческая справка в контексте темы ВКР
Учреждение входит в состав Управления ФСИН России по Ханты‑Мансийскому АО – Югра и является одним из десяти подведомственных учреждений регионального управления. Структура (рисунок 2) Центра утверждена Приказом ФСИН России от 16 июля 2021 г. № 618 «Об утверждении типовых структур и типовых штатных расписаний центров инженерно‑технического обеспечения и вооружения, подведомственных территориальным органам Федеральной службы исполнения наказаний», и включает следующие подразделения [3]:
Руководство;
Канцелярия;
Группа по защите государственной тайны;
Бухгалтерия;
Юридическая служба;
Отдел (отделение) инженерно‑технических средств охраны и надзора;
Группа технических средств пожарной сигнализации;
Рисунок 2 – Организационная структура ЦИТОВ
Отделение ремонта вооружения и специальных средств;
Отдел (отделение) телекоммуникационных и информационных систем;
Отдел (отделение) организации и обеспечения связи;
Отдел межрегионального ремонта;
Отдел (отделение) материально‑технического обеспечения;
Отдел (отделение, группа) информационно‑архивной работы.
Основные функции центра:
Обеспечение монтажом, техническим обслуживанием и ремонтом инженерно‑защитных систем (в том числе СКУД, ОКС, пожарная сигнализация);
Организация и сопровождение защищённых каналов связи, видеомониторинга и информационных систем;
Централизованное хранение и учёт табельного оружия, боеприпасов и специальных средств;
Разработка методических и нормативных документов по эксплуатации инженерно‑технических систем;
Подготовка, аттестация и методическое сопровождение технического персонала.
Центр создан для обеспечения режимных исправительных и следственных учреждений Ханты‑Мансийского автономного округа – Югра комплексом инженерно‑технических, коммуникационных и прочих средств, необходимых для:
эффективного контроля и управления доступом;
поддержания безотказной работы инженерных систем безопасности;
своевременного технического обслуживания и оперативного ремонта оборудования;
единого учёта и контроля табельного оружия и боеприпасов.
Режимные требования и особенности объекта как учреждения ФСИН
Ниже предложена таблица нормативной базы, устанавливающей режимные требования (табл. 1):
Таблица 1
Таблица нормативной базы
Далее приведенные требования рассматриваются подробнее.
Категория важности объекта
Согласно Постановлению Правительства Российской Федерации от 11 апреля 2023 г. № 586 «Об утверждении требований к антитеррористической защищенности объектов (территорий) уголовно-исполнительной системы Российской Федерации, форм паспортов безопасности объектов (территорий) уголовно-исполнительной системы Российской Федерации и признании утратившими силу некоторых актов Правительства Российской Федерации» все режимные учреждения (ИК, СИЗО, ЦИТОВ и пр.) относятся к категориям 1–2 (наиболее высокая значимость) [4]. Для объектов категории 1 обязательны:
вооружённая охрана и организационно‑практические мероприятия (досмотр, служебные собаки, контроль территорий);
комплекс инженерно‑технических средств (контроль доступа, охранное освещение, видеонаблюдение, охранно‑пожарная сигнализация).
Требования к защите информации
Персональные данные и сведения с ограниченным доступом обрабатываются в специально выделенных помещениях. По Приказу ФСИН России от 23.06.2020 № 417:
помещения ПДн должны быть запираемыми, исключать доступ посторонних;
обязательно закрытие окон, шкафов и сейфов при отсутствии операторов;
по окончании рабочего времени – удаление носителей ПДн в металлические шкафы, отключение ПК и освещения [5].
Сетевой доступ и выход в интернет регулируется Приказом ФСИН России от 13.02.2007 № 77:
только служебные ПК, не обрабатывающие засекреченные сведения, могут подключаться к Интернету;
все доступы и трафик контролируются администратором ОИУ;
запрещено использовать личные почтовые сервисы и переносить файлы без антивирусной проверки [6].
Контрольно‑пропускной режим
Многоуровневая сеть КПП – въездные и пешеходные пункты оборудуются автоматическими турникетами, досмотровыми рамками и собаками для поиска запрещённых предметов.
Дозор и патрулирование – регулярный обход периметра службой караула с применением технических средств досмотра и видеонаблюдения.
Журналирование и аварийное оповещение – все события доступа фиксируются в электронных журналах, предусмотрена кнопка «Тревога» и интеграция с охранно‑пожарной сигнализацией.
Использование служебных собак обязательно на КПП и при патрулировании «запретной зоны» [4].
Таким образом, режимные требования ФСИН объединяют нормативы антитеррористической защищённости (категория объекта), строгие процедуры информационной безопасности (ПДн и Интернет) и комплекс технических средств контроля доступа и охраны территории.
Общая характеристика существующей системы обеспечения физической и информационной безопасности объекта (роль СКУД в комплексе)
Система безопасности ФКУ «ЦИТОВ УФСИН по ХМАО–Югре» построена по принципам комплексной физической защиты (СФЗ), включающей в себя как инженерно‑технические средства охраны (ИТСО), так и организационные меры и ИТ‑инфраструктуру (рисунок 3). Основные подсистемы СФЗ представлены ниже:
Система контроля и управления доступом (СКУД);
Система охранной сигнализации (СОС);
Система телевизионного наблюдения (СТН);
Система пожарной сигнализации (СПС);
Рисунок 3 – Компонентная диаграмма СФЗ ФКУ «ЦИТОВ УФСИН Югры»
Система оперативной связи и оповещения (ССОИ);
Обеспечивающие системы (электроснабжение, освещение, противопожарное освещение и резервирование) [7].
Каждая из подсистем интегрирована между собой через ЦПУ (центральный пункт управления) с возможностью централизованного мониторинга и управления в реальном времени.
Физическая безопасность и её подсистемы
СКУД на базе «Стилпост» – комплекс контроллеров доступа, автономных и сетевых считывателей, турникетов и шлюзовых кабин, предназначенный для автоматического контроля прихода/ухода персонала и посетителей, а также управления инженерными барьерами (двери, ворота, ворота, КПП) [11].
СОС обеспечивает своевременное обнаружение попыток несанкционированного проникновения и формирует тревожные сигналы на ЦПУ, а также реализует автоматическую постановку/снятие охраны в зависимости от событий СКУД.
СТН – сеть IP‑камер с функцией хранения видеоархива в централизованной Системе Видеонаблюдения, интегрированная с СКУД для «фотоверификации» и автоматической фиксации лиц, прошедших по пропускам.
СПС контролирует состояние пожарных извещателей и в экстренных ситуациях разблокирует эвакуационные выходы, взаимодействуя со шлюзами СКУД.
ССОИ (средства сбора и обработки информации) собирают тревожные, охранные и пожарные сигналы, обрабатывают их и передают на ЦПУ, где происходит анализ и распределение реагирования служб охраны.
Информационная безопасность
Сетевой сегмент СКУД физически изолирован от офисной сети и интернета, что исключает возможность удалённого несанкционированного доступа к критическим контроллерам и базе данных.
Шифрование каналов передачи между точками прохода и сервером СКУД осуществляется по протоколу TLS, соответствует требованиям ФСТЭК России по защите персональных данных.
Журналирование событий в базе данных ведётся в режиме реального времени с использованием РСУБД, поддерживающей неизменяемые логи, что обеспечивает полноту аудита и позволяет проводить расследования инцидентов.
Управление привилегиями организовано по принципу «минимальных прав»: каждый пользователь получает доступ только к тем функциям СКУД, которые необходимы для его должностных обязанностей [11].
Роль СКУД в системе безопасности объекта
Первичная фильтрация доступа – СКУД «Стилпост» обеспечивает базовый контроль всех точек входа-выхода, выступая «первым рубежом» физической защиты.
Интеграция с другими подсистемами:
при срабатывании СОС автоматически блокируется доступ через соответствующие точки прохода;
при пожарной тревоге СКУД разблокирует все эвакуационные выходы;
при подозрительных событиях системой видеонаблюдения запускается ретроспективная запись камер, в то время как СКУД фиксирует факт несанкционированного попытка прохода.
Управление рабочим временем – на основе данных СКУД формируются отчёты по рабочему времени сотрудников и посетителей.
Аналитика и отчётность – СКУД формирует статистические отчёты по посещаемости, времени отклика, отказам оборудования и потенциальным угрозам, что позволяет руководству оперативно корректировать меры безопасности [11].
Таким образом, СКУД «Стилпост» выступает ядром комплекса инженерно‑технических средств безопасности, обеспечивая как физический контроль доступа, так и тесную интеграцию с охранной сигнализацией, видеонаблюдением и системами оповещения.
Обоснование выбора СКУД «Стилпост» как базовой системы для исследования и развития
Факт установки и эксплуатация
В ФКУ «ЦИТОВ УФСИН России по ХМАО–Югре» в качестве основного решения для контроля и управления доступом применяется СКУД «Стилпост».
Рисунок 4 – Аппаратные части СКУД на базе «Стилпост»
Программный модуль «Бюро пропусков (SYN‑BP)» на базе «Стилпост» интегрирован в состав комплексной системы обеспечения безопасности «Синергет КСБО», эксплуатируемой Центром для регистрации сотрудников, посетителей и транспортных средств [8].
Аппаратная часть «Стилпост» включает сетевые контроллеры STS‑407 К, считыватели карт STS‑705 и шлюзовые турникеты (рисунок 4), что соответствует типовой конфигурации крупных режимных объектов ФСИН.
Соответствие требованиям ФСИН
Система «Стилпост» полностью удовлетворяет режимным и организационно‑технологическим требованиям, установленным для учреждений ФСИН:
Приказ ФСИН России № 618 (16.07.2021) об утверждении типовых структур и штатных расписаний центров инженерно‑технического обеспечения предписывает наличие СКУД с возможностью разграничения доступа по зонам и учёта пропускного режима на уровне подразделений Центра [3].
СКУД «Стилпост» поддерживает гибкое определение правильных режимов доступа (антипасс‑бэк, временные «окна» доступа, разовые пропуска), что обеспечивает исполнение служебных регламентов и процедур выдачи/изъятия пропусков.
Интеграция с подсистемами охранной и пожарной сигнализации, видеонаблюдения и оперативной связи реализована «из коробки» и соответствует требованиям комплексной физической защиты объектов ФСИН [11].
Сертификация ФСТЭК
Для применения в режимных и государственных учреждениях критически важно, чтобы СКУД была сертифицирована органами ФСТЭК.
Компания‑разработчик «Стилсофт» имеет Лицензию ФСТЭК России № 3235 (от 20.03.2015) на проведение мероприятий по технической защите информации, включая аттестацию автоматизированных систем различного уровня и назначения [9].
Дополнительно «Стилсофт» обладает Лицензией ФСТЭК РФ № 0972 на техническую защиту конфиденциальной информации (действует бессрочно), что подтверждает полноту соответствия «Стилпост» требованиям по защите ПДн и гостайны [10].
Таким образом, «Стилпост» выбран как базовое решение ввиду его доказанной надёжности в режиме централизованного управления доступом, формального признания в нормативно‑правовой базе ФСИН и наличия необходимых сертификатов ФСТЭК для эксплуатации в государственных учреждениях высокого уровня секретности.
ОРГАНИЗАЦИОННО-ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ
Анализ текущего состояния АС КУД на базе «Стилпост»
В ФКУ «ЦИТОВ УФСИН по ХМАО–Югре» внедрена распределённая трёхзвенная сетевая архитектура СКУД «Стилпост-Стандарт», построенная по принципу «центр–контроллер–считыватель». Это обеспечивает высокую отказоустойчивость и масштабируемость системы при объединении сотен контроллеров и тысяч считывателей в единое решение [12].
Архитектура системы
Система в текущее время включает в себя (см. приложение 1):
Уровень серверов. В основе системы лежит Центральный сервер «Стилпост», который выполняет три основных функции:
Хранение и управление данными. Реляционная СУБД PostgreSQL (или MS SQL Server по выбору заказчика) со схемой, обеспечивающей нормализацию данных, индексацию по RFID‑идентификаторам и журналирование всех событий доступа. Разделение оперативных и архивных данных: горячие таблицы для текущих запросов, холодные – для исторических отчётов;
Бизнес‑логика и обработка событий. Сервис «Сообщений» обрабатывает и маршрутизирует пакеты событий от контроллеров, применяет правила доступа (антипасс‑бэк, временные окна, бан‑лист) и генерирует команды открытия/закрытия устройств. Сервис «Аналитики» агрегирует статистику, формирует отчёты и оповещения (включая аварийные сценарии);
Интерфейс для операторов и администраторов. Веб‑приложение на базе ASP.NET Core или Java Spring Boot с адаптивным пользовательским интерфейсом (React‑компоненты) для управления пользователями, настройками контроллеров и визуализации схем точек прохода. Поддержка одновременной работы до 10 операторов без деградации производительности.
Для повышения надёжности серверы объединяются в кластер под управлением Kubernetes или Windows Failover Clustering, с репликацией БД и круглосуточным мониторингом через Zabbix или ELK‑stack .
Уровень контроллеров доступа. Сетевые контроллеры STS‑407К с резервным блоком питания АКБ‑7т являются «мозгом» локальных точек прохода [15]:
Аппаратная платформа – двухъядерный ARM‑процессор 1 ГГц, 512 МБ RAM, 4 ГБ флеш‑памяти;
Интерфейсы – Ethernet 10/100 Мбит/с, RS‑485 для шлейфов сигнализации, 2 выхода «сухой контакт» для электрозамков или турникета, 1 вход «сухой контакт» для сигнала тревоги;
Автономный режим – при потере связи с сервером контроллер продолжает выполнять сценарии на основе «локальной» таблицы доступа (до 5 000 карточек) и буферизует события для последующей передачи;
Управление питанием – встроенный ИБП (АКБ‑7т) обеспечивает до 8 часов работы контроллера и считывателей при отключении внешнего питания.
Контроллеры могут быть объединены в избыточные группы по протоколу LACP для защиты от падения отдельного канала связи.
Уровень считывателей и устройств ограничения доступа. На этом уровне расположены проксимити‑считыватели STS‑705 и шлюзовые турникеты [14]:
STS‑705 (EM‑Marin), имеющий антивандальный металлический корпус, степень защиты IP65; диапазон чтения 4–7 см, интерфейс Wiegand 26–42 или Clock‑Data, питание 7,5–13,8 В; встроенный звук и подсветка для визуального и акустического подтверждения статуса доступа;
Шлюзовые турникеты – электромеханические триподы или четырёххватные модели, встроенные индикаторы направления прохода и счётчики. Подключаются напрямую к контроллеру STS‑407К через «сухие контакты».
Все устройства соединяются с контроллерами по Ethernet через PoE‑коммутаторы, что упрощает прокладку кабелей и централизует резервирование питания.
Рисунок 5 – Архитектура АС КУД КАК ЕСТЬ
Преимущества трёхзвенной модели:
Отказоустойчивость – автономный режим контроллеров исключает время простоя при сбоях сети или сервера;
Масштабируемость – добавление новых точек прохода сводится к установке контроллера и считывателя, без изменения серверного ПО;
Централизованное управление – обновление конфигурации, прошивок и политик безопасности выполняется из единого интерфейса администратора.
Состав и характеристика оборудования
В рамках АС КУД «Стилпост» на объекте используются четыре основных вида оборудования. Каждый тип устройств выполняет свою роль в обеспечении контроля доступа и надёжности системы в целом (табл. 2).
Контроллер доступа STS‑407К. Сетевой контроллер STS‑407К является узловым элементом системы, принимающим решения об открытии/закрытии устройств ограничения доступа и обеспечивающим связь между сервером и периферией. Важнейшие характеристики:
Резервное питание – встроенный аккумулятор АКБ‑7т обеспечивает до 8 часов автономной работы при пропадании внешнего питания;
Интерфейсы – Ethernet 10/100 Мбит/с для обмена с сервером, RS‑485 для подключения дополнительных датчиков;
Управление устройствами – до двух электрозамков или одного турникета через «сухие» контакты;
Автономность – локальная база до 5 000 идентификаторов и буферизация событий при потере соединения с сервером, с последующей передачей в очередь сообщений.
Проксимити‑считыватель STS‑705. Считыватели STS‑705 устанавливаются в зоне прохода и предназначены для бесконтактного опознавания носителей (карточек, брелоков). Ключевые параметры:
Тип носителей – EM‑Marin, дальность чтения 4–7 см;
Интерфейс подключения Wiegand 26–42 либо Clock‑Data, что обеспечивает совместимость с большинством контроллеров;
Корпус ударопрочный, степень защиты IP65, имеет встроенную индикаторную подсветку и звуковой модуль для обратной связи пользователю .
Ограничивающие устройства (турникеты). На объекте применяются электромеханические турникеты различных конфигураций (триподы и четырёххватные модели) с интеграцией в систему «Стилпост»:
Турникеты получают команду «проход/запрет» по «сухим» контактам от контроллера STS‑407К;
Встроенные датчики положения и фотореле позволяют фиксировать факт прохождения и передавать событие на контроллер;
Механическая конструкция рассчитана на 1 000 000 циклов безотказной работы.
Точные модели турникетов подбираются по техзаданию Центра и поставляются по контракту с монтажной организацией .
Средства резервирования и связи. Для обеспечения непрерывной работы и обмена данными система оснащена:
PoE‑коммутаторами для питания считывателей и контроллеров по Ethernet‑кабелю;
ИБП для центрального сервера и ключевых контроллеров, гарантирующими минимум 30 минут автономии при отключении сети;
Дублирующие каналы связи (основной – по кабелю Ethernet, резервный – по радиорелейным линиям) для обеспечения отказоустойчивости канала «контроллер–сервер».
Таблица 2
Состав и характеристики оборудования АС КУД «Стилпост»
Анализ программного обеспечения
АС КУД «Стилпост» на объекте ФКУ «ЦИТОВ УФСИН по ХМАО–Югре» работает на специальном программном обеспечении «Стилпост». Программное обеспечение устанавливается на центральный сервер и на рабочие места операторов (АРМ «Стилпост») и состоит из нескольких ключевых модулей, обеспечивающих полный цикл управления доступом, регистрации событий и интеграцию с периферийными устройствами:
«Бюро пропусков». Модуль предназначен для учёта и оформления пропусков сотрудников, посетителей и транспортных средств. Он обеспечивает:
Создание и хранение карточек субъектов доступа с персональными данными и фотографией;
Настройку типов пропусков (постоянный, временный, разовый) и графиков доступа по времени суток и дням недели;
Формирование и распечатку бумажных пропусков через встроенный фоторедактор;
Импорт/экспорт данных о субъектах доступа в форматах XML и CSV для обмена с другими системами [8].
«Администратор системы». Этот модуль служит для настройки логики работы системы:
Конфигурирование контроллеров и считывателей (группировка по зонам, IP‑адресация);
Определение правил доступа: антипасс‑бэк, разрешённые временные «окна», многоэтапная авторизация (карта + ПИН);
Настройка аварийных сценариев («тревожный» режим, разблокировка при пожаре);
Управление уровнями привилегий и ролями операторов согласно принципу минимальных прав.
«Журналы событий». Модуль отвечает за хранение неизменяемых записей всех событий доступа, попыток несанкционированного прохода, ошибок оборудования и аварийных ситуаций. Записи ведутся в СУБД с жёсткой защитой от модификации и поддержкой функций архивации и поиска по фильтрам (участник, точка доступа, время).
В составе «Стилпост» ключевую роль играют три основных фоновых сервиса, обеспечивающих обмен данными, мониторинг устройств и поддержку биометрии [11]:
Сервис сообщений. Отвечает за надёжную двунаправленную передачу команд и статусов между центральным сервером и контроллерами STS‑407К:
Транспортный уровень. Протокол TCP/IP с подтверждением доставки (ACK/NACK) и повторной отправкой при отсутствии подтверждения. Параллельные каналы связи (основной – Ethernet, резервный – радиорелейный) для повышения отказоустойчивости;
Очередь сообщений. Встроенный брокер сообщений (RabbitMQ или ZeroMQ) хранит и повторно пытается доставить недоставленные пакеты при восстановлении связи. Каждое событие (открытие/закрытие, тревога, проверка связи) логируется в очередь до фактической отправки контроллеру;
Контроль целостности – SHA‑256 хеширование полезной нагрузки, Версионирование протокола с обратной совместимостью.
Сервис устройств. Отслеживает состояние периферийных модулей СКУД в реальном времени и формирует оповещения при любых отклонениях:
Периодически критериев. Каждые 30 сек контроллеры и считыватели отсылают служебные пакеты, содержащие информацию о температуре платы, напряжении питания и состоянии связи;
Анализатор отказов. При пропуске трёх периодических критериев подряд генерируется аварийное событие «Контроллер недоступен». При регистрации аномального напряжения или ошибок CRC в данных – «Сбой коммутации»;
Интеграция с ЦПУ. Все аварийные и предупреждающие события транслируются на центральный пункт управления и видны на дашборде оператора с возможностью эскалации на SMS/Email.
Сервис обучения. Обеспечивает работу биометрических модулей при их наличии (опция):
Управление шаблонами. Загрузка, хранение и удаление отпечатков пальцев и 2D‑сканов лиц. Связывание шаблона с учётной записью субъекта доступа;
Процедура калибровки. Интерактивный мастер калибровки сенсоров, включающий проверку качества снимка, повторные попытки и отчёт о соответствии стандартам FVC (Fingerprint Verification Competition);
Интерфейс API. REST‑конечные точки для загрузки/выгрузки шаблонов и управления биометрическими устройствами.
Для защиты служебного трафика и соответствия требованиям ФСТЭК Россия по защите ПДн и гостайны:
TLS 1.2/1.3 на всех каналах HTTPS с использованием сертификатов X.509 и симметричным шифрованием AES‑256;
Взаимная аутентификация (mTLS) – как сервер, так и контроллеры проверяют сертификаты друг друга;
Регулярная ротация ключей и автоматизированная публикация CRL и OCSP‑запросов;
Журналирование сессий – все TLS‑сессии заносятся в защищённый лог для последующего аудита.
Организация точек прохода и зон доступа
Для обеспечения чёткого разграничения потоков и соблюдения режимных требований в ФКУ «ЦИТОВ УФСИН по ХМАО–Югре» АС КУД «Стилпост» разделяет объект на три типа точек прохода, объединённых в логические зоны доступа:
Въездной КПП. Назначение – контроль автотранспорта и крупногабаритных средств вспомогательных служб. Используемое оборудование:
Шлагбаум с электроприводом, связанный с контроллером STS‑407К;
IP‑видеокамера PTZ‑типа для распознавания госномеров и идентификации водителя;
RFID‑считыватель дальнего радиуса действия (до 1 м) для пропусков автотранспорта.
Логика работы выездного КПП следующая – сотрудник или водитель предъявляет RFID‑транспортную карту → считыватель передаёт код контроллеру. Сервис сообщений проверяет карту в «Бюро пропусков» и, при разрешении, командует шлагбауму открыть проезд. Камера фиксирует движение и передаёт видеопоток на СВН; событие «проезд открыт/закрыт» заносится в журнал событий .
Пешеходный КПП. Его назначение – основной вход для персонала и посетителей. Оборудование:
Два шлюзовых турникета (триподы) с индикаторной подсветкой «вход/выход»;
Два проксимити‑считывателя STS‑705 с подсветкой и звуковым сигналом для подтверждения доступа.
Особенности настройки оборудования и режим работы – антипасс‑бэк запрещает многократные проходы по одному пропуску без «обратной» регистрации. График доступа – сотрудникам разрешено проходить с 08:00 до 20:00, посетителям – только по предварительной записи и в строго ограниченные часы. При сигнале пожарной системы или ручной тревоге турникеты автоматически отпираются и фиксируют проход как эвакуационный.
Внутренние проходы. Назначение – контроль доступа в административные, технические и охранные помещения. Используются автономные проксимити‑считыватели STS‑705, питающиеся через PoE‑коммутаторы, и электромагнитные или электромеханические замки с контактным мониторингом закрытия. Сценарии работы настроены таким образом:
При заходе сотрудник прикладывает карту → контроллер проверяет право на вход в зону;
При недопустимой попытке – трёхкратный звуковой сигнал и предупреждение оператора через АРМ;
При срабатывании аварийного сценария (пожар, эвакуация) замки отпираются, что фиксируется как «аварийное открытие».
Для удобства администрирования и отчётности все точки прохода объединены в следующие логические зоны доступа:
Охранная зона – КПП, помещения охраны, службы пропускного контроля;
Административный блок – кабинеты руководства и отделов (канцелярия, юрслужба, бухгалтерия);
Технические службы – отделы ИТСО, связи, ремонта вооружения;
Коммунальные службы – склады и мастерские.
Правила для логических зон:
Графики доступа и антипасс‑бэк настраиваются на уровне каждой зоны в модуле «Администратор системы».
Аварийные сценарии (пожар, тревога) глобально разблокируют все зоны или только эвакуационные коридоры в зависимости от типа события.
Отчёты по зонам формируются модулем «Журналы событий» – статистика проходов, несанкционированных попыток, аварийных открытий разделяется по зонам и подразделениям .
Преимущества такой организации контроля доступа:
Уменьшение ложных тревог за счёт чёткого разграничения прав доступа;
Оперативная локализация ЧП: при инциденте система позволяет мгновенно заблокировать конкретную зону;
Аналитика и отчётность: руководству доступны детальные отчёты по использованию пропускного режима в каждой зоне.
Оценка существующих бизнес-процессов КУД (процедуры выдачи/изъятия пропусков, учет посетителей, реагирование на нарушения) и их эффективности
В ФКУ «ЦИТОВ УФСИН Югры» процедуры работы с пропусками, регистрацией посетителей и реагированием на инциденты реализованы через модуль «Бюро пропусков» и сопутствующие сервисы «Стилпост». Ниже приведён анализ каждого процесса, его шагов и текущей эффективности.
Выдача и изъятие пропусков
Процесс начинается с подачи заявки в модуле «Бюро пропусков (SYN‑BP)» (рисунок 6). Оператор вводит данные сотрудника или посетителя, указывает тип пропуска и время действия. Система автоматически формирует цифровую запись и передаёт её в очередь на печать. Согласно спецификации, полная регистрация нового пользователя и выдача пропуска занимают не более 10 секунд, что значительно ускоряет процедуру по сравнению с ручным заполнением бланков [11].
Рисунок 6 – Бизнес-процесс «Выдача и изъятие пропуска»
После истечения срока действия пропуск автоматически блокируется без участия оператора. В экстренных случаях (увольнение, утрата карты) кадровая служба инициирует ручное изъятие – оператор деактивирует запись в системе и физически изымает карту, фиксируя причину операции в журнале.
Автоматизация согласования и печати пропусков снижает время оформления на 95 % (с 2 мин вручную до ~10 сек) и устраняет ошибки при вводе данных. Недостаток – ручное изъятие требует вмешательства, что добавляет до 1 мин задержки в экстренных сценариях [8].
Учёт посетителей
Модуль «Бюро пропусков» поддерживает регистрацию как сотрудников, так и транспортных средств и гостей (рисунок 7):
Создание предварительной заявки позволяет сотруднику забронировать приём гостя в указанный интервал;
Фиксация на входе через пешеходный КПП: оператор сверяет личные документы, фотографирует гостя и выпускает временный пропуск с ограниченным временем действия;
Контроль возврата пропуска производится на выходе; система автоматически фиксирует время выхода и блокирует карту.
Возможность группового формирования пропусков и учёта транспорта снижает нагрузку на операторов при пиковых потоках (семинары, совещания) [8].
Рисунок 7 – Бизнес-процесс «Регистрация посетителя»
Автоматизированная верификация позволяет сократить среднее время регистрации гостя до 1–2 мин. Однако отсутствие интеграции с внутренней базой кадров приводит к ручному уточнению подразделений и ролей.
Реагирование на нарушения
Каждое несанкционированное событие (несоответствие прав доступа, попытка форсировать турникет) фиксируется контроллером STS‑407К и передаётся в «Журналы событий» с указанием времени, точки доступа и кода ошибки [11] (рисунок 8). Оператор в АРМ видит событие в «красной» зоне дашборда и в течение 10–15 сек получает SMS‑оповещение службы охраны (через интеграцию «Server API» благодаря модулю взаимодействия с внешними системами).
Рисунок 8 – Бизнес-процесс «Реагирование на нарушение»
Далее дежурный охранник выдвигается к месту инцидента, пользуясь видеофиксацией из подсистемы видеонаблюдения. После устранения причины нарушение документируется в журнале с прилагаемыми фото и видеоматериалами.
Время полного цикла «событие → реакция» составляет 3–4 мин. Основная проблема – ложные срабатывания при сбоях питания или перебоях связи, приводящие к необоснованным реакциям.
Таким образом, процессы выдачи и учёта пропусков полностью автоматизированы и работают с высокой скоростью благодаря модулю SYN‑BP. Реагирование на нарушения организовано эффективно, но требует доработки в части уменьшения ложных тревог и расширения интеграции с внутренними информационными системами (кадровыми, ERP).
Выявление недостатков, узких мест, ограничений и потенциальных рисков в текущей конфигурации и использовании СКУД «Стилпост»
Несмотря на широкую функциональность и доказанную надёжность платформы «Стилпост», при анализе её текущего состояния на объекте ФКУ «ЦИТОВ УФСИН Югры» были выявлены следующие проблемы и риски.
Вендор‑лок и зависимость от одного производителя
Ограниченная масштабируемость и вендор‑лок. Термин «вендор‑лок» (vendor lock‑in) обозначает ситуацию, когда клиент оказывается «привязан» к решениям одного вендора из‑за высокой стоимости или технической сложности перехода на альтернативные продукты. В случае СКУД «Стилпост» это выражается в следующих аспектах:
Проприетарные интерфейсы и форматы. Контроллеры STS‑407К и считыватели STS‑705 используют закрытые протоколы обмена (Wiegand или фирменный TCP/IP), для которых нет открытых спецификаций. Переход на оборудование других производителей требует разработки адаптеров, шлюзов или дополнительных модулей преобразования протоколов, что удорожает интеграцию;
Единый поставщик ПО и прошивок. Выпуск обновлений и исправлений ошибок возможен только через ЗАО «Стилсофт». Если критическая уязвимость обнаружена в контроллере, заказчик не может получить быстрого исправления от стороннего разработчика – придётся ждать официального патча и подписать дополнительное соглашение на поддержку;
Ограниченный выбор периферии. Возможность использовать альтернативные считыватели по протоколу OSDP (Open Supervised Device Protocol) теоретически есть, но на практике большинство сторонних устройств не проходят тестирование совместимости с «Стилпост». Даже поддержка двухстороннего шифрованного канала OSDP, рекомендованного Ассоциацией индустрии безопасности (SIA), встречается редко среди отечественных устройств;
Рост затрат при масштабировании. При расширении сети СКУД за счёт новых точек прохода приходится закупать дополнительные контроллеры и считыватели того же производителя. Это ведёт к монопольным ценам на оборудование и сервис: сменить вендора на более дешёвый практически невозможно без полной замены инфраструктуры.
Последствия вендор‑лока могут быть следующими:
Возрастание себестоимости – из‑за отсутствия конкуренции «Стилсофт» может устанавливать более высокие цены на оборудование, лицензии и услуги техподдержки;
Увеличение сроков внедрения – разработка и тестирование кастомных драйверов для сторонних устройств требует 2–3 месяцев дополнительной инженерной работы;
Риски при прекращении поддержки – если вендор изменит бизнес‑модель или будет поглощён другой компанией, риск «брошенного» продукта возрастёт, и Центру придётся экстренно искать замену.
Уязвимости протокола Wiegand
Протокол Wiegand уже десятилетиями используется для передачи данных между считывателями и контроллерами в СКУД, однако его конструктивные особенности оборачиваются серьёзными угрозами безопасности.
Интерфейс Wiegand основан на двух сигнальных линиях (Data0 и Data1) и линии «общего провода» (рисунок 9). При подаче карточки считыватель высылает серию импульсов на одной из линий: «0» передаётся коротким импульсом на линии Data0, «1» – на линии Data1 . Никакой обратной связи, определения источника сигнала или проверки целостности пакета в этом протоколе не предусмотрено.
Рисунок 9 – Схема подключения считывателя по протоколу Wiregand
Основные уязвимости протокола приведены ниже [19]:
Отсутствие шифрования и аутентификации. Всё содержимое сообщения (код карточки) передаётся в открытом виде, без защиты от перехвата. Злоумышленник может легко подключиться к проводам между считывателем и контроллером и «сниффить» битовые последовательности;
Replay-атака. Перехваченный сигнал можно повторно воспроизвести (replay attack) с помощью бюджетного оборудования (Arduino, Raspberry Pi), что позволит злоумышленнику эмулировать легальную карту и получить доступ без физической карточки;
Импульсные помехи и подмена. При физическом доступе к кабельным трассам злоумышленник может вводить высокочастотные помехи или дополнительные импульсы, искажая последовательность кодов («bit-injection») с целью обхода систем «антипасс-бэк» или создания ложных событий;
Отсутствие контроля целостности. Протокол не использует контрольные суммы или CRC, поэтому даже случайная потеря импульса (например, из-за наводок или старения кабеля) может привести к некорректной авторизации или, наоборот, к ложным отказам в доступе;
Практические примеры атак. Прослушка – исследователи демонстрировали запись 26-битных последовательностей Wiegand через портативные осциллографы или логические анализаторы с дальнейшей эмуляцией карты;
Replay-атакa – простейшие устройства на микроконтроллерах могут перехватить и многократно воспроизвести один и тот же код, что позволяет несанкционированный проход в течение всего времени действия записи.
Физические риски и недостаточная защита контроллеров STS-407К
Контроллеры STS-407К в составе СКУД «Стилпост» часто устанавливаются в легкодоступных местах – в настенных щитах общего пользования, под фальш-полом или прямо на стене коридора. Такая практика облегчает техническое обслуживание, но создаёт серьёзные риски:
Лёгкий физический доступ:
Отсутствие охранных корпусов. Контроллеры монтируются без дополнительного запираемого корпуса или сигнализации дверцы шкафа, что позволяет злоумышленнику, получившему ограниченный доступ к техническому помещению, свободно открыть шкаф и получить доступ к плате устройства;
Прямой доступ к сервисным портам. На плате STS-407К обычно присутствуют незапароленные UART- или JTAG-разъёмы для отладки и прошивки. Через них атакующий может получить доступ к командной строке контроллера, изменить его конфигурацию или загрузить собственную прошивку.
Отключение питания и саботаж:
ИБП встроенного типа. Встроенный аккумулятор АКБ-7т даёт ощущение надёжности, но устанавливается в том же щите без отдельного контроля. Перекусив провода питания или выключив предохранитель, злоумышленник может полностью обесточить контроллер, при этом сигнализация «отсутствие питания» не выводится на ЦПУ, а события буферизуются и передаются лишь после восстановления питания без тревожного оповещения;
Манипуляции с кабелями Data0/Data1. Протокол Wiegand легко «отключается» физическим разрывом кабеля, что позволяет обойти контроль доступа без единого срабатывания.
Перепрограммирование и взлом прошивки:
Исследования показывают, что при наличии физического доступа можно:
Считать и модифицировать флеш-память контроллера, заменив оригинальный образ прошивки на «злонамеренный», который игнорирует проверку прав доступа;
Подменить таблицу идентификаторов прямо в EEPROM, добавив новые «легитимные» карты;
Отключить модуль журналирования, исключив запись фактов доступа и нарушений .
Последствия отсутствия физической защиты:
Неавторизованный доступ. Полный контроль над платой контроллера позволяет создать обходные «дыры» в системе, получив постоянный или временный доступ в любую зону без срабатывания тревоги;
Срыв расследований. При модификации журнала событий или отключении модуля логирования все сведения об инцидентах теряются, что блокирует возможность аудита и криминалистического анализа после факта нарушения;
Нарушение бесперебойности. Манипуляции с питанием приводят к «тишине» системы и задержке передачи событий, что даёт злоумышленнику дополнительное время для проникновения.
Процедуры обновления и патч-менеджмент
В текущей инсталляции СКУД «Стилпост» отсутствует централизованная платформа для развертывания обновлений прошивки контроллеров STS-407К и считывателей STS-705. Патчи и новые версии ПО инсталлятор вручную загружает и устанавливает только при плановом техническом обслуживании, что создаёт длительное «окно уязвимости» в случае обнаружения критической ошибки или эксплойта .
Текущая практика обновлений включает в себя:
Ручное отслеживание версий. Ответственные инженеры периодически проверяют сайт производителя на наличие новых версий прошивок и обновлений модулей;
Плановые окна обслуживания. Обновления устанавливаются раз в квартал в заранее согласованное время (обычно ночью), чтобы не нарушить рабочие процессы;
Ручная загрузка и установка. Прошивки копируются на USB-накопитель, вставляются в сервисный порт контроллера; аналогично – считыватели перезагружаются с SD-карт памяти;
Минимальное тестирование. Отсутствует выделенная тестовая среда: обновления сразу развертываются на боевых узлах, что может привести к отказам в работе при несовместимости.
Риски текущего подхода выражены в:
Окно уязвимости – задержка в применении критических патчей может достигать 90 дней, что даёт злоумышленнику время для эксплуатации выявленных брешей;
Человеческий фактор – ручное выполнение процедур чревато пропуском этапов (например, неполной загрузкой образа), что приводит к «катастрофическим» сбоям оборудования;
Отсутствие аудита – нет автоматизированного журнала установки патчей, поэтому невозможно оперативно установить, какие версии работают на конкретном контроллере;
Низкая скорость реагирования – при появлении Zero-Day уязвимости сроки реакции составляют недели, тогда как в современных промышленных системах требуются часы или дни [20].
Сетевая безопасность и мониторинг
Хотя служебный трафик между сервером, АРМ и контроллерами передаётся по защищённым каналам HTTPS/TLS, внутренняя сеть Центра остаётся единой, без сегментации и специализированных средств обнаружения вторжений. Это создаёт ряд критических рисков [21, 22]:
Отсутствие сетевой сегментации. Все устройства (контроллеры доступа, серверы, рабочие станции административного персонала) находятся в одном VLAN. При компрометации любой точки злоумышленник получает возможность «бокового» перемещения (lateral movement):
Захват учётных данных оператора даёт полный доступ ко всем узлам СКУД;
Отсутствие межсегментного файрвола не ограничивает поток управления и данных между контроллерами и сервером;
Нет IDS/IPS-мониторинга. В отсутствии системы обнаружения и предотвращения вторжений (IDS/IPS):
Не фиксируются сканирования портов и аномальные пакеты, характерные для атак на протоколы управления промышленными устройствами;
Невозможно оперативно выявить попытки эксплуатации уязвимостей или внутренние атаки типа ARP-spoofing и DHCP-starvation;
Не централизованное логирование и анализ трафика. Логи сетевого оборудования не собираются в единую SIEM-систему, что сводит на нет возможность корелляции событий (например, одновременное появление «heartbeat-failure» контроллера и попытки подключения неизвестного MAC-адреса). Без централизованного анализа невозможно быстро реагировать на комплексные атаки.
Человеческий фактор и организационные риски
В современных системах контроля и управления доступом (СКУД) надёжность в значительной степени зависит от квалификации персонала и соблюдения формализованных процедур [19, 23]. В текущей эксплуатации «Стилпост» в ФКУ «ЦИТОВ УФСИН Югры» выявлены следующие ключевые проблемы:
Недостаточная подготовка персонала:
Редкие тренинги и аттестации. Операторы проходят вводное обучение при подключении к СКУД и единичные курсы «обходного» характера 1 раз в год. Нет регулярного графика повышения квалификации по новым функциям системы, методам реагирования на инциденты и процедурам безопасности;
Низкая культура кибер- и физической безопасности. Без систематического обучения сотрудники не умеют различать критичные тревоги (несанкционированная попытка доступа) и ложные срабатывания, что приводит к игнорированию реальных инцидентов или избыточному реагированию на несущественные события;
Дефекты «человеческого интерфейса». Интерфейс АРМ «Стилпост» не получает адаптированного обучающего контента и подсказок в процессе работы (tooltip, встроенные видеоинструкции). Операторы вынуждены обращаться к печатным памяткам, что замедляет действия при пиковых нагрузках или в стрессовых ситуациях.
Отсутствие формальных процедур реагирования:
Негласные регламенты. В официальных документах Центра отсутствуют детальные инструкции (либо имеют невнятное описание) по реагированию на типовые сценарии: попытки повторного прохода, взлом турникета, отказ оборудования. Персонал действует «как привык», что может отличаться от смены к смене;
Запаздывание при принятии решений. При ложных срабатываниях операторы редко используют «проверочные» действия (просмотр видеоизображения, запрос у ответственного), предпочитая сразу вызывать службу охраны, что перегружает ресурс и увеличивает время реакции на настоящие ЧП.
Отсутствие формализованного отчёта и обратной связи:
После инцидента не всегда заполняются единые формы отчётов – многие записи делаются устно или в свободной форме, без стандартизированных полей для оценки причин, вовлечённых лиц и принятых мер. Это препятствует проведению аналитики инцидентов и корректировке регламентов .
Риски и последствия такого положения дел:
Ошибка оператора может привести к пропуску серьёзного нарушения (например, попытки флеш-атаки по Wiegand) или, наоборот, к избыточным срабатываниям, резко увеличивающим нагрузку службы охраны и снижая оперативность реагирования;
Недостаток формальных регламентов увеличивает вероятность неконсистентного и непоследовательного реагирования, что особенно критично при распределённых объектах и сменных составах персонала.
Отсутствие аналитики на основе AI
Несмотря на то, что в СКУД «Стилпост» реализован надёжный сбор и хранение событий доступа, система не использует современные методы машинного обучения (ML) и видеоаналитики для автоматической фильтрации ложных тревог и выявления аномалий [23].
Текущая ситуация:
Ложные тревоги из-за шумовых импульсов на интерфейсе Wiegand и помех в электропитании составляют до 5 % всех срабатываний СКУД. Это приводит к избыточным выездам службы охраны и отвлечению операторов от реальных инцидентов.
Видеоаналитика не интегрирована с системой контроля доступа – даже при срабатывании тревоги операторы вручную сопоставляют события СКУД и видеопоток, что замедляет реакцию.
Возможности AI-аналитики:
Фильтрация шума и аномалий. ML-модели (например, основанные на алгоритмах проверки временных рядов) могут автоматически распознавать и отбраковывать «короткие» или «искажённые» последовательности импульсов Wiegand, характерные для помех, снижая число ложных срабатываний до 1–2 %;
Интеллектуальная видеоаналитика. Системы видеоаналитики на базе нейронных сетей (например, распознавание силуэтов и лиц) способны в течение долей секунды сопоставлять факт открытия турникета или двери с наличием человека в кадре. При несовпадении (открытие без человека) автоматически генерируется тревога более высокого приоритета;
Адаптивные правила доступа. На основе анализа исторических данных ML-модуль может динамически настраивать параметры антипасс-бэк и временных «окон» доступа, учитывая пиковые часы и поведенческие паттерны сотрудников;
Прогнозирование отказов оборудования. Сбор телеметрии (температура, ток, частота отказов) и её анализ с помощью алгоритмов предиктивного обслуживания позволяет заранее планировать замену контроллеров и считывателей до критического сбоя.
Бизнес-эффекты внедрения AI:
Снижение трудозатрат операторов на 20–30 % за счёт автоматической предсортировки инцидентов и снижения количества ложных тревог;
Ускорение реагирования на реальные ЧП: время от срабатывания до подтверждения факта уменьшается на 40 % благодаря сопоставлению событий СКУД и видеоаналитики;
Оптимизация затрат на службу охраны – уменьшение числа выездов и переадресаций экономит ресурсы и повышает безопасность объекта.
Таким образом, текущая конфигурация СКУД «Стилпост» демонстрирует высокую надёжность, но страдает от узких мест: вендор‑лок, уязвимости Wiegand, физическая доступность контроллеров, недостаток обновлений и сетевого мониторинга, а также организационные проблемы. Эти ограничения требуют решения на этапе модернизации системы – в частности, внедрения защищённых интерфейсов (OSDP вместо Wiegand), автоматизированного патч‑менеджмента, сегментации сети и AI‑аналитики для повышения эффективности и безопасности.
Формулирование технических (аппаратные/программные обновления, новая функциональность) и организационных (регламенты, инструкции) требований к развитию АС КУД
На основании выявленных в разделе 2.3 ограничений и рисков сформулированы следующие технические и организационные требования, призванные повысить безопасность, отказоустойчивость и управляемость системы [19 -25].
Технические требования
Переход на защищённый протокол OSDP:
Заменить Wiegand-интерфейс между считывателями и контроллерами на OSDP v2 с двунаправленным AES-шифрованием и ключами минимум 128 бит;
Обновить прошивки контроллеров STS-407К и считывателей STS-705 или заменить их на совместимые модели с поддержкой OSDP (например, отечественные TARGControl OSDP Reader) .
Централизованный патч-менеджмент:
Развернуть автоматизированную систему обновлений (на базе Ansible/Chef) с репозиторием подписанных производителем образов прошивок;
Внедрить проверку цифровой подписи (PKI) перед установкой обновлений;
Настроить автоматические оповещения о выходе новых патчей и контрольное тестирование на тестовом стенде.
Физическая защита контроллеров:
Перенести контроллеры в запираемые металл-шкафы класса не ниже IP54 с установкой датчиков открытия и наклона;
Интегрировать датчики шкафа в систему SOS/IDS для немедленного оповещения о попытке физического вмешательства .
Сетевая сегментация и IDS/IPS:
Разграничить VLAN для серверов, контроллеров, операторских АРМ и гостевой сети;
Установить межсетевые экраны (например, «КиберЛаб Фаервол») на границах сегментов и внедрить IDS/IPS (Suricata);
Включить централизованное логирование и корреляцию событий через SIEM (ELK или «Аналитика-Сеть») .
AI-аналитика и видеоинтеграция:
Внедрить ML-модуль для фильтрации ложных тревог по данным контроллеров (анализ временных рядов);
Интегрировать систему видеоаналитики (VisionLabs или аналог) для автоматического сопоставления событий СКУД и видеокадров;
Настроить KPI-отчёты по снижению ложных срабатываний и времени реагирования.
Резервирование и отказоустойчивость:
Организовать географически распределённый кластер приложений и реплику БД для обеспечения непрерывной работы при сбоях ЦПУ;
Внедрить Hot-Standby-контроллеры и автоматический фейловер для критичных точек доступа.
Организационные требования
Разработка и утверждение регламентов (SOP):
SOP-01 «Процедуры выдачи и изъятия пропусков»,
SOP-02 «Регистрация и сопровождение посетителей»,
SOP-03 «Реагирование на инциденты СКУД»,
с чёткими алгоритмами действий, ответственными лицами и временными нормами.
Периодическое обучение и аттестация операторов:
Квартальные тренинги по новым функциям и сценариям инцидентов,
Ежегодная аттестация компетенций с письменным тестированием и практическими заданиями.
План управления инцидентами (Incident Response Plan):
Описание ролей и шагов при обнаружении угроз (анализ, эскалация, ликвидация, отчёт),
Интеграция с внутренней системой ведения заявок (HelpDesk).
Регулярные аудиты и тестирование:
Ежеквартальные «красные учения» (penetration-test) для оценки реальной защищённости,
Полугодовые физические проверки шкафов и кабельных трасс.
Управление конфигурацией и документацией:
Введение системы CMDB (Configuration Management Database) с подробным описанием всех устройств, их версий ПО и расположения;
Поддержка актуальных схем сети, карт шкафов и документации по настройке.
Разработка конкретных предложений по развитию/модернизации СКУД «Стилпост»
На базе выявленных требований и рисков предлагаются следующие меры для повышения функциональности, надёжности и интеграции системы.
Оптимизация структуры точек доступа и зонирования
2.5.1.1. Реинжиниринг зон доступа
Для усиления физической безопасности и оптимизации работы сервиса контроля доступа необходимо провести комплексный реинжиниринг зон, базируясь на принципе риск–важность [26]:
Этап 1. Аудит текущих зон:
Инвентаризация точек доступа:
Составить полный список всех контроллеров, считывателей и турникетов;
Сопоставить их с планом помещения, указав точные координаты и описание смежных помещений.
Инвентаризация угроз:
Для каждой точки определить возможные сценарии угроз: несанкционированный вход, скрытое размещение злоумышленника, удалённое вмешательство;
Оценить частоту и последствия каждого сценария (конфиденциальные данные, критическое оборудование).
Классификация по уровню риска
Высокий риск: помещения с гостайной, архивы, серверные;
Средний риск: офисы руководства, бухгалтерия, юридический отдел;
Техническая зона: мастерские, склады запчастей, ИТСО.
(При этом критерии риска формируются на основе ГОСТ Р 50922-96 и методик антитеррорзащиты ФСИН) .
Этап 2. Проектирование обновлённого зонирования (табл. 3):
Таблица 3
Зонирование помещений
Этап 3. Настройка параметров доступа:
Карты + ПИН – для зоны среднего риска и техзоны включить проверку PIN-кода после считывания карты, чтобы предотвратить использование потерянных носителей.
Биометрия – в зоне высокого риска добавить отпечаток пальца или распознавание лица как обязательный третий фактор.
Усиленные журналы:
На контроллерах зоны высокого риска включить детальный лог: не только пропуски, но и все команды, ошибки и попытки открыть «аварийным» способом;
Все журналы централизованно агрегируются в SIEM с оповещением при подозрительных сериях событий (например, > 3 отказа подряд).
Этап 4. Сценарии экстренной разблокировки:
Двухэтапное согласование (зона высокого риска): при необходимости открытия вне графика требуются параллельные команды от двух операторов с разными уровнями доступа;
Паника-кнопка (для всех зон): одна кнопка «Тревога» на станции охраны в AРМ и аппаратная кнопка на КПП разблокируют двери и отправят SMS-оповещение охране;
Пожарный сценарий: при поступлении сигнала от СПС все зоны переходят в «эвакуационный» режим с разблокировкой дверей и эвакуационными подсказками на табло.
Ожидаемый результат от предлагаемого зонирования:
Чёткое разграничение потоков доступа и обязанностей операторов по зонам;
Снижение ложных срабатываний и повышение скорости реагирования за счёт адаптированных сценариев;
Соответствие регламентным требованиям ФСИН и антитеррористическим стандартам.
2.5.1.2. Динамическое зонирование
Динамическое зонирование – это механизм автоматической перенастройки прав доступа в зависимости от времени суток, календарных событий и местоположения, что позволяет гибко управлять потоками людей и повышать безопасность объекта [27, 28].
Принципы работы:
Графики доступа по расписанию:
Нерабочее время (например, с 19:00 до 08:00) административные коридоры переводятся в режим «минимального доступа» – в них сохраняют право входа только сотрудники охраны и ответственные инженеры. Все остальные пользователи блокируются автоматически.
Часы пик (08:00–11:00 и 17:00–19:00) зона для посетителей расширяется – предварительно зарегистрированные гости получают право прохода в определённые офисы без участия оператора.
Геотеги и indoor-геолокация:
На базе Wi-Fi-точек доступа или BLE-маячков внутри здания реализуется приблизительный «геозональный» контроль (геofence). При перемещении сотрудника за пределы своей основной зоны – например, из кабинета в коридор – система может динамически переключать его права (например, разрешить доступ в переговорные комнаты только в рабочие часы) .
Это снижает вероятность «зависания» привилегий: если пользователь покинул зону и не отсканировал карту в установленном радиусе, его сессия автоматически закрывается.
Календарное зонирование:
Учёт праздничных и выходных дней: в выходной режим переводятся все административные зоны, оставляя открытыми только КПП для спецслужб и аварийных служб.
Интеграция с корпоративным календарём (Exchange или 1С:ЗУП) позволяет автоматически включать или выключать зоны в зависимости от событий (собраний, тренингов, учений).
Помимо этого, предусматриваются «скрытые» зоны с повышенным контролем:
Идентификация «скрытых» зон – серверные шкафы, архивные хранилища гостайны и комнаты ИТСО помечаются как отдельные зоны с высшим уровнем безопасности.
Двухфакторная аутентификация (2FA):
Для входа в скрытую зону пользователь прикладывает карту и вводит ПИН. При необходимости – дополнительно сканирует отпечаток пальца;
В случае неуспешной попытки система блокирует дальнейшие входы данным пользователем на X минут и уведомляет оператора.
Временные метки и аудит:
Любой вход в скрытую зону логируется с точностью до секунды, фиксируется Ф.И.О. пользователя и метод аутентификации;
По окончании доступа сотрудник должен подтвердить выход (анкета на АРМ), иначе система выдаёт автоматическое напоминание и повышает приоритет проверки.
Технически это может быть реализовано как указано ниже (табл. 4):
Таблица 4
Техническая реализация
Ожидаемые выгоды от реализации предложения:
Уменьшение человеческих ошибок: автоматическое переключение прав доступа избавляет операторов от ручного вмешательства;
Повышение уровня безопасности: скрытые зоны остаются физически закрытыми и доступны только по жёстким правилам;
Гибкость управления: можно быстро реагировать на внештатные ситуации (учения, ЧП) изменением расписания без перенастройки оборудования.
Внедрение дополнительных функций ПО «Стилпост»
2.5.2.1. Внедрение жёсткого режима Антипасс-бэк (Strict Anti-Passback)
Антипасс-бэк (Anti-Passback, APB) – метод предотвращения повторного использования одной и той же карты для входа в зону без предварительного выхода. В жёстком режиме (Strict APB) система категорически запрещает любому идентификатору пройти через ту же точку доступа дважды подряд, если не было фиксации выхода [29].
Принципы работы жёсткого режима APB:
Парные события:
Каждая карта при первом проходе генерирует событие Entry; при выходе – Exit;
Система отслеживает их попарно: без фиксации события Exit событие Entry блокируется.
Контролируемая зона:
Жёсткий APB настраивается на границах логической зоны (например, «Высокий риск»);
Считыватели на входе и выходе зоны обязательно различаются: входной считыватель знает, что он «вход», а выходной – «выход».
База состояний:
На контроллере и/или сервере хранится таблица последних состояний карт (IN/OUT);
При срабатывании входного считывателя проверяется статус: если карта уже в состоянии IN, команда на проход игнорируется.
Настройка жёсткого APB в «Стилпост»:
Выделение зоны. В модуле «Администратор системы» определить точку входа и точку выхода зоны высокого риска (например: считыватель у двери архивного помещения как “IN”, а считыватель на обратном проходе – “OUT”).
Конфигурация режима. В свойствах логической зоны включить параметр Strict Anti-Passback. Указать таймаут автоматического сброса (например, через 24 часа система сама переводит все карты в состояние OUT, чтобы избежать «залипания» карт, оставленных внутри зоны).
Обработка нарушений. При попытке повторного входа карта блокируется, на АРМ оператора выводится красное оповещение «APB Violation», синхронно срабатывает звуковой и световой индикатор на считывателе. Событие фиксируется в «Журналах событий» с меткой APB_VIOLATION и причинами отказа.
Режим исключений. Для экстренных сценариев (пожарная тревога, паника-кнопка) APB автоматически отключается, позволяя беспрепятственный выход из зоны.
Преимущества и риски добавления рассматриваемой функциональности:
Преимущества:
Блокировка “tailgating”: исключает проход нескольких лиц по одной карте без повторного сканирования;
Усиленная защита зон высокого риска: обеспечивает, что каждый вход контролируется и требует выхода перед повторным входом.
Риски и ограничения:
Залипание карт: в случае утери карты внутри зоны потребуется процедура ручного сброса состояния;
Дополнительная сложность: увеличивается нагрузка на операторов при частых ложных APB-нарушениях, если зона не детально спроектирована.
Рекомендации по внедрению:
Пилотный запуск – сначала активировать Strict APB на одной тестовой зоне (например, серверная) и отработать сценарии залипания и сброса.
Инструктаж персонала – обучить операторов процедуре ручного сброса состояния карты через АРМ («Reset APB»), а также алгоритму действий при отказе на проход.
Мониторинг и адаптация – в течение первого месяца анализировать количество APB-нарушений, корректировать таймауты и перенастраивать границы зоны.
2.5.2.2. Сложные правила по графику и маршруту
Для повышения точности контроля и предотвращения несанкционированного перемещения персонала внутри объекта в «Стилпост» можно задать условные маршруты и гибкие временные графики доступа.
Определение условных маршрутов:
В модуле «Администратор системы» создаются логические цепочки точек доступа, например:
Маршрут «Инженер»: Въездной КПП → Техническая зона → Серверная комната;
Маршрут «Юрист»: Пешеходный КПП → Административный блок → Юридический отдел.
Каждому маршруту присваивается уникальный идентификатор и список разрешённых последовательностей действий.
Контроль порядка прохода:
Система фиксирует каждое событие доступа по маршруту и проверяет, соответствует ли оно ожидаемой последовательности;
Попытка выйти из маршрута (например, зайти в Серверную не пройдя через Техническую зону) блокируется контроллером и сигнализируется оператору.
Автосброс маршрута:
По завершении нормального маршрута (фиксируется последовательность Entry→Exit во всех точках) система сбрасывает состояние и готова к новому циклу;
При нарушениях маршрута можно автоматически переводить карту в «запрет» до ручной разблокировки.
Гибкие графики (Time-Of-Day):
Настроить несколько профилей доступа:
Дневной (08:00–20:00) – максимальный набор зон для сотрудников и гостей;
Ночной (20:00–08:00) – только охрана и технические службы.
Для каждой группы пользователей (инженеры, административный персонал, посетители) назначить свой профиль.
Учёт смены охраны:
Интегрировать сменные расписания охраны (например, 2 смены по 12 часов), чтобы автоматически менять уровни доступа у сотрудников охраны в конце их смены для исключения длительных сессий.
В днях плановых учений (утренние тренировки) добавить отдельный график с расширенным доступом к тренировочным площадкам.
Автоматическое включение/выключение. Использовать серверное расписание, привязанное к системному времени Windows/Linux, для безостановочного переключения графиков без участия оператора.
2.5.2.3. Кнопки «Тревога» (Тревожные кнопки)
Аппаратные и программные «тревожные кнопки» дают возможность мгновенно активировать чрезвычайный режим работы СКУД.
Аппаратные кнопки:
Устанавливаются на КПП, в кабинете дежурного и у ведущего инженера. При нажатии формируют сигнал тревоги, который передаётся через «Сервис сообщений» контроллерам и серверу.
Конфигурируется как «аварийный сценарий»: разблокировка всех замков зоны, включение сирен и оповещение охраны.
Программная кнопка в АРМ:
В интерфейсе оператора «Стилпост» размещается «тревожная кнопка» рядом с дашбордом. По её нажатию:
Все зоны переходят в режим открытых дверей;
Оповещение уходит на мобильные устройства ответственных лиц и службу охраны в SMS/Email;
Запускается запись видео с основных камер для последующего анализа.
Логирование и откат:
Все действия паники фиксируются в журнале с указанием оператора и времени;
После устранения ЧП требуется стандартизованная процедура «отката» – подтверждение снятия тревоги двумя операторами (двухуровневая валидация).
Ожидаемые эффекты от внедрения правил маршрутов, графиков и тревожных кнопок:
Предотвращение ошибок при экстренных ситуациях и ускорение эвакуации;
Снижение ручных операций при инцидентах, чёткая и быстрая реакция;
Полная прослеживаемость активации и завершения режимов «Тревога».
Обновление и конфигурирование ПО до актуальной версии
Для поддержания безопасности и надёжности СКУД «Стилпост» необходимо регулярно обновлять серверное и клиентское ПО до последней стабильной версии и оптимизировать его конфигурацию [30, 31].
Переход на более свежие версии «Стилпост»:
Проверка новых модулей безопасности. Изучить релиз-ноты новой версии на официальном сайте ЗАО «Стилсофт»: важнейшие обновления включают различные улучшения и расширение функциональности. Сверить наличие патчей, закрывающих известные уязвимости (CVE-идентификаторы) и добавить их в план обновлений;
Тестирование на стенде. Развернуть тестовую среду, полностью копирующую продуктивную (сервер, АРМы, контроллеры), в изолированном VLAN. С помощью набора smoke-тестов (проверка сценариев выдачи/изъятия пропусков, APB, тревожных сценариев) удостовериться в работоспособности новых модулей без регрессий;
Централизованное обновление. Интегрировать систему обновлений в центр патч-менеджмента (Ansible Tower или отраслевой аналог). Составить плейбук, который автоматически подтягивает из репозитория подписанные образы ПО «Стилпост», разворачивает их на кластере серверов и АРМах, перезапуская сервисы без полного останова всей СКУД.
Рекомендации по сопутствующей оптимизации конфигурации ПО:
Параметры логирования:
Установить частоту ротации логов на уровне 1 файл/день с хранением архивов за последние 30 дней для оперативного поиска;
Включить детальное логирование событий безопасности (APB-нарушения, паника-события) в отдельные тематические журналы для быстрого реагирования.
Режим кластера сервисов:
Упаковать ключевые сервисы «Сообщений» и «Устройств» в Docker-контейнеры;
Развернуть их на платформе Kubernetes с авто-масштабированием и health-checks, чтобы сбои одного экземпляра автоматически компенсировались другим без простоев.
Мониторинг доступности:
Настроить liveness и readiness пробы для контейнеров, интегрировав их в Zabbix/Prometheus;
Установить алерты по росту задержки в обработке сообщений (> 200 мс) и падению числа heartbeat-сигналов от контроллеров.
Ожидаемые эффекты от обновления и оптимизации ПО:
Повышенная отказоустойчивость – за счёт кластеризации и контейнеризации критичных сервисов система сохраняет доступность > 99,9 %.
Минимизация простоев – автоматизированный патч-менеджмент и hot-rolling-деплойменты позволяют обновляться без остановки всего комплекса.
Ускоренный поиск инцидентов – оптимизированное логирование и централизованная ротация упрощают диагностику и расследование.
Интеграция с другими системами
2.5.4.1. Интеграция СКУД «Стилпост» с системой видеонаблюдения (СВН)
Для повышения достоверности регистрации событий доступа и оперативной проверки инцидентов целесообразно реализовать двунаправленную интеграцию СКУД «Стилпост» с подсистемой видеонаблюдения по следующим направлениям [32]:
Подключение через API «Сервис сообщений»:
Протокол обмена. Использовать REST-API или WebSocket-интерфейс модуля «Сервис сообщений» для передачи метаданных события («ID карты», «точка доступа», «время»). По факту каждого события доступа (Entry/Exit, отказ, тревога) «Сервис сообщений» отправляет HTTP-запрос на сервер видеонаблюдения с телом, содержащим уникальный идентификатор события и временную метку;
Запрос фрагмента видео. Сервер СВН, поддерживающий ONVIF или собственный REST, по полученной временной метке формирует запрос RTSP к нужной камере:
rtsp://<camera-ip>/stream?start=<t−5s>&end=<t+5s>
Полученный 10-секундный ролик сохраняется на NAS-сервере или в объектном хранилище вместе с метаданными события;
Привязка к журналу событий. В «Журналы событий» СКУД добавляется ссылка на видеофайл и его миниатюра в интерфейсе АРМ. Оператор видит событие и кликабельную иконку «Play», открывающую видеофрагмент в плеере.
Фото-верификация при нештатных событиях:
Детектирование нештатных событий. К событиям «Access Denied» (отказ в доступе) и «Reader Error» (сбой считывателя) автоматически привязывается требование «фото-верификации»;
Съёмка кадра. При получении такого события «Сервис сообщений» отдаёт команду IP-камере (через ONVIF) зафиксировать одиночный кадр в момент отказа. Камера возвращает JPEG-изображение (или snapshot), которое «Сервис устройств» сохраняет в репозиторий СКУД;
Интерфейс оператора. В АРМ «Стилпост» в момент отказа всплывает окно «Фото-верификация»: отображается лицо субъекта, информация о карте и месте отказа. Оператор принимает решение «Разрешить проход» (генерируется повторная команда Entry) или «Отказать» с указанием причины в журнале.
Архитектурная схема интеграции представлена ниже (рисунок 10):
Рисунок 10 – Архитектурная схема интеграции
Диаграмма последовательностей на рисунке 10 наглядно показывает пошаговый обмен сообщениями между подсистемами – как именно и в какой момент Сервис сообщений запрашивает клип, получает снимок и сохраняет их в журнале.
В данной архитектуре контроллер доступа при каждом событии (отказ, разрешение входа или выход) направляет сообщение в центральный сервис обмена («Сервис сообщений»), который по заранее заданным правилам формирует HTTP-запросы к серверу видеонаблюдения (VMS API) – сначала запрашивает фрагмент видеозаписи вокруг времени события (±5 сек), затем одиночный снимок кадра; полученные медиафайлы сохраняются в централи-зованном хранилище («VideoStorage»), а в журнале событий СКУД («Жур-налы событий») создаётся запись с метаданными события и ссылками на со-ответствующие ролик и изображение, что позволяет оператору мгновенно просмотреть или экспортировать доказательную визуальную информацию без ручного поиска по видеопотоку.
Ожидаемые преимущества от интеграции видеонаблюдения в СКУД «Стилпост»:
Ускоренная проверка инцидентов: вместо ручного поиска по записям оператор сразу получает готовый ролик или фото;
Повышенная достоверность: визуальное подтверждение факта прохода или отказа снижает риск ошибок;
Автоматизация расследований: интеграция с хранилищем видео позволяет строить отчёты с доказательной базой.
2.5.4.2. Интеграция СКУД с охранно-пожарной сигнализацией (СОС/СПС)
Для оперативного управления доступом в экстренных ситуациях и синхронизации устройств безопасности целесообразно настроить двунаправленную интеграцию между СКУД «Стилпост» и подсистемами охранной сигнализации (СОС) и пожарной сигнализации (СПС) [33, 34].
Механизм интеграции:
При постановке на охрану. Событие «Arm» от СОС передаётся в СКУД по протоколу OPC UA или по REST-API модуля «Сервис сообщений». При получении сигнала «Arm» все турникеты и электрозамки автоматически переходят в состояние «Lock» (заперто). Параллельно в «Журналы событий» фиксируется причина блокировки – «СОС: постановка на охрану». Турникеты остаются закрытыми до получения команды «Disarm» – обеспечивая невозможность несанкционированного проникновения в режиме охраны;
При пожарной тревоге. Событие «FireAlarm» от СПС передаётся аналогичным способом в СКУД. СКУД реагирует мгновенной разблокировкой всех эвакуационных выходов и турникетов в зонах эвакуации, позволяет свободный проход; в журнал автоматически записывается «СПС: пожарная тревога». Дополнительно СКУД отправляет тревожный пакет обратно в СОС, который на своём терминале отображает статус «Эвакуационный режим активирован», тем самым информируя аварийно-диспетчерский пункт;
Пост-тревожная коррекция. После снятия тревоги (команда «FireReset» или ручная разблокировка), СКУД возвращает турникеты в обычный режим работы, но оставляет зоны пожароопасных помещений открытыми до полной проверки, чтобы предотвратить повторную блокировку до завершения эвакуации.
Техническая схема такой интеграции показана на рисунке 11:
Рисунок 11 – Техническая схема интеграции с системами сигнализации
На представленной схеме показан порядок взаимодействия подсистем. При получении сигнала «ARM» от охранной сигнализации (СОС) он через «Сервис сообщений» передаётся в СКУД «Стилпост», где автоматически блокируются все турникеты, а событие фиксируется в журнале; аналогично, при срабатывании пожарной сигнализации (СПС) уведомление «FireAlarm» идёт в «Сервис сообщений», затем в СКУД, где включается эвакуационный режим с разблокировкой выходов, система возвращает статус «evac_on» обратно в СОС и сохраняет запись «Эвакуационный режим активирован» в журнале событий.
Преимущества интеграции:
Скоординированное реагирование – единый поток команд между СКУД и СОС/СПС исключает человеческий фактор и задержки;
Повышенная безопасность – автоматическая блокировка при охране предотвращает попытки вторжения, а мгновенная разблокировка при пожаре обеспечивает беспрепятственную эвакуацию;
Единый журнал – все смены режимов фиксируются централизованно, что облегчает последующий аудит и расследование инцидентов.
2.5.4.3. Интеграция учёта рабочего времени через СКУД «Стилпост»
Для автоматизации расчёта табелей и минимизации человеческих ошибок предлагается экспортировать события «вход/выход» из СКУД в ERP-систему (1С:ЗУП, например) через REST-API модуля «Сервис обучения» [11, 35].
Механизм передачи данных:
Формат событий. Каждый раз при срабатывании контроллера STS-407К формируется событие вида:
{
"employeeId": "12345",
"cardId": "0x1A2B3C4D",
"eventType": "ВХОД" | "ВЫХОД",
"timestamp": "2025-07-30T08:34:12Z",
"readerId": "KPP-PEDESTRIAN-1"
}
REST-API «Сервис обучения» находится, например, по адресу (POST) https://<server>/api/v1/timeclock/events, куда передаются заголовки:
Content-Type: application/json
Authorization: Bearer <token>
и тело запроса в виде массива объектов событий.
Приём в ERP-системе 1 С:ЗУП: на стороне 1 С настроен внешний обработчик (HTTP-сервис), который по расписанию опрашивает очередь новых событий из «Сервиса обучения» или получает их по Webhook.
Формирование табеля выполняется по следующему алгоритму:
События сортируются по employeeId и timestamp. Для каждого сотрудника формируется пара «вход–выход» и рассчитывается фактическое время пребывания в зоне предприятия. В случаях, когда событие ENTRY не имеет последующего EXIT (или наоборот), применяется правило «автоматического выхода» по окончании смены или фиксированному времени (например, 18:00);
На основании обработанных данных модуль 1 С автоматически заполняет табель (форма Т-13) или документы «Учёт рабочего времени», экспортируя результаты в расчётные листки зарплаты. Исключается ручной ввод времени прихода/ухода, что снижает ошибки на 95 % и экономит до 3 человеко-часов в смену по отделу кадров .
Преимущества интеграции:
Точность данных: вся информация поступает из единого источника – СКУД, нет расхождений между фактом прихода и записями в табеле;
Автоматизация расчётов: сокращается ручная работа кадровой службы и исключаются опечатки;
Прозрачность: руководители получают доступ к отчётам о фактическом режиме работы сотрудников в реальном времени;
Гибкость: легко адаптируется к сменным графикам, сверхурочным часам и учёту неявок.
РАЗДЕЛ ПО БЕЗОПАСНОСТИ РЕШЕНИЙ ПРОЕКТА
Анализ соответствия текущей СКУД «Стилпост» требованиям законодательства и нормативным актам в области ИБ
Система контроля и управления доступом (СКУД) «Стилпост» на объекте ФКУ «ЦИТОВ УФСИН Югры» должна соответствовать трём уровням нормативной базы [36-38]:
Федеральный закон № 152-ФЗ «О персональных данных», регулирующий сбор, хранение и защиту ПДн сотрудников и посетителей;
Требования ФСТЭК России, задающие технические меры по защите информации, не составляющей государственную тайну, в государственных информационных системах;
Ведомственные требования ФСИН, устанавливающие особенности применения технических средств безопасности в исправительных учреждениях.
Соответствие Федеральному закону № 152-ФЗ «О персональных данных»
Закон № 152-ФЗ от 27.07.2006 г. устанавливает принципы законности, целей и объёма обработки ПДн, необходимость получения согласия субъекта и обеспечения конфиденциальности данных.
СКУД «Стилпост» обрабатывает персональные данные (ФИО, фотография, идентификатор карты) сотрудников и посетителей. В системе реализованы:
Ролевой доступ к модулю «Бюро пропусков» только для аттестованных операторов;
Шифрование ПДн в базе данных СКУД и каналов передачи (HTTPS/TLS);
Логи аудита действий операторов и события доступа, хранящиеся в зашифрованных журналах с доступом только через модуль «Журналы событий».
Сроки хранения ПДн (фото, карточные данные) в системе задаются в соответствии со статьями 18–19 закона: данные сотрудников хранятся не менее трёх лет, гостей – период действия пропуска плюс полгода.
Соответствие требованиям ФСТЭК России
Приказ ФСТЭК РФ от 11.02.2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» определяет три класса защищённости ИС, требования к контролю доступа, криптозащите и мониторингу.
Реализация в «Стилпост»:
СКУД классифицирована как ИС II класса (ограниченный доступ, ПДн сотрудников), для которой обеспечены:
AES-шифрование каналов передачи команд (HTTPS, OSDP при модернизации);
Аутентификация операторов по сертификатам и паролям, двухфакторная авторизация при доступе к зоне высокого риска;
Журналы событий хранятся с контрольными суммами и цифровой подписью, что соответствует требованиям целостности;
Мониторинг состояния через «Сервис сообщений» обеспечивает оповещение о сбое или попытках несанкционированного доступа.
Соответствие ведомственным требованиям ФСИН
Свод правил СП 308.1325800.2017 «Исправительные учреждения и центры уголовно-исполнительной системы. Правила проектирования. Часть I» регламентирует оснащение объектов УИС техническими средствами охраны и контроля доступа, включая СКУД, видеонаблюдение, тревожную связь и интеграцию между ними.
Требования к СКУД в учреждениях ФСИН включают:
Раздельное логирование входа/выхода осуждённых и сотрудников;
Интеграция с видеонаблюдением на КПП и в коридорах камерного фонда;
Непрерывный контроль состояния оборудования (heartbeat) и резервирование каналов связи.
«Стилпост» на объекте ЦИТОВ отвечает этим требованиям – установлены шлюзовые турникеты на КПП, проксимити-считыватели в коридорах, интеграция с СВН и СОС/СПС, круглосуточный мониторинг состояния контроллеров.
Текущая конфигурация СКУД «Стилпост» в ФКУ «ЦИТОВ УФСИН Югры» соответствует ключевым требованиям Федерального закона № 152-ФЗ, приказа ФСТЭК № 17 и свода правил ФСИН СП 308.1325800.2017. Для полного соответствия остаётся формализовать регламенты обработки ПДн и завершить сертификацию СКУД по уровню доступа II класса.
Выявление угроз информационной безопасности, присущих текущей системе «Стилпост» и возникающих при реализации предложений по развитию
Ниже приведён подробный каталог выявленных угроз по категориям и с объяснением механизма угрозы, примерной возможной степенью последствий и конкретными мерами смягчения. Чёткое понимание этих угроз требуется, чтобы при модернизации (переход на OSDP, интеграции с ВМС/СОС/ERP, контейнеризации, внедрении AI и т.д.) не получить ухудшение безопасности из-за новых векторов атаки.
Аппаратно-физические угрозы
Физический доступ к контроллерам и сервисным портам:
Механизм – злоумышленник получает доступ к шкафу с контроллером, подключается к UART/JTAG или извлекает флеш, меняет прошивку, подменяет таблицы карт.
Последствия – перманентная компрометация зоны, подмена журналов, скрытая длительная утечка доступа.
Вероятность / Влияние: средняя / высокая.
Митигирование – запираемые шкафы с датчиками вскрытия; защита и пломбирование кабелей; физическая охрана; Secure Boot и подписанные образы прошивки; мониторинг состояния питания и тревога на переключение на резерв.
Саботаж питания (cut power / IБП-атаки):
Механизм – обесточивание контроллеров или целых участков, чтобы «выключить» фиксацию событий; последующая подмена событий при восстановлении.
Последствия – потеря записей в реальном времени, временное «молчание» системы во время проникновения.
Митигирование – резервирование питания, мониторинг ИБП с немедленным оповещением, автономная запись (жёсткие буферы) и оповещение на ЦПУ при переключении на резерв.
Канальные и протокольные угрозы
Прослушка и replay-атаки по Wiegand:
Механизм – Wiegand – нешифруемый односторонний интерфейс; перехват импульсов и последующая эмуляция карты.
Последствия – неавторизованный проход (tailgating), обход антипасс-бэк.
Митигирование – заменить Wiegand на OSDP v2 с AES-шифрованием; экранирование кабелей; мониторинг аномалий сигнала.
Неавторизованные/незащищённые сетевые интерфейсы (API, WebUI):
Механизм – уязвимые веб-интерфейсы АРМ, незашифрованные REST-эндпойнты, слабые пароли, устаревшие TLS.
Последствия – захват учётных записей операторов, удалённая модификация конфигурации, утечка ПДн.
Митигирование – жесткая политика паролей и MFA, mTLS для API, регулярное сканирование уязвимостей, WAF/Reverse proxy, ограничение доступа по IP/VPN.
Сетевая безопасность и инфраструктура
Отсутствие сегментации сети → lateral movement:
Механизм – при компрометации офисной станции злоумышленник перемещается по сети к серверу СКУД и контроллерам.
Последствия – полный контроль над СКУД, манипуляции журналами и картами.
Митигирование – VLAN-разделение (контроллеры, серверы, операторы, гостевая сеть), межсетевые экраны между зонами, NAC, ограничение управляющих протоколов.
Отсутствие IDS/IPS и централизованного логирования (SIEM):
Механизм – аномальное поведение сети остаётся незамеченным; нет корреляции между событиями СКУД и сетевым трафиком.
Последствия – позднее обнаружение атак, трудности расследования.
Митигирование – развёртывание IDS/IPS (Suricata/Suricata-rules), централизованное логирование в SIEM с корреляционными правилами для СКУД/ВМС/СПС.
Программные угрозы и жизненный цикл ПО
Неавтоматизированный патч-менеджмент и устаревшие прошивки:
Механизм – ручные обновления с длительным окном между выпуском патча и его применением.
Последствия – эксплуатация известных CVE, массовые компрометации.
Митигирование – централизованный патч-менеджер, тестовый стенд, цифровая подпись прошивок, мониторинг релизов поставщика.
Ошибки конфигурации при миграции (OSDP, контейнеризация, кластеризация):
Механизм – неверные настройки ключей шифрования, небезопасные default-пароли в контейнерах, открытые административные порты.
Последствия – утечки ключей, доступ злоумышленника к управляющим интерфейсам.
Митигирование – процесс «secure-by-default», контроль конфигураций через CMDB, ревизия контейнеров (image scanning), применение принципа наименьших привилегий.
Уязвимости в сторонних интеграциях (VMS, ERP, СОС/СПС):
Механизм – уязвимость в VMS или ERP даёт доступ к медиа/событиям или к учётным записям; небезопасный Webhook раскрывает события.
Последствия – подмена доказательств, утечка ПДн, изменение табелей.
Митигирование – защищённые API (mTLS), контроль целостности медиафайлов, изоляция интеграционных каналов, контрактные требования по безопасности к интеграторам.
Угрозы, связанные с внедрением AI/аналитики
Подмена/отрезание/переобучение модели (model poisoning / data poisoning):
Механизм – злоумышленник вводит в обучающую выборку «шум», что снижает способность модели отличать ложные тревоги.
Последствия – ухудшение качества фильтрации ложных тревог, ложные оценки событий.
Митигирование – ручная валидация выборок, версионирование моделей, мониторинг качества модели в продакшн, изоляция канала обучения.
Конфиденциальность и соответствие ПДн при обработке биометрии:
Механизм – хранение биометрических шаблонов без строгой защиты; неясные сроки хранения.
Последствия – нарушение 152-ФЗ, риски утечки «сопоставимых» данных (faceprints/fingerprints).
Митигирование – шифрование хранилищ биометрии, минимизация хранения, юридические согласия субъектов, регистрация обработки ПДн, DPIA (оценка влияния).
Человеческий фактор и организационные риски
Социальная инженерия и компрометация учётных записей операторов:
Механизм – фишинг/телефонная атака→ получение прав администратора.
Последствия – изменение политик доступа, отмена журналирования.
Митигирование – обучение персонала, MFA, раздельие ролей (Separation of duties), регулярные аудиты логов.
Недостаточные регламенты и процедуры rollback:
Механизм – при неудачном обновлении/миграции нет чёткой процедуры отката.
Последствия – длительный простой, потеря журналов, нарушение режима безопасности.
Митигирование – план миграции с чек-листом, горячие резервные копии, автоматизированные сценарии отката.
Поставщики и цепочка поставок
Риски поставщика (вендор-лок, одноточечная зависимость):
Механизм – уязвимость у вендора, прекращение поддержки, требование платных обновлений.
Последствия – невозможность оперативного исправления уязвимостей, высокая стоимость замены.
Митигирование – контрактные SLA и SLA-CVE, требование передачи спецификаций/SDK, использование шлюзов/адаптеров для постепенного вывода проприетарных узлов.
Комплектующие с уязвимым ПО (supply chain compromise):
Механизм – злоумышленник вмешивается в прошивку на этапе производства/доставки.
Последствия – предустановленные бэкдоры.
Митигирование – требование цифровой подписи прошивок, проверка хешей при приёме, SBOM и аудит поставщиков.
Угрозы, возникающие при реализации предложений по развитию
Неправильное управление ключами при внедрении OSDP/mTLS:
Механизм – ключи хранятся в открытом виде, либо ротация не настроена.
Последствия – компрометация шифрования, возможность MITM.
Митигирование – централизованный KMS/HSM, регламент ротации ключей, защищённая передача ключей в устройства.
Ошибки контейнеризации и оркестрации (K8s misconfigurations):
Механизм – открытые административные панели, непротестированные образы, отсутствие network policies.
Последствия – взлом сервиса сообщений/логики и получение контроля над критичными компонентами.
Митигирование – image scanning (SCA), runtime protection, RBAC, network policies, регулярные pentest'ы.
Интеграция видеоаналитики → повышение нагрузки и утечка данных:
Механизм – передача видеопотоков в ML-кластер без шифрования/анонимизации.
Последствия – утечка персональных данных, рост нагрузки на сеть, деградация качества сервисов.
Митигирование – локальная предобработка/анонимизация, шифрованные каналы, QoS, оффлайн-обучение моделей.
Рекомендованный порядок действий при реализации предложений по развитию:
Критично (выполнить в первую очередь):
физическая защита контроллеров;
замена Wiegand → OSDP + управление ключами;
сегментация сети и развёртывание IDS/IPS;
централизованный патч-менеджмент.
Важные (следующий этап):
интеграция SIEM;
жесткие регламенты и обучение персонала;
подписывание поставок и SBOM;
настройка резервирования и кластеризации.
Долгосрочные:
внедрение AI-аналитики с безопасными процессами обучения;
полная модернизация архитектуры с открытыми стандартами и уменьшением вендор-лока.
Разработка мер и рекомендаций по обеспечению ИБ модернизированной АС КУД на базе «Стилпост»
Приведен набор технических и организационных мер, которые необходимо реализовать при модернизации СКУД «Стилпост» (переход на OSDP, интеграция с ВМС/СОС/ERP, контейнеризация/кластеризация, AI-модули).
Защита данных в базе данных и при передаче
Цель: обеспечить конфиденциальность, целостность и доступность персональных данных и служебных журналов.
Рекомендации:
Шифрование каналов передачи. Включить и строго требовать TLS 1.2+ (желательно TLS 1.3) для всех HTTP/REST-интерфейсов (АРМ → сервер, «Сервис сообщений» → VMS, интеграции с ERP). Использовать актуальные наборы шифров и отключить устаревшие протоколы/алгоритмы. Это базовая защита каналов между компонентами. (см. практики CISA/NCSC по защите сетевого трафика) [39];
Шифрование данных «at rest» (на диске). Включить TDE/шифрование на уровне СУБД (Transparent Data Encryption для MS SQL / Oracle / поддерживаемая опция для PostgreSQL) или использовать файловое шифрование на уровне СХД. Закрыть доступ к ключам шифрования через KMS/HSM. Рекомендация – AES-256 для хранения. (практики Microsoft/AWS по шифрованию БД) [40];
Управление ключами (KMS/HSM). Ключи шифрования не хранить непосредственно на серверах приложений: использовать HSM либо централизованный KMS с ограниченным доступом и ротацией ключей согласно рекомендациям NIST SP 800-57. Описать процедуры генерации, ротации, бэкапа и удаления ключей [41];
Минимизация объёма и срока хранения ПДн. Хранить только необходимые поля (минимизация), устанавливать автоматические политики удаления/архивации в соответствии с 152-ФЗ и внутренними регламентами. Логировать согласия субъектов ПДн [36];
Шифрование резервных копий. Резервные копии БД обязательно шифровать; ключи для восстановления хранить отдельно; доступ к восстановлению по процедуре с многоуровневой аутентификацией.
Контроль целостности медиаданных. Для привязанных видео/снимков сохранять контрольные суммы (например, SHA-256) и подписи для доказательной силы и защиты от подмены.
Усиление процедур аутентификации и авторизации
Цель: исключить компрометацию учётных записей операторов и администраторов, обеспечить принцип наименьших привилегий.
Рекомендации:
Внедрить MFA для всех привилегированных аккаунтов. Обязательно многофакторная аутентификация (пароль + аппаратный/программный токен или u2f/webauthn) для администраторов, операторов с правами изменения конфигурации и для доступа к АРМ. Руководства OWASP по аутентификации – базовый стандарт реализации [42];
Ролевой доступ и разграничение обязанностей. Настроить RBAC: разделить права на просмотр журналов, управление пользователями, обновление конфигурации, сброс APB и т.д.; внедрить Separation of Duties (например, необходимость двух операторов для восстановления состояния выделенных зон);
Сессии и управление паролями. Ограничить время сессии, запретить «вечные» токены, использовать безопасные cookies/токены, защитить от CSRF. Ввести требования к сложности паролей, блокировку после N неудачных попыток и уведомление об аномалиях. (OWASP, NCSC) [39, 42];
Аутентификация устройств и взаимная аутентификация. Для защищённого взаимодействия контроллер↔считыватель (OSDP) и сервер↔контроллер использовать взаимную аутентификацию (криптографические ключи/сертификаты) и mTLS для API, избежать доверия к незарегистрированным устройствам;
Процедуры управления учётными записями. Индивидуальные учётные записи (запрещены общие «оператор/guest»), формальные процедуры создания/блокировки/удаления аккаунтов при увольнении или смене обязанностей.
Обеспечение надёжного аудита и целостности журналов событий
Цель: иметь непреложные, неизменяемые журналы доступа и операций для расследований и аудитов.
Рекомендации:
Централизованное логирование (SIEM). Все события (АРМ, сервер, контроллеры, VMS, СОС/СПС) собирать в централизованную систему SIEM/Log-hub (ELK/Graylog/Splunk или российский аналог), чтобы кореллировать инциденты и строить оповещения;
Защищённость и недоступность логов для локальной модификации. Логи писать в append-only режим; по возможности использовать WORM-хранилище или технологию подписи/хеширования записей (каждый блок логов подписывается серверным ключом). Настроить удалённое хранение логов на отдельном хосте/клауде с ограниченным доступом. (NCSC: защита логов от подделки) [39];
Цифровая подпись/хеширование журналов. Подписывать периодические контрольные точки журналов (например, каждые 1 час) и хранить подписи отдельно; при расследовании легко выявить попытку изменения;
Политики хранения и доступности. Установить сроки хранения журналов в соответствие требованиям ФСИН и внутренним регламентам (например, критичные журналы – ≥1 год, детализированные – ≥6 мес), настроить архивирование и быстрый поиск;
Мониторинг и оповещение. В SIEM прописать корреляции: множественные APB-ошибки, попытки массовой записи карт, отключение heartbeat от нескольких контроллеров – генерировать тревоги и тикеты. (практики CISA/NCSC) [39].
Повышение отказоустойчивости системы
Цель: сохранить функционирование критичных сервисов при аппаратных/сетевых сбоях и снизить RTO/RPO.
Рекомендации:
Кластеризация серверных сервисов. Развернуть ключевые сервисы «Сообщений», «Устройств», БД в кластере (active-passive или active-active в зависимости от возможностей ПО). Контейнеризация (Docker + Kubernetes) – опция при соблюдении правил безопасности (secure images, network policies) [40];
Репликация БД и гео-репликация. Настроить синхронную или асинхронную репликацию БД; иметь резервный (DR) сайт с регулярным тестовым восстановлением;
Резервирование питания и сетей. Для серверов и шкафов контроллеров – ИБП с мониторингом состояния, ёмкость АКБ, аварийные каналы связи (дублирование Ethernet/4G) и мониторинг переключения питания;
Hot-Standby контроллеры и локальные буферы. Контроллеры должны поддерживать автономную работу и локальное буферизирование событий; при потере связи события должны сохраняться и синхронизироваться при восстановлении связи;
План восстановления и тесты. Разработать Disaster Recovery Plan, регулярно проводить учения на стенде, проверять ролл-бэки и RTO.
Рекомендации по безопасной настройке оборудования и ПО
Цель: снизить поверхность атаки и обеспечить «secure by default» конфигурацию.
Рекомендации:
Хардениг ОС и сервисов. Применять CIS-бенчмарки или аналогичные чеклисты для ОС серверов и рабочих станций; отключить ненужные сервисы, закрыть порты, запретить прямой доступ root/admin по ssh без MFA. (CIS/NCSC) [39];
Безопасные образы контейнеров и SCA. При контейнеризации использовать сканирование образов (SCA) и управляющие политики (image signing), минимальные привилегии контейнера;
Защита сервисных портов и админ-интерфейсов. Админ-интерфейсы доступные только из защищённых VLAN или через VPN/bastion; применять WAF/Reverse proxy и mTLS для API;
Файлом подлинности и проверка прошивок. Требовать цифровую подпись прошивок от поставщика; на стороне заказчика проверять подписи перед установкой; внедрить Secure Boot/Trusted Boot, где поддерживается;
Физическое укрепление. Контроллеры – в запираемых шкафах с датчиками вскрытия, опломбирование, видеомониторинг помещений с контроллерами, ограничение доступа техперсоналу (протокол посещений);
Политика обновлений и тестирования (патч-менеджмент). Централизованный патч-менеджер с тестовым стендом, staged rollout, контроль цифровой подписи образов и откатных планов. (см. CISA RP for patch management);
Обеспечение безопасности интеграций. Все интеграционные каналы (VMS, ERP, СОС/СПС) реализовать через защищённые API (mTLS), ограничить список IP и использовать контрактные требования по безопасности от интеграторов (включая SBOM и подписи).
Организационные и процедурные меры
Политика безопасности и регламенты. Описать процессы: управление учётными записями, обновлениями, резервированием, реагированием на инциденты, тестированием DR и физическими проверками.
Резервы и SLA с поставщиком. Пересмотреть контракт с ЗАО «Стилсофт»: SLA-поддержка, скорость реакции на CVE, доступ к закрытому порталу релизов, требование подписи прошивок/образов.
Обучение персонала и тренировки. Квартальные тренинги операторов, ежегодные Red/Blue-team учения, документированные процедуры rollback и эскалации.
Оценка рисков и регулярный аудит. Проводить TRA/RA перед каждой крупной миграцией; внешний аудит/пен-тест не реже 1 раза в год.
Разработка/адаптация организационно-распорядительной документации (регламенты работы с системой, инструкции по ИБ для операторов СКУД)
В данном подразделе сформирован перечень управленческих и эксплуатационных документов, который переводит технические решения модернизации СКУД в устойчивую практику эксплуатации, минимизирует человеческие ошибки и обеспечивает соответствие нормативным требованиям (152-ФЗ, требования ФСТЭК, ведомственные требования ФСИН). Кроме того, приведена структура требуемых документов, пример их содержания, распределение ответственности, регламенты пересмотра и образцы ключевых процедур/форм.
Перечень обязательных документов
Приведен минимальный комплект необходимых управленческих и эксплуатационных документов:
Политика информационной безопасности АС КУД (ИБ-политика);
Регламент эксплуатации СКУД «Стилпост»;
Инструкция для оператора «АРМ Оператора – ежедневная операция»;
Инструкция по выдаче/изъятию пропусков и учёту посетителей;
Регламент реагирования на инциденты СКУД;
Регламент управления изменениями;
Регламент патч-менеджмента и использования тест-стенда;
Регламент резервного копирования и восстановления;
Регламент управления доступом;
Регламент по физической защите контроллеров;
Регламент ведения журналов и их защиты;
Регламент по обработке персональных данных (PDн) и согласия субъектов;
План обучения и аттестации персонала;
План аудитов и проверок;
Формы и шаблоны (журналы, акты, отчёты): форма выдачи пропуска, акт изъятия, форма инцидента, журнал APB-нарушений, журнал посещений техперсонала и т. п.
Политика информационной безопасности АС КУД
Цель документа – определить принципы защиты ПДн, целостности журналов и доступности сервисов СКУД.
Область действия – ФКУ «ЦИТОВ УФСИН Югры», все подразделения, использующие СКУД.
Ключевые принципы: минимизация привилегий, защита «at rest» и «in transit», аудит и прозрачность, соблюдение 152-ФЗ и требований ФСТЭК.
Основные обязанности: владелец системы (начальник Центра) – ответственный за политику; администратор – эксплуатация; оператор – оперативные действия; служба ИБ – мониторинг и аудит.
Ревизия – ежегодно или при значимых изменениях (внедрение OSDP, интеграция VMS, смена версии ПО).
Регламент эксплуатации СКУД
Каждый регламент эксплуатации должен быть практическим, с понятными шагами и контактами:
Общие положения: цель, область действия, ответственные;
Определения и сокращения (APB, AРМ, ЦПУ и т. п.);
Порядок запуска/остановки сервисов (ежедневные проверки health-check);
Проверка состояния контроллеров и каналов связи (heartbeat, ИБП);
Порядок выдачи/изъятий пропусков (включая случаи утери/утраты);
Процедуры на случай отказа оборудования (локальный сброс, переход в автономный режим, синхронизация буферов);
Действия при APB-нарушении (см. пример оператора ниже);
Ежедневные/еженедельные рутинные операции (проверка журналов, очистка временных файлов, проверка резервного копирования);
Эскалация и контакты (с кем связываться при аварии, часы работы);
Форма отчёта по операциям (ссылка на электронную форму в CMDB).
Инструкция оператора (пример содержания и ключевые алгоритмы)
Инструкция должна быть «рабочей карточкой» – максимум шагов и минимум лишней теории.
Содержание:
Требования к доступу оператора (MFA, профиль);
Действия при штатном проходе, при регистрации посетителя;
Алгоритм при отказе считывателя:
1) снять фото;
2) сделать попытку повторного считывания;
3) зарегистрировать событие;
4) по решению – маршрутизировать на службу охраны;
Алгоритм при APB-нарушении (см. ниже);
Алгоритм обработки сигнала «Паника» (как подтвердить, кто инициировал, требуемые действия);
Порядок ручного сброса состояния карты (полномочия, журнал);
Шаблон ежедневного отчёта (число посетителей, APB-нарушений, инцидентов);
Требования по защите ПДн в АРМ (не оставлять экран разблокированным, не распечатывать фото гостей без причины).
Пример шага из инструкции – обработка APB-нарушения (оператор):
Оповещение на АРМ: «APB Violation: Карта 0x1A2B, точка: SERVER_IN, время»;
Оператор открывает фото (если доступно) и проверяет идентификацию;
Если свидетель очевиден и это сотрудник с правом входа – запросить у сотрудника подтверждение, затем вручную выполнить Reset APB только после отметки причины;
Если подозрение на злоумышленника – не выполнять Reset, срочно уведомить службу охраны и включить видеоархив вокруг времени события;
Оформить инцидентную запись: ID события, фамилия оператора, предпринятые шаги, приложенные файлы.
Регламент реагирования на инциденты (IRP) – структура и процессы
IRP должен быть согласован с политикой организации и включать:
Определения – что считается инцидентом (несанкционированный доступ, утечка ПДн, отключение питания, взлом контроллера);
Классификация инцидентов – нивелирование по степени (Critical / High / Medium / Low);
Роли и обязанности – владелец инцидента, triage-команда, техническая группа, PR/юридический представитель;
Процедура обнаружения и первичной оценки – источник (лог/видео), быстрый анализ;
Containment (локализация) – блокировка учётных записей, изоляция сетевого сегмента, отключение интерфейсов;
Eradication (искоренение) – обновление/патч, восстановление конфигурации, перепрошивка контроллеров;
Recovery (восстановление) – восстановление из бэкапа, проверка целостности журнала;
Post-incident – отчёт, уроки, изменение регламентов;
Коммуникация – когда информировать руководство, ФСИН, регуляторов (включая требования 152-ФЗ по уведомлению субъектов ПДн при утечке);
Шаблон инцидентного отчёта – уникальный ID, время обнаружения, классификация, действия, время восстановления, рекомендованные меры.
Регламент управления изменениями
Цель: избежать непреднамеренных нарушений работы при апдейтах/конфигурациях.
Процесс: «Запрос» → «Оценка» → «Утверждение» → «Тест» → «Развёртывание» → «План отката» → «Обзор после развёртывания»
Комитет по цифровой трансформации: Change Advisory Board (CAB): представитель ИТ, представитель службы ИБ, представитель эксплуатации, представитель ФСИН (по режимным изменениям).
Критерии для экстренных изменений (security patch) – сокращённый путь с последующей ретроспективой.
Документация: каждый change имеет карточку в CMDB, связанный ticket и план rollback.
Регламент патч-менеджмента и тестовый стенд
Стратегия: поэтапное внедрение: тест → пре-продакшен (pre-prod) → продакшен (prod)."
Частота и SLA: критические патчи – 72 ч / non-critical – ежемесячно.
Тест-стенд: реальное аппаратное окружение (контроллеры, считыватели, турникеты) изолировано от сети; автоматические smoke-тесты перед промо.
Контроль подписи образов: проверка цифровой подписи ПО и прошивок перед инсталляцией.
Регламент резервного копирования и восстановления
Политика: ежедневные инкрементальные бэкапы БД, еженедельные полноразмерные, хранилище за пределами площадки.
Шифрование: все бэкапы шифруются (AES-256).
Тесты восстановления: ежеквартальные тесты восстановления на DR-сайте.
RTO / RPO: определить (например, RTO ≤ 2 часа для сервера сообщений, RPO ≤ 15 мин для журналов событий).
Регламент управления доступом
Процедура учётных записей: создание по заявке, утверждение руководителем, сроки действия, отзыв учетных записей при увольнении в течение 24 часов.
Пароли и MFA: политика сложности, смена каждые 90 дней для админов, MFA для всех операторов.
Разделение ролей: минимальные привилегии, необходимость 2-факторной валидации при критических действиях (Reset APB, сброс журнала).
Отчётность: ежемесячный аудит активных аккаунтов.
Регламент по обработке ПДн и согласия субъектов
Реестры обработки ПДн: для каждого вида данных – цель, срок хранения, правовое основание.
Согласие: шаблоны подписей для посетителей/сотрудников (фото, биометрия – отдельное согласие).
DPIA (оценка воздействия на приватность): для функций биометрии/AI обязателен DPIA.
Уведомления: порядок уведомления субъектов и регуляторов при утечке ПДн (соответствие 152-ФЗ).
План обучения и аттестации персонала
Программа: вводный курс, квартальные короткие тренинги, годовая аттестация (теория + практическая часть).
Темы: работа с АРМ, ИБ-угрозы, процедура IRP, GDPR/152-ФЗ основы хранения ПДн, физическая безопасность.
Результат: сертификат оператора, обновление прав доступа.
План аудита и контроля
Виды аудитов: внутренний (ежеквартально), внешний (годовой пен-тест), физические инспекции (полугодно).
Метрики: MTTR инцидента, среднее число ложных тревог, % устройств с актуальной прошивкой, % несоответствий по регламентам.
Отчётность: руководству и службе ИБ, корректирующие действия и сроки исполнения.
Формы и шаблоны (необходимые примеры)
Форма выдачи пропуска – ID, ФИО, подразделение, тип пропуска, срок действия, подпись выдающего, основания.
Акт изъятия пропуска – ID карты, причина, дата/время, кто забрал, подтверждение передачи в архив.
Инцидентный репорт – ID, категория, краткое описание, время обнаружения, задействованные лица, предпринятые меры, последствия, рекомендации.
Журнал APB-нарушений – дата, карта, точка, оператор, фото.
Change Request – инициатор, описание, влияние, тест-план, откатный план, утверждения.
Роли, ответственности и SLA
Владелец системы (R) – утверждение политик, бюджет.
Служба эксплуатации (A/R) – ежедневная эксплуатация, выполнение SOP.
Служба ИБ (C/A) – мониторинг, аудит, утверждение изменений, инцидент-менеджмент.
Кадровая служба (C) – инициирование запросов на выдачу/аннулирование пропусков.
Поставщик ПО (C) – поддержка, выпуск патчей, выдача релиз-нот.
Руководство (I/A) – утверждение ключевых регламентов и изменение SLA.
Таблица 5
Матрица RACI для эксплуатации и сопровождения АС КУД «Стилпост»
Таблица 5 – матрица RACI – показывает кто за что отвечает при эксплуатации и сопровождении АС КУД «Стилпост»: кто выполняет работу, кто утверждает/несёт ответственность, кого привлекают как эксперта и кого нужно информировать.
Процесс внедрения документации (пошагово)
Составление проекта документов (служба ИБ + эксплуатация).
Согласование с юридическим отделом и представителем ФСИН (по режимным требованиям).
Пилотное применение (одна зона – 1 месяц).
Корректировка по результатам пилота.
Утверждение руководителем Центра.
Обучение персонала и вступление в силу.
Мониторинг исполнения и ежегодный пересмотр.
Контрольные точки качества
Здесь определим KPI для разделов документации:
Доля персонала, прошедшего аттестацию ≥ 95 %.
Время реакции на инцидент (первичный отклик) ≤ 5 мин для критических.
Доля соответствия журналов требованиям (наличие цифровой подписи) – 100 %.
Тест восстановления (DR) – успешно ≥ 1 раз в квартал.
Примеры: краткий шаблон инцидентного репорта (поля)
Уникальный ID инцидента.
Дата/время обнаружения.
Обнаружившее лицо/система.
Краткое описание.
Категория (APB, Physical tamper, Network compromise, Data leak).
Действия containment.
Восстановление (да/нет, время).
Последствия (оценка).
Рекомендации.
Подписи ответственных.
Примечания по согласованию с регуляторами и ведомственными требованиями
Все регламенты и инструкции должны быть проверены юридическим отделом на соответствие 152-ФЗ.
Для ФСИН – отдельный модуль требований: хранение журналов, обмен данными с ведомственными системами и порядок предоставления сведений по запросу уполномоченных лиц.
Ресурсы на разработку и сроки (оценочно)
Составление комплекта документов (первичная версия): 4–6 недель (команда: 1 ведущий специалист ИБ, 1 инженер СКУД, 1 юрист, 1 представитель эксплуатации).
Пилот и корректировка: 4 недели.
Обучение персонала: 2 недели (серии коротких занятий).
Разработанный таким образом комплект организационно-распорядительных документов формализует технические решения модернизации СКУД «Стилпост» в управляемые процессы – убирает двусмысленность ответственности (RACI), снижает риски человеческой ошибки через регламентированные процедуры и обучение, обеспечивает соответствие 152-ФЗ/требованиям ФСТЭК и ФСИН, а также задаёт механизмы контроля (аудит, тесты восстановления, регулярные проверки) и порядок внедрения изменений (стенд → пилот → продакшн) для гарантированной безопасности и устойчивости работы системы.
ЭКОНОМИЧЕСКИЙ РАЗДЕЛ
Оценка затрат на реализацию предложенных мероприятий по развитию СКУД «Стилпост»
Ниже приведены основные статьи затрат с единичной оценкой и источниками:
Контроллеры доступа STS-407K – 12 шт. × ≈ 40 825 ₽/шт = 489 900 ₽. (ориентир по розничным предложениям STS-407/STS-407К) [43].
Проксимити-считыватели (антивандальные, формат EM-Marin / Wiegand) – 24 шт. × ≈ 3 000 ₽/шт (ориентир 1–9k ₽ в рознице) = 72 000 ₽. (широкий диапазон цен – от ~1 000 ₽ до 9 000 ₽ в зависимости от модели/вандалозащиты) [44, 47].
Шлюзовые/электромеханические турникеты – 2 шт. × ≈ 60 000 ₽/шт = 120 000 ₽. (рыночные предложения модели трипод/компакт-турникеты в диапазоне ~50–80k ₽) [45].
Сервер (стойка 1U/2U для сервиса «Стилпост», БД, журналов) – 1 шт. × ≈ 150 000 ₽ = 150 000 ₽ (ориентир: бюджетный rack-сервер в рознице) [48].
АРМ оператора / админа (ПК, монитор, периферия) – 2 шт. × ≈ 60 000 ₽/шт = 120 000 ₽. (классические рабочие станции) [48, 50].
Программные лицензии и модули «Стилпост» (обновление/модули: Бюро пропусков, Мониторинг событий и др.) – ориентировочно ≈ 250 000 ₽ (оценка / возможна договорная цена у вендора – часто «по запросу»); на сайте производителя модули описаны, цены – по запросу [46].
Интеграция и пусконаладочные работы (проектирование, монтаж, настройка, тесты) – ≈ 10 человеко-дней × 25 000 ₽/день = 250 000 ₽ (ориентир на рыночные прайсы интеграции: пакеты настройки/интеграции и прайсы системных интеграторов) [49].
Обучение персонала и методические материалы – ≈ 100 000 ₽ (проведение 1–2 дней обучения для операторов и админов; материалы, печать, тест-стенд).
SIEM / журналирование (инфраструктура + годовые операционные расходы) – вариант «базовый»: инфраструктура ≈ 200 000 ₽ + годовые операционные расходы ≈ 300 000 ₽ (если выбирать self-hosted ELK-/Elastic-решение с профессиональной поддержкой/сервисом – суммы сильно варьируются). Для коммерческих решений (Splunk/Elastic Cloud) цена может быть существенно выше – требует запроса прайс-оферты [51].
UPS, коммутация, стойка, монтажные материалы – ≈ 100 000 ₽ [48].
Опционально: аппаратный модуль HSM / ПАКМ (для ключевого хранения крипто-ключей, ФСБ/ФСТЭК-классовая защита) – ≈ 1 600 000 ₽ (ориентир на российские решения типа «КриптоПро HSM / ПАКМ» и аналоги) – опция для строгих требований по защите ключей [50].
Итого (оценочно, без НДС):
Базовый вариант (полная модернизация без HSM) – суммарно по строкам: ≈ 2 151 900 ₽ (subtotal) → с учётом резерва 15% на непредвиденные расходы и монтажные изменения → ≈ 2 474 685 ₽.
Расширенный (с HSM и полным набором сервисов) – суммарно: ≈ 3 751 900 ₽ (subtotal) → с 15% contingency → ≈ 4 314 685 ₽.
В расчётах использованы указанные выше ориентиры. Подробная табличная раскладка ниже (табл. 6).
Таблица 6
Детализация (ориентировочные суммы)
Примечание к табл. 6: лицензии «Стилпост» и цены лицензирования модулей часто идут «по запросу» у вендора; в сумму взята оценка – для точного бюджета требуется коммерческое предложение от Stilsoft.
Расчёт ожидаемого экономического и операционного эффекта
При оценке экономического эффекта проекта важно учитывать не только прямые денежные выгоды, но и косвенные операционные эффекты, которые влияют на производительность и надёжность работы учреждения. Поэтому в расчётах мы последовательно включили четыре группы эффектов, каждая из которых даёт свой вклад в годовой экономический результат:
Снижение трудозатрат на администрирование. Автоматизация «Бюро пропусков», интеграция с табелированием и упрощение процедур выдачи/аннулирования пропусков уменьшают время, затрачиваемое сотрудниками кадровой службы и операторами СКУД на рутинные операции. Это прямое сокращение фонда рабочего времени и, соответственно, фонда оплаты труда.
Снижение потерь/издержек от инцидентов безопасности. Улучшенная защита (замена Wiegand на OSDP, мониторинг, SIEM, физическая защита контроллеров) уменьшает вероятность и/или масштабы инцидентов (несанкционированный доступ, подмена журналов, восстановительные работы), что даёт экономию на восстановлении и сопутствующих потерях.
Операционные эффекты (повышение скорости прохода, уменьшение очередей). Сокращение времени прохода сотрудников повышает фактор полезного рабочего времени и уменьшает простои, а также повышает оперативность процессов, что можно оценить в денежном эквиваленте через среднюю стоимость рабочего часа.
Качественные (немонометарные) эффекты. Соответствие ФСИН/ФСТЭК, улучшение доказательной базы, снижение регуляторных рисков – важны для принятия проекта, но прямо в годовой денежный эффект их включать не будем; тем не менее они повышают обоснованность инвестиций.
Эти четыре группы покрывают как прямые экономические выгоды, так и операционные улучшения, поэтому итоговая годовая экономия – суммарный эффект по всем четырём пунктам.
Для числовых расчётов принимаются следующие допущения (основания и ссылки указаны в конце):
Параметры экономии времени HR (кадровая служба):
Экономия за счёт автоматизации: ≈ 20 часов/месяц = 240 часов/год.
Средняя месячная зарплата специалиста по кадрам (ориентир): 55 632 ₽/мес.
Для перевода в почасовую ставку используем стандартное деление на 160 часов/мес (1):
Годовая экономия HR (2):
Параметры экономии времени администратора/оператора:
Экономия: ≈ 260 ч/год (автоматизация мониторинга, меньше ручных процедур).
Средняя месячная зарплата системного администратора (ориентир): 149 792 ₽/мес.
Почасовая ставка (3):
Годовая экономия админов (4):
Снижение расходов от инцидентов:
Консервативная оценка годовой экономии за счёт уменьшения числа и тяжести инцидентов: 300 000 ₽/год.
Операционная выгода – скорость прохода сотрудников:
Число регулярных сотрудников, учитываемых в расчёте: 150 чел.
Экономия времени на каждого – 1 мин/день после модернизации.
Количество рабочих дней в году: 250 (учёт выходных/праздников).
Общее сохранённое время в минутах (5):
Перевод в часы (6):
Для оценки денежной эквивалентности используем упрощённую среднюю «стоимость рабочего часа» (оценочный показатель эффективности труда) – 500 ₽/ч.
Годовая операционная экономия (7):
Все почасовые ставки и численности – ориентировочные; при подготовке окончательной сметы и экономического обоснования следует подставить реальные данные предприятия (фактические зарплаты, точное число сотрудников, фактическая длительность прохода).
Суммируем годовые составляющие (каждая величина уже рассчитана выше):
Автоматизация HR: 83 448 ₽/год.
Экономия админ/операторного труда: 243 412 ₽/год.
Снижение прямых потерь от инцидентов: 300 000 ₽/год.
Операционная выгода (скорость прохода): 312 500 ₽/год.
Сумма годового эффекта (8):
Итого примерная годовая экономия ~ 939 360 ₽/год.
Это – консервативная агрегированная оценка прямых и косвенных годовых выгод; при других допущениях (например, большее сокращение времени прохода или более значимые потери от инцидентов) итог будет выше.
Оценка экономической целесообразности и ожидаемого срока окупаемости проекта развития АС КУД
Используем простую формулу простого срока окупаемости (без дисконтирования, для предварительной оценки) (9):
Расчёты по вариантам:
Базовый (CAPEX ≈ 2 474 685 ₽; см. раздел 4.1):
Промежуточные шаги: ; остаток ; – поэтому итог .
Расширенный (с HSM, CAPEX ≈ 4 314 685 ₽):
Интерпретация: для бюджетных и государственных учреждений срок окупаемости 2,5–3 года часто считается приемлемым для инвестиций в безопасность и автоматизацию; вариант с HSM удлиняет период до ~4.6 лет – это оправдано при строгих нормативных требованиях к хранению ключей, но требует дополнительного обоснования.
Чтобы понять, насколько чувствительна окупаемость к изменениям в годовой экономии, рассмотрим два сценария (±25% от базового эффекта):
Сценарий −25% годовой экономии: годовой эффект (12).
Сценарий +25% годовой экономии: годовой эффект .
Вывод по чувствительности. Основные драйверы окупаемости:
снизу (затраты): стоимость лицензий и интеграции – эти позиции способны значительно увеличить CAPEX;
сверху (выгода): реальная операционная экономия (сокращение времени прохода, сокращение времени администрирования) и уменьшение затрат на инциденты – эти параметры во многом зависят от того, насколько хорошо реализованы автоматизация и интеграция; изменение эффектов на пилоте даст точные значения.
Для академической строгой оценки посчитаем NPV и IRR с учётом дисконтирования (например, ставка дисконтирования 8–12% для государственного учреждения) и учесть операционные OPEX (поддержка, лицензии), а также налоги/НДС.
Входные данные и допущения:
CAPEX (инвестиции) – ориентировочные суммы из ранее согласованной сметы:
Базовый вариант (без HSM): 2 474 685 ₽ (включая contingency 15%).
Расширенный (с HSM): 4 314 685 ₽.
НДС (налог) – принял 20% и учёл НДС как единовременную надбавку к CAPEX (т. е. текущая закупка оплачивается с НДС):
формула для расчёта первичного денежного оттока, если при оплате капитальных затрат нужно заплатить НДС 20% «прямо сейчас» .
Базовый вариант = 2 969 622 ₽.
Расширенный = 5 177 622 ₽.
Годовые денежные эффекты (входы) – использованы ранее рассчитанные годовые выгоды: 939 360 ₽/год (суммарно: экономия HR + экономия админов + снижение потерь от инцидентов + операционная выгода).
Годовые операционные расходы (OPEX) – добавлены ежегодные расходы на поддержку/эксплуатацию:
SIEM/поддержка и сопутствующие сервисы (ориентир): 300 000 ₽/год;
поддержка лицензий (оценочно 10% от ПО 250 тыс. ₽) ≈ 25 000 ₽/год;
сервисное обслуживание аппаратуры (≈ 5% от аппаратного блока ≈ 52 595 ₽/год).
Для расширенного варианта добавлено обслуживание HSM ≈ 80 000 ₽/год, поэтому OPEX (расширенный) ≈ 457 595 ₽/год.
Чистый годовой денежный поток = годовая выгода − OPEX:
Базовый вариант: 939 360 − 377 595 = 561 765 ₽/год.
Расширенный: 939 360 − 457 595 = 481 765 ₽/год.
Горизонт анализа: стандартно берем 5 лет для основной оценки (короткий академический горизонт). Дополнительно показаны результаты за 10 лет, т.к. безопасность часто окупается дольше.
Ставки дисконтирования для NPV: приняты три сценария: 8%, 10%, 12% (рекомендуемые значения для учреждений/проектов).
Формулы расчета:
где – чистый денежный поток в год , – ставка дисконтирования, – горизонт (лет).
IRR: ставка 𝑟, при которой .
Простая окупаемость:
Результаты расчётов:
Простая окупаемость (без дисконтирования, с НДС и OPEX учтёнными в годовых потоках):
Базовый вариант Initial = 2 969 622 ₽, годовый net = 561 765 ₽ → Payback ≈ 5,29 года.
Расширенный Initial = 5 177 622 ₽, годовой net = 481 765 ₽ → Payback ≈ 10,75 года.
Эти результаты показывают, что при учёте НДС и реальных OPEX простой срок окупаемости увеличивается по сравнению с ранним грубым подсчётом (без OPEX и без НДС).
Таблица 7
NPV за 5 лет (три ставка дисконтирования):
Интерпретация результатов из табл. 7: для 5-летнего горизонта при выбранных ставках NPV отрицательный и для базового варианта, и тем более для расширенного – проект не окупается за 5 лет с учётом НДС и ежегодных OPEX.
Таблица 8
NPV за 10 лет и IRR (10 лет)
Из табл. 8 следует:
Для базового варианта: при длинном горизонте (10 лет) проект даёт положительную NPV и IRR (~13.66%), превышающую предложенные ставки 8–12% → проект выгоден на 10-летнем горизонте.
Для расширенного (с HSM): остаётся убыточным при всех вариантах – вложение в HSM значительно увеличивает начальный отток и уменьшает рентабельность; IRR даже отрицателен за 10 лет.
Модернизация АС КУД «Стилпост» в базовом варианте требует ориентировочного капитального вложения ≈ 2,47 млн ₽ (с резервом 15%) и при консервативной оценке даёт совокупную годовую экономию ≈ 0,94 млн ₽/год; простая окупаемость по этому сценарию без учёта НДС/OPEX ≈ 2,6 года, а при учёте НДС (20%) и реальных годовых OPEX – ≈ 5,3 года. При финансовом анализе с учётом дисконтирования проект по базовому сценарию даёт отрицательную NPV за 5 лет при ставках 8–12%, но положительную NPV за 10 лет (при r=10% ≈ +482 тыс. ₽) и IRR ≈ 13,7% – то есть проект экономически оправдан при долгосрочном горизонте. Вариант «Расширенный» с аппаратным HSM резко увеличивает CAPEX (≈ 4,31 млн ₽) и остаётся невыгодным в рассматриваемых сценариях (отрицательная NPV и IRR даже на 10 лет) – оправдан только при формальном нормативном/режимном требовании к аппаратному хранению ключей.
Практические рекомендации (приоритеты):
Реализовать поэтапно: пилот → масштабирование базового варианта → HSM только при явной необходимости.
Запустить пилот (1–3 месяца) в 1–2 точках для точного измерения экономии времени прохода и администрирования – результаты пилота дадут корректные «входные» данные для окончательной сметы и NPV/IRR.
Получить актуальные коммерческие предложения от Stilsoft (лицензии/модули) и от 2–3 интеграторов (оборудование, монтаж, поддержка) – цены по позициям (особенно лицензии) существенно влияют на CAPEX.
Уточнить налоговую схему (НДС) с бухгалтерией – возможный возврат/зачёт НДС заметно улучшит экономику проекта.
Ограничить покупку HSM – рассматривать аппаратный модуль как опцию «по требованию» (если ФСИН/ФСТЭК или анализ рисков потребуют жесткой защиты ключей) – до тех пор применять программный KMS и жёсткие процедуры.
В целом модернизация целесообразна, если организация готова смотреть на 5–10-летний горизонт и/или подтвердит пилотом операционные выгоды. Дорогостоящие опции (HSM) следует вводить только при строгих режимных показаниях или после дополнительного экономического обоснования.
