Содержание к диссертации
Введение
1. Особенности разработки защищенных информационных систем 12
1.1. Понятие защищенной информационной системы 12
1.2. Формальные модели доступа 14
1.3. Подходы к проектированию программного обеспечения защищенных информационных систем 17
1.4. Диаграмма потоков данных 20
1.5. Диаграмма «сущность-связь» 22
1.6. Объектно-ориентированный анализ и проектирование , 25
1.7. Компонентное программное обеспечение 29
1.8. Выводы 33
2. Концептуальное моделирование программного обеспечения и баз данных защищенных информационных систем 35
2.1. Способы пюектирования баз данных защищенных информационных систем 35
2.2. Модель потоков данных для описания процессов защищенных информационных систем 60
2.3. Методика объектно-ориентированного проектирования программного обеспечения с учетом мандатной политики доступа 76
2.4. Конструкции языка UML для описания компонентного программного обеспечения с учетом мандатной политики доступа 85
2.5. Взаимосвязь между разработанными моделями 96
2.6. Выводы 101
3. Трансляция концептуальных моделей программного обеспечения защищенных информационных систем в программные спецификации 104
3.1. Генерация базы данных с поддержкой многоуровневой модели доступа к данным по модели «сущность-связь» 104
3.2. Преобразование многоуровневой объектно-ориентированной модели в программные спецификации 118
3.3. Особенности разработки компонентного программного обеспечения 135
3.4. Выводы 140
4. Архитектура и пример применения системы проектирования компонентного программного обеспечения защищенных информационных систем 142
4.1. Описание функциональных свойств системы 142
4.2. Пример применения системы проектирования кпо защищенных информационных систем .. 146
4.3. Оценка сложности многоуровневой модели кпо 163
4.4. Эффективность использования системы проектирования защищенного кпо 165
4.5. Выводы 168
Заключение 169
Библиографический список 171
Приложение 1 176
Приложение 2 184
- Подходы к проектированию программного обеспечения защищенных информационных систем
- Методика объектно-ориентированного проектирования программного обеспечения с учетом мандатной политики доступа
- Преобразование многоуровневой объектно-ориентированной модели в программные спецификации
- Пример применения системы проектирования кпо защищенных информационных систем
Введение к работе
В современном обществе информационные технологии охватывают практически все сферы человеческой деятельности. Одной из важных функций информационных систем становится разграничение доступа пользователей к информации.
В настоящее время используются различные средства разграничения доступа, как программные, так и аппаратные. Но зачастую, они являются дополнением к уже существующим системам, которые разрабатывались без учета требований защиты информации. Такие «внешние» по отношению к информационной системе средства защиты практически всегда можно преодолеть и получить доступ к конфиденциальной информации. Поэтому их использование не является эффективным решением.
Более перспективным является подход, который позволяет наделить свойствами безопасности сами информационные системы. Для этого их необходимо разрабатывать с учетом соответствующих требований, тестировать на предмет защищенности от несанкционированного доступа (НСД).
К сожалению, подавляющее большинство CASE-средств (Computer Aided Software Engineering) не уделяет должного внимания вопросам защиты информации при проектировании программного обеспечения и баз данных информационных систем, предоставляя разработчику самому реализовывать механизмы защиты и управления доступом. Такая ситуация приводит к непроизводительным затратам времени на разработку, является потенциальным источником ошибок, приводящих к НСД.
В связи с этим весьма актуальной является задача создания моделей и методов, поддерживающих различные этапы разработки программного обеспечения (ПО) информационных систем, в которых необходимо организовать разграничение доступа к обрабатываемой информации. Средства автоматизированной разработки ПО защищенных информационных систем, основанные на данных моделях, позволят увеличить скорость создания такого рода систем за счет автоматической генерации специфиаций текстов программ; позволят выявлять и предотвращать некоторые виды ошибок, связанные с проектированием, нарушающим положения политики доступа; в целом повысят производительность труда проектировщика ПО и качество создаваемого программного продукта.
Цель работы Целью работы является создание моделей для проектирования программного обеспечения и баз данных информационных систем, позволяющих учитывать особенности, связанные с разграничением доступа пользователей к обрабатываемой информации, разработка на основе данных моделей способов проектирования и методик синтеза спецификаций текстов программ.
Задачи работы
1) разработка концептуальных моделей, позволяющих при проектировании баз данных учитывать особенности, связанные с разграничением доступа к данным в БД;
2) разработка способов трансляции полученных моделей в инструкции на языке SQL (structured query language);
3) разработка концептуальных моделей для проектирования программного обеспечения, в котором необходимо обеспечить разграничение доступа к данным;
4) разработка способов трансляции полученных моделей в программные спецификации;
5) разработка прототипа инструментального средства для создания программного обеспечения защищенных информационных систем.
Используемые методы исследования Для решения поставленных в работе задач используются элементы теории множеств, дискретной математики, реляционная алгебра, а также методы математической логики.
Основные положения, выносимые на защиту
1) расширения реляционной модели данных для осуществления мандатного доступа к данным в базах данных, позволяющие организовать ссылочную целостность при наличии явления многозначной реализации;
2) расширения диаграммы «сущность-связь», которые позволяют на концептуальном уровне моделировать структуру базы данных, поддерживающей многоуровневую модель данных (БД с мандатным доступом), процедура преобразования расширенной модели «сущность-связь» в инструкции на языке SQL для генерации базы данных с поддержкой многоуровневой модели данных;
3) расширения диаграмм потоков данных (ДПД), которые позволяют моделировать процессы защищенной информационной системы с учетом мандатной политики доступа. Многоуровневая объектно-ориентированная модель и многоуровневая модель компонентного ПО (КПО), с помощью которых может быть специфицировано объектно-ориентированное и компонентное ПО с учетом мандатного доступа к данным;
4) способы трансляции многоуровневой объектно-ориентированной модели и многоуровневых компонентных моделей в программные спецификации на языке описания XMI.
Научные результаты 1. Разработаны расширения реляционной модели для осуществления мандатного доступа к данным в базах данных, позволяющие организовать ссылочную целостность при наличии явления многозначной реализации. Расширения основаны на разделении исходной схемы отношения на две - ключевую и схему данных. В рамках этих расширений разработана операционная семантика таких операций как INSERT, UPDATE, DELETE, позволяющая манипулировать данными в предложенной модели.
2. Разработаны расширения диаграммы «сущность-связь», которые позволяют указывать уровень детализации (таблицы, атрибуты, поэлементная классификация) при организации мандатного доступа к данным и создавать концептуальную модель базы данных, поддерживающей многоуровневую модель данных. Разработан алгоритм синтеза инструкций на языке SQL по расширенной модели «сущность-связь» для генерации базы данных с поддержкой многоуровневой модели доступа к данным.
3. Разработаны расширения для диаграмм потоков данных (ДПД), которые позволяют моделировать функциональность защищенной информационной системы с учетом мандатной политики доступа. При этом отражается взаимодействие между процессами системы и хранилищами данных, реализуемых с поддержкой многоуровневой модели доступа к данным. Дана графическая нотация предложенных расширений диаграмм потоков данных. Разработана многоуровневая объектно-ориентированная модель, расширяющая исходную описанием легитимных и нелегитимных потоков данных, а также правил фильтрации этих потоков. Данная модель складывается из субъектно-ориентированной модели, позволяющей формально описать возникающие в системе потоки информации на основе концептов субъектов и объектов, а также ассоциированных с субъектами объектов, и, собственно, многоуровневой объектно-ориентированной модели. На основе многоуровневой объектно-ориентированной модели разработана многоуровневая модель компонентного программного обеспечения (КПО), состоящая из обобщенной формальной модели доступа для КПО, статической и динамической многоуровневой модели КПО, позволяющих описать взаимодействие между субъектами, компонентами и экземплярами компонентов при фиксированных и динамически изменяющихся уровнях доступа.
4. Разработаны подходы к синтезу программных спецификаций на языке описания XMI из многоуровневой объектно-ориентированной и многоуровневых компонентных моделей. Данные программные спецификации инвариантны по отношению к языку программирования и могут использоваться в любых CASE средствах, поддерживающих технологию XMI.
Научная новизна
Новизна предлагаемых моделей и способов заключается в том, что они позволяют уже на уровне проектирования разрабатываемых информационных систем описать особенности, связанные с организацией мандатного доступа к информации.
Предлагаемые расширения реляционной модели в отличие от существующих, позволяют при многозначной реализации «исходного» первичного ключа (ключа, определенного проектировщиком при создании БД) обеспечить все аспекты ссылочной целостности в многоуровневых БД «стандартным» образом - на основании этого «исходного» первичного ключа. Это дает возможность организовывать многоуровневую БД с помощью широко распространенных систем управления БД (СУБД), поддерживающих стандартную реляционную модель.
Разработанные расширения диаграммы «сущность-связь» и алгоритм синтеза инструкций на языке SQL по расширенной диаграмме «сущность-связь» позволяют создавать концептуальную модель многоуровневой базы данных и генерировать базы данных с поддержкой многоуровневой модели доступа к данным.
Разработанные расширения ДПД позволяют моделировать процессы защищенной информационной системы с учетом мандатной политики доступа. Это дает возможность выделять в системе критически важные с точки зрения организации доступа к данным участки, определять скрытые каналы утечки информации. Подобные диаграммы можно использовать как исходную информацию для создания набора тестов информационной системы на защищенность от НСД. Словарь проекта, полученный из расширенной ДПД содержит классифицированный по уровням доступа перечнь функций и данных. Эта информа Ция используется администратором системы для распределения полномочий между пользователями и является исходным материалом при построении многоуровневой модели данных информацонной системы. Разработанная многоуровневая объектно-ориентированная модель формально описывает информационные потоки, возникающие в объектно-ориентированном ПО, определяет правила фильтрации этих потоков в соответствии с требованиями мандатного доступа. Разработанная многоуровневая компонентная модель определяет правила реализации смешанной политики доступа в КПО, трансляции полномочий пользователей из одной формальной модели доступа в другую, описывает взаимодействие между субъектами, компонентами и экземплярами компонентов при фиксированных и динамически изменяющихся уровнях доступа компонентов.
Разработанные способы преобразования многоуровневой объектно-ориентированной и многоуровневых компонентных моделей в программные спецификации позволяют создавать инвариантные по отношению к языку программирования спецификации программ на языке описания XMI, которые могут использоваться в любых CASE средствах, поддерживающих технологию XMI.
Практическая значимость Предложенные в диссертационной работе модели и способы проектирования реализованы в прототипе инструментального средства для автоматизированной разработки защищенного КПО. Данный прототип позволяет: моделировать интерфейсы и компоненты системы, с возможностью указания особенностей, связанных с организацией мандатного доступа; анализировать модели на удовлетворение требованиям многоуровневой компонентной модели; генерировать программные спецификации для компонентов модели. Применение данного прототипа дает возможность: увеличить скорость разработки защищенных информационных систем за счет автоматической генерации спецификаций текстов программ на 34%; повысить качество программного продукта за счет ав 10 тематического выявления некоторых видов ошибок, связанных с проектированием, нарушающим положения политики доступа на 48%; повысить производительность труда проектировщика за счет исключения повторного проектирования и разработки элементов, связанных с организацией доступа к данным.
Реализация и внедрение результатов Основные теоретические положения и практические результаты работы были использованы при разработке информационной системы автоматизации военных лечебных и медицинских учреждений министерства обороны Российской Федерации, осуществляемой в ЗАО "Эврика", при выполнении работ по гранту 2002 года для студентов, аспирантов, молодых ученых и специалистов по теме «Концептуальное моделирование безопасности компонентного программного обеспечения» (номер гранта: М01-3.11К-296), при выполнении работ по гранту РФФИ «Разработка метамоделей, методов, инструментальных средств и технологии конвертации проектов информационных систем, созданных в соответствии с различными методологиями в различных CASE-системах» (per. номер 00-07-90344), а также в учебном процессе в государственном образовательном учреждении высшего профессионального образования «Санкт-Петербургский государственный университет аэрокосмического приборостроения».
Апробация работы Основные положения и некоторые результаты диссертационной работы докладывались и обсуждались на следующих конференциях и семинарах:
1) Третья научная сессия аспирантов и соискателей ГУАП, ГУ АЛ, СПб, 2000.
2) Четвертая научная сессия аспирантов и соискателей ГУАП, посвященная Всемирному дню космонавтики и 60-летию ГУАП, СПб, 2001;
3) Шестая Санкт-Петербургская ассамблея молодых ученых и специалистов. Политехнический симпозиум «Молодые ученые промышленности Северозападного региона», СПбГТУ, 2001.
4) Пятая научная сессия аспирантов и соискателей ГУАП, ГУАП, СПб, 2002.
5) Шестая научная сессия аспирантов и соискателей ГУАП, ГУАП, СПб, 2003.
6) Политехнический симпозиум «Молодые ученые промышленности Северозападного региона», СПбГТУ, 2003.
Публикации Основные результаты работы опубликованы в 10 печатных работах.
Структура и объем работы Диссертация состоит из введения, четырех разделов, заключения, библиографического списка (94 наименования), имеет общий объем 195 машинописных страниц, содержит 14 таблиц и 23 рисунка.
Подходы к проектированию программного обеспечения защищенных информационных систем
Под защищенной системой обработки информации понимается такая система, в которой «для определенных условий эксплуатации обеспечивается конфиденциальность и целостность обрабатываемой информации и поддержка работоспособности в условиях воздействия на нее заданного множества уг-роз»[23].
Традиционно выделяют три вида угроз: угрозы конфиденциальности информации, угрозы целостности информации и угрозы отказа в обслуживании. Угрозы могут носить как случайный (объективный), так и целенаправленный (субъективный) характер. К первым относятся сбои аппаратуры, изменения параметров внешней среды, случайные действия неквалифицированных пользователей и т.д. Ко вторым - целенаправленные действия, например, воздействия хакеров, программы-вирусы и т.д. Функция разграничения доступа пользователей к ресурсам системы совместно с другими средствами направлена на противодействие всем этим видам угроз, прежде всего угрозам конфиденциальности и целостности информации.
Успешная реализация угроз обусловлена, прежде всего, свойствами самой информационной системы. Именно «изъяны защиты» или «уязвимости» в системе защиты позволяют злоумышленнику осуществить несанкционированный доступ к информации. Новые виды несанкционированного доступа рождают новые средства защиты, а недостатки в последних «провоцируют» новые
средства «взлома» системы. В этой ситуации есть два возможных выхода [23]: создавать безупречные средства защиты, или устранить сами предпосылки, служащие источником успешной реализации угроз. Первый из этих подходов трудно осуществим вследствие большого, экспоненциально растущего количества возможных угроз. Причем это множество растет не только количественно, но и качественно. Средства защиты, в этом случае должны не только быть безупречными, но и «предсказывать» появление новых угроз. Второй подход, связанный с устранением причин, обуславливающих успешную реализацию угроз, не зависит от развития угроз, так как ликвидирует причину, а не следствие. Для реализации этого подхода необходимо разработать такую технологию проектирования, которая бы позволила на концептуальном уровне исключить предпосылки к появлению изъянов защиты.
Создание защищенных информационных систем ведется уже достаточно давно, и, естественно, что сложились определенные требования к таким системам. Эти требования выражены в стандартах информационной безопасности. Стандарты играют очень важную роль при создании защищенных информационных систем. Необходимость в подобных стандартах была осознана достаточно давно (первый документ в этой области появился в 1983 году), и в своем развитии стандарты безопасности претерпели целую эволюцию. Стандарты безопасности достаточно полно раскрыты в [23]. В прил. 2 приведены основные сведения о наиболее распространенных стандартах.
Стандарты безопасности разработаны в виде соответствующих требований и критериев, образующих шкалу для оценки степени защищенности автоматизированных систем обработки информации. Этим они создают основу для взаимодействия между производителями, потребителями и экспертами по квалификации продуктов информационных технологий. Потребители используют стандарты для выражения своих требований к производителю. Производители нуждаются в стандартах, как в средстве сравнения возможностей своих продуктов, а также как в наборе требований безопасности, который мог бы ограничить фантазию заказчика и заставить его выбирать требования из этого набора.
Эксперты по квалификации и специалисты по сертификации используют стандарты для оценки уровня безопасности, обеспечиваемого информационным продуктом. Следует отметить, что защищенность является качественной характеристикой системы, её нельзя измерить, нельзя даже с однозначным результатом сравнить уровень защиты двух систем - одна будет лучше обеспечивать безопасность информации в одном случае, другая - в другом. Поэтому оценка защищенности - сложная задача и основывается на экспертных оценках с использованием стандартов информационной безопасности.
Таким образом, защищенная система обработки информации обладает следующими свойствами: осуществляет автоматизацию некоторого процесса конфиденциальной обработки информации; противостоит заданному множеству угроз, действующих в определенной среде; соответствует требованиям и критериям стандартов информационной безопасности.
Методика построения защищенной информационной системы должна учитывать все эти особенности. Но если разработка автоматизированных систем обработки информации - процесс достаточно проработанный [4, 10, 14, 60 и др.], то учет в проекте информационной системы особенностей, связанных с требованиями, предъявляемыми стандартами безопасности, практически ни в какой методологии не встречается.
К сожалению, большинство требований, предъявляемых стандартами информационной безопасности, не могут быть формально представлены в какой-либо методологии разработки программного обеспечения и возможные системы проектирования, направленные на оценку уровня безопасности системы, должны быть по большей части экспертными системами. Но очевидно, что ряд моментов должен учитываться именно в ходе проектирования будущей информационной системы. Прежде всего, это касается требования следованию формальным моделям доступа и возможности верификации спецификаций ИТ-продукта на предмет удовлетворения этому требованию.
Формальные модели необходимы и используются достаточно широко, потому что только с их помощью можно доказать безопасность системы, опираясь при этом на объективные и неопровержимые постулаты математической теории [23]. Кроме того, формальные модели позволяют решить еще целый ряд задач, возникающих в ходе проектирования, разработки и сертификации защищенных систем. Это и спецификация политики доступа разрабатываемой системы, и базовые принципы архитектуры, и использование в качестве эталонной модели в процессе анализа системы на предмет защиты от НСД. Собственно под моделью доступа (Security model) понимается формальное представление политики доступа (безопасности). Политика безопасности (Security policy) - совокупность норм и правил, обеспечивающих эффективную защиту системы обработки информации от заданного множества угроз.
Среди множества моделей доступа можно выделить следующие основные классы [23, 51]: модели на основе дискретных компонент, модели конечных состояний, ролевые политики доступа, политики доменов и типов, модели на основе анализа угроз. Политика доменов и типов специфична только для операционной системы UNIX, а модель на основе анализа угроз носит вероятностный характер, а значит, допускает взлом системы защиты. Первые три класса формальных моделей наиболее распространены и имеют достаточно четкий математический аппарат. Поэтому, в дальнейшем, рассматриваются только модели этих классов. Эти модели доступа основаны на следующих базовых представлениях [23]:
Методика объектно-ориентированного проектирования программного обеспечения с учетом мандатной политики доступа
Большинство современных СУБД реализуют реляционную модель данных, которая была предложена Коддом в 1970 году. Согласно этой модели [61] данные хранятся в таблицах, называемых отношениями. Каждое отношение содержит одну или несколько колонок, называемых атрибутами. В некоторый момент времени отношение содержит в себе множество строк (которое может быть и пустым). Каждая строка называется кортежем. Количество кортежей в отношении меняется с течением времени в результате выполнения операций манипулирования данными, предусмотренных в реляционной алгебре. Набор атрибутов, однозначно идентифицирующих кортеж, называется возможным ключом отношения. Из всех возможных ключей для каждого отношения выбирается только один, который называется первичным ключом. В качестве примера рассмотрим отношение «Проекты», показанное в табл.
Это отношение состоит из трех атрибутов: «Код», «Наименование», «Описание». В отношении определены три кортежа, описывающие проекты некоторой строительной фирмы. Первичным ключом для данного отношения является атрибут «Код».
Следует отметить, что теория реляционных баз данных динамично развивается и в настоящее время существует множество интерпретаций Кодда. В данной работе будет использоваться подход, предложенный Д. Мейером и развитый К. Дж. Дейтом [20, 28]. Приведем основные положения.
Домен - это семантическое понятие, которе можно рассматривать как подмножество значений некоторого типа данных. Домен характеризуется следующими свойствами: имеет уникальное имя (в пределах БД); определен на некотором простом типе данных или другом домене; может иметь некоторое логическое условие, описывающее подмножество данных, допустимых для данного домена; несет определенную смысловую нагрузку. Например, домен D, имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел: D = {п eN\(n 18)&(« 80)}. Будем считать, что в БД существует некоторе множество доменов: D = {D; / j = \,Т).
Схема отношения - конечное множество имен атрибутов [28]: R={Ak,Ak eANames/k=l,K}, где ANames={A,l i = \I) - множестов имен атрибутов. При этом К называют степенью отношениия. Часто схема отношения обозначается R{AX,A2,...,AK). Каждому атрибуту в схеме поставлен в соответствие некоторый домен. Домен атрибута At обозначают как dom{A ). Собственно dom -это функциональное соответствие между множеством имен атрибутов и множеством доменов: dom: A Names - D, В схеме атрибутов не должно быть двух повторяющихся имен атрибутов.
Отношением г со схемой R называют подмножество декартова произведения доменов атрибутов, входящих в схему: r(R) х dom{Ak),Ak eR . Но еледует отметить, что в отличие от математического понятия «отношение» в реляционном отношении порядок доменов не важен [61, 62, 20]. Элементы отношения называются кортежами. Кортеж - это упорядоченный набор элементов, обозначается как: (a,, ,..., ), где N - размерность (длина) кортежа. Отношение можно представить как множество кортежей длины К, где каждый кортеж -элемент из декартова произведения: r(R) = {tm \tm = (amUam2,...,amK)/m = l,M}, где tmexdom(Ak), М - кардинальность (мощность) отношения. При этом атк Gdom(Ak) - значение атрибута Ак в m-ом кортеже отношения г. Оброзначим tm{Ak). Следует подчеркнуть, что под г понимается «экземпляр отношения» (или значение переменной-отношения [20]) в некоторый момент времени. Само отношение, как изменяющаяся во времени переменная, по традиции обозначается как Л [61, 62, 20]. Но это приводит к путанице, т.к. ранее мы условились обозначать схему отношения как R. Поэтому в дальнейшем под R будем понимать схему переменной-отношения и будем считать, что переменная-отношение (также обозначаемая как R ) задается этой схемой.
Большинство существующих коммерческих систем управления базами данных позволяют поддерживать только дискреционную и ролевую политики доступа. Типичная реализация дискреционного контроля - списки прав доступа. При этом для каждого объекта системы (например, отношения) указывается перечень субъектов, которые имеют право на выполнение определенных операций над этим объектом. Для баз данных объектами доступа являются: сама база данных; отдельная таблица базы данных (отношение); отдельный атрибут таблицы (колонка); отдельная запись в таблице (кортеж) или даже отдельный элемент данных отдельной записи таблицы. Административные средства СУБД позволяют пользователю управлять доступом других пользователей к его данным и контролировать неприкосновенность последних. В большинстве
СУБД установлена ответственность каждого пользователя за управление доступом к созданному им объекту. Когда пользователь создает некоторый объект и определяет операции отношения над ним, то он должен в полном объеме контролировать выполняемые действия. В большинстве СУБД существуют следующие виды доступа: READ - чтение, INSERT - вставка, DELETE - удаление, UPDATE - обновление, EXPAND - расширение, IMAGE -создание образа, CONTROL - управление. Пользователь может предоставить право доступа к объектам и операциям другому пользователю с помощью оператора GRANT (предоставить). Однако это может сделать только пользователь, имеющий соответствующий атрибут доступа - CONTROL. Ключевое слово PUBLIC (общедоступный) может быть использовано вместо списка пользователей, если вид доступа разрешается всем пользователям. Фраза ALL RIGHTS (все права) может быть использована вместо списка видов доступа в операторе GRANT. Вид доступа может быть как установлен, так и снят (отменен). Он удаляется из списка атрибутов того пользователя, который его установил, и всех пользователей, которым данный атрибут был передан этим пользователем, исключая тех, кому удаляемый атрибут был установлен другим пользователем. Процесс отмены атрибута может также иметь и другие особенности. В некоторых сетевых СУБД пользователю, имеющему атрибут CONTROL, разрешается формировать утверждение о целостности. Утверждение - логический предикат, который может принимать значение TRUE (истина) или FALSE (ложь). При выполнении оператора ASSERT (утвердить) система проверяет текущее значение предиката. Если предикат равен FALSE, утверждение игнорируется; если же значение предиката TRUE, система с этого момента времени вводит в действие утверждение по отношению ко всем будущим изменениям в БД. Каждому утверждению пользователь присваивает имя. Если оператор вставки, удаления или обновления нарушает утверждение, он игнорируется и пользователю возвращается код нарушения вместе с именем (именами) нарушенного утверждения (утверждений). Утверждение простейшего вида относится к отдельному отношению и распространяется на каждый элемент отношения. Как и в запросах, утверждению может быть присвоена метка, которая используется в блоках, связанных с утверждением, для указания некоторого свойства, относящегося ко всем элементам отношения, на которые распространяется утверждение.
Не смотря на достаточно гибкие механизмы предоставления полномочий таких средств недостаточно для обеспечения безопасности данных, т.к. дискреционный контроль не обеспечивает гарантий по защите данных от несанкционированного доступа, поскольку не контролирует потоки информации. В частности он не решает проблему «троянского коня». Кроме того, мы не можем с помощью дискреционного доступа обеспечить защиту отдельного поля записи и даже отдельного кортежа, так как нет механизма меток безопасности для этих объектов. Эти недостатки отсутствуют при организации мандатного управления доступом. Именно поэтому стандарты безопасности для СУБД высокого класса защищенности требуют поддержки мандатной политики доступа. Для реализации такой поддержки необходимо специальным образом расширить стандартную реляционную модель для организации так называемой многоуровневой модели доступа к данным [35].
Преобразование многоуровневой объектно-ориентированной модели в программные спецификации
Но при удалении могут возникнуть и более сложные ситуации. Например, пользователь с уровнем полномочий «О» хочет удалить запись о проекте с кодом «BZM00» из отношения «Проекты» (табл. 8, 9). При этом он видит только одну запись (BZM00 О, Волна О, Пристань О). Вторую запись с несекретным ключом «BZM00» он не видит в силу требований null-целостности. Если пользователь удалит эту первую запись, то он не должен увидеть вторую запись. Иначе, возникнет канал утечки о существовании скрытой информации о проекте «BZM00». Но эта вторая запись изначально даже не входила в представление для пользователя «О» уровня (г "о).
В этом случае необходимо физически удалить кортеж (BZM00 О, Волна О, Пристань О) из отношения «Проекты"». А во втором кортеже с несекретным ключом «BZM00» повысить уровень доступа ключа на один уровень (т.е. до уровня «К»). С точки зрения политики доступа это вполне допустимо, поскольку такая операция будет рассматриваться как запись данных с более низкого уровня на более высокий. Но с точки зрения ссылочной целостности это невозможно пока не создан кортеж «BZM00 К» в отношении «Проекты ». Только после создания такой записи и повышения уровня доступа ключевой связи в отношении «Проекты"» можно удалить кортеж «BZM00 О» в отношении «Проекты ». Теперь операцию удаления можно считать корректно совершенной.
Если бы кортеж (BZM00 О, Волна О, Пристань О) не существовал изначально в отношении «Проекты"», то пользователь уровня секретности «О» видел бы только второй кортеж: (BZM00 О, null О, null О). Но просто так удалять такой кортеж тоже нельзя. Иначе будет потеряна конфиденциальная информация (BZM00 О, Прометей К, Строительство казарм К), которая доступна пользователю с уровнем секретности «К». Поэтому в данной ситуации надо создать кортеж «BZM00 К» в отношении «Проекты » и, затем, повысить уровень секретности атрибута «Код» со значением «BZM00» в отношении «Проекты"». Только после этого можно удалить кортеж «BZM00 О» из отношения «Проекты ».
Еще один вариант удаления кортежа из отношения «Проекты»: допустим, что пользователь с полномочиями уровня «К» хочет удалить кортеж (BZM00 О, Прометей К, Строительство казарм К). В этом случае надо лишь физически удалить этот кортеж из отношения «Проекты"» и все.
Следует отметить, что если с отношением «Проекты » связаны другие отношения (собственно в нашем примере так и есть - имеется связь с отношением «Сотрудники»), то возникнет ситуация с нарушением ссылочной целостности при попытке удаления кортежа «BZM00 О». В этом случае процесс удаления должен быть отменен, а состояние базы данных вернуться в исходное - в то, которое было до начала удаления (откат транзакции).
Формально, алгоритм удаления кортежа из отношения г в рассматриваемых расширениях реляционной модели представлен на рис. 5. Алгоритм учитывает все возможные случаи при удалении кортежа из отношения. В этом алгоритме для каждого кортежа из Sr" = {te г", t удовлетворяет p} выполняются следующие действия: 1. Проверяется метка уровня доступа удаляемого кортежа. Если она меньше или равна уровню полномочий пользователя, то производится физическое удаление кортежа из отношения г". Если нет, то выполняется «алгоритм повышения уровня доступа кортежа», который заключается не в физическом удалении кортежа из отношения, а в увеличении на один уровень секретности всех меток доступа всех его атрибутов. 2. Проверяется существование среди удаляемых кортежей таких, в которых видимый первичный ключ и его метка уровня доступа идентична видимому первичному ключу и метки уровня доступа кортежа, удаленного на шаге 1. Если такие кортежи есть, то они будут обработаны в следующих итерациях, если нет, то проверяется необходимость удаления первичного ключа из отношения г . 3. Проверка необходимости удаления ключа из отношения г заключается в проверке существования таких кортежей в отношении г", которые не входят в число удаляемых кортежей, но у которых первичный ключ и его метка уровня доступа идентичны первичному ключу и метке уровня доступа кортежа, удаляемого на первом шаге. Если таких кортежей нет вообще, значит необходимо удалить первичный ключ из отношения г . Если такие кортежи есть, то надо проверить есть ли необходимость в удалении первичного ключа. 4. Такая необходимость есть только в случае, когда среди найденных на шаге 3 кортежей есть такие, которые не относятся к множеству гс. Это те кортежи, которые были вытеснены в силу требования null целостности из представления отношения для пользователя с уровнем полномочий «с». Для таких кортежей запускается «алгоритм повышения уровня доступа кортежа». После этого необходимо вернуться на шаг 3 для повторной проверки.
Пример применения системы проектирования кпо защищенных информационных систем
Но существует и ряд специфичных для многоуровневой объектно-ориентированной модели моментов. Необходимо решить вопросы наследования в такой модели, вопросы организации вызова методов, модели поведения объектов, совместного взаимодействия.
Вообще же основная задача многоуровневой объектно-ориентированной модели - контролирование потоков информации между объектами в соответствии с мандатной политикой доступа [78]. Рассмотрим, какие потоки информации существуют в объектно-ориентированной программной среде.
Очевидно, что данные от объекта к объекту могут быть переданы в первую очередь через параметры вызова методов - прямой поток. Обратный поток - возвращаемый результат вызова метода (которого может и не быть). Следует отметить, что не всегда вызов метода приводит к возникновению потока от объекта к объекту. Объект «принимает» информацию только тогда, когда изменяется его состояние, например, меняется значение атрибутов. Значит, если не было изменения атрибутов, значит, не было и потока информации между объектами. Пусть существует поток от объекта oj к объекту о2 через объект о3. Т.е. существует поток от объекта о і к объекту о2 и поток от объекта о2 к объекту о3. Назовем поток от объекта о і к объекту о2 транзитным потоком.
Все вышеперечисленные виды потоков являются прямыми потоками, т.е. в результате существования этого потока было изменено состояние по крайней мере одного из участников процесса передачи информации. Теперь рассмотрим ситуацию, когда при вызове метода объекта о2 объектом о; состояние объекта о2 не изменилось, а вместо этого возникает поток от объекта о2 к объекту о3, причем часть данных (или все данные), которые были в потоке от объекта о і к объекту о2, теперь участвуют в этом новом потоке. Т.е. фактически, получился поток между объектами oj объектом оз. Такой поток не может рассматриваться как прямой транзитный поток, так как обмена сообщениями между объектами о і и о3 не было. Кроме того, поток между объектами о7 и о2 мог быть, а мог и не быть. Такой вид передачи информации будем называть косвенным. В косвенном потоке может участвовать более трех объектов, например, если объект о3 инициализирует поток к объекту 04 с данными, пришедшими к нему от объекта 0/.
Теперь предположим, что все объекты маркированы метками доступа. Т.е. каждому объекту поставлен в соответствие уровень доступа из множества уровней доступа. Обозначим уровень доступа объекта как L(o). Назовем поток от объекта о,- к объекту о,- легальным, если L(o,) Ь(о/). Все остальные потоки назовем нелегальными. Основания задача системы разграничения доступа - исключить нелегальные потоки, т.е. осуществить функцию фильтрации потоков, пропуская только легальные потоки.
С точки зрения моделей безопасности взаимодействие между объектами в объектно-ориентированном мире может быть достаточно сложным. Следует отличать понятие объекта в объектно-ориентированной методологии (будем называть такой объект - экземпляр класса) и объекта из множества пассивных сущностей-объектов политики безопасности (см. раздел 0). Экземпляр класса объектно ориентированного ПО выступает и как объект-цель защиты политики безопасности и как субъект - активная сущность системы, поскольку обладает поведением. Для того чтобы разобраться в том, что именно является субъектами и объектами в ООП предлагается использовать субъектно-ориентированную модель, разработанную профессором Щербаковым А.Ю. [51].
В общем случае следует считать, что субъекты в компьютерной системе (КС) могут быть порождены только активной компонентой (субъектами) из объектов. С точки зрения объектно-ориентированного мира под объектом в этом случае следует понимать текст программы, записанный на диске, а в качестве субъекта выступает вектор испольняемого кода программы в оперативной памяти ЭВМ, который исполняется процессором ЭВМ для создания новых субъектов.
Объект О, называется источником для субъекта Sm, если существует субъект Sj, в результате воздействия которого на объект Ot в КС возникает субъект Sm: Create(Sj, О і) - Sm.
Для любого субъекта в КС существует некоторый объект (объекты) отображающие его состояние. Например, для активной программы это будет содержание участка оперативной памяти с исполняемым кодом данной программы. Таким образом, объект Ot в момент времени t ассоциирован с субъектом Sm, если состояние объекта О, повлияло на состояние субъекта в следующий момент времени. Т.е. субъект Sm использует информацию, содержащуюся в объекте Oj. Введем отношение:
Среди ассоциированных с субъектом объектов можно выделить функционально ассоциированные объекты и ассоциированные объекты-данные. Функционально ассоциированные объекты содержат, как правило, код программы. Ассоциированные объекты-данные являются аргументами операций. Для объекта ООП функционально ассоциированными объектами будут являться вектора исполняемого кода методов объекта ООП, а ассоциированными объектами-данными будут являться значения атрибутов, характеризующих объект ООП.
