2.5. Методология построения защищенных ас

Рассмотрим методы построения защищенных АС. Эти методы ус­ловно можно разделить на две группы:

1) относящиеся к произвольному ПО АС:

• иерархический метод разработки;

• исследование корректности и верификация.

2) специфичные только для систем защиты (теория безопасных систем).

Иерархический метод разработки по ас

В соответствии с принципом абстракции при проектировании АС раз­работчики могут идти по меньшей мере двумя путями: от аппаратуры "вверх"- к виртуальной машине, представляющей АС, или от виртуальной машины "вниз"- к реальному оборудованию. Это и есть два основных ме­тода проектирования - метод снизу вверх и метод сверху вниз. Остальные методы по своей сути сводятся к этим двум или являются их сочетанием.

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

К недостаткам метода проектирования снизу вверх относят:

• необходимость с самого начала принимать решение о выборе способа реализации компонентов АС - с помощью аппаратуры, микропрограмм или программ, что сделать очень трудно;

• возможность проектирования АС только после разработки аппаратуры;

• расхождение между реальной АС и определённой в ТЗ.

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

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

• функциональный блок;

• конструкция обобщенного цикла;

• конструкция принятия двоичного решения.

Функциональный блок можно представить как отдельный вычислительный оператор или как любую другую реальную последовательность вычислений с единственным входом и единственным выходом, как в под­программе. Организация цикла в литературе часто упоминается как эле­мент DO-WHILE. Конструкция принятия двоичного решения называется IF-THEN-ELSE.

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

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

Преимущества использования модульного принципа состоят в сле­дующем:

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

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

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