Rbac-paper

Управление доступом в сложных информационных системах на основе ролевой авторизации

О.С. Бартунов (*), Е.Б. Родичев (**), С.Н. Ардатский (**), С.Н. Назин (***)

(*) - Государственный Астрономический институт им. П.К. Штернберга, МГУ

(**) - ООО Дельта-Софт

(***) - ООО "СЦС Совинтел"

АБСТРАКТ

Рассматривается технологическая модель управления доступа к информационным объектам на основе ролей, определенных в информационной системе. Эта технология, получившая название RBAC, интенсивно разрабатывающаяся в последние годы на уровне научных разработок, сейчас является де-факто стандартом для управления доступом в сложных информационных системах. Национальный институт стандартов и технологий США (NIST)[1] подготовил соответствующий стандарт, который активно используется разработчиками для построения информационных систем.

Показана необходимость использования ролевой авторизации в образовательных ресурсах и примеры ее реализации. Ролевая авторизация используется в ряде научных и научно-образовательных сайтов и в федеральной программе "Единая Образовательная Информационная Среда 2001-2005".

Научные разработки частично были поддержаны РФФИ, грант 02-07-90222.


ВВЕДЕНИЕ

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

  [ 
   Здесь надо подчеркнуть, что ИС ,как правило, разрабатываются как
   Web-приложение (итранет/интернет)
   ]

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

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

Классические модели контроля доступа, описанные в "Оранжевой книге" мин. обороны США, и которые широко используются во многих операционных системах, не совсем годятся для современных информационных систем. В [6] подробно описываются принципы, практика использования, преимущества и недостатки основных классических систем управления доступа (MAC, DAC).

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

Дискреционное или произвольное управление доступом (DAC) основывается на понятии владельца объекта. Для получения соответствующих прав для действий над объектом, пользователь должен быть либо его владельцем, либо входить в группу пользователей, для которой разрешены какие-либо действия над объектом. Эта информация обычно хранится в так называемых "списках доступа" (ACL), поддержание которых плохо шкалируется при росте числа пользователей и объектов в системе, что может приводить к "непланируемым ошибкам". Действительно, из-за того, что в DAC модели пользователь напрямую связывается с привилегиями, то полное количество этих отношений является произведением числа пользователей и объектов в системе. Несмотря на то, что эта модель широко используется в популярных ОС, однако имеет несколько недостатков, например, незащищена от "троянского коня", не обладает средствами слежения за передачей информации, т.е. ничто не может помещать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных пользователей.

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

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

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

 [
   здесь надо подробнее написать, почему объектов может быть много.
   Например, требования "least privilege" - выдавать ровно столько 
   привилегий, чтобы их было достаточно для выполнения работы. 
 ]
 [
   При этом само требование "least privilege" не является произвольным, оно
   возникает как следствие фундаментального принципа обеспечения
   безопасности системы - "принципа минимального ущерба". Здесь вероятно
   следует отметить, что абсолютно защищенных систем не существует
   (есть чья-то замечательная фраза "Система может считаться абсолютно защищенной если
   она обесточена, заперта в сейф, сейф помещен в охраняемый бункер - но
   даже в этом случае сомнения не оставляют меня" :)) ) и следовательно
   любая система обеспечения безопасности должна учитывать риски преодоления
   системы безопасности. Принцип "минимального ущерба" как раз и подразумевает
   такое построение системы безопасности, при котором злоумышленник проникший
   в систему сможет нанести лишь минимальный ущерб своими действиями. А уже
   из этого принципа следует требование "least privilege" и как следствие
   дробление информационного наполнения на большое кол-во отдельных информационных 
   объектов доступ к которым регулируется раздельно.
 ] 

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

  • целостность, т.е. структура каталога может быть изменена только очень компетентными редактором.

Другой пример, заведение автора в системе.

  [
    Подробно описать и привести к необходимости введения ролей, которые   
    выступают как группировка прав
   ]

Широкое использование ИС в науке, образовании, бизнесе, привело к появлению большого количества вариантов схем управления доступом, в том числе и на основе RBAC. Стандарт [2,3], регламентирующий терминологию, принципы и функциональность ролевой системы доступа, был разработан Национальным институтом стандартов и технологий США и находится на стадии рассмотрения. Тем не менее, он уже широко используется разработчиками информационных систем.

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

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

Кроме того, важнейшим свойством RBAC-модели является ее нейтральность, то есть RBAC предоставляет аппарат для выражения политики безопасности, а не накладывает определенные ограничения, соответствующие определенной политике (подобно требованию однонаправленности информационного потока в MAC-модели). Используя RBAC-модель, можно эмулировать дискреционное и мандатное управление доступом [5]. Это является крайне важным, так как можно разрабатывать системы, поддерживающие RBAC-модель и конфигурировать их в случае необходимости для реализации дискреционного или мандатного управления доступом.

  [ 
    Надо дать определения терминам
   ]

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

  [
    Здесь надо дать описание RBAC, лучше с рисунками
  ]

Различают 4 различных вариаций RBAC [2]

  1. Core RBAC
  • пользователи получают права через роли
  • Поддерживает отношение многое-ко-многим для пользователей и ролей
  • Поддерживает отношение многое-ко-многим для прав и ролей
  • Активация ролей на сессию
  1. Иерархический RBAC
  • Core RBAC + поддержка иерархии ролей
  1. RBAC с поддержкой статического разделения конфликтов
  • Иерархический RBAC + разрешение конфликтов между ролями
  1. RBAC с поддержкой динамического разделения конфликтов
  • Иерархический RBAC + разрешение конфликтов между ролями

ПРИМЕР РЕАЛИЗАЦИИ

 [ 
   Считаю весьма важным показать каким образом Назин
   все придумал и как мы это использовали.
  ]

"Плоская модель" (Core RBAC) на серверах Научной Сети и фед. порталов, разработанная в рамках гранта РФФИ (???) на основе базы данных PostgreSQL. Взять пример астронета

Показать step-by-step

  1. Создание привилегии
  2. Создание роли (роль-привилегии)
  3. Роль-пользователь
  4. Использование

Недостатки плоской модели, пути развития

ССЫЛКИ

[1] RBAC NIST http://csrc.nist.gov/rbac/

[2] Proposed voluntary consensus standard for role based access control http://csrc.nist.gov/rbac/rbac-std-ncits.pdf

[3] D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R. Chandramouli, "A Proposed

Standard for Role Based Access Control (PDF)," ACM Transactions on Information and System Security , vol. 4, no. 3 (August, 2001) - draft of a consensus standard for RBAC. http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf

[4] RBAC LIST (Laboratory for Information Security Technology, George Mason University) http://www.list.gmu.edu/

[5] Sylvia Osborn, Ravi Sandhu and Qamar Munawer, Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies, ACM Transactions on Information and Systems Security (TISSEC), Volume 3, Number 2, February 2000.

[6] Ravi Sandhu and P. Samarati, Access Control: Principles and Practice, IEEE Communications, Volume 32, Number 9, September 1994.