Ручной набор системы разрешений RBAC

Источник статьи: «Анализ, проектирование и внедрение системы полномочий RBAC» | shuwoom.com

В настоящее время наиболее часто используемой моделью управления разрешениями является модель RBAC (управление доступом на основе ролей). В этой статье также в основном представлена ​​система управления разрешениями на основе RBAC. Я расскажу, что такое RBAC и как разработать RBAC.

1. Что такое RBAC

1. Обзор модели RBAC

Модель RBAC (Role-Based Access Control: управление доступом на основе ролей) — это новая модель, разработанная в 1990-х годах, но на самом деле эта идея была предложена в период многопользовательских вычислений в 1970-х, вплоть до середины и В конце 1990-х RBAC не привлекал к себе внимания в исследовательском сообществе, и последовательно предлагались многие типы моделей RBAC. Среди них наиболее репрезентативной и общепризнанной является модель RBAC96, предложенная Лабораторией технологий информационной безопасности (LIST) Университета Джорджа Мейсона в США.

RBAC считает, что процесс авторизации полномочий можно абстрактно резюмировать следующим образом: может ли кто выполнять операции доступа к как к чему, и процесс решения, заключающийся в оценке того, истинно ли это логическое выражение, то есть преобразование проблемы полномочий в вопрос «что и как». Кто, что и как составляют тройку прав доступа Конкретные теории см. в документе RBAC96.

2. Состав RBAC

В модели RBAC есть три основных компонента: пользователи, роли и разрешения.

RBAC контролирует разрешение пользователя, определяя разрешение роли и предоставляя пользователю определенную роль.Он реализует логическое разделение пользователей и разрешений (отличное от модели ACL), что значительно облегчает управление разрешениями.

Прежде чем объяснять, позвольте мне представить некоторые существительные:

• Пользователь (пользователь): каждый пользователь имеет уникальный идентификатор UID и получает разные роли.

• Роль: разные роли имеют разные разрешения

• Разрешение: права доступа

• Сопоставление ролей пользователей: отношения сопоставления между пользователями и ролями.

• Сопоставление ролей и разрешений: сопоставление между ролями и разрешениями

Отношения между ними показаны на рисунке ниже:

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

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

3. Принципы безопасности, поддерживаемые RBAC

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

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

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

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

4. Преимущества и недостатки RBAC

(1) Преимущества:

• Упрощает отношения между пользователями и разрешениями

• Простота расширения и обслуживания

(2) Недостатки:

• Модель RBAC не предоставляет механизма управления порядком операций, что затрудняет адаптацию модели RBAC к системам, предъявляющим строгие требования к порядку операций.

5. Три модели RBAC

(1) RBAC0

RBAC0 — самая простая и примитивная реализация и основа других моделей RBAC.

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

（2）RBAC1

На основе модели RBAC0 вводится отношение наследования между ролями, то есть существует различие между верхними и нижними ролями по ролям.

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

Эта модель подходит для четкой иерархии между ролями и может группировать и стратифицировать роли.

（3）RBAC2

RBAC2, основанный на модели RBAC0, выполняет ролевой контроль доступа.

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

Модель имеет следующие ограничения:

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

• Ограничения кардинальности: количество пользователей, назначенных на роль, ограничено, количество ролей, которые может иметь пользователь, также должно быть ограничено, чтобы контролировать распределение расширенных прав в системе. Например, лидеры компании ограничены;

• Необходимые роли: Роль может быть назначена пользователю только в том случае, если этот пользователь уже является членом другой роли, соответственно право доступа может быть присвоено роли только в том случае, если эта роль уже имеет другой вид прав доступа. Это означает, что для того, чтобы получить более высокий авторитет, нужно сначала иметь более низкий уровень авторитета. Как и в нашей жизни, президент страны избирается из числа вице-президентов.

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

2. Как спроектировать RBAC

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

1. Функциональные модули RBAC

2. Процесс выполнения RBAC

3. Дизайн базы данных RBAC