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

В области безопасности компьютерных систем управление доступом на основе ролей ( RBAC ) [1] [2] или безопасность на основе ролей [3] является подходом к ограничению доступа к системе для авторизованных пользователей. Он используется на большинстве предприятий с численностью сотрудников более 500 человек [4] и может реализовывать обязательный контроль доступа (MAC) или дискреционный контроль доступа (DAC).

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

Дизайн [ править ]

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

Вмешательство в управление доступом на основе ролей является относительно новой проблемой в приложениях безопасности, где несколько учетных записей пользователей с динамическими уровнями доступа могут привести к нестабильности ключа шифрования, позволяя внешнему пользователю использовать уязвимость для несанкционированного доступа. Приложения для совместного использования ключей в динамических виртуализированных средах показали некоторый успех в решении этой проблемы. [6]

Для RBAC определены три основных правила:

  1. Назначение ролей: субъект может использовать разрешение только в том случае, если субъект выбрал или ему была назначена роль.
  2. Авторизация роли: активная роль субъекта должна быть авторизована для субъекта. С помощью правила 1, приведенного выше, это правило гарантирует, что пользователи могут выполнять только те роли, для которых они авторизованы.
  3. Разрешение авторизации: субъект может использовать разрешение только в том случае, если разрешение разрешено для активной роли субъекта. С помощью правил 1 и 2 это правило гарантирует, что пользователи могут использовать только те разрешения, на которые они авторизованы.

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

Используя концепции иерархии ролей и ограничений, можно управлять RBAC для создания или моделирования управления доступом на основе решетки (LBAC). Таким образом, RBAC можно рассматривать как надмножество LBAC.

При определении модели RBAC полезны следующие соглашения:

  • S = Тема = Человек или автоматический агент
  • R = Роль = Должностная функция или должность, определяющая уровень полномочий
  • P = Permissions = Утверждение режима доступа к ресурсу
  • SE = Session = отображение, включающее S, R и / или P
  • SA = Назначение темы
  • PA = Назначение разрешений
  • RH = Частично упорядоченная иерархия ролей. RH также можно записать: ≥ (Обозначение: x ≥ y означает, что x наследует разрешения y.)
    • У субъекта может быть несколько ролей.
    • Роль может иметь несколько субъектов.
    • У роли может быть много разрешений.
    • Разрешение может быть назначено многим ролям.
    • Операции можно назначить множество разрешений.
    • Разрешение может быть назначено многим операциям.

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

Таким образом, используя обозначения теории множеств :

  • и является разрешением многие ко многим для отношения назначения ролей.
  • и многие ко многим зависят от отношения назначения ролей.

Субъект может иметь несколько одновременных сессий с / в разных ролях.

RBAC

Стандартизированные уровни [ править ]

См. Также: модель NIST RBAC

Стандарт NIST / ANSI / INCITS RBAC (2004) распознает три уровня RBAC: [7]

  1. ядро RBAC
  2. иерархический RBAC, который добавляет поддержку наследования между ролями
  3. ограниченный RBAC, который добавляет разделение обязанностей

Отношение к другим моделям [ править ]

RBAC - это гибкая технология управления доступом, гибкость которой позволяет реализовать DAC [8] или MAC . [9] DAC с группами (например, как реализовано в файловых системах POSIX) может эмулировать RBAC. [10] MAC может моделировать RBAC, если граф ролей ограничен деревом, а не частично упорядоченным набором . [11]

До разработки RBAC модель Bell-LaPadula (BLP) была синонимом MAC, а разрешения файловой системы были синонимами DAC. Они считались единственными известными моделями управления доступом: если модель не была BLP, она считалась моделью DAC, и наоборот. Исследования конца 1990-х годов показали, что RBAC не попадает ни в одну из категорий. [12] [13] В отличие от управления доступом на основе контекста (CBAC), RBAC не смотрит на контекст сообщения (например, на источник соединения). RBAC также подвергался критике за то, что привело к взрывному росту ролей [14].проблема в крупных корпоративных системах, которые требуют контроля доступа с более высокой степенью детализации, чем то, что может обеспечить RBAC, поскольку роли по своей сути назначаются операциям и типам данных. По аналогии с CBAC, система управления доступом на основе отношений на основе сущностей (ERBAC, хотя такая же аббревиатура также используется для модифицированных систем RBAC [15], таких как расширенное управление доступом на основе ролей [16] ), система способна защищать экземпляры данных. учитывая их связь с исполняющим субъектом. [17]

Сравнение с ACL [ править ]

RBAC отличается от списков контроля доступа(ACL), используемые в традиционных дискреционных системах контроля доступа, в которых системы RBAC назначают разрешения для определенных операций со смыслом в организации, а не для низкоуровневых объектов данных. Например, список управления доступом может использоваться для предоставления или запрета доступа на запись к определенному системному файлу, но он не будет указывать, как этот файл может быть изменен. В системе на основе RBAC операция может заключаться в транзакции «создать кредитный счет» в финансовом приложении или «заполнить запись теста на уровень сахара в крови» в медицинском приложении. Назначение разрешения на выполнение конкретной операции имеет смысл, потому что операции детализированы и имеют смысл в приложении. Было показано, что RBAC особенно хорошо подходит для требований разделения обязанностей (SoD),которые гарантируют, что два или более человека должны участвовать в авторизации критических операций. Проанализированы необходимые и достаточные условия безопасности SoD в RBAC. Основополагающий принцип SoD заключается в том, что ни один человек не должен иметь возможность нарушить безопасность с помощью двойных привилегий. В более широком смысле, никто не может занимать роль, которая осуществляет аудит, контроль или контроль над другой, одновременно выполняемой ролью.[18] [19]

С другой стороны, «минимальную модель RBAC», RBACm , можно сравнить с механизмом ACL, ACLg , где только группы разрешены в качестве записей в ACL. Barkley (1997) [20] показал, что RBACm и ACLg эквивалентны.

В современных реализациях SQL , таких как ACL инфраструктуры CakePHP , ACL также управляют группами и наследованием в иерархии групп. В этом аспекте конкретные реализации «современных ACL» можно сравнить с конкретными реализациями «современных RBAC» лучше, чем «старые реализации (файловой системы)».

Для обмена данными и для «сравнений высокого уровня» данные ACL могут быть переведены в XACML .

Контроль доступа на основе атрибутов [ править ]

Управление доступом на основе атрибутов или ABAC - это модель, которая развивается из RBAC и учитывает дополнительные атрибуты в дополнение к ролям и группам. В ABAC можно использовать атрибуты:

  • пользователь, например, гражданство, допуск,
  • ресурс, например, классификация, отдел, владелец,
  • действие, и
  • контекст, например время, местоположение, IP.

ABAC основан на политике в том смысле, что он использует политики, а не статические разрешения, чтобы определить, что разрешено, а что нет.

Использование и доступность [ править ]

Использование RBAC для управления привилегиями пользователей (разрешениями компьютера) в одной системе или приложении широко признано как лучшая практика. В отчете за 2010 год, подготовленном для NIST Институтом исследовательского треугольника, анализировалась экономическая ценность RBAC для предприятий и оценивалась выгода в расчете на одного сотрудника за счет сокращения времени простоя сотрудников, более эффективного выделения ресурсов и более эффективного администрирования политик контроля доступа. [4]

В организации с разнородной ИТ-инфраструктурой и требованиями, охватывающими десятки или сотни систем и приложений, использование RBAC для управления достаточным количеством ролей и назначения соответствующего членства в ролях становится чрезвычайно сложным без иерархического создания ролей и назначения привилегий. [21] Новые системы расширяют старую модель RBAC NIST [22], чтобы устранить ограничения RBAC для развертывания в масштабе предприятия. Модель NIST была принята INCITS в качестве стандарта как ANSI / INCITS 359-2004. Также было опубликовано обсуждение некоторых вариантов дизайна для модели NIST. [23]

См. Также [ править ]

  • Список контроля доступа
  • Атрибутный контроль доступа (ABAC)
  • Управление доступом на основе организации (OrBAC)
  • RSBAC
  • Безопасность на основе возможностей
  • Аутентификация на основе местоположения
  • Риск-ориентированная аутентификация
  • AGDLP (рекомендации Microsoft по внедрению RBAC)
  • Сеть, управляемая идентификацией (IDN)
  • РАЗРЕШЕНИЕ
  • Классифицированная информация
  • Крепость Апачей

Ссылки [ править ]

  1. ^ Феррайоло, DF & Kuhn, DR (октябрь 1992). «Ролевой контроль доступа» (PDF) . 15-я Национальная конференция по компьютерной безопасности : 554–563.
  2. ^ Санду Р., Койн, EJ, Файнштейн, HL и Youman, CE (август 1996). «Модели управления доступом на основе ролей» (PDF) . Компьютер IEEE . 29 (2): 38–47. CiteSeerX 10.1.1.50.7649 . DOI : 10.1109 / 2.485845 .  CS1 maint: несколько имен: список авторов ( ссылка )
  3. ^ АБРЕУ, ВИЛМАР; Сантин, Альтаир О .; ВИЕГАС, ЭДУАРДО К .; STIHLER, MAICON (2017). Модель активации многодоменных ролей (PDF) . ICC 2017 2017 Международная конференция IEEE по коммуникациям . IEEE Press. С. 1–6. DOI : 10.1109 / ICC.2017.7997247 . ISBN  978-1-4673-8999-0. S2CID  6185138 .
  4. ^ Б A.C. O'Connor & RJ Loomis (март 2002). Экономический анализ ролевого контроля доступа (PDF) . Институт Исследовательского Треугольника. п. 145.
  5. Перейти ↑ Gilbert MD, Lynch N, Ferraiolo FD (1995). «Изучение потребностей федеральной и коммерческой политики контроля доступа» . Национальная конференция по компьютерной безопасности, 1993 (16-я) Труды: Безопасность информационных систем: выбор пользователя . ДИАНА Паблишинг. п. 107. ISBN 9780788119248.
  6. ^ Marikkannu, P (2011). «Отказоустойчивая адаптивная система мобильного агента с использованием динамического контроля доступа на основе ролей» . Международный журнал компьютерных приложений . 20 (2): 1–6. Bibcode : 2011IJCA ... 20b ... 1M . DOI : 10.5120 / 2409-3208 .
  7. ^ Альберто Belussi; Барбара Катания; Элисео Клементини; Елена Феррари (2007). Пространственные данные в Интернете: моделирование и управление . Springer. п. 194. ISBN 978-3-540-69878-4.
  8. ^ Рави Сандху; Камар Мунавер (октябрь 1998 г.). «Как сделать дискреционный контроль доступа с помощью ролей». 3-й семинар ACM по ролевому контролю доступа : 47–54.
  9. ↑ Сильвия Осборн; Рави Сандху и Камар Мунавер (2000). «Настройка контроля доступа на основе ролей для принудительного применения политик обязательного и дискреционного контроля доступа». ACM-транзакции по информационной и системной безопасности : 85–106.
  10. ^ Brucker, Achim D .; Вольф, Буркхарт (2005). «Подход к проверке безопасности прикладных систем» . Международный журнал программных средств для технологий (STTT) . 7 (3): 233–247. DOI : 10.1007 / s10009-004-0176-3 . ЛВП : 20.500.11850 / 52625 . S2CID 6427232 . 
  11. ^ DR Kuhn (1998). «Контроль доступа на основе ролей в системах MLS без изменений ядра». Материалы третьего семинара ACM по ролевому контролю доступа - RBAC '98 (PDF) . Третий семинар ACM по ролевому контролю доступа . С. 25–32. CiteSeerX 10.1.1.55.4755 . DOI : 10.1145 / 286884.286890 . ISBN   978-1-58113-113-0. S2CID  1711956 .
  12. ^ Редактор, CSRC Content (21.11.2016). «Контроль доступа на основе ролей - часто задаваемые вопросы» . csrc.nist.gov . Проверено 15 августа 2018 .CS1 maint: дополнительный текст: список авторов ( ссылка )
  13. ^ (NIST), Автор: Дэвид Феррайоло; (NIST), автор: Ричард Кун (1992-10-13). «Контроль доступа на основе ролей» (PDF) . csrc.nist.gov . С. 554–563 . Проверено 15 августа 2018 .
  14. Перейти ↑ AA Elliott & GS Knight (2010). «Взрыв ролей: признание проблемы» (PDF) . Труды Международной конференции 2010 г. по исследованиям и практике программной инженерии .
  15. ^ «ERBAC - Управление доступом на основе ролей предприятия (вычисления) - AcronymFinder» . www.acronymfinder.com . Проверено 15 августа 2018 .
  16. ^ «Доктор Бхавани Турайсингам и Шринивасан Айер (PPT)» . Проверено 15 августа 2018 .
  17. ^ Корхонен, Калле. "гобелен-безопасность-JPA" . www.tynamo.org . Проверено 15 августа 2018 .
  18. ↑ DR Kuhn (1997). «Взаимное исключение ролей как средство реализации разделения обязанностей в ролевых системах контроля доступа» (PDF) . 2-й семинар ACM Управление доступом на основе ролей : 23–30.
  19. ^ Ninghui Ли, Зияд Bizri и Махеш В. Tripunitara. Трипунитара (2004). «О взаимоисключающих ролях и разделении обязанностей» (PDF) . 11-я конференция ACM по компьютерной и коммуникационной безопасности . CCS '04: 42–51. CiteSeerX 10.1.1.159.2556 . DOI : 10.1145 / 1030083.1030091 . ISBN   978-1581139617. S2CID  798546 .CS1 maint: несколько имен: список авторов ( ссылка )
  20. ^ Дж. Баркли (1997) « Сравнение простых моделей управления доступом на основе ролей и списков управления доступом », В «Протоколах второго семинара ACM по управлению доступом на основе ролей», страницы 127-132.
  21. ^ Системы, Hitachi ID. «Помимо ролей: практический подход к корпоративной IAM» . www.idsynch.com . Проверено 15 августа 2018 .
  22. ^ Санду Р., Феррайоло, DF и Kuhn, DR (июль 2000). «Модель NIST для ролевого контроля доступа: к единому стандарту» (PDF) . 5-й семинар ACM Управление доступом на основе ролей : 47–63. CS1 maint: несколько имен: список авторов ( ссылка )
  23. ^ Феррайоло, DF, Куна, DR, и Санду Р. (ноябрь-декабрь 2007). «Обоснование стандарта RBAC: комментарии к критике стандарта ANSI по ролевому контролю доступа» (PDF) . Безопасность и конфиденциальность IEEE . 5 (6): 51–53. DOI : 10.1109 / MSP.2007.173 . S2CID 28140142 . Архивировано из оригинального (PDF) 17 сентября 2008 года.   CS1 maint: несколько имен: список авторов ( ссылка )

Дальнейшее чтение [ править ]

  • Дэвид Ф. Феррайоло; Д. Ричард Кун; Рамасвами Чандрамули (2007). Контроль доступа на основе ролей (2-е изд.). Артек Хаус. ISBN 978-1-59693-113-8.

Внешние ссылки [ править ]

  • Часто задаваемые вопросы о моделях и стандартах RBAC
  • Контроль доступа на основе ролей в NIST
  • Ядро XACML и профиль управления доступом на основе иерархических ролей
  • Институт кибербезопасности Техасского университета в Сан-Антонио
  • Практический опыт внедрения RBAC