Geum.ru
Авторефераты по всем темам  >>  Авторефераты по техническим специальностям

На правах рукописи

УСОВ СЕРГЕЙ ВЛАДИМИРОВИЧ

МЕТОДИКА ПРОВЕРКИ НАЛИЧИЯ ВОЗМОЖНОСТИ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА В ОБЪЕКТНООРИЕНТИРОВАННЫХ СИСТЕМАХ

Специальность:

05.13.19 - Методы и системы защиты информации, информационная безопасность

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

Омск-2012

Работа выполнена в ФГБОУ ВПО ОмГУ им. Ф.М.Достоевского.

Научный консультант: доктор физико-математических наук, доцент Белим Сергей Викторович

Официальные оппоненты: доктор технических наук, профессор Коробейников Анатолий Григорьевич кандидат физико-математических наук, доцент Комаров Игорь Иванович

Ведущая организация: ФГБОУ ВПО "Челябинский государственный университет"

Защита состоится 15.05.2012 на заседании диссертационного совета Д 212.227.05 в 15-50 по адресу: 197101, Санкт-Петербург, пр. Кронверкский, д.49., СПбГУ ИТМО, ауд. Интернет-центр.

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

Автореферат разослан 13 апреля 2012 г.

Ученый секретарь диссертационного совета Д 212.227.05 В.И. Поляков АКТУАЛЬНОСТЬ ПРОБЛЕМЫ Одной из основных проблем обеспечения безопасности информации является проблема выявления возможности несанкционированного доступа к данным.

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

Модель Харрисона-Руззо-Ульмана (Harrison-Ruzzo-Ulman, HRU) является одной из наиболее проработанных в математическом плане моделей. Одним из ее основных результатов является алгоритмическая неразрешимость задачи проверки произвольной системы на наличие каналов утечки информации вследствие несанкционированного доступа. В связи с этим предложен ряд ограничений модели, позволяющих выявить системы, для которых можно гарантировать защищенность, однако при этом существенно ограничивается функциональность компьютерной системы.

Модель Take-Grant более предсказуема, чем модель HRU. Для нее сформулированы две теоремы, содержащие условия, при которых в системе гарантированно не произойдет утечек информации. Однако модель Take-Grant допускает сведение к частному случаю модели HRU, и, следовательно, описывает меньший по мощности класс компьютерных систем.

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

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

В частности, операционные системы семейства Windows защищенной линии (NT/2000/XP/Vista/Seven) реализованы на основе объектно-ориентированного подхода и имеют собственную подсистему безопасности. Также широкое распространение получил объектно-ориентированный подход к построению баз данных, соответствующие базы данных получили название объектно-реляционных.

Таким образом, становится актуальным объектно-ориентированный подход к описанию системы безопасности, наряду с выявлением классов объектноориентированных систем, допускающих проверку безопасности и выработкой методики проверки этих систем на возможность утечки права доступа.

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

Для достижения поставленной цели решены следующие задачи:

1. Разработка объектно-ориентированной модели безопасности систем с дискреционным разделением доступов.

2. Выявление видов объектно-ориентированных систем, допускающих проверку безопасности.

3. Выявление влияния иерархии классов объектов на безопасность системы.

4. Классификация моделей безопасности объектно-ориентированных систем в зависимости от наличия взаимосвязи между объектами.

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

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

Научная новизна результатов исследований.

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

2. Доказана алгоритмическая неразрешимость проверки безопасности для произвольной объектно-ориентированной системы.

3. Выделено несколько видов объектно-ориентированных систем, допускающих автоматическую проверку безопасности.

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

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

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

Основные положения, выносимые на защиту:

1. Объектно-ориентированный подход при анализе безопасности существующих систем и при проектировании новых безопасных систем.

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

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

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

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

Апробация работы. Основные результаты диссертации докладывались и обсуждались на следующих конференциях: XIII международная научно-практическая конференция Решетнёвские чтения (Красноярск, 2009); IV международная научнопрактическая конференция Актуальные Проблемы Безопасности Информационных Технологий (Красноярск, 2010); I международная конференция Информационные технологии и системы (Банное, 2012), а также на научных семинарах Омского государственного университета им Ф.М. Достоевского.

Публикации. По теме диссертации опубликовано 7 научных работ, в том числе одна статья в журнале из списка, рекомендованного ВАК.

Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения и списка литературы. Работа содержит 131 страницу основного текста, 2 рисунка и 9 таблиц. Список литературы включает 1наименований.

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

Во введении обоснована актуальность выбранной темы диссертационной работы и сформулированы основные цели исследования.

В первой главе, носящей обзорно-аналитический характер, рассматриваются модели политик безопасности компьютерных систем с дискреционным разделением доступа. Приводится описание моделей Харрисона-Руззо-Ульмана (HRU) и TakeGrant. Выписаны все известные классы систем, допускающие проверку безопасности.

Вторая глава посвящена объектно-ориентированному подходу к построению политик безопасности с дискреционным разделением доступа.

Компьютерная система рассматривается в виде множества объектов О, имеющих открытые поля и скрытые поля, а также методы обработки полей. Каждый из объектов принадлежит какому-то классу k из множества всех классов системы K.

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

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

В субъектно-объектной модели произвольное разграничение доступа строится на основе отображения: M: S2R, где S - множество субъектов системы, O - множество объектов системы, R - множество видов доступа. Данное отображение принято записывать в виде таблицы, в строки которой соответствуют субъектам системы, а столбцы объектам системы. Таблицу обычно называют матрицей доступов, и она является общей для всей системы.

В рамках объектно-ориентированной модели у объектов существует два вида полей - private (P) и public (F), а также множество методов S. К скрытым полям (private) доступ осуществляется методами самого объекта, поэтому разрешения на доступ к таким полям сводятся к разрешениям активизации соответствующих методов объекта. Для открытых полей (public) будем считать верным следующее предположение: открытые поля всех объектов имеют одно и то же множество возможных типов доступа.

Множество доступов к открытым полям обозначим через R.

В силу того, что набор методов работы со скрытыми полями у каждого объекта свой определение общей матрицы доступов для всей компьютерной системы лишено смысла. Для построения системы дискреционного разделения доступа модифицируем все объекты системы, введя для каждого объекта oO дополнительное private поле M, содержащее локальную матрицу доступов, и методы работы с матрицей доступов.

o.M: O(oF o.S2R {0,1}, причем oТ.M[o, f] 2R (o, oТO), где f oТ.F, то есть для открытых полей в явном виде задается множество разрешенных доступов, и oТ.M[o, s] {0,1} (o, oТO), где s oТ.S, то есть для методов определяем разрешение (1) или запрет (0) вызова.

В случае, когда потребуется подчеркнуть принадлежность поля f объекту o, мы будем обозначать его o.f. Аналогичные обозначения будем использовать и для методов объекта. В частности, oТ.F - множество всех открытых полей объекта o.

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

1) Create(o, k) - создает объект o класса kK, при этом O'=O{o}, а в матрице доступа объектов oТo добавляется строка, соответствующая объекту o, причем foТ.F oТ.M[o, f]:= , soТ.S oТ.M[o, s]:=0. Матрица доступа объекта o создается полностью пустой.

2) Destroy(o) - уничтожает объект o, при этом O'=O\{o}, а в матрице доступа объектов oТo уничтожается строка, соответствующая объекту o.

3) Enter(r, o, oТ.f) - вносит право доступа r в oТ.M[o, f], при этом матрица доступа изменяется по правилу: oТ.M[o, f]:= oТ.M[o, f]{r}.

4) Delete(r, o, oТ.f) - удаляет право r доступа из oТ.M[o, f], при этом матрица доступа изменяется по правилу: oТ.M[o, f]:=oТ.M[o, f]\{r}.

5) Grant(o, oТ.s) - разрешает вызов объекту o метода oТ.s, при этом матрица доступа изменяется по правилу: oТ.M[o, s]= 1.

6) Deprive(o, oТ.s) - запрещает вызов объекту o метода oТ.s, при этом матрица доступа изменяется по правилу: oТ.M'[o, s]=0.

Под состоянием компьютерной системы в момент времени t будем понимать пару Q(t)=(O(t), M(t)), где O(t)={Oj} - множество всех объектов системы в момент времени t, а M(t)={o.M[](t),oO} - семейство всех матриц доступа объектов системы в состоянии на момент t. Начальное состояние системы будем обозначать Q(0).

Состояния компьютерной системы в модели HRU изменяются под воздействием запросов на модификацию матрицы доступа в виде команд следующего формата:

Command g(x1,..., xg):

if <конъюнкция логических выражений вида roТ.M[o, f] или oТ.M[o, s]=1> then <последовательность элементарных операторов>.

Здесь аргументы xk представляют собой либо объекты, либо классы, участвующие в качестве переменных в условной части либо в элементарных операторах.

Факт перехода системы под действием команды g из состояния Q(t), в котором она находилась в момент времени t, в состояние Q(t+1), в котором она находилась в следующий момент времени t+1, будем записывать в сокращенном виде:

Q(t)gQ(t+1).

HRU-модель системы безопасности называется монооперационной, если каждая команда в этой системе содержит только один элементарный оператор.

HRU-модель системы безопасности называется моноусловной, если каждая команда в этой системе содержит только одно условие.

HRU-модель системы безопасности объектно-ориентированной компьютерной системы называется монотонной, если команды этой системы не содержат операторов Delete, Deprive и Destroy.

Будем говорить, что состояние системы Q(t) допускает утечку права доступа rR, если существуют такие команда g, объект o и поле oТ.f объекта oТ, что roТ.M[o, f](t), но roТ.M[o, f](t+1), где Q(t)gQ(t+1).

Будем говорить, что состояние системы Q(t) допускает утечку права вызова, если существуют такая команда g, объект o и метод oТ.s объекта oТ, что oТ.M[o, f](t)=0, но oТ.M[o, f](t+1)=1, где Q(t)gQ(t+1).

Будем говорить, что система r-безопасна, если не существует такой последовательность команд g1...gT, что Q(t-1)gtQ(t), t=1,...,T, и Q(T) допускает утечку права r либо утечку права вызова.

Возникает вопрос, в каких случаях возможно решить проблему r-безопасности системы для объектно-ориентированной системы. Разрешимость аналогичной проблемы для HRU-моделей субъектно-объектных систем уже была доказана для некоторых частных случаев. А именно, для монооперационных систем, и для монотонных моноусловных систем. Наша цель - распространить эти результаты на модель OOHRU.

Теорема 2.1. Проблема r-безопасности системы является NP-разрешимой для монооперационной объектно-ориентированной модели.

Теорема 2.2. Проблема r-безопасности системы является NP-разрешимой для моноусловной монотонной объектно-ориентированной модели.

Теорема 2.3. Проблема r-безопасности системы неразрешима для произвольной объектно-ориентированной модели.

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

Также во второй главе поднимается вопрос о возможности реализации объектноориентированной модели безопасности, все объекты которой взаимно-корректны.

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

Каждый объект o взаимно-корректной модели обладает методом s, который активирует методы других объектов, и рядом методов sij o.S, осуществляющих соответственно виды доступа ri R к полям объекта fj o.F. При активации метод s требует два аргумента: имя метода oТ.sij, который надо активировать, и инструкции x, которые метод должен выполнить по активации. Так, например, если метод oТ.swзаписывает полученную информацию в поле oТ.f1, то x - это именно та информация, которую он должен записать.

В общей объектно-ориентированной модели метод o.s обладает правом ri на поле oТ.fj объекта oТ тогда и только тогда, когда в матрице доступа MТ взаимнокорректной модели на пересечении столбца o и строки oТ.sij стоит 1. Иначе говоря, oТ.MТ[o, oТ.sij] = ( ri oТ.M[o, oТ.fj] ), где M - матрица доступов общей объектноориентированной модели, а символ играет роль предиката.

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

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

Действительно, в субъектно-объектном случае на объект доступа (в том числе и субъект) на первый взгляд не накладывалось вообще никаких ограничений. Но объектно-ориентированный подход к устройству объектов сам по себе не оказывает существенного влияния на устройство модели разграничения доступа: например, public-поле объекта при таком подходе описано ничуть не подробнее объекта (не являющегося субъектом) в традиционном подходе. Есть и третье существенное отличие, индуцированное разницей в подходах, которое будет указано несколько позже.

Дискреционная модель безопасности компьютерной системы однозначно определяется множеством своих состояний (включая начальное) и способов перехода из одного состояния в другое, то есть набором команд, изменяющих матрицу доступа. Поэтому в каждый момент времени естественно рассматривать такую модель как четверку (O, S, M, Г), где O - множество объектов системы, не являющихся субъектами, S - множество активированных субъектов, M - множество прав доступа, оформленное в виде матрицы доступов, наконец, Г - набор команд системы. Вообще говоря, = (t) = (O(t), S(t), M(t), Г), где t - текущий момент времени.

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

Такие две модели = (t) = (O(t), S(t), M(t), Г) и Т = Т (t) = (OТ(t), SТ(t), MТ(t), ГТ) будем называть эквивалентными, если существует взаимно-однозначное отображение , определенное на каждом из элементов модели, такое что (O(t)) = OТ(t), (S(t)) = SТ(t), (M(t)) = MТ(t) (в каждый момент времени t) и (Г) = ГТ, причем действие этого отображения на матрице доступов и на наборе команд индуцируется по некоторым правилам. А именно:

t s S(t) o O(t) : M(t)[s, o] = (M(t)) [(s), (o)]. (1) t Г : (t) (t+1) Т(t) Т(t+1), ( x1,..., xp ) ( )( ( x1 ),..., ( x )) p где x1,Е xp O(t) S(t). (2) Это определение хорошо подходит для субъектно-объектных систем, однако бессмысленно для объектно-ориентированных систем, обладающих более сложной структурой. Однако можно предложить аналог эквивалентности для субъектнообъектной и объектно-ориентированной систем.

Будем говорить, что объектно-ориентированная модель Т реализует субъектнообъектную систему = (t) = (O(t), S(t), M(t), Г), если существует взаимнооднозначное отображение , определенное на каждом из элементов модели , такое что (O(t)) (S(t)) = OТ(t) - множество объектов системы Т (в момент времени t), (M(t)) определяет матрицу доступов системы Т (в момент времени t), а (Г) определяет набор команд системы Т. При этом выполняются соотношения (1) и (2).

В общем виде, будем говорить, что объектно-ориентированная модель некоторого класса A реализует субъектно-объектную модель некоторого класса B, если для каждого представителя класса B найдется реализующий его представитель класса A.

Теорема 2.4 Объектно-ориентированная модель HRU реализует субъектнообъектную модель HRU. Другими словами, SOOO, где через SO обозначено множество компьютерных систем, представимых в субъектно-объектной HRUмодели безопасности, а через OO - множество компьютерных систем, представимых в объектно-ориентированной HRU-модели безопасности.

На самом деле объектно-ориентированная модель реализует более широкий класс систем, чем субъектно-объектная.

Теорема 2.5 Существует объектно-ориентированная модель Т, для которой не найдется субъектно-объектной модели, которую бы реализовывала Т.

Теорема. 2.6 Объектно-ориентированная модель HRU реализует субъектнообъектную модель HRU с типизированной матрицей доступов (ТАМ).

Однако не любая объектно-ориентированная политика безопасности HRU является реализацией некоторой субъектно-объектной политики HRU с типизированной матрицей доступа. Дело в том, что классы определяют не только тип безопасности объекта, как в модели TAM, они определяют еще и структуру объекта, которая может быть довольно сложной.

Теорема 2.7 Объектно-ориентированная модель HRU реализует субъектнообъектную модель Take-Grant.

Класс субъектно-объектных моделей Take-Grant, очевидно, строго уже класса объектно-ориентированных моделей HRU по причине строго определенного вида команд.

Однако не является ли по той же причине модель дискреционного доступа TakeGrant частным случаем субъектно-объектной модели HRU? Ответ на этот вопрос отрицательный. Дело в том, что в субъектно-объектной модели HRU объект, не являющийся субъектом, принципиально не может обладать правами доступа к другому объекту (объект объектно-ориентированной модели такими правами обладает), что подразумевается в модели Take-Grant. В модели Take-Grant активный статус субъекта определяется не наличием прав доступа, а его способностью к передаче прав доступа другому объекту. Хотя, очевидно, объекты, не являющиеся субъектами, воспользоваться своими правами доступа также не могут.

Третья глава посвящена исследованию HRU-моделей объектноориентированных систем с иерархией.

Будем рассматривать компьютерную систему в виде множества объектов О классов K, обладающих открытыми полями f F и скрытыми полями pP, а также методами обработки полей sS. Здесь F=k.F (по всем kK) - множество всевозможных открытых полей всех объектов и классов, k.F - множество открытых полей класса k (каждый объект класса k обладает тем же набором k.F открытых полей), аналогично определяются P и S. Причем если поле k.f наследуется классом k у класса k', то соответствующее поле класса k' мы будем для удобства обозначать именно k'.f, подчеркивая тем самым их взаимосвязь (таким образом, fk.F и fk'.F).

Пусть Ok O - множество объектов класса k K. В случае, если требуется уточнить класс объекта, поле f объекта ok Ok будем обозначать ok.f, поле f класса k - k.f. Для скрытых полей и методов класса будем использовать аналогичные обозначения.

HRU-модель системы безопасности называется иерархической, если на множестве объектов O задан частичный порядок-иерархия, и в любой момент работы системы для любых двух объектов o, o'O таких, что o' o, для любого поля или метода xX, общего для объектов o и oТ, и для любого поля или метода yX объекта o''O верно следующее: o''.M[o, x]o''.M[o', x] и o'.M[o'', x]o.M[o'', x]. Здесь и далее X - множество всевозможных полей и методов всех существующих в системе на данный момент времени объектов, "" - отношение частичного порядка.

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

Частным случаем является система, на множестве объектов которой задано отношение полного порядка.

Однако в объектно-ориентированных системах классы (и, соответственно, объекты этих классов) уже связаны частичным отношением наследственности, поэтому в данном случае иерархия строится естественным образом.

HRU-модель объектно-ориентированной системы безопасности назовем моделью с естественной иерархией, если в любой момент работы системы для любых двух объектов ok, ok ' классов k и k' таких, что k' является потомком k, для любого поля или метода x, общего для классов k и k', и для любого поля или метода y X объекта ok" выполняются следующие соотношения: ok".M[ok, y] ok".M[ok ', y] и ok '.M[ok", x] ok.M[ok", x].

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

Класс объектно-ориентированной системы безопасности называется однородным, если матрицы доступа всех объектов этого класса в любой момент времени совпадают. В этом случае имеет смысл рассматривать матрицу доступа как атрибут не отдельного объекта класса, а класса целиком. HRU-модель объектноориентированной системы безопасности называется однородной, все ее классы однородны.

Заметим, что в реальных системах безопасности модели с естественной иерархией как правило либо однородны, либо все объекты системы являются представителями классов, не имеющих наследников. Во втором случае матрица доступов объекта o класса k подчиняется соотношениям из определения естественной иерархии как матрица наследника по отношению к матрице самого класса k.

Расширяя модель Харрисона-Руззо-Ульмана, определим следующие элементарные операторы для работы с матрицей доступов:

1. Create(o,k) - создает объект o класса k K, при этом O : O o.

2. Destroy(o,k) - уничтожает объект o, при этом O : O \ o.

Первые два оператора никак не отражаются на матрице доступов.

3. Enter(r, k, k'.f) - вносит право доступа r в k'.M[k, f ], при этом матрица доступа изменяется по правилу: k'.M[k, f ] : k'.M[k, f ] r. Данный элементарный оператор может быть выполнен, только если выполнены следующие условия:

а) для любого потомка k"класса k, r k'.M[k", f ], б) для любого родителя k" класса k', обладающего полем f, r k".M[k, f ].

4. Delete(r, k, k'.f) - удаляет право r доступа из k'.M[k, f ], при этом матрица доступа изменяется по правилу: k'.M[k, f ] : k'.M[k, f ] \ r. Данный элементарный оператор может быть выполнен, только если выполнены следующие условия:

а) для любого родителя k" класса k, обладающего полем f, r k'.M[k", f ], б) для любого потомка k" класса k', r k".M[k, f ].

5. Grant(k, k'.s) - разрешает вызов объекту класса k метода k'.s, при этом матрица доступа изменяется по правилу: k'.M[k, s] 1. Данный элементарный оператор может быть выполнен, только если выполнены следующие условия:

а) для любого потомка k" класса k k'.M[k", s] 1, б) для любого родителя k" класса k', обладающего методом s, k".M[k, s] 1.

6. Deprive(k, k'.s) - запрещает вызов объекту класса k метода k'.s, при этом матрица доступа изменяется по правилу: k'.M[k, s] 0. Данный элементарный оператор может быть выполнен, только если выполнены следующие условия:

а) для любого родителя k" класса k, обладающего методом s, k'.M[k", s] 0, б) для любого потомка k" класса k' k".M[k, s] 0.

Условия а) и б) выполнения операторов Enter, Delete, Grant, Deprive будем называть условиями целостности.

Под состоянием компьютерной системы в момент времени t будем понимать пару Q(t)=(O(t), M(t)), где O(t) - множество всех объектов системы в момент времени t, а M(t) - семейство всех матриц доступа классов системы в состоянии на момент времени t. Начальное состояние системы будем обозначать Q(0).

Состояния компьютерной системы в модели HRU изменяются под воздействием запросов на модификацию матрицы доступа в виде команд следующего формата:

if <условная часть (представляет собой конъюнкцию значений логических выражений вида r k'.M[k, f ] или k'.M[k, s] 1)> then <последовательность элементарных операторов>.

Аргументы команды представляют собой поля или функции заданных классов, участвующие в качестве переменных в условной части либо в элементарных операторах. Классы аргументами команды не являются: они определяют саму команду.

Отметим, что если хотя бы одно условие целостности операторов Enter, Delete, Grant, Deprive, входящих в команду, не будет соблюдено, вся команда не будет выполнена.

К тому же, не должно существовать команд, содержащих одновременно операторы Enter(r,k,k''.f) и Delete(r,k,k'.f), либо Grant(k,k''.s) и Deprive(k,k'.s), либо Enter(r,k',k.f) и Delete(r,k'',k.f), либо Grant(k',k.s) и Deprive(k'',k.s), где k'' - потомок k'.

Несоблюдение этого условия приведет к нарушению естественной иерархии.

Действительно, пусть, к примеру, Enter(r,k',k.f) и Delete(r,k'',k.f) присутствуют в одной команде, и в момент, когда r k.M[k", f ], но r k.M[k', f ] команда выполняется, в результате чего класс k'' (потомок) теряет право r на поле k.f, а родительский класс k' его приобретает.

Все прочие сочетания элементарных операторов являются допустимыми, т.к. не могут привести к нарушению естественной иерархии.

Без ограничения общности можно считать, что не обладающий полем (или методом) x X класс все же таковым обладает, но это поле пусто (или метод ничего не выполняет), а доступом к такому полю (методу) могут обладать все классы.

Факт перехода системы под действием команды из состояния Q(t), в котором она находилась в момент времени t, в состояние Q(t+1), в котором она находилась в следующий момент времени t+1, будем записывать в виде: Q(t) 1).

Q(t Будем говорить, что состояние однородной системы Q(t) допускает утечку права доступа r R, если существуют такие команда , класс k и поле f класса k', что r k'.M[k, f ](t), но r k'.M[k, f ](t 1), где Q(t) 1). Аналогично определим Q(t состояние, допускающее утечку права вызова. Будем говорить, что система rбезопасна, если не существует такой последовательность команд 1,,..., что 2 T t Q(t 1) Q(t) t=1,2,Е T, и Q(T) допускает утечку права r либо утечку права вызова.

Теорема 3.1. Проблема r-безопасности системы является NP-разрешимой для однородной объектно-ориентированной модели (в том числе, и для модели с естественной иерархией).

Введем дополнительную, командную иерархию на множестве классов. Класс k будем называть ребенком относительно команды , если команда содержит оператор Create(x, k), где x - аргумент команды класса k. Класс k будем называть родителем относительно команды , если существует аргумент x команды класса k такой, что не содержит оператор Create(x, k). Вообще, будем называть класс k - родителем класса kТ, а класс kТ - ребенком класса k, если существует такая команда Г, относительно которой k является родителем, а kТ - ребенком.

Командную иерархию удобно представлять графом, который будем называть графом наследования. Это ориентированный граф с множеством вершин K, в котором дуга от k к kТ существует только в том случае, если k - родитель kТ.

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

Теорема 3.2. Проблема r-безопасности системы является NP-разрешимой для монотонной ациклической неоднородной объектно-ориентированной модели с иерархией.

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

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

В заключении третьей главы изучаются свойства семейства наборов прав дискреционной политики безопасности:

Рассмотрим компьютерную систему с дискреционной политикой безопасности.

Пусть М - ее общая матрица доступа, и M(t) - состояние матрицы доступа в момент времени t. Тогда для M(t) можно рассмотреть множество A(t) как неструктурированный набор прав: A(t) = {a Stotal Ototal R | a=(s, o, r) и r M(t)[s, r]}. Здесь в случае объектно-субъектной модели Stotal - множество всех субъектов, допускающих активацию в данной системе, Ototal - множество всех объектов, которые могут быть созданы в системе, R - множество всевозможных прав, которыми может обладать субъект на объект. В случае объектно-ориентированной модели Stotal - множество объектов, которые могут быть созданы в системе, Ototal - множество полей и методов объектов системы, R - множество всевозможных прав, которыми может обладать объект на поле или метод.

Рассмотрим семейство всевозможных подмножеств декартова произведения Stotal Ototal R. Понятно, что A(t) . Семейство конечно, если множества Stotal и Ototal конечны. Такие компьютерные системы будем называть конечными. Далее, если не оговорено противного, будем рассматривать именно конечные компьютерные системы.

Будем говорить, что набор прав доступа A(t) допускает утечку права доступа r R, если состояние системы Q(t) с соответствующей набору прав A(t) матрицей доступа M(t) допускает утечку права r. Будем говорить, что набор A r-безопасен, если система с соответствующей набору прав A начальной матрицей доступа M(0) rбезопасна.

Теорема 3.3 Семейство I всех r-безопасных наборов прав доступа образует систему независимости.

Рассмотрим на множестве наборов всевозможных прав аддитивную функцию : R (множество действительных чисел). Для этого достаточно задать значение функции на элементах множества Stotal Ototal R. Смыслом этой функции может быть, например, оценка эффективности права доступа. По теореме Радо-Эдмондса жадный алгоритм точно решает задачу нахождения максимального значения аддитивной функции на r-безопасном наборе, если семейство I всех r-безопасных наборов прав доступа является матроидом.

Теорема 3.4 Существует дискреционная модель безопасности компьютерной системы, семейство всех r-безопасных наборов прав доступа которой является матроидом.

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

Изложим в пошаговой форме инструкции по проверке данной объектноориентированной модели безопасности на возможность утечки права доступа (приводятся в сокращении).

I. В первую очередь необходимо составить список прав доступа и список классов системы с описанием полей и методов. Каждому праву и каждому классу присвоен натуральный порядковый номер.

II. Составить список всех команд системы. Для упрощения дальнейшей обработки данных команду удобно представлять как объект, содержащий три списка:

список аргументов (А), в котором перечислены классы, список условий (У) и список элементарных операторов (О).

Опишем подробно элементы каждого из списков.

Запись списка аргументов команды содержит два поля. Первое поле содержит номер класса соответствующего аргумента, а второе - указатель на запись следующего аргумента. Аргументы следуют в списке в том же порядке, в котором они следовали в команде. Указатель записи последнего аргумента устанавливается на NULL.

Запись списка условий команды содержит пять полей. Первое поле содержит номер права, наличие которого проверяется в соответствующем условии. Второе поле содержит указатель на запись аргумента, подставленный в качестве которого объект должен обладать этим правом. Третье поле содержит указатель на запись аргумента, на поле (или метод) которого (точнее, на поле или метод подставленного вместо него объекта) должно распространяться это право. Четвертое поле содержит номер поля (или метода), на который должно распространяться это право. Пятое поле содержит указатель на запись следующего условия. Указатель записи последнего условия устанавливается на NULL. В случае безусловной команды список содержит единственную запись, первое поле которой пусто, а указатель второго поля установлен на NULL.

Запись списка элементарных операторов команды содержит шесть полей.

Первое поле содержит имя соответствующего элементарного оператора. Второе поле содержит номер права, относительно которого выполняется данный оператор. В случае оператора Destroy или Create второе поле не содержит данных. Третье поле содержит указатель на запись аргумента, который является вторым аргументом соответствующего элементарного оператора. В случае оператора Create или Destroy третье поле содержит указатель на запись аргумента, подставленный в качестве которого объект требуется создать или уничтожить. Четвертое поле содержит указатель на запись аргумента, который является третьим аргументом соответствующего элементарного оператора. В случае оператора Create или Destroy четвертое поле пусто. Пятое поле содержит номер поля (или метода), по отношению к которому применяется оператор с правом, номер которого указан во втором поле. В случае оператора Create или Destroy пятое поле пусто. Наконец, шестое поле содержит указатель на запись следующего элементарного оператора. Указатель записи последнего оператора устанавливается на NULL. Отдельно следует рассмотреть случай иерархических систем безопасности, когда возможны элементарные операторы, аргументами которых являются не объекты, а классы. В этом случае соответствующие поля содержат номер класса, а не указатель на аргумент.

Несложно написать компилятор, который данным, содержащимся в объектекоманде, будет сопоставлять исполняемый код.

III. Установить, относится ли данная система безопасности к одному из классов, допускающих проверку безопасности.

III.a. Алгоритм проверки на монооперационность.

Шаг 1. Устанавливаем значение monooperational:= TRUE. Выбираем первую команду из списка команд. Переходим на Шаг 2.

Шаг 2. В текущей команде находим список О. Если указатель первого элемента списка О не указывает на NULL, присваиваем monooperational:=FALSE. Переходим на Шаг 3.

Шаг 3. Если monooperational = TRUE и текущая команда - не последняя в списке, переходим на Шаг 4, в противном случае - на Шаг 5.

Шаг 4. Выбираем следующую команду из списка и переходим на Шаг 2.

Шаг 5. Возвращаем значение переменной monooperational и завершаем работу.

Если по окончании работы алгоритма переменная monooperational принимает значение TRUE, то система является монооперационной. Если система оказалась немонооперационной, переходим к пункту III.b III.b. Алгоритм проверки на монотонность и моноусловность.

Шаг 1. Устанавливаем значения monotone:=TRUE, monoconditional:=TRUE.

Выбираем первую команду из списка команд. Переходим на Шаг 2.

Шаг 2. В текущей команде находим список У. Если указатель первого элемента списка У не указывает на NULL, присваиваем monoconditional:=FALSE. Переходим на Шаг 3.

Шаг 3. Выбираем первый элементарный оператор из списка О, если он не пуст.

Переходим на Шаг 4. Если список пуст, переходим на Шаг 7.

Шаг 4. Если первое поле текущего оператора принимает значение Delete или Destroy, присваиваем monotone:= FALSE. Переходим на Шаг 5.

Шаг 5. Если указатель шестого поля текущего элементарного оператора из списка О указывает на NULL или monotone = FALSE, переходим на Шаг 7. В противном случае переходим на Шаг 6.

Шаг 6. Выбираем следующий оператор из списка О. Переходим на Шаг 4.

Шаг 7. Если monotone=TRUE, monoconditional=TRUE и текущая команда - не последняя в списке, переходим на Шаг 8. В противном случае переходим на Шаг 9.

Шаг 8. Выбираем следующую команду из списка. Переходим на Шаг 2.

Шаг 9. Возвращаем значение переменных monotone и monoconditional.

Завершаем работу алгоритма.

Если по окончании работы алгоритма переменные monotone и monoconditional принимают значения TRUE, то система является монотонной и моноусловной. В противном случае переходим к пункту III.c.

III.c. Проверка системы на реализацию модели Take-Grant. Алгоритм проверки полностью приведен в тексте работы.

III.d. Если проверяется модель безопасности OOHRU с иерархией, сохраняющей наследование (в смысле следствия из теоремы 3.2), достаточно проверить систему на монотонность.

Алгоритм проверки на монотонность:

Шаг 1. Устанавливаем значение monotone:=TRUE. Выбираем первую команду из списка. Переходим на Шаг 2.

Шаг 2. Выбираем первый элементарный оператор из списка О, если он не пуст.

Переходим на Шаг 3. Если список пуст, переходим на Шаг 6.

Шаг 3. Если первое поле текущего оператора принимает значение Delete или Destroy, присваиваем monotone:= FALSE. Переходим на Шаг 4.

Шаг 4. Если указатель шестого поля текущего элементарного оператора из списка О указывает на NULL или monotone = FALSE, переходим на Шаг 6. В противном случае переходим на Шаг 5.

Шаг 5. Выбираем следующий оператор из списка О. Переходим на Шаг 3.

Шаг 6. Если monotone = TRUE и текущая команда - не последняя в списке, переходим на Шаг 7. В противном случае переходим на Шаг 8.

Шаг 7. Выбираем следующую команду из списка. Переходим на Шаг 2.

Шаг 8. Возвращаем значение переменной monotone. Завершаем работу алгоритма.

Если по окончании работы алгоритма переменная monotone принимает значения TRUE, то система является монотонной.

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

В результате применения описанной методики нам либо удастся доказать безопасность объектно-ориентированной системы, либо доказать, что система допускает утечку право доступа, либо выяснить, что система не относится ни к одному из известных классов, допускающих проверку безопасности.

Также в четвертой главе предложена интерпретация операционной системы MS Windows как системы с моделью безопасности OOHRU, в результате чего к Windows или ее компонентам возможно применение описанной выше методики. Выработаны рекомендации по администрированию ОС Windows для автоматической проверки безопасности. Рассмотрены также объектно-реляционные базы данных в рамках СУБД Oracle, которые также укладываются в одну из разновидностей объектноориентированных моделей безопасности.

В заключении сформулированы основные результаты и выводы.

ОСНОВНЫЕ РЕЗУЛЬТАТЫ РАБОТЫ Проведено построение модели безопасности компьютерных систем с дискреционным разделением доступа HRU на основе объектно-ориентированного подхода.

1.1 Определены элементарные операторы объектно-ориентированной HRUсистемы.

1.2 Доказана алгоритмическая неразрешимость проверки безопасности для произвольной объектно-ориентированной системы.

1.3 Выявлены классы объектно-ориентированных HRU-систем, допускающих проверку безопасности системы.

1.4 Построена взаимно-корректная объектно-ориентированная система.

2. Показаны преимущества объектно-ориентированного подхода перед субъектно-объектным.

2.1 Показано, что все субъектно-объектные системы представимы в виде объектно-ориентированных, обратное неверно.

2.2 Показано, что Take-Grant-системы также сводятся к объектноориентированным HRU-системам.

2.3 Сделаны выводы об отношениях между классами этих моделей, допускающими проверку безопасности системы.

3. Построены объектно-ориентированные HRU-системы с иерархией.

3.1 Определены элементарные операторы однородной объектноориентированной HRU-системы с иерархией.

3.2 Доказано, что проблема безопасности разрешима для однородной объектноориентированной HRU-системы с иерархией.

3.3 Определены элементарные операторы для финально-однородной объектноориентированной HRU-системы с иерархией. Также указаны случаи разрешимости проблемы безопасности для данной модели.

3.4 Изучен случай объектно-ориентированной модели с иерархией, допускающей всевозможные команды.

4. Изучены свойства семейств наборов прав доступа конечной дискреционной модели.

4.1 Показано, что семейство наборов прав доступа конечной дискреционной модели, безопасных относительно утечки некоторого права, образует систему независимости.

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

5. Проведен анализ реально существующих объектно-ориентированных систем с использованием построенных моделей.

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

5.2. Проведен анализ объектно-реляционных баз данных Oracle. Показано, что к ним применима однородная объектно-ориентированная модель с иерархией. С использованием разработанной методики выделены требования к администрированию системы, при которой она будет монооперцирнной или монотонной моноусловной и, как следствие, допускать автоматическую проверку безопасности.

Основное содержание диссертации опубликовано в следующих работах:

В научных журналах, рекомендованных ВАК:

1. Белим С. В., Белим С. Ю., Усов С.В. Объектно-ориентированная модификация модели безопасности HRU //Проблемы информационной безопасности.

Компьютерные системы. 2010, В.1, С.6-14.

В других изданиях:

2. Усов С.В., Белим С.В., Белим С.Ю. Дискреционное разграничение доступа для объектно-ориентированной модели компьютерной системы // Проблемы обработки и защиты информации. Книга 1. Модели политик безопасности компьютерных систем.

Коллективная монография / Под общей редакцией С.В. Белима. - Омск: ООО Полиграфический центр КАН, 2010.

3. Усов С.В., Белим С.В. Объектно-ориентированный подход в построении дискреционной политики безопасности // Математические структуры и моделирование, 2009, №20. С.153-14. Усов С.В. Объектно-ориентированный подход в построении политики безопасности. Системы с естественной иерархией // Математические структуры и моделирование, 2010, №21. С.151-15. Белим С.В., Усов С.В. Объектно-ориентированная модель компьютерной системы // Материалы XIII Международной научной конференции Решетневские чтения, Красноярск, 2009, с.56. Усов С. В. Объективно-ориентированная модель компьютерной системы с наследованием прав доступа // Актуальные проблемы безопасности информационных технологий: материалы IV Международной научно-практической конференции / под общей ред. О.Н. Жданова, В. В. Золотарева; Сиб. гос. аэрокосмич. ун-т. Красноярск, 2010. С.90 - 93.

7. Усов С. В. Об отношении между объектно-ориентированными и субъектнообъектными дискреционными моделями безопасности компьютерных систем // Информационные технологии и системы: материалы Первой междунар. конф., Банное, Россия, 28 февр. - 4 марта 2012г./ отв. ред. В.А. Мельников. Челябинск: Издво Челяб. гос. ун-та,2012. 157с.

Подписано в печать 10.04.2012.

Формат 60x84/16. Бумага писчая.

Оперативный способ печати.

Усл. печ. л. 1,06. Тираж 100 экз. Заказ № 192.

Отпечатано в Полиграфическом центре КАН тел. (3812) 24-70-79, 8-904-585-98-84.

E-mail: pc_kan@mail.ru 644050, г. Омск, ул. Красный Путь, Лицензия ПЛД № 58-47 от 21.04. Авторефераты по всем темам  >>  Авторефераты по техническим специальностям