Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Введение в теоретические основы компьютерной безопасности (Прокофьев И.В., Шрамков И.Г., Щербаков А.Ю.).pdf
Скачиваний:
217
Добавлен:
28.06.2014
Размер:
2.36 Mб
Скачать

-160-

Заключение. Процесс построения защищенной компьютерной системы

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

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

-с распределенностью КС,

-с составом аппаратной компоненты,

-с составом и свойствами «программного наполнения» (в первую очередь свойствами операционных сред КС).

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

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

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

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

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

-161-

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

Затем, как правило, необходим этап опытной эксплуатации КС (к этому моменту КС содержит ОС и прикладное наполнение со свойствами корректности включенных субъектов, корректные вызовы МРЗФ и «инфраструктуру» (программы и данные) для управления защитой). Цель этапа опытной эксплуатации - убедиться в выполнении целевой функции КС и встроенных в нее защитных механизмов (т.е. решает ли КС и защита те задачи, для которых была спроектирована).

Параллельно может выполняться начальная процедура мягкого администрирования - определение необходимых для выполнения пользовательских задач множеств объектов-источников и других данных.

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

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

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

Схематически описанный процесс представлен на рисунке 1.

-162-

Рис. 1. Взаимосвязь методов проектирования защищенной КС.