Главная страница

Модель Харрисона - Руззо - Ульмана. Элементами модели матрицы доступов Харрисона Руззо Ульмана являются


Скачать 129.9 Kb.
НазваниеЭлементами модели матрицы доступов Харрисона Руззо Ульмана являются
АнкорМодель Харрисона - Руззо - Ульмана
Дата11.12.2021
Размер129.9 Kb.
Формат файлаdocx
Имя файла6_lab_is.docx
ТипДокументы
#300146

Модель Харрисона - Руззо - Ульмана используется для анализа систем защиты, реализующих дискреционную политику безопасности.

Это частный случай реализации модели машины состояний. Состояния безопасности системы представлены в виде таблицы, содержащей по одной строке для каждого субъекта системы и по одной колонке для каждого субъекта и объекта (таблица 1).

Каждое пересечение в массиве определяет режим доступа данного субъекта к каждому объекту или другому субъекту системы.

Элементами модели матрицы доступов Харрисона - Руззо - Ульмана являются:

  • О - множество объектов системы;

  • S - множество субъектов системы (SczO);

  • R - множество видов прав доступа субъектов на объекты, например права на чтение (read), на запись (write), владения (own);

  • М - матрица доступов, строки которой соответствуют субъектам, а столбцы соответствуют объектам. M[s, о]

  • qR - права доступа субъекта 5на объект о.

Таблица 1 Матрица доступа.



Примечание:

  • R— право чтения;

  • W — право записи;

  • D — право удаления.

Общая модель матрицы доступов Харрисона - Руззо - Ульмана может выражать большое разнообразие политик дискреционного разграничения доступа, но при этом не предоставляет алгоритма проверки их безопасности.

Белла — Лападула, модель была разработана для обеспечения военной системы безопасности, но она подходит и для других организаций. У военных документы (объекты) должны обладать грифом секретности, например: «несекретный», «для служебного пользования», «секретный» и «совершенно секретный». Люди также получают форму допуска, определяющую, какие документы им разрешено просматривать. Генералу может быть разрешено просматривать все документы, а лейтенант может иметь допуск к просмотру лишь документов с грифом «секретно» и ниже. Процесс, принадлежащий пользователю, приобретает его уровень безопасности. Так как уровней безопасности несколько, такая схема называется многоуровневой системой безопасности (multilevel security system) рисунок 1.

Модель Белла — Лападулы имеет следующие правила организации информационного потока.

1. Простое свойство безопасности (The simple security property) — процесс, запущенный на уровне безопасности k, может проводить операцию чтения только в отношении объектов своего или более низкого уровня. К примеру, генерал может читать документы лейтенанта, но лейтенант не может читать генеральские документы.

2. Свойство * (The * property) — процесс, работающий на уровне безопасности k, может вести запись только в объекты своего или более высокого уровня. К примеру, лейтенант может добавить сообщение в генеральский почтовый ящик, докладывая обо всем, что ему известно, но генерал не может добавить сообщение в лейтенантский почтовый ящик, сообщая о том, что известно ему, поскольку генерал может быть ознакомлен с совершенно секретными документами, содержание которых не должно доводиться до лейтенанта.



Рисунок 1 Многоуровневая модель безопасности Белла — Лападулы

Модель Белла — Лападулы относится к организационной структуре, но в конечном счете она должна быть реализована операционной системой. Один из способов реализации заключается в назначении каждому пользователю уровня безопасности, который должен храниться вместе с другими относящимися к пользователю данными, например UID и GID. После входа в систему пользовательская оболочка приобретет пользовательский уровень безопасности, который будет унаследован всеми ее дочерними процессами. Если процесс, выполняющийся на уровне безопасности k, попытается открыть файл или другой объект, уровень безопасности которого выше k, то операционная система должна отклонить попытку открытия файла. По аналогии с этим должны отклоняться и все попытки открыть для записи любой объект, уровень безопасности которого ниже, чем k.

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

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

При использовании ролевой политики управление доступом осуществляется в две стадии:

- для каждой роли указывается набор полномочий (разрешений на доступ к различным объектам системы);

- каждому пользователю сопоставляется список доступных ему

ролей.

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

U — множество пользователей;

R — множество ролей;

Р — множество полномочий (разрешений) на доступ к объектам системы;

Ролям сопоставляются полномочия, а пользователям — роли. Это задается путем определения следующих множеств:

PAczPxR — определяет множество полномочий, установленных ролям (для наглядности условно может быть представлено в виде матрицы доступа);

UA^U х /? — устанавливает соответствие между пользователями и доступными им ролями.

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

user: S ->U — для каждого сеанса s eS эта функция определяет пользователя, который осуществляет этот сеанс работы с системой: user(s) = и I и е I);

roles — для каждого сеанса s е S данная функция определяет подмножество ролей, которые могут быть одновременно доступны пользователю в ходе этого сеанса: roles(s) = {/} I (user(s r{) е UA};

permissions :S —» P — для каждого сеанса seS эта функция задает набор доступных в нем полномочий, который определяется путем объединения полномочий всех ролей, задействованных в этом сеансе: permissions^) = LUro/e^A1 € рл)

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

система считается безопасной, если любой пользователь системы, работающий в сеансе s е S, может осуществлять действия, требующие полномочия р е Р, только в том случае, если р е permissions^).

Существует несколько разновидностей ролевых моделей управления доступом, различающихся видом функций user, roles и permissions, а также ограничениями, накладываемыми на множества РАи UA.

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

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

Одним из наиболее распространенных современных стандартов в области информационной безопасности является международный стандарт ISO/IEC 15408. Он был разработан на основе стандарта «Общие критерии безопасности информационных технологий» вер. 2.1. В 2006 году был принят стандарт в Республике Казахстан, как ГОСТ Р ИСО/МЭК 15408-2006 «Информационная технология» он идентичен национальному стандарту Российской Федерации.

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

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

«Общие критерии» предусматривают наличие двух типов требований безопасности — функциональных и доверия. Функциональные требования относятся к сервисам безопасности, таким как управление доступом, аудит и т. д. Требования доверия к безопасности относятся к технологии разработки, тестированию, анализу уязвимостей, поставке, сопровождению, эксплуатационной документации и т. д.

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

- аудит безопасности;

- связь (передача данных);

- криптографическая поддержка (криптографическая защита);

- защита данных пользователя;

- идентификация и аутентификация;

- управление безопасностью;

- приватность (конфиденциальность);

- защита функций безопасности объекта;

- использование ресурсов;

- доступ к объекту оценки;

- доверенный маршрут/канал.

Основные структуры, определяемые «Общими критериями» — это профиль защиты и задание по безопасности. Профиль защиты — это независимая от реализации совокупность требований безопасности для некоторой категории 00, отвечающая специфическим запросам потребителя. Профиль состоит из компонентов или пакетов функциональных требований и одного из уровней гарантированности. Структура профиля защиты представлена на рисунок. 2.

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

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



Рисунок 2. Структура профиля защиты

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


написать администратору сайта