Программные продукты в системах безопасности: рынок, функционал, киберзащита

Сегодня рынок требует программных комплексов и решений, которые могут бесперебойно работать с отечественными операционными системами, обеспечивая стабильность, безопасность и надлежащий контроль на объектах. Сначала, в виду массового тренда на импортозамещение, отечественный софт стал появляться в госсекторе, сейчас к этому активно подключились коммерческие организации. Мы пригласили экспертов из компаний "Итриум СПб", BIOSMART, "КомплИТех", МПК "СОАР", "АРМО-Системы", "СБ Инжиниринг", "ААМ Системз", "ТвинПро" и "РУБЕЖ" рассказать о важности программных продуктов в системах безопасности, возможности их масштабирования, взаимосвязи, обеспечении киберзащиты и т.п.

Расскажите о достоинствах и недостатках кросс-платформенных программных комплексов для управления СКУД и ИСБ, об их работе с отечественными операционными системами. Что востребовано рынком и что предлагают разработчики?

Денис Иванов, Итриум СПб

Мне кажется, что по сути своей вопрос адресован системным интеграторам, которые хорошо знакомы с имеющимися на рынке продуктами, знают своих заказчиков, их потребности и задачи. Мы же, как производители, выпустившие первый кросс-платформенный программный комплекс еще в 2008 г. (до того, как это стало мейнстримом), можем иметь искаженный взгляд на вещи, и тем не менее. Начнем с того, что, по нашему мнению, пока рано рассуждать о достоинствах и недостатках существующих кросс-платформенных программных комплексов (ПК): большинство разработчиков еще только в начале этого пути. Настолько, что возможность запустить свое программное обеспечение (ПО) в среде операционной системы Linux под Wine выдают за кросс-платформенное решение.

Кроме того, имеет место подмена понятий: сегодня на рынке востребована не кросс-платформенность, а возможность использования прикладного ПО в среде отечественных операционных систем (то есть отказ от Windows). И актуальная кросс-платформенность сужается до возможности работы ПО под управлением разных "семейств" Linux (например, РЕД ОС, Astra Linux, Alt Linux и т.д.). Для кого-то это может быть сюрпризом, но даже такая кросс-платформенность требует отдельных немалых усилий со стороны разработчика.

Егор Голубкин, BIOSMART

В последние несколько лет прослеживается четкая тенденция перехода многих компаний на отечественные операционные системы, потому что в первую очередь покупать лицензии на Windows стало сложно, нелегитимно и небезопасно. Сначала, ввиду массового тренда на импортозамещение, отечественный софт стал появляться в госсекторе, но и коммерческие организации сейчас к этому активно подключились. Именно поэтому практически все современные производители систем контроля и управления доступом (СКУД) и интегрированных систем безопасности (ИСБ) уже давно адаптировались к этому фактору и обеспечили совместимость своих продуктов с отечественными ОС, такими как Astra Linux и РЕД ОС.

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

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

Алексей Лагойко, КомплИТех

Кросс-платформенность – это способность программных комплексов для СКУД и ИСБ легко разворачиваться и полноценно функционировать на разных операционных системах (ОС). Для этого необходимо изначально проектировать программное обеспечение с правильной архитектурой. По-настоящему кросс-платформенным будет ПК, реализованный как клиент-серверное решение с тонкими клиентами на базе веб-технологий. Движение в данном направлении началось, но пока не стало массовым.

Будем откровенны: до 2022–2023 гг. около 90% отечественных производителей СКУД и ИСБ разрабатывали свои решения исключительно для ОС Windows. использовали такие языки программирования, как С++, и среды разработки вроде Delphi и Microsoft Visual Studio. Мало кто предполагал, что однажды от этого придется отказаться.

Большинство существующих решений на нашем рынке представляют собой скомпилированные программные продукты. Сделать их кросс-платформенными с помощью веб-технологий означает фактически переписать систему с нуля. Некоторые разработчики, создающие толстые клиенты, предусмотрительно использовали кросс-платформенные библиотеки Qt для языка C++. Это облегчает им задачу модернизации ПО для работы на отечественных ОС. Они не могут быстро перейти на веб-технологии, но, по крайней мере, способны перекомпилировать свое ПО и двигаться дальше.

Аркадий Созданов, МПК "СОАР"

О достоинствах. Это единый интерфейс для всех платформ, код пишется один раз и используется на нескольких платформах, вероятность возникновения ошибок снижается. При этом наблюдается экономия по финансовым затратам, не нужно создавать отдельные версии для каждой платформы, пользователи могут использовать одно приложение для разных устройств. То есть единый интерфейс для всех платформ – это главный плюс.

Недостатки. При работе на разных устройствах и ОС возникают проблемы с совместимостью ПО и железа. При разных архитектурах и возможностях СКУД и ИСБ могут быть недоступны некоторые опции, при медленной работе ограничивается функциональность, для СКУД важным фактором является быстрота реакции на события. При использовании веб-технологий программы могут иметь сниженную реакцию на изменения в системе СКУД (например, добавить/удалить ключ у сотрудника), поскольку ПО должно интерпретировать код вместо его компиляции. Обновление ПО на новые версии может стать невозможным.

Предлагаемые продукты для кросс-платформенных ПК:

• Xamarin – платформа от Microsoft, с использованием C# и .NET, с доступом к API;
• Ionic Framework – гибридный фреймворк, который использует HTML5, CSS;
• Cordova (PhoneGap) – фреймворк, который позволяет использовать HTML, CSS. JavaScript.

Вячеслав Петин, АРМО-Системы

К достоинствам таких ПК следует отнести в первую очередь совместимость с различными ОС, в том числе российскими (на данный момент самая востребованная из них – Astra Linux).

Среди преимуществ также снижение затрат на ИТ-инфраструктуру и обслуживание, соответствие требованиям импортозамещения.

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

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

Андрей Артюшкин, СБ Инжиниринг

За последние несколько лет почти все отечественные разработчики программных комплексов систем безопасности обеспечили кросс-платформенность своим продуктам. Кто-то из разработчиков начал доработку комплексов для поддержки российских ОС сразу после приказа Министерства связи и массовых коммуникаций РФ № 334 от 29 июня 2017 г., кто-то позже.
Безусловно, поддержка программных комплексов систем безопасности российскими ОС – это еще большой шаг вперед для наших российских разработчиков, но при этом есть ряд проблем.

Во-первых, достаточно мало ИТ-специалистов, готовых обеспечить качественное администрирование российских ОС, во-вторых, мало специалистов, готовых настроить и обеспечить поддержку информационной безопасности на российских ОС. В-третьих, если мы говорим об интегрированных системах безопасности, то очень часто бывает, что в таких системах найдется сегмент смежного (интегрируемого) программного комплекса или вспомогательный программный модуль, который будет требовать наличие платформы Microsoft, так как этот сегмент или модуль пока не адаптирован для работы на российских ОС. Пока также есть проблемы с поддержкой виртуализации и альтернативами для AD. Уверен, что все эти проблемы или уже имеют решение, или решаемы в будущем, доля российских ОС растет, и главным достоинством этого роста является явно заданный тренд на обеспечение технологической независимости.

Алексей Гинце, ААМ Системз

Что касается первой части вопроса, можно привести простой пример. У вас имеется два варианта программного комплекса, один нативный, другой кросс-платформенный, при этом оба выполняют одну ту же задачу. Один из этих ПК жестко привязан к определенной ОС и не позволяет выбрать систему управления базами данных (СУБД), например можно использовать только Windows и Microsoft SQL Server, другой может работать на операционных системах как Windows, так и Linux (включая отечественные ОС "РЕД ОС", ОС "Альт", Astra Linux), и поддерживает разные СУБД (например, PostgreSQL, ORACLE, Microsoft SQL Server и пр.). Достоинства первого – специализация, меньшее время разработки и, скорее всего, лучшая оптимизация, второго – универсальность и возможность работы на разных устройствах и платформах.
Что является достоинством или недостатком – зависит от потребителя и решаемой задачи, но есть один нюанс.

Госкомпаниям и компаниям, осуществляющим закупки по 223-ФЗ, было запрещено с 2022 г. закупать для использования на объектах критической информационной инфраструктуры зарубежные ИТ-решения, а с 2025 г. – их использовать. Это выводит в лидеры кросс-платформенные программные комплексы, поддерживающие отечественные ОС. Для коммерческого сегмента это не столь актуально, но в крупных многофилиальных системах кросс-платформенное ПО, обладающее высокой гибкостью, также, скорее всего, будет иметь преимущества за счет возможности более точно настроить решение под особенности каждого филиала компании.

Павел Фомичёв, ТвинПро

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

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

К сожалению, не все производители и разработчики готовы к оперативному переводу своих продуктов к работе на базе отечественных ОС. К тому же, имея достаточно давнюю историю применения продуктов на старых (недружественных) ОС, необходимо обеспечить совместимость этих решений. Простыми словами, заказчик должен иметь возможность внедрения нового продукта ОС Linux и подключать к нему старые версии ИСБ на базе продукта этого же производителя, но используя ОС Windows. Это дает возможность пользователю переходить на новые ОС без остановки работы больших распределенных систем, поэтапно.

Михаил Андрющенко, РУБЕЖ

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

Кросс-платформенные решения для систем безопасности – это программное обеспечение, которое может работать на различных операционных системах и устройствах. В ряде случаев это достигается за счет использования веб-интерфейса.

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

Возьмем, к примеру, систему контроля доступа, построенную на веб-контроллерах. Доступ к системе осуществляется через веб-интерфейс, что позволяет избежать необходимости выделенного сервера. Каждый контроллер сам по себе является мини-сервером, что делает продукт универсальным и применимым на любых объектах. автоматическое рабочее место (АРМ) можно развернуть почти на любых устройствах.

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

ПК для СКУД и ИСБ в контексте поддержки аппаратного обеспечения (контроллеров) разных производителей. Есть ли такие решения на рынке и какие задачи с их помощью можно решить? Достоинства и недостатки такого ПО, что может заинтересовать потребителя?

Денис Иванов, Итриум СПб

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

Многие разработчики утверждают, что их ПО поддерживает оборудование разных производителей. Но что это, как правило, значит в реальной жизни? Обычно то, что интеграция выполняется в соответствии с конкретными требованиями технического задания (ТЗ), в котором на практике невозможно учесть всю специфику оборудования, ПО, предусмотреть все особенности бизнес-процессов и в полной мере осознать разделение сфер ответственности (производителей оборудования, разработчика ПО, интегратора, заказчика(!)).

Очень часто результат такой интеграции в дальнейшем начинает тиражироваться разработчиком ПО как законченное серийное интегрированное решение (без актуализации протоколов, особенностей прошивок оборудования, расширения спектра оборудования и т.д.).

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

Если же ни то, ни другое невозможно (оборудование разных производителей уже установлено, и его замена в не рассматривается ни при каких условиях) – что ж, можно выбирать интеграционное решение. Но отдавая себе отчет в том, что интеграция – это не результат, а процесс, часто мучительный, и внедренное решение будет интегрированным здесь и сейчас (в момент внедрения), но неизбежно будет "разъезжаться" в процессе эксплуатации.

Алексей Лагойко, КомплИТех

Вопрос поддержки контроллеров разных производителей программными комплексами для СКУД и ИСБ упирается в глубину интеграции. Некоторые разработчики заявляют, что готовы интегрировать любые контроллеры, но на практике ограничиваются лишь базовыми функциями – синхронизацией картотеки пользователей и общей базы данных (БД). Они не создают многовендорную СКУД с полноценным функционалом, включая эмиссию карт доступа, настройку прав доступа, управление режимами работы контроллеров, поддержку антипассбэка, настройку зон и др. Таких решений не существует.

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

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

Не каждый производитель будет рад сотрудничать – велик риск потерять долю рынка. Ведь заказчики, ранее установившие зарубежные СКУД с большим количеством оборудования, которое еще не исчерпало свой жизненный цикл, быстро оценят выгоды мультиплатформы, которая позволит им полноценно интегрировать старые контроллеры и постепенно внедрять новые. Появится ли когда-нибудь такая платформа? Возможно.

Аркадий Созданов, МПК "СОАР"

Поддержка аппаратного обеспечения (контроллеров) разных производителей возможна только на кросс-платформенных программных комплексах, но при этом производитель контроллеров должен отдать свой протокол (коды, прошивки и т.д.) разработчику ПК, что для производителя практически неприемлемо. Для потребителя это обеспечивает надежность комплекса в целом.

Вячеслав Петин, АРМО-Системы

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

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

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

Андрей Артюшкин, СБ Инжиниринг

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

Но существуют различные PSIM-платформы (Physical Security Information Management) более высокого уровня, позволяющие объединить оборудование и системы от разных производителей. При всех достоинствах таких систем эти решения требуют достаточно больших ресурсов в проработке и разработке технического задания, проекта, программировании, изменении и организации внутренних процессов, а также в реализации задачи в целом. Поэтому для наиболее эффективного решения задач безопасности на объектах в первую очередь необходим аудит существующего оборудования и систем заказчика-потребителя, четкое описание текущих задач, а также необходимо спрогнозировать развитие потребностей заказчика на будущее. Исходя из этого, уже можно будет предложить заказчику оптимальные варианты решения текущей поставленной задачи.

Алексей Гинце, ААМ Системз

Такие решения на отечественном рынке есть. Приведу конкретный пример на основе опыта нашей компании. Мы долгое время являлись дистрибьютором и предлагали контроллеры управления СКУД и ОС одной из известных западных компаний. При этом для управления мы использовали программные комплексы собственной разработки. В 2022 г. мы выпустили на рынок свою линейку оборудования, разрабатываемую и производимую в России. Наш зарубежный партнер не прекратил взаимодействия с нами, но усложнилась логистика и выросла стоимость импортного оборудования. С учетом текущих предпочтений заказчиков по внедрению полностью отечественных решений (как ПО, так и железа) возник вопрос: как расширять огромный парк имеющихся систем без потери установленного импортного оборудования? С помощью нашего ПО мы реализовали интеграцию этих СКУД в единую систему и успешно работаем как с зарубежным, так и с нашим оборудованием одновременно.

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

Павел Фомичёв, ТвинПро

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

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

Михаил Андрющенко, РУБЕЖ

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

На данный момент не существует готовых решений, система сбора и обработки информации (ССОИ) на рынке РФ больше проектный продукт, чем массмаркет. Прайсы и лицензионная политика большинства компаний закрыта.

Применительно к ПО для управления СКУД и ИСБ – что во что входит или как взаимодействует: ССОИ, PSIM, ИСБ? Какие решения есть на отечественном рынке?

Денис Иванов, Итриум СПб

Очевидно, что СКУД – это часть ИСБ. Очевидно, что для того, чтобы ИСБ выполняла свои задачи по назначению, в ней должна быть ССОИ. PSIM же – это "надстройка" над ИСБ и ее ССОИ, нацеленная на выполнение определенных бизнес-процессов обеспечения безопасности с максимальной эффективностью, скоростью, прозрачностью, понятностью и удобством.

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

Алексей Лагойко, КомплИТех

1. ПО СКУД предназначено для контроля и управления доступом на объекты, в помещения и к ресурсам. Выполняет задачи идентификации пользователей, управления точками входа и регистрации событий доступа.
2. ПО ИСБ объединяет разные системы безопасности (СКУД, видеонаблюдение, охранная и пожарная сигнализация) в единое решение для централизованного мониторинга и управления.
3. ПО ССОИ аккумулирует данные от различных систем безопасности (СКУД, видеонаблюдение, охранка и др.), обеспечивая их анализ и отображение. Может быть частью ИСБ.
4. ПО PSIM позволяет интегрировать системы безопасности и другие информационные системы предприятия в единую среду управления, обеспечивая централизованный мониторинг инфраструктуры, обработку инцидентов на основе регламентов и сценариев, а также координацию действий служб. Охватывает не только задачи физической безопасности, но и вообще все критические аспекты, влияющие на бесперебойную работу предприятия.

PSIM включает в себя ИСБ, которая объединяет СКУД и ССОИ в качестве отдельных подсистем. PSIM может получать данные как от сервера ИСБ, так и напрямую от серверов СКУД, видеонаблюдения и других подсистем в зависимости от задач и архитектуры системы. В некоторых случаях эффективнее работать через ИСБ, а в других PSIM управляет подсистемами напрямую для более глубокого взаимодействия с отдельными компонентами и более быстрого реагирования.

Аркадий Созданов, МПК "СОАР"

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

Вячеслав Петин, АРМО-Системы

ССОИ – это система, основной задачей которой является сбор, анализ и передача информации в другие системы (пример – R-PLATFORMA от RUBEZH).

PSIM – интеграционная платформа для управления данными от различных систем, в том числе и ССОИ, которая обеспечивает контроль, визуализацию, автоматизацию реагирования и управление событиями (например, PSIM NEST от АО НПЦ "ЭЛВИС", "Интегра-С" от "Консорциум "Интегра-С").

ИСБ – комплексная система, включающая в себя множество подсистем, таких как СКУД, СОТ, СОС и т.д., которая может получать и работать с данными от ССОИ и PSIM (пример – Timex от Smartec).

Андрей Артюшкин, СБ Инжиниринг

На российском рынке нет единых стандартов-требований к взаимодействию СКУД, ИСБ, ССОИ и PSIM. На рынке было и есть много примеров, где СКУД играет второстепенную роль в других сторонних системах и использует для работы не собственную, а чужую БД (например, билетные системы). Поэтому говорить о том, как должно быть, не совсем корректно. Если говорить о классическом представлении в области систем безопасности, то СКУД является составляющей частью ИСБ и в большинстве случаев использует общую, единую БД. ССОИ при этом может являться как независимой системой (для сбора и логирования информации для дальнейшего стороннего аудита действий), так и в составе PSIM, где она играет вспомогательную роль. Взаимодействие между системами также может быть различным – через API, SDK, прямое обращение к БД, отработка скриптов, использование автоматических отчетов с данными и т.д. При выборе PSIM-системы, опять же повторюсь, необходимо руководствоваться принципом необходимости и достаточности не только в текущем времени, но и с учетом будущих задач. По сути, внедрение PSIM на различных предприятиях можно сравнить с индивидуальным пошивом костюма. Никогда не бывает одинаковых стандартных решений, все проекты получаются индивидуальными.

Алексей Гинце, ААМ Системз

Много лет на рынке существуют решения, которые я и многие коллеги относим к разряду ИСБ. Под этим термином я подразумеваю прежде всего базовую четверку систем безопасности: системы контроля и управления доступом, системы теленаблюдения, системы охранной сигнализации, системы пожарной сигнализации, взаимодействующие между собой на аппаратном и/или программном уровне. Этот базовый набор может быть сокращен или расширен в зависимости от потребностей заказчика и характера объекта защиты. В такой набор могут войти и другие системы: охраны периметра, управления доступом автотранспорта, досмотровые и пр. Разные компании-интеграторы исторически приходили к ИСБ с разных сторон, кто-то со стороны охранно-пожарной сигнализации, кто-то со стороны систем теленаблюдения, а кто-то – со стороны СКУД. Исходя из собственного почти тридцатилетнего опыта работы в отрасли, могу сказать, что для крупных ИСБ в качестве основы подходит именно СКУД как система с наиболее сложной и развитой аппаратной логикой. К сожалению, формат материала не позволит привести весь список аргументов в пользу этого утверждения.

В ИСБ интеграция систем может осуществляться как на аппаратном уровне (пришла тревога – замкнул реле на панели ОС, включил камеру CCTV, заблокировал проход СКУД), так и на программном (например, через драйвер соответствующего оборудования СКУД, CCTV или ОПС, запущенный на управляющем компьютере). Объясняю предельно упрощенно, чтобы постараться выделить отличия ИСБ от ССОИ и PSIM. Не хочу еще больше запутывать ситуацию, но достаточно распространен еще термин КСБ (комплексные системы безопасности). Искать различия с ИСБ не буду, на мой взгляд это близкие понятия!

ССОИ – система сбора и обработки информации. Перечень систем, которые должны быть интегрированы в ССОИ, указан в постановлении Правительства РФ № 969. В принципе все системы, упомянутые выше как возможная составная часть ИСБ, могут входить в ССОИ. Главная задача ССОИ – сбор, хранение и обработка информации от входящих в нее систем, а также выдача в удобном виде данных операторам и администраторам системы для принятия дальнейших решений по управлению объектом. В ССОИ возможна автоматизация действий и реакций на основе заранее заложенных алгоритмов взаимодействия подсистем. Я это формулирую как "конструктор последовательности действий (реакций)" на полученную от подсистем информацию. Реакция выполняется либо человеком-оператором (через подсказки и инструкции), либо программой (если реакция автоматическая). Впрочем, это возможно и в развитых ИСБ. В моем понимании ССОИ – это прежде всего ПО верхнего уровня, чья главная задача – работа с информационными потоками и грамотная визуализация данных, позволяющая оператору правильно оценить ситуацию. 

Что касается автоматизации действий и реакций, то я думаю, что их скорость будет выше при взаимодействии на более низком (аппаратном) уровне или на уровне отдельных подсистем, что характерно для ИСБ. Обобщая сказанное выше: ИСБ входит в ССОИ, поскольку ССОИ – это верхний уровень управления.

Википедия¹ расшифровывает PSIM как "управление информацией о физической безопасности" и "аппаратно-программный комплекс для интеграции нескольких не связанных между собой приложений и устройств безопасности и управления ими через единый пользовательский интерфейс". На мой взгляд, безумно похоже на описание ССОИ. Да простят меня коллеги, вспоминается "бритва Оккама": не следует множить сущности без необходимости. Я бы сказал, что ССОИ и PSIM – это очень близкие понятия, как ИСБ и КСБ.

Павел Фомичёв, ТвинПро

В первую очередь необходимо определиться в понятиях:

• ИСБ – аппаратно-программный комплекс, позволяющий интегрировать все подсистемы безопасности (охранную и пожарную сигнализации, СКУД, видеонаблюдение, охрану периметра и проч.) в единую систему с возможностью настройки автоматических взаимодействий между этими подсистемами;
• ССОИ – программный комплекс, позволяющий регистрировать и протоколировать все события от различных подсистем безопасности в рамках единого интерфейса и времени;
• PSIM – система верхнего уровня, позволяющая автоматизировать управление инцидентами и обеспечивать оперативное реагирование на эти инциденты.

Отсюда вытекает и иерархия построения таких систем на объекте. Если говорить простыми словами, то в первую очередь на объектах строится ИСБ и определяется ССОИ, а потом уже надстраивается PSIM-система.

Конечно же, идеальным решением для построения таких систем являются модульные комплексы, которые позволяют решить эту задачу поэтапно.

Как решаются вопросы масштабирования ПО для управления СКУД и ИСБ при установке на объектах разной емкости и топологии – от малой системы (все на одном компьютере) до системы крупного географически распределенного холдинга (много объектов в разных городах с собственными серверами и локальной вычислительной сетью (ЛВС)?

Денис Иванов, Итриум СПб

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

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

Егор Голубкин, BIOSMART

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

Важен выбор правильной базы данных, которая позволит масштабироваться. Отличный пример – PostgreSQL, которую мы используем для решения задач наших клиентов (масштабирование на объектах до 1 млн человек). Из дополнительных плюсов – у этого решения есть официальная в России версия, прошедшая множество сертификаций. Эта БД может работать с большими объемами данных и поддерживать высокую нагрузку, что делает ее подходящим выбором для систем управления СКУД и ИСБ.

Алексей Лагойко, КомплИТех

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

Давайте ответим на этот вопрос откровенно, отбросив экономический аспект и сосредоточившись на технической составляющей. Такие компании, как LENEL, APOLLO, NEDAP, Bosch и Honeywell, предлагали масштабируемые решения, которые позволяли создавать многоуровневые и многоранговые СКУД и ИСБ (с объектовыми и региональными уровнями и централизацией), а также легко расширять их по горизонтали и вертикали. Зарубежные системы выдерживали нагрузку при объединении сотен или тысяч объектов в единую систему со сквозным управлением на всех уровнях, чего многие отечественные производители не могли предложить.

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

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

Аркадий Созданов, МПК "СОАР"

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

Вячеслав Петин, АРМО-Системы

На начальном этапе осуществляется выбор подходящей для данного объекта архитектуры. Принимается решение, будет это система локальная или территориально распределенная. При разработке ПО для упрощения дальнейшего масштабирования отдельных компонентов системы используется микросервисная архитектура. Далее по необходимости система наращивается за счет добавления ресурсов в сервер и/или добавления новых серверов.

Андрей Артюшкин, СБ Инжиниринг

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

Алексей Гинце, ААМ Системз

1. Малая изолированная система. В этом случае все модули комплекса (сервер БД, ядро, функциональные модули, драйверы оборудования и управляющая консоль) устанавливаются на одном компьютере. К этому же компьютеру подключается и оборудование всех подсистем безопасности. Компьютер должен обладать достаточной вычислительной мощностью и объемом памяти для функционирования всех этих модулей, а также дисковым пространством для хранения базы данных системы. Данная конфигурация хорошо подходит для построения СКУД небольшого масштаба.

2. Централизованная многопользовательская система. В данном случае все служебные модули комплекса (ядро, драйверы оборудования и логики) функционируют на одном компьютере – центральном сервере, а запуск управляющей консоли возможен не только на данном компьютере, но и на других машинах сети. В такой системе центральный сервер должен обладать вычислительной мощностью, объемом памяти и дисковым пространством еще большими, чем в случае применения однопользовательской системы. Однако в данной схеме появляется возможность задействовать не очень мощные компьютеры в качестве клиентских рабочих станций. Достоинства очевидны: простота установки, обслуживания и контроля линий связи, так как все оборудование подключено к одному компьютеру. В такой системе легко контролировать состояние функциональных модулей и драйверов оборудования, так как все они функционируют на одной машине. Недостатки в значительной степени повторяют предыдущий вариант. Для распределенной системы главным отрицательным фактором будет тот же – необходимость подключения всего управляемого оборудования к одному компьютеру (серверу), особенно в случае большой территориальной распределенности оборудования. Конфигурация хорошо подходит для построения СКУД среднего размера.

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

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

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

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

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

Классическая многофилиальная система представляет собой несколько взаимодействующих филиалов, каждый из которых находится под управлением автономного программного комплекса, функционирующего в локальной сети.
То есть в каждом филиале присутствует собственное ядро системы, драйверы оборудования и логики, а также база данных. Фактически каждый филиал может функционировать как полностью автономная система безопасности.
При этом для каждого филиала может быть выбран любой из вариантов развертывания ПК: изолированная, централизованная или распределенная система. Выбор зависит от размера системы безопасности конкретного филиала и задач, которые перед ней ставятся. Следует особо отметить, что многофилиальная система – это не просто репликация данных между базами. Подходит для СКУД и ИСБ крупных и особо крупных компаний с филиалами в разных городах.

Павел Фомичёв, ТвинПро

Безусловно, самыми сложными объектами для построения комплексных систем безопасности являются территориально распределенные объекты с необходимостью мониторинга и управления из одной точки, будь то ситуационный центр или пункты централизованного наблюдения. По нашему мнению, рациональнее всего строить такие системы с применением механизмов репликации данных и пунктов централизованного управления (ПЦН). По-простому, каждый объект сначала оборудуется всем необходимым локально со своими серверами систем (оборудования и баз данных), а потом уже объединение этих объектов в единую систему. Такой способ позволяет минимизировать риски сбоев при нарушении или потери в работе каналов связи. Особенно это актуально, когда каналы связи не принадлежат непосредственно предприятию (холдингу), а арендуются у провайдеров. Вдобавок ко всему прочему, построение распределенных систем по такому принципу наименее затратно для заказчика и не подразумевает в самом начале создание большого ЦОД и последующего подключения к нему удаленных объектов.

Михаил Андрющенко, РУБЕЖ

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

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

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

Способы обеспечения требований по информационной безопасности в программно-аппаратных комплексах управления СКУД и ИСБ – что есть на рынке? Приведите конкретные примеры и укажите используемые технологии.

Денис Иванов, Итриум СПб

Сейчас разработчики на рынке физической безопасности ведут себя так, словно их этот вопрос не касается: "Уважаемый заказчик, если тебе нужна защита информации – защищай наложенными средствами (антивирусы, брандмауэры, VLAN, VPN и т.п.). Мы работаем в изолированной сети безопасности, у нас все и так защищено физически, и если мы не ходим в Интернет, нам ничто не угрожает". Ровно так же, как отвечают на вопрос о защите персональных данных: "Я разработчик ПО, а не оператор персональных данных. Если ты, уважаемый заказчик, обрабатываешь персональные данные – принимай меры в соответствии с действующим законодательством".
Тот и другой подход в равной степени ущербны.

Информационная безопасность (киберзащищенность) программных комплексов должна быть исходно заложена в их архитектуру и используемые технологии. В ПО должны быть внедрены как минимум следующие средства:

• управление парольными политиками (сложность паролей, ротация паролей и т.п.);
• аудит всех действий в системе;
• изоляция прикладных программных средств;
• эффективное разделение полномочий пользователей;
• разделение системного и бизнес-администратора;
• защита информационного взаимодействия;
• ограничение сетевой коммуникации до необходимого минимума.

Если в ПО этих возможностей нет, никакими наложенными средствами полноценную защиту не обеспечить.

Егор Голубкин, BIOSMART

Сейчас особенно актуально для нас (производителей биометрических решений) говорить о 572-м Федеральном законе, в рамках которого на объектах критической информационной инфраструктуры требуются особые меры по обеспечению информационной безопасности.

Важно понимать, что это не просто рекомендации, а обязательные требования. Чтобы соответствовать им, необходимо использовать специальные средства защиты информации класса КС1 в терминалах с идентификацией по лицу, а также в программном обеспечении. Для биометрической системы контроля доступа это необходимо, так как безопасность является первоочередной задачей. Без специализированных средств защиты информации (СКЗИ) эти системы просто не могут быть запущены. Это новый уровень требований, и мы готовы соответствовать ему.

Алексей Лагойко, КомплИТех

Первое – правильная архитектура ПО. Она подразумевает разграничение доступа к информации на основе логических уровней:

• клиентское ПО (обеспечивает взаимодействие с пользователем);
• сервер приложений (получает и обрабатывает информацию, контролирует к ней доступ);
• сервер СУБД.

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

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

Третье – использование специализированных инструментов для безопасного хранения "секретов" (логинов, паролей, ключей шифрования, токенов API и других конфиденциальных данных).

Четвертое – запрет на наличие скрытых механизмов обхода безопасности в ПО (бэкдоров). Не должно быть системных учетных записей с доступом к ПО по умолчанию.

Пятое – применение алгоритмов шифрования, а также двусторонней аутентификации между сервером и контроллерами, например с использованием протокола EAP-TLS (802.1X).

Шестое – поддержка цифрового протокола OSDP для зашифрованной двусторонней связи между контроллерами и считывателями, что повышает безопасность по сравнению с устаревшими протоколами, такими как Wiegand, где данные передаются в незащищенном виде.

Седьмое – продуманный механизм эмиссии карт доступа. Если ключ шифрования на считывателе скомпрометирован, возникают две критические задачи. Одна из них – корректная замена ключей. Многие считыватели не поддерживают смену ключей через OSDP, что приводит к необходимости использования собственных, зачастую неудобных, решений. Другая – что делать с картами пользователей?

В большинстве случаев все карты доступа блокируются, и пользователи должны явиться в бюро пропусков для перезаписи ключей шифрования. А если речь идет о 10 тыс. сотрудников? А если это 200 тыс.?

Аркадий Созданов, МПК "СОАР"

Необходимо рассматривать несколько компонентов информационной безопасности (ИБ).

К ним относятся:

• защита ПО СКУД и ИСБ в программном коде, метод шифрования и защита паролей БД;
• защита используемого оборудования от программных закладок в электронных компонентах;
• создание корпоративной системы безопасности с включением в нее ПО, железа и рисков от человеческого фактора.

Внедрение PSIM-платформы на предприятии позволяет решить все перечисленные проблемы безопасности.

Вячеслав Петин, АРМО-Системы

Наиболее распространенные способы обеспечения информационной безопасности на сегодня: шифрование данных (например, AES), аутентификация и авторизация (к примеру, многофакторная), защита сетевой инфраструктуры (брандмауэры), биометрия (по геометрии лица, отпечаткам пальцев, ладони, сетчатке), видеоаналитика (определение праздношатания, оставленных предметов) и т.д.

В целом информационная безопасность в сфере СКУД и ИСБ – это комплексный вопрос, который требует применения различных технологий и мер защиты.

Андрей Артюшкин, СБ Инжиниринг

На всех предприятиях требования к информационной безопасности разные и обусловлены характером решаемых задач для разных категорий субъектов информационных отношений. Это относится также и к программно-аппаратном комплексам безопасности. Требования по информационной безопасности от заказчика запрашиваются, формируются и учитываются еще на этапе переговоров и создания технического задания. После реализации проекта привлекается сторонняя компания, которая проводит аудит информационной безопасности с подготовкой отчета. С нашей точки зрения, наиболее простым и эффективным решением для обеспечения информационной безопасности является использование отдельных, изолированных на физическом уровне, сетей для всего сегмента систем безопасности со своим NTP-сервером.

Алексей Гинце, ААМ Системз

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

В этом случае не лишним будет шифрование информации, передаваемой между контроллерами по линиям связи. Для этого могут использоваться различные криптоалгоритмы. На аппаратном уровне также должна обеспечиваться защита линий связи "считыватель – контроллер". В современных СКУД это обычно выполняется за счет использования в считывателях OSDP-протокола с шифрованием. OSDP позволяет организовать криптографическую защиту интерфейса при применении шифрования с использованием протокола SCP (Secure Channel Protocol).

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

Павел Фомичёв, ТвинПро

ИБ и кибербезопасность – это, конечно же, яркий тренд на рынке систем безопасности (СБ). На текущий момент требования по информационной безопасности не являются основными при выборе решений для СБ, однако всё чаще и чаще встречаются в технических заданиях.

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

По нашему мнению, в ближайшее время этот тренд активно подхватят и другие вертикали рынка.

Михаил Андрющенко, РУБЕЖ

Одним из наиболее распространенных способов обеспечения информационной безопасности является шифрование данных. Этот метод позволяет защитить информацию от несанкционированного доступа путем преобразования ее в зашифрованный вид. В программно-аппаратных комплексах управления СКУД и ИСБ применяются различные алгоритмы шифрования, такие как AES, RSA, ECC и др.

Для обеспечения доступа к системе только авторизованным пользователям применяются методы аутентификации и авторизации. Аутентификация позволяет подтвердить личность пользователя, а авторизация – определить его права доступа к системе. В программно-аппаратных комплексах управления СКУД и ИСБ используются различные методы аутентификации, такие как пароли, токены, биометрические данные и др.

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

Для обеспечения сохранности данных в случае сбоя или атаки применяется резервное копирование и восстановление данных. Резервные копии позволяют восстановить данные после сбоя, а системы восстановления данных – быстро вернуть систему в рабочее состояние.

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

¹ РКН: иностранный владелец ресурса нарушает закон РФ.

Опубликовано в журнале "Системы безопасности" № 5/2024

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>

Изображение от creativeart на Freepik