Формальные модели защищаемых систем, их применение в современных ОС

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

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

Модель политики безопасности – формальное представление политики безопасности для определенной системы или класса систем, определяющее методы обработки, распространения и защиты информации.

Формальные правила в большинстве моделей определяют следующие требования в порядке важности:

1. Доступность
2. Целостность
3. Конфиденциальность
4. Подотчетность

Каждое из требований отвечает за свою область в модели политики безопасности.

Доступность – требование, отвечающее за доступ к информации, а именно:

· предоставление доступа легальным пользователям в разрешенных масштабах

· предотвращение отсутствия такового

· предотвращение от нелегального доступа

Целостность отвечает за две области:

· целостность информации – обеспечение защиты информации от нелегальных действий в процессе хранения, обработки и передачи

· целостность системы – отсутствие двойственности в работе системы

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

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

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

Потайные каналы утечки информации из формально защищенной системы.

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

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

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

Вопрос 1.21. Этапы проектирования БД. Архитектурные уровни СУБД. Инфологическое моделирование. Компоненты инфологической модели. Модель «сущность-связь». Моделирование и объединение локальных представлений.

Схема проектирования:

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

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

Физический этап – выбор рациональной структуры хранения данных и методов доступа к ним, исходя из арсенала методов и средств, которые предоставляются разработчику конкретной СУБД.

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 2.1:

Рис. 2.1. Трехуровневая модель системы управления базой данных, предложенная ANSI

1. Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.
2. Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.
3. Физический уровень — собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных.

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

Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель «сущность—связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена «сущность—связь», или «Entity Relationship», стала фактическим стандартом при инфологическом моделировании баз данных.

Date: 2016-05-25; view: 1122; Нарушение авторских прав