В области безопасности компьютерных систем контроль доступа на основе ролей ( RBAC ) [1] [2] или безопасность на основе ролей [3] представляет собой подход к ограничению доступа к системе только авторизованными пользователями, а также к реализации обязательного контроля доступа (MAC) или дискреционного контроля доступа (DAC) .
Управление доступом на основе ролей — это нейтральный к политике механизм управления доступом, определенный вокруг ролей и привилегий. Такие компоненты RBAC, как роли-разрешения, отношения пользователь-роль и роль-роль, упрощают выполнение назначений пользователей. Исследование NIST показало, что RBAC удовлетворяет многие потребности коммерческих и государственных организаций. [4] RBAC можно использовать для упрощения администрирования безопасности в крупных организациях с сотнями пользователей и тысячами разрешений. Хотя RBAC отличается от фреймворков управления доступом MAC и DAC, он может применять эти политики без каких-либо сложностей.
В организации роли создаются для различных должностных функций. Разрешения на выполнение определенных операций назначаются определенным ролям. Поскольку пользователям разрешения не назначаются напрямую, а только приобретаются через их роль (или роли), управление правами отдельных пользователей сводится к простому назначению соответствующих ролей учетной записи пользователя; это упрощает общие операции, такие как добавление пользователя или изменение отдела пользователя.
Для RBAC определены три основных правила:
Могут также применяться дополнительные ограничения, а роли могут быть объединены в иерархию , где роли более высокого уровня включают в себя разрешения, принадлежащие подролям.
С помощью концепций иерархии ролей и ограничений можно управлять RBAC для создания или имитации управления доступом на основе решетки (LBAC). Таким образом, RBAC можно рассматривать как надмножество LBAC.
При определении модели RBAC полезны следующие соглашения:
Ограничение устанавливает ограничительное правило на потенциальное наследование разрешений от противоположных ролей. Таким образом, его можно использовать для достижения соответствующего разделения обязанностей . Например, одному и тому же человеку не должно быть разрешено и создавать учетную запись для входа, и авторизовать создание учетной записи.
Таким образом, используя обозначения теории множеств :
У субъекта может быть несколько одновременных сеансов с/в разных ролях.
Стандарт RBAC NIST/ANSI/ INCITS (2004) признает три уровня RBAC: [5]
RBAC — это гибкая технология управления доступом, гибкость которой позволяет реализовать DAC [6] или MAC . [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) используются в традиционных системах дискреционного контроля доступа (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 можно использовать атрибуты:
ABAC основан на политиках в том смысле, что для определения того, что разрешено, а что нет, он использует политики, а не статические разрешения.
Relationship-based access control или ReBAC — это модель, которая развивается из RBAC. В ReBAC разрешение субъекта на доступ к ресурсу определяется наличием отношений между этими субъектами и ресурсами.
Преимущество этой модели в том, что она допускает детальные разрешения; например, в социальной сети, где пользователи могут делиться сообщениями с другими определенными пользователями. [19]
Использование RBAC для управления привилегиями пользователей (разрешениями компьютера) в рамках одной системы или приложения широко признано как передовая практика. В отчете 2010 года, подготовленном для NIST Институтом исследовательского треугольника, проанализирована экономическая ценность RBAC для предприятий и оценены выгоды на одного сотрудника от сокращения времени простоя сотрудников, более эффективного предоставления и более эффективного администрирования политики контроля доступа. [20]
В организации с неоднородной ИТ-инфраструктурой и требованиями, которые охватывают десятки или сотни систем и приложений, использование RBAC для управления достаточным количеством ролей и назначения адекватного членства в ролях становится чрезвычайно сложным без иерархического создания ролей и назначения привилегий. [21] Более новые системы расширяют старую модель NIST RBAC [22] для устранения ограничений RBAC для развертываний в масштабах предприятия. Модель NIST была принята в качестве стандарта INCITS как ANSI/INCITS 359-2004. Обсуждение некоторых вариантов дизайна для модели NIST также было опубликовано. [23]
Вмешательство в управление доступом на основе ролей является относительно новой проблемой в приложениях безопасности, где несколько учетных записей пользователей с динамическими уровнями доступа могут привести к нестабильности ключа шифрования, позволяя внешнему пользователю использовать уязвимость для несанкционированного доступа. Приложения совместного использования ключей в динамических виртуализированных средах продемонстрировали определенный успех в решении этой проблемы. [24]
{{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite book}}
: CS1 maint: несколько имен: список авторов ( ссылка ){{cite journal}}
: CS1 maint: несколько имен: список авторов ( ссылка )