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

С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 90 СПЕЦПРОЕКТ ПРОгРаММНыЕ КОМПлЕКСы ДлЯ СКУД И ИСБ октябрь – ноябрь 2024 www.secuteck.ru независимо от того, в каком филиале они при- сутствовали, и пр. Кроме того, в связи с геогра- фической удаленностью филиалов друг от друга система должна гарантировать полно- функциональную работу в случае разрыва связи между ними. Классическая многофилиальная система пред- ставляет собой несколько взаимодействующих филиалов, каждый из которых находится под управлением автономного программного ком- плекса, функционирующего в локальной сети. То есть в каждом филиале присутствует собст- венное ядро системы, драйверы оборудования и логики, а также база данных. Фактически каждый филиал может функционировать как полностью автономная система безопасности. При этом для каждого филиала может быть выбран любой из вариантов развертывания ПК: изолированная, централизованная или распре- деленная система. Выбор зависит от размера системы безопасности конкретного филиала и задач, которые перед ней ставятся. Следует особо отметить, что многофилиальная систе- ма – это не просто репликация данных между базами. Подходит для СКУД и ИСБ крупных и особо крупных компаний с филиалами в раз- ных городах. Павел Фомичёв, ТвинПро Безусловно, самыми сложными объектами для построения комплексных систем безопас- ности являются территориально распределен- ные объекты с необходимостью мониторинга и управления из одной точки, будь то ситуа- ционный центр или пункты централизованного наблюдения. По нашему мнению, рациональ- нее всего строить такие системы с применени- ем механизмов репликации данных и пунктов централизованного управления (ПЦН). По- простому, каждый объект сначала оборудуется всем необходимым локально со своими сер- верами систем (оборудования и баз данных), а потом уже объединение этих объектов в единую систему. Такой способ позволяет минимизировать риски сбоев при нарушении или потери в работе каналов связи. Особенно это актуально, когда каналы связи не принад- лежат непосредственно предприятию (хол- дингу), а арендуются у провайдеров. Вдоба- вок ко всему прочему, построение распреде- ленных систем по такому принципу наименее затратно для заказчика и не подразумевает в самом начале создание большого ЦОД и последующего подключения к нему удален- ных объектов. Михаил Андрющенко, РУБЕЖ Рассмотрим ситуацию, когда необходимо установить систему контроля и управления доступом на небольшом объекте, например в офисе или магазине. В таком случае все про- граммное обеспечение и оборудование могут быть размещены на одном компьютере или контроллере, что позволяет быстро и без лиш- них затрат установить систему и начать ее использование. Представим другую ситуацию – установку системы на крупном географически распреде- ленном холдинге, состоящем из множества объектов в разных городах. В этом случае необходимо учитывать множество факторов, таких как наличие собственных серверов, локальной вычислительной сети и других тех- нических особенностей каждого объекта. Для объединения различных по назначению систем в интегрированную систему безопасно- сти используется ПО верхнего уровня. Для под- ключения СКУД разных вендоров в единую систему также используется верхнеуровневый софт. В результате мы получаем мультифунк- циональное, мультивендорное решение, что является одним из направлений развития рынка СКУД в России. Денис Иванов, Итриум СПб Сейчас разработчики на рынке физической безопасности ведут себя так, словно их этот вопрос не касается: "Уважаемый заказчик, если тебе нужна защита информации – защищай наложенными средствами (антиви- русы, брандмауэры, VLAN, VPN и т.п.). Мы работаем в изолированной сети безопасно- сти, у нас все и так защищено физически, и если мы не ходим в Интернет, нам ничто не угрожает". Ровно так же, как отвечают на вопрос о защите персональных данных: "Я разработчик ПО, а не оператор персональ- ных данных. Если ты, уважаемый заказчик, обрабатываешь персональные данные – принимай меры в соответствии с действую- щим законодательством". Тот и другой подход в равной степени ущербны. Информационная безопасность (киберзащи- щенность) программных комплексов должна быть исходно заложена в их архитектуру и используемые технологии. В ПО должны быть внедрены как минимум следующие средства: l управление парольными политиками (слож- ность паролей, ротация паролей и т.п.); l аудит всех действий в системе; l изоляция прикладных программных средств; l эффективное разделение полномочий поль- зователей; l разделение системного и бизнес-админи- стратора; l защита информационного взаимодействия; l ограничение сетевой коммуникации до необходимого минимума. Если в ПО этих возможностей нет, никакими наложенными средствами полноценную защиту не обеспечить. Егор Голубкин, BIOSMART Сейчас особенно актуально для нас (произво- дителей биометрических решений) говорить о 572-м Федеральном законе, в рамках которого на объектах критической информационной инфраструктуры требуются особые меры по обеспечению информационной безопасности. Важно понимать, что это не просто рекоменда- ции, а обязательные требования. Чтобы соот- ветствовать им, необходимо использовать спе- циальные средства защиты информации класса КС1 в терминалах с идентификацией по лицу, а также в программном обеспечении. Для био- метрической системы контроля доступа это необходимо, так как безопасность является пер- воочередной задачей. Без специализированных средств защиты информации (СКЗИ) эти систе- мы просто не могут быть запущены. Это новый уровень требований, и мы готовы соответство- вать ему. Алексей Лагойко, КомплИТех Первое – правильная архитектура ПО. Она под- разумевает разграничение доступа к информа- ции на основе логических уровней: l клиентское ПО (обеспечивает взаимодей- ствие с пользователем); l сервер приложений (получает и обрабатыва- ет информацию, контролирует к ней доступ); l сервер СУБД. Клиенты должны взаимодействовать только с сервером приложений через API. Прямой доступ клиентов к БД следует исключить: ника- ких запросов напрямую, особенно в незашиф- рованном виде, как это бывает с толстыми кли- ентами. Второе – обязательное шифрование данных на всех уровнях, включая обмен данными между клиентом и сервером, а также между серверны- ми компонентами. В качестве алгоритмов шиф- рования следует применять современные про- токолы, такие как TLS. Третье – использование специализированных инструментов для безопасного хранения "секре- тов" (логинов, паролей, ключей шифрования, токенов API и других конфиденциальных данных). Четвертое – запрет на наличие скрытых меха- низмов обхода безопасности в ПО (бэкдоров). Не должно быть системных учетных записей с доступом к ПО по умолчанию. Пятое – применение алгоритмов шифрования, а также двусторонней аутентификации между сервером и контроллерами, например с использованием протокола EAP-TLS (802.1X). Шестое – поддержка цифрового протокола OSDP для зашифрованной двусторонней связи между контроллерами и считывателями, что повышает безопасность по сравнению с уста- ревшими протоколами, такими как Wiegand, где данные передаются в незащищенном виде. Седьмое – продуманный механизм эмиссии карт доступа. Если ключ шифрования на считы- вателе скомпрометирован, возникают две кри- тические задачи. Одна из них – корректная Способы обеспечения требований по информационной безопасности в программно-аппаратных комплексах управления СКУД и ИСБ – что есть на рынке? Приведите конкретные примеры и укажите используемые технологии.