13.На какой эталонной модели базируется система управления доступом?

К данному типу относятся системы, на которые возлагается решение задач, связанных

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

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

В качестве примеров систем управления доступом можно привести следующие системы:

• банкоматы;

• торговые автоматы;

• системы безопасности.

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

доступом (Reference Monitor model), которая была разработана еще

в 1960-х гг. и использовалась в качестве системы управления досту-пом как в мейнфреймах, так и мини- ЭВМ для обеспечения безопасности в режиме многопользовательского доступа к компьютерам.

Несмотря на солидный возраст данная модель продолжает активно использоваться для построения систем безопасности, хотя основная сфера использования — это подсистемы безопасности, в которых она

используется как вспомогательное приложение.

Обобщенная структура эталонной модели доступа (рис. 1.8) включает следующие основные элементы: субъекты, объекты, базу данных авторизаций (БДА), подсистему аудита безопасности (ПАБ) и движок.

Субъект представляет собой некоторую активную сущность, которая запрашивает доступ к ресурсу от имени определенного пользователя. При входе в систему пользователь вводит свое имя и па-

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

группах.

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

М ожно назвать следующие типовые объекты:

• файлы;

• директории;

• дисковые тома;

• сетевые объекты;

• почтовые ящики;

• очереди сообщений.

14.Укажите стили проектирования ис.

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

• календарный стиль - основанный на календарном планирова-нии (Calendar-driven);

• стиль, основанный на управлении требованиями (Requirements-driven);

• стиль, в основу которого положен процесс разработки докумен-тации (Documentation-driven);

•стиль, основанный на управлении качеством (Quality-driven);

•архитектурный стиль (Arcbltecture-driven).

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

Стиль, основанный на управлении требованиями, предполага-ет, что основное внимание уделяется функциональным характери-стикам системы, при этом часто недостаточно внимания уделяется

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

из локальных целей, связанных с реализацией тех или иных функций. Данный подход достаточно эффективен в случае, если требования определены и не изменяются в процессе проектирования. Основные недостатки данного подхода следующие: недостаточное внимание уделяется требованиям стандарта IS0 9126 (управление качеством); разрабатываемые архитектуры, как правило, не являются стабильны-ми, так как каждая из реализуемых функций отображается на один или несколько функциональных компонентов. Это обстоятельство усложняет добавление к системе новых требований. Данный под-

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

Стиль, в основу которогр положен процесс разработки до-кументации, до настоящего времени продолжает использоваться

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

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

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

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

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

на управлении требованиями. Использование архитектурного сти-ля позволяет реализовать инкрементное и итеративное проектиро-вание, т. е. оперативно изменять существующую и добавлять новую функциональность.