Модель Грэхэма-Деннинга

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

История[править | править код]

Концепцию дискреционного разграничения доступа впервые предложил Батлер В. Лэпмсон[1]. Развивая эту теорию, Скотт Грэхэм и Питер Деннинг формализовали введенные Лэмпсоном принципы и построили одну из первых фундаментальных моделей разграничения доступа[2]. В основу модели легло понятие, что каждый процесс имеет уникальный идентификационный номер, который прикрепляется системой к каждой попытке доступа процесса к объекту системы. Модель Грэхэма-Деннинга сформировала основу для последующих систем безопасности, например, широко распространённой модели HRU (Harrison-Ruzzo-Ullman).

Описание модели[править | править код]

Компоненты модели[править | править код]

Основу модели составляют следующие компоненты[3]:

  • Множество объектов O — сущностей, доступ к которым должен контролироваться. Примерами объектов в контексте ОС являются страницы оперативной памяти, программы, устройства внешней памяти компьютера, инструкции и файлы.
  • Набор субъектов S, чей доступ к объектам должен контролироваться. Под субъектом обычно имеют в виду пару (процесс, домен), в которой процесс представляет собой активную выполняющуюся программу, а домен — окружение, в котором выполняется процесс. Примерами доменов в системе IBM System/370 являются состояния процессора, супервизора или прикладной программы.

Так как субъекты системы должны быть защищены, они в свою очередь также рассматриваются как объекты. Для каждого объекта определён субъект-«владелец», а для каждого субъекта — субъект-«контролер», которые имеют особые права к данному объекту или субъекту соответственно[4].

  • С каждым типом объекта ассоциируется специальный управляющий процесс — монитор обращений, через который проходят все попытки доступа к объектам. Примерами мониторов являются, например, системные файлы, оборудование для выполнения инструкций и адресации памяти.
  • Набор правил доступа R, определяющих возможный вид доступа субъекта по отношению к объекту. В модели Грэхэма-Деннинга определяются следующие восемь правил доступа, задающих действия и операции, которые субъект может выполнить над объектом[5].
    • Создание объекта, создание субъекта, удаление объекта и удаление субъекта позволяют субъекту создать новый объект/субъект в системе или, соответственно, удалить существующий.
    • Чтение прав доступа позволяет субъекту определить текущие права доступа субъекта к объекту.
    • Назначение прав доступа позволяет владельцу объекта назначить любое право доступа к объекту для другого субъекта.
    • Удаление прав доступа позволяет субъекту удалить право другого субъекта по отношению к объекту (субъект, удаляющий права, является или владельцем объекта, или контролером субъекта, права которого удаляются).
    • Передача прав доступа позволяет субъекту передать одно из его прав к объекту другому субъекту. Разделяют передаваемые или непередаваемые права. Если субъект получает передаваемое право, он может потом передать это право (как передаваемое или нет) другому субъекту. Если субъект получает непередаваемое право, он может использовать это право, но не может передать это право другому субъекту.
  • Правила обычно задаются матрицей контроля доступа А, в которой строки соответствуют субъектам, столбцы — объектам (включая субъекты), а элементы таблицы (так называемые атрибуты доступа) A[S,O] содержат список разрешенных привилегий субъекта s по отношению к объекту o.

Операции для работы с матрицей доступа[править | править код]

В таблице приведены операции для работы с матрицей доступа и соответствующие пред- и постусловия[6]. Субъект, выполняющий каждую из команд, обозначен x. r* — право доступа, которое может быть впоследствии передано другому субъекту. Соответственно, право r (без символа ‘*’) считается непередаваемым.

Команда Предусловие Результат
Создать объект o - В матрицу A добавлен столбец o; назначен владелец объекта в атрибуте A[x, o]
Создать субъект s - В A добавлена строка s; в A[x,s] назначен контролер субъекта
Удалить объект o Владелец в A[x,o] Удален столбец o
Удалить субъект s Контролер в A[x,s] Удалена строка s
Прочитать права доступа s к o Контролер в A[x,s] или владелец в A[x,o] Скопировать атрибут A[s,o] субъекту x
Удалить прав доступа r субъекта s к объекту o Контролер в A[x,s] или владелец в A[x,o] Удалить право r из A[s,o]
Назначить право доступа r к o для s Владелец в A[x,o] Добавить r в A[s,o]
Передать право доступа r или r* к o для s В A[x,o] есть право r* Добавить r или r* соответственно в A[s,o]

Корректность модели[править | править код]

Требования к корректности[править | править код]

Модель безопасности должна решать следующие задачи[7]:

  1. отобразить состояние безопасности,
  2. дать субъектам доступ к объектам только в случаях и видах, разрешенных состоянием безопасности,
  3. и позволить субъектам защиты в определённом смысле изменять состояние безопасности.

Реализация[править | править код]

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

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

Вторая задача решается в предположении, что любая попытка доступа субъекта к объекту перехватывается и проверяется монитором обращений (реализация этого требования остается за разработчиками системы). Доступ субъекта s к объекту o происходит следующим образом[2]:

  1. s инициирует доступ к o в манере атрибута а
  2. система предоставляет тройку (s, a, o) монитору O
  3. Монитор O запрашивает матрицу доступа о наличии а в A[s, o]. Если атрибут есть, доступ разрешается; в противном случае он запрещается и применяются меры по устранению нарушения.

Заметим, что атрибуты доступа интерпретируются мониторами объектов во время попытки доступа. Поэтому, даже если субъект s знает идентификационный номер каждого другого субъекта, у s нет возможности изменить факт, что его номер предоставляется монитору; следовательно, монитор не может быть обманут запрашиванием неверной сущности в А[3]. Так как ни у каких субъектов нет доступа к А, на основании вышеизложенного можно построить доказательство, подтверждающее корректность системы безопасности

Доказательство корректности[править | править код]

Чтобы доказать корректность описанной модели безопасности, покажем, что субъект может получить доступ к объекту только будучи авторизованным[2].

Нужно показать, что:

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

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

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

Покажем последнее на примере.

Примеры[править | править код]

Рассмотрим передачу и создание прав доступа. Предположим субъект s1 создал объект х и дал разные типы доступа к х субъектам s2 — sn. Предположим также, что s1 хочет, чтобы у s0 ни при каких обстоятельствах не было доступа к x. Он может сделать это, не давая никаких атрибутов доступа s0, но он также должен создавать непередаваемые права всем субъектам s2-sn, которые могут нарушить доверие и дать доступ к x s0 напрямую. Другими словами, должно быть понимание между s1 и субъектами, получающими доступ к x, что s0 не должен получить, напрямую или косвенно, доступ к x. Только если такое понимание достигнуто и реквизиты доверия представлены, s1 может назначать передаваемые права доступа. Тогда, правила создания и передачи прав доступа корректны.

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

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

Заключение[править | править код]

Приведенная модель может использоваться как для защиты ОС, так и для защиты баз данных[9].

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

Примечания[править | править код]

  1. ↑ Lampson B. W. Protection (неопр.) // Proceeding of the 5th Princeton Symposium of Information Sciences and Systems. — 1971. — March.
  2. ↑ 1 2 3 4 Graham, Denning, 1972.
  3. ↑ 1 2 Малюк, Пазизин, Погожин, 2004.
  4. ↑ Pfleeger, 2006, p. 244.
  5. ↑ Pfleeger, 2006, pp. 244—245.
  6. ↑ Одеров, 2014.
  7. ↑ Механизмы безопасности Архивная копия от 21 апреля 2018 на Wayback Machine // Orange book.
  8. ↑ Pfleeger, 2006.
  9. ↑ Denning D.E. A Lattice Model of Secure Information Flow (неопр.) // Communication of ACM. — 1976.

Литература[править | править код]

  • Graham G. S., Denning P. J. Protection - Principles and Practice. — Joint Computer Conference, 1972.
  • А. А. Малюк, С. В. Пазизин, Н. С. Погожин. Введение в защиту информации в автоматизированных системах. — 2-е издание. - Москва: Горячая линия-Телеком, 2004.
  • Р. С. Одеров. Управление политиками контроля доступа на основе ролевой модели. — 2014.
  • Charles P. Pfleeger, Shari Lawrence Pfleeger. Security in Computing. — Prentice Hall, 2006.
Источник — https://ru.wikipedia.org/w/index.php?title=Модель_Грэхэма-Деннинга&oldid=124090936