Вы находитесь в разделе Типовых решений систем безопасности
Требования к современным программным комплексам управления ИСБ. Часть 1Д. А. Шестаков  Интегрированные системы безопасности (ИСБ) присутствуют на рынке более 10 лет. За это время произошли качественные изменения в развитии как аппаратных, так и программных технологий. Изменились задачи, а следовательно, и функциональные требования заказчиков, предъявляемые к ИСБ. Повысились требования к надежности, защищенности и масштабируемости этих систем Основа для создания и управления ИСБ - программный комплекс (ПК) - специализированное программное обеспечение, предназначенное для взаимодействия с оборудованием, входящим в состав этих систем, и для решения задач, связанных с обеспечением технической безопасности на объекте. Рассматриваемые в данной аналитической статье требования, предъявляемые к программным комплексам для управления ИСБ, учитывают опыт работы с заказчиками и вопросы теории, необходимые для создания качественных автоматизированных систем. Требования разделены на две категории: основные и дополнительные. К основным относятся те, что кардинально влияют на систему: надежность, защищенность, масштабируемость и эргономичность. изучим эти требования подробнее. Надежность ИСБ должна функционировать в режиме 24х7 (24 часа в сутки, 7 дней в неделю). Исходя из этого к надежности программных комплексов для ИСБ предъявляются жесткие требования. Надежность аппаратных систем определяется двумя факторами: надежностью использованных элементов и дефектами в конструкции, допущенными при проектировании и изготовлении. Для программных систем надежность определяется этими же факторами, но в данном случае ошибки проектирования и реализации имеют доминирующее значение. Типовая архитектура современного ПК для управления ИСБ строится по модульному принципу и состоит из следующих компонентов:
2) функциональные модули - обеспечивают бизнес-логику комплекса: драйверы поддержки оборудования, драйверы логики (например, драйвер графических планов, картотеки, отчетов по сообщениям и т.д.); 3) пользовательские приложения - приложения с визуальным интерфейсом, предназначенные для взаимодействия операторов с комплексом; ядро и функциональные модули обычно не имеют визуального интерфейса и считаются серверными приложениями. Современные ПК строятся как распределенные системы и работают в рамках локальной вычислительной сети (ЛВС). Среди множества компьютеров выделяют один, на котором будет запускаться программный сервер. Этот компьютер называется сервер системы. На других компьютерах запускаются пользовательские приложения и функциональные модули. Поскольку отказ как в программной части ИСБ, так и в аппаратной части, обеспечивающей функционирование программной системы, может повлечь за собой отказ всей системы в целом, будем рассматривать требования к надежности программных комплексов относительно двух критериев: защита от отказов аппаратной части ПК и защита от программных сбоев. 1. Защита от отказов аппаратной части Под аппаратной частью будем понимать аппаратуру, обеспечивающую функционирование ПК (компьютеры, ЛВС). Можно выделить следующие виды отказов:
В теории надежности введение в структуру дополнительно параллельно включенного элемента повышает надежность системы. Такое структурное изменение называется резервированием. Внедрение в систему резервирующего элемента с эквивалентной степенью отказа позволяет, при некоторых допущениях, снизить на два порядка вероятность отказа связки из основного и резервирующего элемента . ПК должен поддерживать следующие методы резервирования. Структурное резервирование. Это способ повышения надежности, заключающийся в применении дополнительных элементов, которые не являются необходимыми для выполнения функций системы, но обязательны для обеспечения уровня надежности. Современные ПК имеют, в основном, централизованную архитектуру, когда в системе есть программный сервер (ядро), обеспечивающий целостность системы. Очевидно, что исчезновение ядра приведет к распаду системы на несвязанные компоненты, в результате чего она перестанет функционировать. Для предотвращения такого рода отказа ПК должен поддерживать функцию горячего резервирования ядра системы. В ней имеются два ядра (или более), каждое из которых запущено на отдельном компьютере. В начальный момент времени, когда система считается нормально функционирующей, активно только одно ядро, которое и обеспечивает работу комплекса. Остальные ядра находятся в "спящем" режиме и только отслеживают наличие активного ядра. Как только активное ядро перестает функционировать (вышел из строя компьютер данного ядра), одно из резервных ядер автоматически становится активным и обеспечивает дальнейшее функционирование системы. Если произошел обрыв ЛВС и ее распад на несвязанные сегменты, резервные ядра обеспечат функционирование тех сегментов, где оказались их компьютеры. В обоих случаях после устранения первопричины отказа система продолжает функционировать в нормальном режиме, при этом информация, накопленная в резервных ядрах, пересылается в центральное ядро. Структурное резервирование повышает стоимость системы, трудоемкость администрирования, но обеспечивает надежное функционирование ее центральных элементов. Функциональное резервирование повышает надежность системы за счет устранения или снижения последствий отказа перераспределением функций м. элементами системы. Избыточных элементов при таком способе резервирования в системе нет. Некоторые элементы временно начинают дополнительно выполнять необходимые для работы системы функции. Данный вариант обеспечивает резервирование модулей, осуществляющих взаимодействие с аппаратурой ИСБ и логикой системы. Например, если в системе на разных компьютерах запущены модули, обеспечивающие взаимодействие с аппаратурой одного и того же типа, то в нормальном состоянии каждый из этих модулей обслуживает свой набор аппаратуры, а при выходе из строя одного из компьютеров оставшийся модуль автоматически начинает обслуживать набор аппаратуры от другого модуля. Информационное резервирование. Практически любая ИСБ содержит в своем составе базу данных, в которой хранится конфигурация системы, и регистрируются все события, происходящие в системе. Выход из строя базы приведет к временному отказу в работе системы, который будет устранен только после восстановления минимально необходимой конфигурации системы. Вся накопленная информация по событиям также будет утеряна. Для предотвращения такого отказа может быть использовано горячее резервирование ядра, в составе которого производится и дублирование базы данных для каждого из резервных ядер. Наиболее целесообразно обеспечение периодического сохранения резервных копий баз данных. Оно должно осуществляться с периодичностью, не оказывающей значимого влияния на производительность системы, но и обеспечивающей минимально приемлемый интервал, события за который будут утеряны. Структурное и функциональное резервирование используются по схеме горячего резервирования, когда отказавший модуль автоматически заменяется резервным без участия оператора. Рассмотренные выше методы резервирования значительно повышают надежность системы, предотвращая наиболее распространенные варианты отказов. Использование того или иного метода, и сочетания методов в первую очередь зависит от размеров системы и экономической целесообразности. 2. Защита от программных сбоев Программа любой сложности и назначения при жестко фиксированных исходных данных и абсолютно надежной аппаратуре выполняет строго детерминированный набор действий и дает на выходе определенный результат. но случайное изменение исходных данных и накопленной при обработке информации, и множество условных переходов в программе создают огромное число различных маршрутов исполнения каждого сложного программного модуля. Крайне трудоемкой задачей является проверка по завершении разработки ПК правильности функционирования комплекса и обработки им всех сочетаний входных данных. При создании ПК должны выполняться следующие требования:
Показатель надежности ПК - использование в нем современных апробированных технологий и спецификаций, разработанных различными консорциумами (типа OMG или OPC Foundation), что позволяет снизить вероятность ошибок при проектировании, и повысить v и качество реализации за счет использования полностью готовых надежный решений. 3. Восстановление после отказа цикл восстановления системы после сбоя зависит от первопричины отказа. Если причина -программный сбой (ошибка в программном модуле, повлекшая его выгрузку из памяти или "зависание"), то восстановление может произойти в автоматическом режиме без участия пользователя. Если причиной отказа стало физическое разрушение оборудования, восстановление системы может происходить в два этапа. Первый обязательный этап - восстановление работоспособности оборудования (компьютера, коммуникаций) - очевидно, не может происходить без участия человека. Второй этап - введение в работу программного модуля, вышедшего из строя в результате отказа оборудования. Если программный модуль являлся функциональным и не имел в своем составе хранилища данных, то его введение в работу не потребует дополнительных действий оператора. Другой вариант, когда программный модуль содержит в своем составе хранилище (базу) данных, изучим на следующем примере. Пусть имеется ПК с централизованной архитектурой. Для обеспечения резервирования программного сервера в состав системы входят два компьютера, на одном запущен базовой программный сервер, а на другом - резервный. Компьютеры объединены в локальную сеть. Если происходит обрыв связи м. данными компьютерами, то система распадается на два независимых сегмента. Работу каждого из сегментов обеспечивает свой программный сервер со своей базой данных. Очевидно, что изначально базы данных содержат эквивалентную информацию. С течением времени в каждой из баз она будет изменяться произвольным образом. В итоге, когда связь м. компьютерами будет восстановлена, в системе образуются две базы данных, содержащие разную информацию. Эти базы необходимо синхронизировать. И в момент синхронизации данных возможны коллизии: если в обеих базах была изменена разным образом информация об одном и том же объекте, , решение о том, какую версию данных использовать, принимается администратором системы. Существуют автоматические варианты разрешения подобных конфликтов: по приоритетам (принимается изменение того программного сервера, чей приоритет выше), по времени (чье изменение произошло позднее, то и принимается). Защищенность ПК от несанкционированного доступа Для рассматриваемых ПК можно выделить два основных вида угроз:
2) внутренние угрозы, связанные с преднамеренными действиями оператора по воздействиям на систему; 3) внутренние угрозы, связанные со случайными действиями оператора в системе. Исходя из этих угроз сформулируем требования к защищенности ПК. Руководящий документ "Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автомати-зированных систем и требования по защите информации" от 2 декабря 1997 г. устанавливает 9 классов защищенности автоматизированных систем (АС) от несанкционированного доступа (НСД) к информации. Классы подразделяются на три группы, отличающиеся особенностями обработки информации в автоматизированных системах. Программные комплексы для построения ИСБ относятся к первой группе. Она включает в себя многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности. Не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А. Выбираемый класс защиты зависит от специфики объекта и требований заказчика. Например, для банков, аэропортов, объектов атомной энергетики имеются отдельные нормативные документы по обеспечению их защиты. Предъявляемые требования должны согласовываться с этими нормативными документами. На основе требований к классам защищенности укажем основные требования к ПК по руководящему документу, указанному выше.
2. Подсистема регистрации и учета в ПК Здесь должны осуществляться: 3. Подсистема обеспечения целостности. Эта подсистема должна: Масштабируемость Изначально на этапе формулирования требований заказчик может исходить из одних объемов системы, но в дальнейшем вполне вероятно ее расширение. Различают функциональную масштабируемость и масштабируемость по мощности. Функциональная масштабируемость означает принцип. возможность при необходимости приобрести и внедрить дополнительные функциональные модули системы, которые не нужны на начальных этапах. Они должныбыть совместимы друг с другом и с модулями, внедренными ранее. Использование программного комплекса, который не сможет обеспечить расширение системы по мощности на 30-40% или же не позво-ляет расширять функционал, экономически нецелесообразно для более-менее серьезных объектов, так как в цикле эксплуатации комплекса могут возникнуть новые задачи или появится потребность во введении новых рабочих мест, добавлении оборудования. Заказчику может потребоваться поддержка в системе оборудования, которое было задействовано на объекте после установки ПК, например для замены старого оборудования с истекшим сроком эксплуатации. Даже в том случае, когда функционал полностью решает поставленную задачу и точно соответствует определенным требованиям, в цикле эксплуатации может прийти понимание того, как сделать цикл оптимальным, что также потребует функциональной доработки. Принятая классификация разделяет объекты на малые, средние и большие. При этом четко сформулированных критериев для такого деления нет. Размер объекта традиционно определяется совокупностью таких параметров, как количество: рабочих мест в системе; активных держателей карт СКД в системе; охранно-пожарных датчиков, считывателей, камер; помещений, защищаемых техническими средствами безопасности. Например, система, насчитывающая до 5 рабочих мест, не более 300 охранных шлейфов и до 100 считывателей, может считаться малой. От 5 до 20 рабочих мест, до 3000 охранных шлейфов и до 1000 считывателей - это уже средняя система. принцип. возможность масштабируемости во многом зависит от технологий, использованных при разработке ПК. Если комплекс изначально строился как распределенная система с применением соответствующих технологий, то это закладывает принцип. возможность масштабирования на архитектурном уровне. Поддержка функционального резервирования обеспечит производительность при значительном увеличении размеров системы. Рассмотрен минимально необходимый набор требований, предъявляемый к ПК. Очевидно, что их состав зависит от специфики объекта и принятой на нем стратегии обеспечения безопасности. Чем больше требований будет предъявлено к комплексу, тем выше будет стоимость его внедрения и эксплуатации. При определении этого набора надо четко обосновывать необходимость наличия реализации того или иного требования. Читайте далее:  "Безопасный город" глобальный проект по охране и жизнеобеспечению жителей мегаполиса Система безопасности ТАС Слагаемые успеха Создание корпоративной Концепции физической защиты объектов Технический регламент на СКБ. Заседание ТК 439 Типовое решение для АЗС Управление технической системой безопасности в промышленности В целях сохранения прибыльности рынок систем обеспечения безопасности жилья делает ставку на техниче Защита периметра в системах комплексной безопасности
|
