8 (800) 222-42-27
Подписаться
на новости и события
Расписание
Июнь 2020
Пн Вт Ср Чт Пт Сб Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
1
2
3
4
5
выставка
информационный семинар
обучающий семинар

Требования к современным программным комплексам управления ИСБ.

январь 2007

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


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

Надежность


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


Типовая архитектура современного ПК для управления ИСБ строится по модульному принципу и состоит из следующих компонентов:
1) программный сервер (ядро) - модуль, представляющий набор сервисов для функциональных модулей: сервис вычитки и сохранения конфигурации, рассылки и регистрации сообщений, контроля прав и т.д.; как правило, именно этот модуль взаимодействует с базой данных;
2) функциональные модули - обеспечивают бизнес-логику комплекса: драйверы поддержки оборудования, драйверы логики (например, драйвер графических планов, картотеки, отчетов по сообщениям и т.д.);
3) пользовательские приложения - приложения с визуальным интерфейсом, предназначенные для взаимодействия операторов с комплексом; ядро и функциональные модули обычно не имеют визуального интерфейса и считаются серверными приложениями.


Современные ПК строятся как распределенные системы и работают в рамках локальной вычислительной сети (ЛВС). Среди множества компьютеров выделяют один, на котором будет запускаться программный сервер. Этот компьютер называется сервер системы. На других компьютерах запускаются пользовательские приложения и функциональные модули.


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


Защита от отказов аппаратной части


Под аппаратной частью будем понимать аппаратуру, обеспечивающую функционирование ПК (компьютеры, ЛВС). Можно выделить следующие виды отказов:

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


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


Структурное резервирование.

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

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

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

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


Функциональное резервирование.

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

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

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


Информационное резервирование.

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


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


Защита от программных сбоев


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


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


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


Восстановление после отказа


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

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


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

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


Защищенность ПК от несанкционированного доступа


Для рассматриваемых ПК можно выделить два основных вида угроз:


1) внешние угрозы, связанные с несанкционированными попытками входа в систему с целью управления оборудованием или хищения информации, а также с внедрением программных модулей, несущих вредоносную логику либо предоставляющих возможности для несанкционированного доступа к элементам системы;


2) внутренние угрозы, связанные с преднамеренными действиями оператора по воздействиям на систему;


3) внутренние угрозы, связанные со случайными действиями оператора в системе.
Исходя из этих угроз, сформулируем требования к защищенности ПК.


Руководящий документ "Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации" от 2 декабря 1997 г. устанавливает 9 классов защищенности автоматизированных систем (АС) от несанкционированного доступа (НСД) к информации.

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

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


На основе требований к классам защищенности укажем основные требования к ПК по руководящему документу, указанному выше.


1. Подсистема управления доступом к ПК


На этом уровне должны осуществляться:


 идентификация и проверка подлинности операторов при входе в систему по идентификатору (коду) и паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов; идентификация запускаемых программных модулей, входящих в состав ПК и проверка их подлинности;

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


2. Подсистема регистрации и учета в ПК


Здесь должны осуществляться:

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


3. Подсистема обеспечения целостности


Эта подсистема должна:

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

Масштабируемость


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


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


Принятая классификация разделяет объекты на малые, средние и большие. При этом четко сформулированных критериев для такого деления нет.
 Размер объекта традиционно определяется совокупностью таких параметров, как количество: рабочих мест в системе; активных держателей карт СКД в системе; охранно-пожарных датчиков, считывателей, камер; помещений, защищаемых техническими средствами безопасности. Например, система, насчитывающая до 5 рабочих мест, не более 300 охранных шлейфов и до 100 считывателей, может считаться малой. От 5 до 20 рабочих мест, до 3000 охранных шлейфов и до 1000 считывателей - это уже средняя система.


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

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


Продолжение статьи читайте в следующем номере.

 



Просмотреть файл 1134.01 Кб

Полный список публикаций