4. Семейство базовых моделей

Для понимания различных аспектов КДОР мы даем определения семейству четырех концептуальных моделей. Отношения между этими четырьмя моделями показаны на иллюстрации 1 (а), а их основные характеристики приведены в иллюстрации 1 (b). КДОР 0, базовая модель, находится у основания, указывая на то, что это является минимальным требованием для любой системы, создатели которой заявляют, что их система поддерживает КДОР. КДОР 1 и КДОР 2 оба включают в себя КДОР 0, однако добавляют к нему дополнительные черты. Они называются усовершенствованными моделями. КДОР 1 имеет в качестве дополнения концепцию иерархии ролей (ситуаций, когда роли могут наследовать разрешения от других ролей). КДОР 2 добавляет ограничивающие условия (устанавливающие ограничения на допустимые конфигурации различных компонентов КДОР). КДОР 1 и КДОР2 не являются абсолютно идентичными друг другу. Сводная модель КДОР 3 включает КДОР 1 и КДОР 2 и, по свойству транзитивности, КДОР 0.

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

4.1 Базовая модель

Базовая модель КДОР 0 состоит из той части иллюстрации 1(b), которая не относится ни к одной из трех усовершенствованных моделей. Существует три множества объектов, называемых пользователи (U), роли (R) и разрешения (P). Диаграмма также показывает множество сеансов (S). Пользователь в данной модели является человеком. Концепт пользователя может быть обобщен до включения в него таких разумных автономных агентов как роботов, неподвижных компьютеров, или даже компьютерных сетей. Для простоты мы сконцентрируем особое внимание на пользователе в лице человека. Роль — это рабочая функция или наименование работы внутри организации с определенной связанной с ней семантикой в аспекте власти и ответственности, переданной члену данной роли.

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

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

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

Иллюстрация 1 (b) показывает отношение назначения пользователя (UA) и назначения разрешения (PA). Оба отношения принадлежат к типу многие-ко-многим. Пользователь может являться членом многих ролей, а у роли может быть много пользователей. Таким же образом, у роли может быть много разрешений, и одно и то же разрешение может быть дано многим ролям. Ключ к пониманию КДОР лежит в этих двух отношениях. В конечном итоге, именно пользователь осуществляет доступ через разрешения. Метод размещения роли в качестве посредника для передачи пользователю права осуществлять решение позволяет достичь большего контроля над конфигурацией и наблюдением за доступом, чем метод прямого соотношения пользователей и разрешений.

Каждый сеанс является соотнесением одного пользователя с возможным количеством ролей, то есть пользователь начинает сеанс, в течение которого он активирует определенное подмножество ролей, чьих членом он(а) является. Двусторонняя стрелка от сеанса к R на иллюстрации 1 (b) показывает, что одновременно могут активироваться много ролей. Разрешения, имеющиеся у пользователя, являются объединением разрешений от всех ролей, активированных в данном сеансе. Каждый сеанс ассоциирован с одним пользователем, как указано односторонней стрелкой от сеанса к U на иллюстрации 1 (b). Данная ассоциация остается постоянной на все время сеанса. Пользователь может одновременно создавать множественные сеансы, например, каждый в отдельном окне на экране рабочей станции. Каждый сеанс может иметь различную комбинацию активных ролей. Данное качество КДОР 0 поддерживает принцип минимальной привилегии. Пользователь, являющийся членом нескольких ролей, может задействовать любое их подмножество, необходимое для решения задач, поставленных в данном сеансе. Следовательно, пользователь, являющийся членом сильной роли может постоянно держать свою роль деактивированной и активировать ее только при необходимости. Мы откладываем рассмотрение всех видов ограничительных условий, включая ограничения на активацию ролей, до описания КДОР 2. поэтому в КДОР 0 именно пользователь решает, какие роли ему следует активировать в том или ином сеансе. КДОР 0 также позволяет динамическую активацию и дезактивацию ролей во время сеанса. Понятие сеанса совпадает с традиционным понятием субъекта в литературе по контролю доступа. Субъект (или сеанс) является единицей контроля доступа, и пользователь может активировать несколько субъектов (или сеансов) с разными разрешениями одновременно. Следующее определение формулирует все вышесказанное.

Определение 1.

Модель КДОР 0 имеет следующие компоненты:

U, R, P и S (соответственно, пользователи, роли, разрешения и сеансы),

PAPR, отношение между разрешением множество-множество и наделением ролями,

UAUR, отношение между пользователями множество-множество и наделением ролями,

user : SU, функция, соотносящая каждый сеанс с одним пользователем user ( ) (неизменным на протяжении сеанса)

roles :S , функция, соотносящая каждый сеанс с множеством ролей roles( )

r(user( ), r) UA (может меняться со временем) и сеанс имеет разрешения .

Мы ожидаем, что каждая роль может быть придана как минимум одному разрешению и каждый пользователь — как минимум одной роли. Данная модель, тем не менее, этого не требует.

Как было отмечено выше, КДОР 0 принимает разрешения в качестве неинтерпретированных символов, так как точная природа разрешения является зависимой от выполнения и системы. Тем не менее, мы требуем, чтобы разрешения относились к данным и ресурсам, а не к компонентам самого КДОР. Разрешения на изменение множеств U, R, P, и отношений PA и UA называются административными разрешениями. Они будут рассмотрены позже в модели управления КДОР. На данном этапе следует считать, что один сотрудник службы безопасности может изменять эти компоненты.

Сеансы контролируются отдельными пользователями. Что касается самой модели, пользователь может создавать сеанс и выбирать активацию некоего подмножества пользовательских ролей. Роли, являющиеся активными в данном сеансе, могут быть изменены по усмотрению пользователя. Сеанс заканчивается по инициативе пользователя. (Некоторые системы завершают сеанс, остающийся неактивным слишком долгое время. Строго говоря, это является ограничительным условием и должно принадлежать КДОР 2.)

Некоторые авторы [6] включают обязанности, в дополнение к разрешениям, в качестве атрибута ролей. Обязанность — это обязательство пользователя производить ту или иную функцию, что в общем необходимо для четкой работы организации. По нашему мнению, обязанности являются усовершенствованным концептом, не принадлежащим КДОР0. Мы также решили не встраивать обязанности в наши усовершенствованные модели. Мы считаем, что встраивание таких понятий, как обязанности в модели контроля доступа требует дополнительных предварительных исследований. Один из подходов может быть рассмотрение их как подобных разрешениям. Другие подходы могут основываться на новых парадигмах контроля доступа, как, например, авторизация по основанию задания [4].