Контроль доступа на основе ролей - Role-based access control

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

Управление доступом на основе ролей (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 /ИНЦИТЫ Стандарт RBAC (2004) признает три уровня RBAC:[7]

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

Отношение к другим моделям

RBAC - это гибкая технология контроля доступа, гибкость которой позволяет реализовать ЦАП[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 разрешены только группы. Баркли (1997)[20] показало, что RBACm и ACLg эквивалентны.

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

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

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

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

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

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

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

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

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

Согласование RBAC и обязанностей сотрудников

В Согласование прав доступа с потребностями управления с метамоделью ответственности (ReMMo) в рамках архитектуры предприятия[24] была определена выразительная метамодель ответственности, которая позволяет представить существующие обязанности на бизнес-уровне и, таким образом, позволяет разработать права доступа, необходимые для выполнения этих обязанностей, на уровне приложений. Предложен метод более точного определения прав доступа с учетом выравнивания ответственности и RBAC.[25]

Смотрите также

использованная литература

  1. ^ Феррайоло, Д.Ф. И Кун, Д. (Октябрь 1992 г.). «Контроль доступа на основе ролей» (PDF). 15-я Национальная конференция по компьютерной безопасности: 554–563.
  2. ^ Сандху, Р., Койн, Э.Дж., Файнштейн, Х.Л. и Юман, С.Е. (август 1996 г.). «Модели управления доступом на основе ролей» (PDF). IEEE Computer. 29 (2): 38–47. CiteSeerX  10.1.1.50.7649. Дои:10.1109/2.485845.CS1 maint: несколько имен: список авторов (ссылка на сайт)
  3. ^ АБРЕУ, ВИЛМАР; Сантин, Альтаир О .; ВИЕГАС, ЭДУАРДО К .; STIHLER, MAICON (2017). Модель активации многодоменных ролей (PDF). ICC 2017 2017 Международная конференция IEEE по коммуникациям. IEEE Press. С. 1–6. Дои:10.1109 / ICC.2017.7997247. ISBN  978-1-4673-8999-0. S2CID  6185138.
  4. ^ а б A.C. О'Коннор и Р.Дж. Лумис (март 2002 г.). Экономический анализ ролевого контроля доступа (PDF). Институт Исследовательского Треугольника. п. 145.
  5. ^ Гилберт, доктор медицины, Линч Н., Феррайоло, Форд (1995). «Изучение потребностей федеральной и коммерческой политики контроля доступа». Национальная конференция по компьютерной безопасности, 1993 (16-я) Труды: Безопасность информационных систем: выбор пользователя. Издательство ДИАНА. п. 107. ISBN  9780788119248.
  6. ^ Марикканну, П. (2011). «Отказоустойчивая адаптивная система мобильного агента с использованием динамического контроля доступа на основе ролей». Международный журнал компьютерных приложений. 20 (2): 1–6. Bibcode:2011IJCA ... 20b ... 1M. Дои:10.5120/2409-3208.
  7. ^ Альберто Белусси; Барбара Катания; Элисео Клементини; Елена Феррари (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. Дои:10.1007 / s10009-004-0176-3. HDL:20.500.11850/52625. S2CID  6427232.
  11. ^ D.R. Кун (1998). «Контроль доступа на основе ролей в системах MLS без изменений ядра». Материалы третьего семинара ACM по ролевому контролю доступа - RBAC '98 (PDF). Третий семинар ACM по ролевому контролю доступа. С. 25–32. CiteSeerX  10.1.1.55.4755. Дои:10.1145/286884.286890. ISBN  978-1-58113-113-0. S2CID  1711956.
  12. ^ Редактор, CSRC Content (21 ноября 2016 г.). «Контроль доступа на основе ролей - часто задаваемые вопросы». csrc.nist.gov. Получено 15 августа 2018.CS1 maint: дополнительный текст: список авторов (ссылка на сайт)
  13. ^ (NIST), Автор: Дэвид Феррайоло; (NIST), автор: Ричард Кун (1992-10-13). «Контроль доступа на основе ролей» (PDF). csrc.nist.gov. стр. 554–563. Получено 15 августа 2018.
  14. ^ А. А. Эллиотт и Г. С. Найт (2010). «Взрыв ролей: признание проблемы» (PDF). Материалы Международной конференции по исследованиям и практике программной инженерии 2010 г..
  15. ^ «ERBAC - Управление доступом на основе ролей предприятия (вычисления) - AcronymFinder». www.acronymfinder.com. Получено 15 августа 2018.
  16. ^ "Д-р Бхавани Турайсингам и Шринивасан Айер (PPT)". Получено 15 августа 2018.
  17. ^ Корхонен, Калле. "гобелен-безопасность-jpa". www.tynamo.org. Получено 15 августа 2018.
  18. ^ D.R. Кун (1997). «Взаимное исключение ролей как средство реализации разделения обязанностей в ролевых системах контроля доступа» (PDF). 2-й семинар ACM Управление доступом на основе ролей: 23–30.
  19. ^ Нинхуэй Ли, Зиад Бизри и Махеш В. Трипунитара. Трипунитара (2004). «О взаимоисключающих ролях и разделении обязанностей» (PDF). 11-я конференция ACM по компьютерной и коммуникационной безопасности. CCS '04: 42–51. CiteSeerX  10.1.1.159.2556. Дои: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. ^ Сандху, Р., Феррайоло, Д.Ф. и Кун, Д. (Июль 2000 г.). «Модель NIST для ролевого контроля доступа: к единому стандарту» (PDF). 5-й семинар ACM Управление доступом на основе ролей: 47–63.CS1 maint: несколько имен: список авторов (ссылка на сайт)
  23. ^ Феррайоло Д.Ф., Кун Д.Р. и Сандху Р. (ноябрь – декабрь 2007 г.). «Обоснование стандарта RBAC: комментарии к критике стандарта ANSI по ролевому контролю доступа» (PDF). Безопасность и конфиденциальность IEEE. 5 (6): 51–53. Дои:10.1109 / MSP.2007.173. S2CID  28140142. Архивировано из оригинал (PDF) 17 сентября 2008 г.CS1 maint: несколько имен: список авторов (ссылка на сайт)
  24. ^ Фелтус К. (2014). Согласование прав доступа с потребностями управления с метамоделью ответственности (ReMMo) в рамках архитектуры предприятия (PDF).
  25. ^ Фельтус, К., Пети, М., Сломан, М. (2010). «Улучшение согласования ИТ бизнеса за счет включения компонентов ответственности в RBAC» (PDF). Ceur-Ws. 599.CS1 maint: несколько имен: список авторов (ссылка на сайт)

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

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

внешние ссылки