Русский

авторизация
rbac
abac

Ролевой доступ (RBAC) и атрибутивный доступ (ABAC): модели управления доступом, которые вы должны знать

Ролевой доступ (RBAC) и атрибутивный доступ (ABAC) - это две из самых популярных моделей управления доступом. В этом посте мы предоставим краткий обзор обеих моделей и обсудим их различия.

Simeng

Developer

7/3/2024

Хватит тратить недели на аутентификацию пользователей

Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.

Начать

Введение

Управление доступом является критически важным аспектом безопасности в любой системе. Оно гарантирует, что только авторизованные пользователи могут получить доступ к ресурсам и выполнять действия. Ролевой доступ (RBAC) и атрибутивный доступ (ABAC) - это две из самых популярных моделей управления доступом, используемых в современных системах. Обе модели широко распространены и могут эффективно использоваться для применения политик управления доступом. Но что они собой представляют и в чем их различия?

Ролевой доступ (RBAC)

Ролевой доступ (RBAC) впервые был введен в начале 1990-х годов. Формализация модели приписывается Дэвиду Ферраиоло и Рику Куну в статье, опубликованной в 1992 году. С тех пор RBAC стал одной из самых широко используемых моделей управления доступом в индустрии.

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

Ключевые компоненты RBAC

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

Варианты RBAC

Существуют несколько вариантов RBAC, которые расширяют базовую модель для удовлетворения более сложных требований к управлению доступом:

RBAC0: Базовая модель, в которой пользователям назначаются роли, а ролям назначаются разрешения.
RBAC1: Добавляет концепцию иерархии ролей. Роли могут наследовать разрешения от других ролей. Также известен как иерархический RBAC.
RBAC2: Добавляет ограничения к ролям. Ограничения можно использовать для определения дополнительных условий, которые должны быть выполнены для назначения пользователю роли. Также известен как ограничивающий RBAC.
RBAC3: Объединяет особенности RBAC1 и RBAC2. Поддерживает как иерархии ролей, так и ограничения.

Для получения дополнительной информации о этих вариантах, обратитесь к RBAC models and their evolution.

Плюсы RBAC

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

Минусы RBAC

Жесткость: RBAC может быть жестким, когда речь идет об определении сложных политик управления доступом. Он может не подходить для систем, где политики управления доступом должны быть более динамичными и контекстно-зависимыми.
Гранулярность: RBAC может не иметь необходимой гранулярности для тонкой настройки доступа. Политики управления доступом привязаны к четко определенным ролям, и может потребоваться дополнительное усилие для определения разрешений на более детальном уровне.
Взрыв ролей: В крупных организациях со сложными структурами разрешений количество ролей может экспоненциально увеличиться, что приводит к взрыву ролей. Управление большим количеством ролей может быть сложным.

Атрибутивный доступ (ABAC)

В конце 2000-х годов, когда системы становились более сложными и динамичными, все больше организаций начали принимать атрибутивный доступ (ABAC) как альтернативу RBAC. Значимым шагом в формализации ABAC является публикация NIST Special Publication 800-162 в 2014 году.

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

Ключевые компоненты ABAC

Субъект: Субъект - это сущность, которая запрашивает доступ к ресурсу. Это может быть пользователь, устройство, приложение или любая другая сущность, которой необходимо получить доступ к ресурсам.
Ресурс: Как и в RBAC, ресурс - это сущность, к которой субъект может получить доступ. Ресурсы могут быть файлами, базами данных, API или любой другой системной сущностью.
Действие: Действие - это конкретная операция, которую субъект может выполнить над ресурсом. Это может быть создание, чтение, обновление, удаление или любое другое действие, которое нужно контролировать.
Окружение: Окружение - это контекст, в котором делается запрос на доступ. Оно может включать такие атрибуты, как время суток, местоположение, сеть, устройство и т. д.
Атрибут: Атрибут - это характеристика субъекта, ресурса, действия или окружения. Атрибутами могут быть, например, роли пользователя, отдел, местоположение, IP-адрес, тип устройства и т. д.
Политика: Политика - это правило, которое определяет условия, при которых доступ разрешается или запрещается. Политики определяются на основе атрибутов.

Плюсы ABAC

Гибкость: ABAC может удовлетворить сложные политики управления доступом, которые основаны на нескольких атрибутах. Это позволяет организациям определять детальные политики, которые могут адаптироваться к различным контекстам и условиям.
Динамичность: Политики ABAC могут быть динамичными и осведомленными о контексте. Решения о доступе могут приниматься на основе атрибутов в реальном времени, таких как местоположение, время суток, тип устройства и т. д.
Гранулярность: ABAC обеспечивает подробное управление доступом, позволяя организациям определять политики на основе нескольких атрибутов. В отличие от определения ролей и разрешений, политики, основанные на атрибутах, могут быть более детализированными.

Минусы ABAC

Сложность: ABAC может быть более сложным для реализации и управления по сравнению с RBAC. Определение атрибутов и политик может требовать больше усилий и экспертизы. В отличие от RBAC, где роли и разрешения четко структурированы, атрибуты могут быть более динамичными, равно как и политики. Управление большим количеством атрибутов и политик в сложной системе может быть сложным. Часто требуется центральная система оценки политик для их выполнения.
Производительность: Оценка атрибутов может влиять на производительность, особенно в средах реального времени. Политики, основанные на множестве атрибутов и условий реального времени, могут вводить задержки в принимаемых решениях о доступе.

Таблица сравнения

Функция	RBAC	ABAC
Политика управления доступом	Основана на ролях	Основана на атрибутах
Гранулярность	Грубая градация	Тонкая градация
Гибкость	Ограниченная	Высоко гибкая
Сложность	Более простая	Более сложная
Влияние на производительность	Минимальное	Может быть значительным
Управление доступом	Управление ролями	Управление политиками
Лучше всего подходит	Четко определенная структура разрешений	Динамичное и контекстуально-осведомленное управление доступом

Из таблицы сравнения ясно, что RBAC лучше всего подходит для систем с четко определенной структурой разрешений и где политики управления доступом относительно статичны. С другой стороны, ABAC более подходящий для систем, где политики управления доступом должны быть динамичными, контекстуально осведомленными и с тонкой градацией.

Примеры

Сценарий: Система больницы, которая должна управлять доступом к медицинским записям пациентов для различных сотрудников.

Сотрудники: Врачи, медсестры, администраторы
Ресурсы: Медицинские записи пациентов
Разрешения: Чтение, запись, удаление

Случай 1

Политики управления доступом относительно просты:

Врачи могут читать и записывать медицинские записи.
Медсестры могут читать медицинские записи.
Администраторы могут читать, писать и удалять медицинские записи.

Модель RBAC

В этом случае RBAC прост и эффективен. Мы можем определить роли для врачей, медсестер и администраторов и назначить соответствующие разрешения каждой роли.

Оценка управления доступом проста:

GET /patient-records: user.permission.includes('чтение')
POST /patient-records: user.permission.includes('запись')
DELETE /patient-records: user.permission.includes('удаление')

Модель ABAC

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

Атрибуты:

user.role: врач, медсестра, администратор
resource.name: медицинская запись
действие: чтение, запись, удаление

Политики:

Политика 1: Разрешить доступ на чтение на основе user.role и resource.name
- субъект: Пользователь с ролью врач, медсестра, администратор
- ресурс: Ресурс с именем медицинская запись
- действие: чтение
- эффект: разрешить
- основание: "Разрешить доступ на чтение к медицинским записям для всех ролей"
Политика 2: Доступ на редактирование для врачей и администраторов
- субъект: Пользователь с ролью врач, администратор
- ресурс: Ресурс с именем медицинская запись
- действие: запись
- эффект: разрешить
- основание: "Разрешить доступ на запись к медицинским записям для врачей и администраторов"
Политика 3: Доступ на удаление для администраторов
- субъект: Пользователь с ролью администратор
- ресурс: Ресурс с именем медицинская запись
- действие: удаление
- эффект: разрешить
- основание: "Разрешить доступ на удаление к медицинским записям для администраторов"

Для каждого запроса на чтение/запись/удаление движок политик оценивает все релевантные политики на основе атрибутов и принимает решение о доступе.

Сравнение

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

В модели RBAC процесс оценки управления доступом к ресурсу медицинских записей останется простым и понятным, будет ли у пользователя разрешение чтение, запись, или удаление;
ABAC, с другой стороны, должен вовлечь дополнительные атрибуты, такие как идентификатор отдела и идентификатор врача. Что, если IoT-устройство, необходимое для доступа к медицинским записям? Потребуется новый атрибут идентификатор устройства, чтобы быть включенным в оценку политики. А как насчет временного разрешения чтение для стажера?

В заключение, RBAC - лучшее решение. RBAC прост и эффективен для систем с четко определенными структурами разрешений и где политики управления доступом статичны.

Случай 2

Та же система больницы, теперь давайте введем новую роль пациент и новый атрибут идентификатор пациента.

Политики управления доступом таковы:

Врачи могут читать и записывать медицинские записи.
Медсестры могут читать медицинские записи.
Администраторы могут читать, писать и удалять медицинские записи.
Пациенты могут читать свои собственные записи.

Модель RBAC

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

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

GET /patient-records: user.permission.includes('чтение')
POST /patient-records: user.permission.includes('запись')
DELETE /patient-records: user.permission.includes('удаление')
GET /patient-records/:patient-id: user.permission.includes('чтение собственного') && user.id === patient-id || user.permission.includes('чтение')

Модель ABAC

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

Атрибуты:

user.role: врач, медсестра, администратор, пациент
user.id: идентификатор пациента
resource.name: медицинская запись
resource.patient-id: идентификатор пациента
действие: чтение, запись, удаление

Политики:

Политика 1: Разрешить доступ на чтение ко всем медицинским записям
- субъект: Пользователь с ролью врач, медсестра, администратор
- ресурс: Ресурс с именем медицинская запись
- действие: чтение
- эффект: разрешить
- основание: "Разрешить доступ на чтение к медицинским записям для всех сотрудников и пациентов"
Политика 2: Разрешить доступ на запись ко всем медицинским записям для врачей и администраторов
- субъект: Пользователь с ролью врач, администратор
- ресурс: Ресурс с именем медицинская запись
- действие: запись
- эффект: разрешить
- основание: "Разрешить доступ на запись к медицинским записям для врачей и администраторов"
Политика 3: Разрешить доступ на удаление ко всем медицинским записям для администраторов
- субъект: Пользователь с ролью администратор
- ресурс: Ресурс с именем медицинская запись
- действие: удаление
- эффект: разрешить
- основание: "Разрешить доступ на удаление к медицинским записям для администраторов"
Политика 4: Разрешить доступ на чтение к своим собственным медицинским записям
- субъект: Пользователь с ролью пациент
- ресурс: Ресурс с именем медицинская запись
- действие: чтение
- условие: user.id === resource.patient-id
- эффект: разрешить
- основание: "Разрешить доступ на чтение к своим собственным медицинским записям"

Сравнение

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

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

В этом случае ABAC может быть более подходящим. ABAC более подходит для систем, где политики управления доступом должны быть динамичными, контекстуально осведомленными и с тонкой градацией.

Заключение

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

Попробуйте Logto Cloud бесплатно

Введение#

Ролевой доступ (RBAC)#

Ключевые компоненты RBAC#

Варианты RBAC#

Плюсы RBAC#

Минусы RBAC#

Атрибутивный доступ (ABAC)#

Ключевые компоненты ABAC#

Плюсы ABAC#

Минусы ABAC#

Таблица сравнения#

Примеры#

Случай 1#

Модель RBAC#

Модель ABAC#

Сравнение#

Случай 2#

Модель RBAC#

Модель ABAC#

Сравнение#

Заключение#

Введение#

Ролевой доступ (RBAC)#

Ключевые компоненты RBAC#

Варианты RBAC#

Плюсы RBAC#

Минусы RBAC#

Атрибутивный доступ (ABAC)#

Ключевые компоненты ABAC#

Плюсы ABAC#

Минусы ABAC#

Таблица сравнения#

Примеры#

Случай 1#

Модель RBAC#

Модель ABAC#

Сравнение#

Случай 2#

Модель RBAC#

Модель ABAC#

Сравнение#

Заключение#

Введение

Ролевой доступ (RBAC)

Ключевые компоненты RBAC

Варианты RBAC

Плюсы RBAC

Минусы RBAC

Атрибутивный доступ (ABAC)

Ключевые компоненты ABAC

Плюсы ABAC

Минусы ABAC

Таблица сравнения

Примеры

Случай 1

Модель RBAC

Модель ABAC

Сравнение

Случай 2

Модель RBAC

Модель ABAC

Сравнение

Заключение

Введение

Ролевой доступ (RBAC)

Ключевые компоненты RBAC

Варианты RBAC

Плюсы RBAC

Минусы RBAC

Атрибутивный доступ (ABAC)

Ключевые компоненты ABAC

Плюсы ABAC

Минусы ABAC

Таблица сравнения

Примеры

Случай 1

Модель RBAC

Модель ABAC

Сравнение

Случай 2

Модель RBAC

Модель ABAC

Сравнение

Заключение