Войти
В безопасности компьютерных систем роль- управление доступом на основе (RBAC ) или безопасность на основе ролей - это подход к ограничению доступа к системе для авторизованных пользователей. Он используется на большинстве предприятий с более чем 500 сотрудниками и может реализовать обязательный контроль доступа (MAC) или дискреционный контроль доступа (DAC).
Управление доступом на основе ролей (RBAC) - это не зависящий от политик механизм управления доступом, определенный для ролей и привилегий. Компоненты RBAC, такие как роли-разрешения, отношения пользователь-роль и роль-роль, упрощают выполнение назначений пользователей. Исследование NIST показало, что RBAC удовлетворяет многие потребности коммерческих и государственных организаций. RBAC можно использовать для облегчения администрирования безопасности в крупных организациях с сотнями пользователей и тысячами разрешений. Хотя RBAC отличается от структур управления доступом MAC и DAC, он может применять эти политики без каких-либо осложнений.
Внутри организации роли созданы для различных рабочих функций. Разрешения на выполнение определенных операций назначаются определенным ролям. Членам или сотрудникам (или другим пользователям системы) назначаются определенные роли, и посредством этих назначений ролей они получают разрешения, необходимые для выполнения определенных функций системы. Поскольку пользователям не назначаются разрешения напрямую, а они получают их только через свою роль (или роли), управление правами отдельных пользователей становится вопросом простого назначения соответствующих ролей учетной записи пользователя; это упрощает общие операции, такие как добавление пользователя или изменение отдела пользователя.
Вмешательство в управление доступом на основе ролей является относительно новой проблемой в приложениях безопасности, где несколько учетных записей пользователей с динамическими уровнями доступа могут привести к нестабильности ключа шифрования, позволяя внешнему пользователю использовать уязвимость для несанкционированного доступа. Приложения для совместного использования ключей в динамических виртуализированных средах продемонстрировали некоторый успех в решении этой проблемы.
Для RBAC определены три основных правила:
Также могут применяться дополнительные ограничения, и роли могут быть объединены в иерархию, где более высокий уровень роли включают в себя разрешения, принадлежащие подчиненным ролям.
Используя концепции иерархии ролей и ограничений, можно управлять RBAC для создания или моделирования управления доступом на основе решетки (LBAC). Таким образом, RBAC можно рассматривать как надмножество LBAC.
При определении модели RBAC полезны следующие условные обозначения:
Ограничение накладывает ограничивающее правило на возможное наследование разрешений от противоположных ролей, поэтому его можно использовать для достижения соответствующего разделения обязанностей. Например, одному и тому же человеку не должно быть разрешено одновременно создавать учетную запись для входа и авторизовывать создание учетной записи.
Таким образом, используя теорию множеств нотацию :
и много для многих разрешений на отношение назначения ролей.
и многие ко многим зависят от отношения назначения ролей.
Субъект может иметь несколько одновременных сеансов с / в разных ролях.
RBAC NIST / ANSI / INCITS Стандарт RBAC (2004) распознает три уровня RBAC:
RBAC - это гибкая технология управления доступом, гибкость которой позволяет реализовать DAC или MAC. DAC с группами (например, реализованный в файловых системах POSIX) может эмулировать RBAC. MAC может имитировать RBAC, если граф ролей ограничен деревом, а не частично упорядоченным набором.
До разработки RBAC модель Bell-LaPadula (BLP) была синонимом MAC. и разрешения файловой системы были синонимами DAC. Они считались единственными известными моделями управления доступом: если модель не была BLP, она считалась моделью DAC, и наоборот. Исследования конца 1990-х годов показали, что RBAC не попадает ни в одну из категорий. В отличие от управления доступом на основе контекста (CBAC), RBAC не смотрит на контекст сообщения (например, на источник соединения). RBAC также подвергался критике за то, что он приводил к взрывному росту ролей, что является проблемой в крупных корпоративных системах, которые требуют более точного контроля доступа, чем то, что может обеспечить RBAC, поскольку роли по сути назначаются операциям и типам данных. По аналогии с CBAC, система управления доступом на основе отношений сущностей (ERBAC, хотя тот же акроним также используется для модифицированных систем RBAC, таких как расширенное управление доступом на основе ролей), может защищать экземпляры данных, учитывая их связь с исполняющий субъект.
RBAC отличается от списков управления доступом (ACL), используемых в традиционных дискреционных системах управления доступом, тем, что системы RBAC назначают разрешения для конкретные операции со смыслом в организации, а не с низкоуровневыми объектами данных. Например, список управления доступом может использоваться для предоставления или запрета доступа на запись к определенному системному файлу, но он не будет диктовать, как этот файл может быть изменен. В системе на основе RBAC операция может заключаться в транзакции «создать кредитный счет» в финансовом приложении или «заполнить запись теста на уровень сахара в крови» в медицинском приложении. Назначение разрешения на выполнение конкретной операции имеет смысл, потому что операции являются детализированными и имеют смысл в приложении. Было показано, что RBAC особенно хорошо подходит для требований разделения обязанностей (SoD), которые гарантируют, что два или более человека должны участвовать в авторизации критических операций. Проанализированы необходимые и достаточные условия безопасности SoD в RBAC. Основополагающий принцип SoD заключается в том, что ни один человек не должен иметь возможность нарушить безопасность с помощью двойных привилегий. В более широком смысле, никто не может занимать роль, которая осуществляет аудит, контроль или проверку другой, одновременно выполняемой роли.
С другой стороны, «минимальную модель RBAC», RBACm, можно сравнить с механизмом ACL, ACLg, где в качестве записей в ACL разрешены только группы. Баркли (1997) показал, что RBACm и ACLg эквивалентны.
В современных реализациях SQL, таких как ACL структуры CakePHP, ACL также управляют группами и наследованием в иерархии групп. В этом аспекте конкретные реализации «современных ACL» можно сравнить с конкретными реализациями «современных RBAC» лучше, чем «старые реализации (файловой системы)».
Для обмена данными и «высокоуровневых сравнений» данные ACL могут быть преобразованы в XACML.
Управление доступом на основе атрибутов или ABAC - это модель, которая развивается из RBAC и учитывает дополнительные атрибуты в дополнение к ролям и группам. В ABAC можно использовать атрибуты:
ABAC основан на политике в том смысле, что он использует политики, а не статические разрешения, чтобы определить, что разрешено, а что нет.
Использование RBAC для управления привилегиями пользователей (разрешениями компьютера) в одной системе или приложении широко признано как лучшая практика. В отчете за 2010 год, подготовленном для NIST Research Triangle Institute, анализировалась экономическая ценность RBAC для предприятий и оценивалась выгода в расчете на одного сотрудника за счет сокращения времени простоя сотрудников, более эффективного выделения ресурсов и более эффективного доступа. контролировать администрирование политик.
В организации с разнородной ИТ-инфраструктурой и требованиями, охватывающими десятки или сотни систем и приложений, использование RBAC для управления достаточным количеством ролей и назначения адекватного членства в ролях становится чрезвычайно сложным без иерархического создания ролей и назначения привилегий. Новые системы расширяют старую модель NIST RBAC, чтобы устранить ограничения RBAC для развертываний в масштабе предприятия. Модель NIST была принята в качестве стандарта INCITS как ANSI / INCITS 359-2004. Также было опубликовано обсуждение некоторых вариантов дизайна для модели NIST.
В Согласовании прав доступа с потребностями управления с метамоделью ответственности (ReMMo) в Структура Архитектуры предприятия была определена выразительная метамодель ответственности, которая позволяет представить существующие обязанности на бизнес-уровне и, таким образом, позволяет разработать права доступа, необходимые для выполнения этих обязанностей, на уровне приложений. Предложен метод для более точного определения прав доступа с учетом выравнивания ответственности и RBAC.
