Jump to content

Управление доступом на основе ролей

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

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

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

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

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

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

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

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

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

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

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

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

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

РБАК

Стандартизированные уровни

[ редактировать ]

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

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

Связь с другими моделями

[ редактировать ]

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

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

По сравнению с ACL

[ редактировать ]

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

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

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

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

Управление доступом на основе атрибутов

[ редактировать ]

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

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

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

Контроль доступа на основе отношений

[ редактировать ]

Управление доступом на основе отношений или ReBAC — это модель, которая развивается из RBAC. В ReBAC разрешение субъекта на доступ к ресурсу определяется наличием связей между этими субъектами и ресурсами.

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

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

[ редактировать ]

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

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

Потенциальные уязвимости

[ редактировать ]

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


См. также

[ редактировать ]
  1. ^ Феррайоло, Д.Ф. и Кун, Д.Р. (октябрь 1992 г.). «Ролевой контроль доступа» (PDF) . 15-я Национальная конференция по компьютерной безопасности : 554–563.
  2. ^ Сандху Р., Койн Э.Дж., Файнштейн Х.Л. и Юман CE (август 1996 г.). «Модели управления доступом на основе ролей» (PDF) . IEEE-компьютер . 29 (2): 38–47. CiteSeerX   10.1.1.50.7649 . дои : 10.1109/2.485845 . S2CID   1958270 . {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
  3. ^ АБРЕУ, ВИЛМАР; Сантин, Альтаир О.; ВИЕГАС, ЭДУАРДО К.; ШТИЛЕР, МАЙКОН (2017). «Модель многодоменной ролевой активации». Международная конференция IEEE по коммуникациям (ICC) 2017 г. (PDF) . IEEE Пресс. стр. 1–6. дои : 10.1109/ICC.2017.7997247 . ISBN  978-1-4673-8999-0 . S2CID   6185138 .
  4. ^ Гилберт, доктор медицинских наук, Линч Н., Феррайоло Ф.Д. (1995). «Анализ потребностей федеральной и коммерческой политики контроля доступа» . Национальная конференция по компьютерной безопасности, 1993 (16-я) Труды: Безопасность информационных систем: выбор пользователей . Издательство ДИАНА. п. 107. ИСБН  9780788119248 .
  5. ^ Альберто Белусси; Барбара Катания; Элисео Клементини; Елена Феррари (2007). Пространственные данные в Интернете: моделирование и управление . Спрингер. п. 194. ИСБН  978-3-540-69878-4 .
  6. ^ Рави Сандху; Камар Мунавер (октябрь 1998 г.). «Как осуществлять дискреционное управление доступом с помощью ролей». 3-й семинар ACM по ролевому контролю доступа : 47–54.
  7. ^ Сильвия Осборн; Рави Сандху и Камар Мунавер (2000). «Настройка контроля доступа на основе ролей для обеспечения соблюдения обязательных и дискреционных политик контроля доступа». Транзакции ACM по информационной и системной безопасности : 85–106.
  8. ^ Брукер, Ахим Д.; Вольф, Буркхарт (2005). «Подход к проверке прикладной системной безопасности» . Международный журнал по программным инструментам для трансфера технологий . 7 (3): 233–247. дои : 10.1007/s10009-004-0176-3 . hdl : 20.500.11850/52625 . S2CID   6427232 .
  9. ^ Д. Р. Кун (1998). «Управление доступом на основе ролей в системах MLS без изменений ядра». Материалы третьего семинара ACM по ролевому управлению доступом (PDF) . стр. 25–32. CiteSeerX   10.1.1.55.4755 . дои : 10.1145/286884.286890 . ISBN  978-1-58113-113-0 . S2CID   1711956 .
  10. ^ «Управление доступом на основе ролей: часто задаваемые вопросы» . csrc.nist.gov . Центр исследований компьютерной безопасности. 21 ноября 2016 г. Проверено 15 августа 2018 г.
  11. ^ Феррайоло, Дэвид; Кун, Ричард (13 октября 1992 г.). «Управление доступом на основе ролей» (PDF) . csrc.nist.gov : 554–563 . Проверено 15 августа 2018 г.
  12. ^ А.А. Эллиотт и Г.С. Найт (2010). «Ролевой взрыв: признание проблемы» (PDF) . Материалы Международной конференции по исследованиям и практике в области программной инженерии 2010 года .
  13. ^ «ERBAC – Управление доступом на основе ролей предприятия (вычисления) – AcronymFinder» . www.acronymfinder.com . Проверено 15 августа 2018 г.
  14. ^ «Доктор Бхавани Турайсингхам и Шринивасан Айер (ППТ)» . Проверено 15 августа 2018 г.
  15. ^ Корхонен, Калле. «гобелен-безопасность-jpa» . www.tynamo.org . Проверено 15 августа 2018 г.
  16. ^ Д. Р. Кун (1997). «Взаимное исключение ролей как средство реализации разделения обязанностей в ролевых системах контроля доступа». Материалы второго семинара ACM по управлению доступом на основе ролей - RBAC '97 (PDF) . стр. 23–30. дои : 10.1145/266741.266749 . ISBN  0897919858 . S2CID   482687 .
  17. ^ Ли, Нинхуэй; Бизри, Зиад; Трипунитара, Махеш В. (2004). «О взаимоисключающих ролях и разделении обязанностей». Материалы 11-й конференции ACM по компьютерной и коммуникационной безопасности (PDF) . стр. 42–51. CiteSeerX   10.1.1.159.2556 . дои : 10.1145/1030083.1030091 . ISBN  978-1581139617 . S2CID   798546 .
  18. ^ Дж. Баркли (1997) « Сравнение простых моделей управления доступом на основе ролей и списков управления доступом », в «Материалах второго семинара ACM по управлению доступом на основе ролей», страницы 127-132.
  19. ^ Гейтс, Кэрри (2007). «Требования к контролю доступа для обеспечения безопасности и конфиденциальности Web 2.0» . Интернет IEEE . 2 : 12–15.
  20. ^ AC О'Коннор и Р.Дж. Лумис (март 2002 г.). Экономический анализ ролевого контроля доступа (PDF) . Научно-исследовательский институт «Треугольник». п. 145.
  21. ^ Системы, Хитачи ID. «За пределами ролей: практический подход к корпоративному IAM» . www.idsynch.com . Проверено 15 августа 2018 г.
  22. ^ Сандху Р., Феррайоло Д.Ф. и Кун Д.Р. (июль 2000 г.). «Модель NIST для управления доступом на основе ролей» (PDF) . Материалы пятого семинара ACM по ролевому управлению доступом . стр. 47–63. дои : 10.1145/344287.344301 . ISBN  158113259X . S2CID   14539795 . {{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка )
  23. ^ Феррайоло Д.Ф., Кун Д.Р. и Сандху Р. (ноябрь – декабрь 2007 г.). «Обоснование стандарта RBAC: комментарии к критике стандарта ANSI по управлению доступом на основе ролей» (PDF) . Безопасность и конфиденциальность IEEE . 5 (6): 51–53. дои : 10.1109/MSP.2007.173 . S2CID   28140142 . Архивировано из оригинала (PDF) 17 сентября 2008 г. {{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )
  24. ^ Марикканну, П. (2011). «Отказоустойчивая адаптивная система мобильных агентов с использованием динамического ролевого контроля доступа» . Международный журнал компьютерных приложений . 20 (2): 1–6. Бибкод : 2011IJCA...20b...1M . дои : 10.5120/2409-3208 .

Дальнейшее чтение

[ редактировать ]
  • Дэвид Ф. Феррайоло; Д. Ричард Кун; Рамасвами Чандрамули (2007). Ролевой контроль доступа (2-е изд.). Артех Хаус. ISBN  978-1-59693-113-8 .
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 9741f7d97c6f9e2ab421a71fd0aa6eef__1716992040
URL1:https://arc.ask3.ru/arc/aa/97/ef/9741f7d97c6f9e2ab421a71fd0aa6eef.html
Заголовок, (Title) документа по адресу, URL1:
Role-based access control - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)