Методика проверки объектно-ориентированной системы на наличие возможностей несанкционированного доступа

Размещено на http://www.allbest.ru/

Методика проверки объектно-ориентированной системы на наличие возможностей несанкционированного доступа

Т.Ю. Алмаев, О.М. Лепешкин

Аннотация

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

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

This article discusses existing access control models. A modern approach to the description of discretionary security policy is presented. A method for analyzing a computer system for the possibility of unauthorized access has been developed. Recommendations are proposed in the design of new security models based on an object-oriented approach.

Keywords: object-oriented system; method; access control; security policy; unauthorized access; analysis.

Введение

На сегодняшний день возможность несанкционированного доступа к данным является одной из основных проблем обеспечения безопасности информации. Для решения этой проблемы принято проводить анализ компьютерной системы на основе дискреционной модели безопасности [2, 3, 4, 5].

Среди известных моделей дискреционного разграничения доступа модель Харрисона-Руззо-Ульмана (Harrison-Ruzzo-Ulman, HRU) [2, 3, 4] является одной из наиболее проработанных в математическом плане моделей.

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

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

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

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

Модели разграничения доступа

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

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

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

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

Для описания модели разграничения доступа достаточно указать принципы ограничения доступов некоторых субъектов к некоторым объектам, т.е. описать множество допустимых потоков. Исходя из способов наложения ограничений на доступ различают следующие типы моделей разграничения доступа [2, 4]:

1. Дискреционные политики безопасности.

2. Мандатные политики безопасности.

3. Ролевые политики безопасности

4. Тематические политики безопасности.

5. Политики безопасности информационных потоков.

6. Субъектно-объектная модель программной среды.

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

В политике дискреционного доступа множество допустимых доступов задается для субъектов и объектов явным образом, т.е. перечислением всех допустимых троек субъект-объект-право доступа [3, 4].

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

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

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

Модель разделения доступа Харрисона-Руззо-Ульмана в объектно-ориентированной системе

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

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

, причем

, где

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

, где,

то есть для методов определяем разрешение (1) или запрет (0) вызова.

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

Command:

If <конъюнкция логических выражений вида или >

then <последовательность элементарных операторов>.

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

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

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

Будем говорить, что состояние системы Q(t) допускает утечку права доступа, если существуют такие команда g, объект о и поле объекта о', что, но , где.

Будем говорить, что состояние системы Q(t) допускает утечку права вызова, если существуют такая команда g, объект о и метод объекта о', что, но, где .

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

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

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

F1. Базовая (неоднородная) модель объектно-ориентированной системы без наследования. В данной модели каждый объект принадлежит определенному классу, при этом все классы независимы.

FZ. Безусловная неоднородная модель, включающая в себя всевозможные команды.

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

Н1. Неоднородная модель с иерархией. Отличается от модели F1 заданием строгой связи - иерархии - на множестве классов.

Н2. Финально-неоднородная модель с иерархией.

HZ. Безусловная неоднородная модель с иерархией, включающая в себя всевозможные команды.

Методика проверки объектно-ориентированной системы безопасности на наличие возможностей несанкционированного доступа

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

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

2. Составить список всех команд системы. Для упрощения дальнейшей обработки данных команду удобно представлять, как объект, содержащий три списка: список аргументов (А), в котором перечислены классы, список условий (У) и список элементарных операторов (О).

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

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

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

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

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

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

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

Если по окончании работы алгоритма переменная monooperational принимает значение TRUE, то система является монооперационной. В этом случае мы можем выполнить проверку на r-безопасность системы согласно алгоритму, для монооперационной объектно-ориентированной модели, а именно, изучить результаты применения к системе конечного количества цепочек команд конечной длины, на основании чего сделать выводы о возможности утечки права доступа.

Если система оказалась немонооперационной, переходим к пункту 3.2

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

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

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

Шаг 3. Выбираем первый элементарный оператор из списка O, если он не пуст. Переходим на Шаг 4. Если список пуст, переходим на Шаг 7.

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

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

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

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

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

Шаг 9. Возвращаем значение переменных monotone и monoconditional. Завершаем работу алгоритма.

Если по окончании работы алгоритма переменные monotone и monoconditional принимают значения TRUE, то система является монотонной и моноусловной. В этом случае мы можем выполнить проверку на r-безопасность системы согласно алгоритму, для моноусловной монотонной объектно-ориентированной модели.

3.3 Если проверяется модель безопасности OOHRU с иерархией, сохраняющей наследование, достаточно проверить систему на монотонность.

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Литература

1. Лепешкин О.М., Орловский В.М. Развитие математического аппарата информационной

безопасности. // Известия ЮФУ. Технические науки, 2003, № 4 (33). - С. 91-92.

2. Гайдамакин Н.А. Разграничение доступа к информации в компьютерных системах. Е.: Издательство Уральского Университета, 2003. 328 с.

3. Грушо А.А., Тимонина Е.Е. Теоретические основы защиты информации. М.: Яхтсмен, 1996. 192с.

4. Девянин П.Н. Модели безопасности компьютерных систем: Учебное пособие для студентов высших учебных заведений. М.: Издательский центр «Академия», 2005. 144 с.

5. Теоретические основы компьютерной безопасности: Учебное пособие для вузов / Девянин П.Н. и др. М.: Радио и связь, 2001. 192 с.

Размещено на Allbest.ru