Методы управления доступом в распределенных средах
Уже довольно давно, как практически все организации признали неоспоримые преимущества использования интернет для управления знаниями. Однако если организация имеет множество отделений и при этом эти отделения должны иметь доступ к знаниям других отделений, требуется объединение баз знаний всех отделений.
На данный момент, мы подошли к черте, когда без возможности связать базы знаний нескольких отделений организаций или даже нескольких организаций воедино не обойтись. Но при этом вопрос о разграничении прав доступа к документам становится еще более актуальным. Без удобного и надежного способа управления правами доступа либо наступит полный хаос и потеряется весь смысл объединения.
Управление доступом в распределенной среде может быть как централизованным, так и децентрализованным. Их отличие состоит в том, что в централизованной системе должен быть центр управления доступом, который будет регулировать все вопросы определения доступа к ресурсам всех систем. Эта модель фактически не является распределенной системой, и может быть востребована только в организациях в которых доступ должен регулироваться только фиксированной группой лиц (например военные организации).
Однако в большенстве случаев, организаций, желающих свои объеденить ресурсы друг с другом, не устраивает схема, при котором доступ к их ресурсам будет регулироваться не ими. В этом случае используется децентрализованная модель управления доступом. В ней нет центра регулирующего права пользоватей к ресурсам каждой организации, а доступ к ресурсам каждой организации управляется самой организацией.
Далее мы кратко опишем существующие модели управления доступом, а затем опишем модель управления доступом в распределенных средах.
Цель управления доступом это ограничение операций которые может проводить легитимный пользователь (зарегистрировавшийся в системе). Управление доступом указывает что конкретно пользователь имеет право делать в системе, а так же какие операции разрешены для выполнения приложениями, выступающими от имени пользователя.
Таким образом управление доступом предназначено для предотвращения действий пользователя, которые могут нанести вред системе, например нарушить безопасность системы.
|
Доступ |
Доступ субъекта к объекту для определенных операций. |
|
Объект |
Контейнер информации в системе |
|
Субъект |
Сущность определяющая пользователя при работе в системе |
|
Пользователь |
Человек выполняющий действия в системе или приложение выступающее от его имени. |
Table 1
Средства Дискреционного Контроля за Доступом (Discretionary Access Control - DAC) обеспечивают защиту персональных объектов в системе. Контроль является дискреционным в том смысле, что владелец объекта сам определяет тех, кто имеет доступ к объекту, а также вид их доступа.
Дискреционный контроль доступа управляет доступом субъектов к объектам базируясь на идентификационной информации субъекта и списка доступа объекта, содержащего набор субъектов (или групп субъектов) и ассоциированных с ними типов доступа (например чтение, запись). При запросе доступа к объекту, система ищет субъекта в списке прав доступа объекта и разрешает доступ если субъект присутствует в списке и разрешенный тип доступа включает требуемый тип. Иначе доступ не предоставляется.
Гибкость DAC позволяет использовать его в большом количестве систем и приложений. Благодаря этому этот метод очень распространен, особенно в коммерческих приложениях. Очевидным примером использования DAC является система Windows NT/2k/XP.
Однако DAC имеет существенный недостаток. Он заключается в том, что он не предоставляет полной гарантии того, что информация не станет доступна субъектам не имеющим к ней доступа. Это проявляется в том, что субъект имеющий право на чтение информации может передать ее другим субъектам, которые этого права не имеют, без уведомления владельца объекта. Система DAC не устанавливает никаких ограничений на распространение информации после того как субъект ее получил.
Еще одной особенностью DAC, которую можно отнести к недостаткам, является то, что все объекты в системе принадлежат субъектам, которые настраивают доступ к ним для других. На практике оказывается, что в большинстве случаев данные в системе не принадлежат отдельным субъектам, а всей системе. Наиболее распространенным примером такой системы является информационная система.
Классическая система дискреционного контроля доступа называется "закрытой" в том смысле, что изначально объект не доступен никому, и в списке прав доступа описывается список разрешений. Также существуют "открытые" системы, в которых по умолчанию все имеют полный доступ к объектам, а в списке доступа описывается список ограничений.
Средства Обязательного Контроля за Доступом (Mandatory Access Control - MAC). Контроль является обязательным в том смысле, что пользователи не могут изменять стратегию MAC в отношении объектов. При создании объекта система автоматически присваивает ему атрибуты MAC, и изменить эти атрибуты может только администратор, имеющий соответствующие полномочия. Средства MAC не позволят пользователю случайно или преднамеренно сделать информацию доступной для лиц, которые не должны обладать ею.
Обязательный контроль доступа управляет доступом на основе классификации объектов и субъектов системы. Каждому субъекту и объекту системы назначается некоторый уровень безопасности (УБ). Уровень безопасности объекта, как правило, описывает важность этого объекта и возможный ущерб, который может быть причинен при разглашении информации содержащейся в объекте. Уровень безопасности субъекта является уровнем доверия к нему. В простейшем случае все уровни безопасности являются членами некоторой иерархии. Например: Совершенно Секретно (СС), Секретно (С), Конфиденциально (К) и Рассекречено (Р), при этом верно следующее: СС > C > K > P, т.е. каждый уровень включает сам себя и все уровни находящиеся ниже в иерархии.
Доступ субъекта к объекту предоставляется если выполнено некоторое условие отношения (которое зависит от типа доступа) между уровнями безопасности объекта и субъекта. В частности, должны выполняться следующие условия:
Выполнение этих условий, гарантирует, что данные высокоуровневых объектов (например Совершенно Секретно) не попадут в низкоуровневые объекта (например Рассекреченный).
В этой модели важно различать понятия пользователь и субъект. Уровни безопасности назначаются субъектам. А пользователи могут выступать от имени субъекта в тот или иной момент. При этом в различных ситуациях один пользователь может выступать от имени различных субъектов. При этом важно, чтобы в каждый конкретный момент, пользователь выступал от имени только одного субъекта. Это обеспечивает невозможность передачи информации от высокого уровня к более низкому.
Основная идея ролевой модели контроля за доступом (Role-Based Access Control - RBAC) основана на максимальном приближении логики работы системы к реальному разделению функций персонала в организации.
Ролевой метод управления доступом контролирует доступ пользователей к информации на основе типов их активностей в системе. Применение данного метода подразумевает определение ролей в системе. Понятие роль можно определить как совокупность действий и обязанностей, связанных с определенным видом деятельности. Таким образом, вместо того, чтобы указывать все типы доступа для каждого пользователя к каждому объекту, достаточно указать тип доступа к объектам для роли. А пользователям, в свою очередь, указать их роли. Пользователь, "выполняющий" роль, имеет доступ определенный для роли.
Вообще говоря, пользователь может выполнять различные роли в разных ситуациях. Одна и та же роль может использоваться несколькими различными пользователями, причем иногда даже одновременно. В некоторых системах пользователю разрешается выполнять несколько ролей одновременно, в других есть ограничение на одну или несколько не противоречащих друг другу ролей в каждый момент времени.
Основными достоинствами ролевой модели управления доступом являются:
Как мы показали выше Дискреционная и Обязательная модели строят некоторые матрицы описывающие права доступа субъектов к объектам. В случае распределенное системы для определения прав доступа субъекта из одной организации к объекту из другой организации, придется вносить информацию о субъекте в систему второй организации и назначать ему права на объект. Очевидно, что такая схема не является распределенной, т.к. каждая организация имеет свой собственный набор субъектов и их прав доступа к объектам.
Ролевая модель более абстрактна. Роль может не существовать в конкретной системе, но в системе может быть прописана взаимосвязь этой роли с существующими ролями. При этом вопрос о принадлежности этой роли пользователю может разрешаться внешней системой. Для облегчения дальнейшего понимания работы модели рассмотрим следующий пример, который будет использоваться и в дальнейшем.
Предположим у нас есть Университет и есть Институт. В университете учится Студент, который хочет написать статью и опубликовать ее в Институте. Студент стажируется в институте у Профессора института, но поскольку он там не оформлен он не является сотрудником института, а соответственно не имеет прав на доступ в систему публикаций института.
Перед тем как строить модель управления правами доступа в распределенной среде, мы опишем базовую модель управления доступом на основе ролевой модели.
Таким образом, роль есть уникальное имя в области имен сущности регулирующее доступ к этой сущности. Например роль U.student определяет имя student в области имен сущности U.
[Субъект --> Роль] Доверитель,
где Субъект это либо пользователь либо роль и Доверитель это сущность определившая и подтверждающая делегирование. Стреку --> можно читать как «выполняет роль». Данная связь между субъектом и ролью подписана приватным ключом доверителя и может быть проверена с помощью его открытого ключа.
Существует три вида делегирования: само-подтверждающее, третье-сторонее и административное делегирование. Первые два относятся к делегированию ролей, а третья к делегированию прав на делегирование ролей. Далее рассмотрим их подробнее.
В случае само-подтверждающего делегирования, доверитель делегирует роль из своего пространства имен определенному пользователю или другой роли. Это ознает, что сущность сама передает права на проведение некоторых операций над собой определенному пользователю или роли.
Например.
У нас есть сущность Университет (U) и у университета есть роль Ректор (rector). Есть пользователь (Р). Назначение пользователя Р на роле ректора можно описать так:
[P --> U.rector] U
В этом случае сущность «Университет» сама назначила пользователя на исполнение роли из своего пространства имен. Такое делегирование передает все права роли «rector» из пространства имен сущности «U» пользователю «Р».
Третье-сторонее делегирование это делегирование прав роли сущностью, пространство имен которой не содержит этой роли.
В общем виде делегирование можно описать следующим образом:
[Субъект --> Сущность.Роль] Доверитель.
Т.е. доверитель делегировал права роли «Роль» принадлежащей сущности «Сущность» пользователю или роли «Субъект».
При этом Сущность не может являтся самим доверителем, т.к. иначе это будет само-подтверждающее делегирование.
Также при третье-стороннем делегировании не разрешается Доверителю делегировать себе (напрямую или косвенно) никакие полномочия.
Например.
У нас есть пользователь Студент университета (Student), ему должна быть назначена роль (U.student). Роль назначается ректором (Rector).
[Student --> U.student] Rector
Очевидно, что при таком делегировании, Rector должен иметь определенные права на делегирование не своей роли. Так мы приходим к третьему виду.
Право делегировать права доступа роли R также является некоторой ролью. Назовем ее R'. Делегирование такой роли называется административным делегированием и роль называется административной. Пользователь, обладающий административной ролью, имеет право на делегирование прав соответствующей ей роли, а также самой административной роли, другим субъектам.
[Субъект --> Роль'] Доверитель
Возвращаясь к примеру их прошлого пункта мы его можем продолжить следующим образом:
[Rector --> U.student'] U
[Student --> U.student] Rector
Здесь сущность «U» делегировала право делегировать права своей роли «student» пользователю «Rector».
Мы описали некоторую ролевую модель управления доступом. Попробуем описать часть нашего примера с помощью этой модели.
Итак у нас есть университет. У университета есть ректор. Ректор университета имеет право набирать студентов.
Университет это сущность «U», у которой есть следующие роли: студент университета «U.student» и ректор «U.rector». Роль ректора университета позволяет назначать пользователям роль студентов университета:
[U.rector --> U.student'] U
Университет назначает пользователя «Rector» ректором университета, т.е. назначает ему роль «U.rector»:
[Rector --> U.rector] U
Пользователь «Rector», имея права на делегирование роли «U.student» другим субъектам, назначает пользователю «Student» роль «U.student»:
[Student --> U.student] Rector.
Проверка того, что пользователь «Student» действительно является студентом университета, будет заключаться в следующем рекурсивном алгоритме:
1. Найти роль «U.student» среди ролей пользователя. Если роль не найдена, то результат проверки отрицательный. Иначе перейти к пункту 2.
2. Выяснить была ли эта роль делегирована с помощью само-подтверждающего делегирования, если да, то проверка закончилась успешно. Если нет, то перейти к пункту 1: найти роль «U.student'» среди ролей Доверителя.
Очевидно, что, при условии, что Доверитель не имеет права делегировать себе полномочия, этот алгоритм конечен и результатом его будет либо подтверждение того что пользователь является студентом университета, либо опровержение этого.
Как пример того, как алгоритм будет бесконченым без указанного условия, рссмотрим следующую цепочку делегирования:
(1) [Student -> U.student] Rector
(2) [Rector -> U.rector] U
(3) [U.rector -> U.teacher] U
(4) [U.teacher -> U.student'] Rector
При проходе этой цепочки мы дойдя до пункта (4) пройдем ее заново начиная с пункта (2) и опять попадем на пункт (4).
Как уже говорилось в описании ролевой модели управления доступом, кроме ролей в этой модели возможны некоторые дополнительные ограничения. Эти ограничения могут вносить некоторые изменения на характер использования определенной роли. Например институт, при назначении роли «опубликовать статью», может дополнительно накладывать различные ограничения на публикацию. В качестве такого ограничения может служить например количество страниц или размер. При этом эти ограничения могут быть разными для разных людей с этой ролью. Например студент института может опубликовать статью с ограничением в 30 страниц, а профессор - без ограничения на объем. При этом обе сущности «студент» и «профессор» будут иметь одну и ту же роль «опубликовать статью», но с различными атрибутами. Конечно можно ввести несколько ролей типа «опубликовать статью без ограничения размера», «опубликовать статью с ограничением в 30 страниц», и т.д. Но при таком подходе задача администрирования системы с течением времени может стать практически невозможной.
Итак атрибут это свойство пользователя или роли, имеющий уникальное название и численное значение соответствующее этому названию. Формально назначение атрибута можно описать следующим образом:
[Субъект --> A.Роль with B.атрибут1<оператор><значение> <and C.атрибут2<оператор><значение>...>] D
Оператор может быть одним из:
При передаче прав делегирования роли субъекту доверитель должен указать, какие из атрибутов этой роли субъект имеет право изменять и как. Формально описывается следующим образом:
[Субъект --> Роль' with атрибут1<оператор>' <and атрибут2<оператор>' ...>] Доверитель
Теперь с помощью данной терминологии сформулируем как должна делегироваться роль «опубликовать статью» в институте.
I - институт
I.professor - Роль: профессор института
I.student - Роль: студент института
I.publish - Роль: право публиковаться
I.size - атрибут из области имен института, указывающий ограничение на количество страниц.
1. Дать студентам право публиковаться с ограничением 30 страниц.
[I.student --> I.publish with I.size = 30] I
2. Дать пофессорам право публиковаться без ограничения страниц.
[I.professor --> I.publish with I.size = 0] I
Значение 0 означает отсутствие ограничения.
Или тоже самое но с помощью третье-стороннего делегирования. В этом случае профессор будет иметь право делегировать право публиковаться с ограничением на число страниц:
1. Дать профессору право делегировать право публиковаться с ограничением:
[I.professor --> I.publish' with I.size<='] I
[Professor --> I.professor] I
2. Профессор должен делегировать право публиковаться студентом, но с ограничением в 30 страниц:
[I.student --> I.publish with I.size <= 30] Professor
При делегировании полномочий часто встает вопрос о сроке их годности, т.е. на какой срок эти полномочия делегируются. Это связано с тем что сотрудники организаций часто меняются, а также позволяет проверять правильность полномочий на регулярной основе. Например студент университета может его закончить или его могут отчислить. После этого он не будет являтся студентом. Соответственно при зачислении, пользователю дадут полномочия студента до следующей сессии, после которой эти полномочия должны быть продлены.
Формальное указание срока годности делегирования:
[Субъект --> Роль <срок истечения: дата>] Доверитель
Поскольку сущности могут принадлежать различным организациям, а доступ к ресурсам одной организации требуется дать пользователям другой, то при работе с сущностью, системе надо знать какой организации она (сущность) принадлежит. Для этих целей каждая сущность должна нести в себе информацию о том какой организации она принадлежит и как это можно проверить. Под ролевым доменом сущности будем понимать набор сведений об организации, которой сущность принадлежит:
Формальное указание ролевого домена при делегировании:
[Cубъект<ролевой домен> --> Объект<ролевой домен>.Роль] Доверитель<ролевой домен>.
В предыдущих главах мы построили ролевую модель с возможностью делегирования полномочий и возможностью проверки этого делегирования. Также мы описали некоторые расширения этой модели, которые потребуются для описания распределенной среды управления доступом.
Итак опишем что такое распределенная среда управления доступом. В распределенной среде есть несколько полностью независимых организаций. Под независимостью мы понимаем то, что никакая организация не имеет никакой информации о сотрудниках или ресурсах другой организации (с некоторыми исключениями, которые мы опишем ниже). При этом между этими организациями принято соглашение о предоставлении ресурсов одной организации сотрудникам другой на определенных условиях.
Опишем инфраструктуру организаций, требуемую для предоставления ресурсов одной организации для сотрудников другой.
Каждая организация должна иметь свой центр авторизации. Этот центр отвечает за определение прав доступа к русурсам каждой организации на основе делегирования. Организации-партнеры должны иметь права доступа центрам авторизации своих партнеров и возможность выполнять запросы по проверке прав пользователя.
Основа работы центра авторизации заключается в хранении существующих цепочек делегирования полномочий и возможности проверки правильности этих цепочек. Таким образом у каждого центра фаторизации храниться набор делегаций вида:
[Субъект --> Роль] Доверитель
При этом типичный запрос к этому центру может выглядет так: имеет ли субъект С привилегии роли Р при условиях У. При выполнении этого запроса центр составляет из отдельных делегирований цепочку делегирования и запоминает ее для ускорения проверки при следующем запросе.
В момент регистрации пользователя в системе, он указывает свою идентификационную информацию, принадлежность к ролевому домену, а также может указать свою роль в том же ролевом домене, которая ему нужна для доступа к ресурсам внешней системы.
Для внешней системы, роль пользователя является упорядоченным набором абстрактных названий. Но, поскольку при делегировании полномочий мы не привязываемся к конкретным сущностям, мы можем делегировать этой абстрактной (внешней) роли свою локальную роль. И уже эту локальную роль использовать для проверки полномочий пользователя в системе. А для того, чтобы убедится, что пользователь действительно имеет полномочия роли указанной им, мы можем обратиться к центру авторизации внешней системы.
Таким образом при делегировании полномочий системе управления доступом не важно о каких субъектах или объектах идет речь. Система просто строит проверяемые цепочки позволяюшие определить имеет ли субъект доступ к объекту.
Вернемся к изначальному примеру.
Используемые роли и сущности:
Центр авторизации университета содержит следующие цепочки делегирования:
(1). [Student<UD> --> U<UD>.student] Rector<UD> (Студент является студентом университета, подписано ректором)
(2). [Rector<UD> --> U<UD>.rector] U<UD> (Ректор выполняет роль ректора университета)
(3). [U<UD>.rector --> U<UD>.student'] U<UD> (Роль ректора позволяет делегировать роль студента университета)
Центр авторизации института содержит следующие цепочки делегирования:
(4). [U<UD>.student --> I<ID>.student with I<ID>.pages <= 20] Professor (Студент Университета является студентом института с ограничением 20 страниц на публикацию, подписано Профессором. Третье-сторонее делегирование)
(5). [Proffesor<ID> --> I<ID>.professor] I (Профессор является профессором института, подписано институтом)
(6). [I<ID>.professor --> I<ID>.student' with I<ID>.pages <='] I (Профессор имеет право делегировать роль Студент Института с понижением числа страниц, подписано институтом)
(7). [I<ID>.student --> I<ID>.publish with I<ID>.pages = 100] I (Студент института имеет право публиковаться с числом страниц не больше 100, подписано институтом)
Требуется найти доказательство того, что Студент имеет право опубликоваться в институте имея размер статьи 15 страниц:
Student ==> I.publish with I.pages = 15; ?
Рассмотрим весь процесс по шагам.
1. Студент подключается к системе института и представляет себя как выполняющего роль Студента Университета (U<UD>.student).
2. Сервер института опрашивает сервер университета, действительно ли Студент является студентом университета
3. Сервер университета проверяет цепочку делегирования и, так как она подписана им же и состоит из одной делегации, отвечает утвердительно. (1), (2), (3).
4. Сервер института сохраняет у себя цепочку подтвержденную сервером университета, для последующего использования.
5. Сервер института проверяет есть ли у него цепочки делегаций начинающиеся с Роли Студент Университета (U.Student)
Находит цепочку дающие права Студентам Университета Студентов Института подписанную Профессором.(4)
6. Сервер института проверяет есть ли право делегировать полномочия Студентов Института у профессора, и находит соответствующую цепочку (5).
7. Сервер института проверяет есть ли право у студента института публиковаться (7).
8. Сервер института проверяет значения атрибутов.
9. Сервер института сохраняет всю цепочку.
10. Выдает положительный ответ.
В этой статье мы рассмотрели различные методы управления доступом:
Выяснили, что с помощью ролевой модели мы можем построить любую другую модель доступа, что означает, что ролевая модель является моделью или методом построения для любой модели управления доступом.
Определили основные проблемы при построении распределенной системы управления доступом. На основе ролевой модели контроля за доступом и принципа подписанного делегирования полномочий описали модель системы управления доступом в распределенной среде, состоящей из полностью независимых участников обмена ресурсами.
[1]. Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE Comunication Magazine 1994
[2]. Sylvia Osborn, Ravi Sandhu, Qamar Munawer: Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies. 2000
[3]. M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. IEEE Conf. on Privacy and Security, 1996.
[4]. Eric Freudenthal, Tracy Pesin, Lawrence Port, Edward Keenan, Vijay Karamcheti: dRBAC: Distributed Role-based Access Control for Dynamic Coalition Environments. Department of Computer Science New York University 2002.
[5]. E. Freudenthal, E. Keenan, T. Pesin, L. Port, and V. Karamcheti. DisCo: A Distribution Infrastructure for Securely Deploying Decomposable Services in Partially Trusted Environments. Technical Report 2001-820, Computer Science, New York University, 2001.
[6]. R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF RFC 2459, 1999.
[7]. N. Li,W.Winsborough, and J. Mitchell. Distributed credential chain discovery in trust management. In Proc. of ACM Conf. on Computer and Communications Security, 2001.
[8]. R. L. Rivest and B. Lampson: SDSI - A simple distributed security infrastructure. CRYPTO'96, 1996.