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

Введение#

Управление доступом является критически важным аспектом безопасности в любой системе. Оно гарантирует, что только авторизованные пользователи могут получить доступ к ресурсам и выполнять действия. Ролевой доступ (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 более подходящий для систем, где политики управления доступом должны быть динамичными, контекстуально осведомленными и с тонкой градацией.

Примеры#

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

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

Случай 1#

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

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

Модель 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#

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

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

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

Модель 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 более подходит для систем, где политики управления доступом должны быть динамичными, контекстуально осведомленными и с тонкой градацией. На практике организации могут выбирать использовать комбинацию обеих моделей для достижения желаемого уровня управления доступом.