Предисловие

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

В крупномасштабной системе совместной работы нескольких человек эффективно управлять правами доступа различных пользователей и обеспечивать безопасность и стабильность системы — это задача, с которой должен столкнуться каждый разработчик. Для решения этой проблемы в отрасли предложена широко используемая модель управления доступом — Role-Based Access Control (RBAC).

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

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

один、что такое RBAC Шерстяная ткань?

RBAC Прямо сейчасУправление доступом на основе ролей（Role-Based Access Control）。Этоодинсвоего рода пропускРоли связаны с разрешениями, а роли также связаны с пользователями.из Метод авторизации。

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

Основные понятия RBAC:

1. Роль（Role）：Рольдаодин Группа Разрешенияизсобирать,Представляет группу пользователей, которые выполняют определенные задачи или обязанности в организации. Например,«Администратор», «Редактор», «Гость» и т. д.
2. Пользователь: фактический пользователь в системе.,Им назначена одна или несколько ролей.,Тем самым получив соответствующее из Разрешения.
3. Разрешения (Разрешение): Разрешения определяет, что пользователи могут выполнять операции с системными ресурсами, такие как «чтение», «запись» или «удаление» и т. д.
4. Сеанс: после того, как пользователь проходит аутентификацию, между пользователем и системой устанавливается соединение.,Во время сеанса будет активирован пользователь из роли и Разрешения.

Преимущества RBAC:

1. Упрощенное управление Разрешениями: назначайте Разрешения через роли.,Администраторам не нужно настраивать Разрешения индивидуально для каждого пользователя.,Уменьшает сложность управления.
2. Повышение безопасности: RBAC может реализовать принцип минимального разрешения,То есть предоставить пользователю только минимальный объем информации, необходимый для выполнения задачи.,Тем самым снижая потенциальные риски безопасности.
3. Поддержка гибкого расширения: по мере роста и изменений организации.,Новые персонажи и Разрешения могут быть легко добавлены.,Для удовлетворения меняющихся потребностей.
4. Повышенное соответствие: RBAC помогает соблюдать многие правила и требования соответствия, такие как GDPR, HIPAA и т. д.

Ниже приведен пример кода простой модели RBAC, написанной на Python:

class User:  
    def __init__(self, name):  
        self.name = name  
        self.roles = []  
  
    def add_role(self, role):  
        self.roles.append(role)  
  
    def has_role(self, role):  
        return role in self.roles  
  
class Role:  
    def __init__(self, name):  
        self.name = name  
        self.permissions = []  
  
    def add_permission(self, permission):  
        self.permissions.append(permission)  
  
    def has_permission(self, permission):  
        return permission in self.permissions  
  
class RBAC:  
    def __init__(self):  
        self.users = {}  
        self.roles = {}  
  
    def register_user(self, user):  
        self.users[user.name] = user  
  
    def register_role(self, role):  
        self.roles[role.name] = role  
  
    def assign_role(self, user, role):  
        user.add_role(role)  
        role.add_user(user)  
  
    def check_permission(self, user, permission):  
        for role in user.roles:  
            if role.has_permission(permission):  
                return True  
        return False

В этом примере мы определяем три класса: Пользователь, Роль и RBAC.

• Класс User представляет пользователя и имеет методы для добавления и проверки ролей.
• Класс Role представляет роль и имеет методы для добавления и проверки Разрешенияиз.
• Класс RBAC является основным классом Разрешения Менеджментиз.,При зарегистрированном пользователе, Зарегистрировать роль、Назначьте роли и проверьте методы Разрешенияиз.

В методе check_permission мы перебираем все роли пользователя, проверяем, имеет ли каждая роль необходимое разрешение, и возвращаем True, если найдена роль, имеющая такое разрешение.

Если ни одна роль не имеет такого разрешения, возвращается False.

2. Состав RBAC

Внутри RBACМодель,Есть 3 компонента Базы,Они есть：Пользователи, роли и разрешения.

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

• Пользователь: каждый пользователь идентифицируется уникальным UID и получает разные роли.
• Роль: разные роли имеют разные разрешения.
• Разрешение: права доступа
• Сопоставление ролей пользователя: взаимосвязь между пользователями и ролями.
• Сопоставление ролей и разрешений: сопоставление между ролями и разрешениями.

Связь между ними показана на рисунке ниже:

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

3.1 Преимущества：

• Упрощает взаимоотношения между пользователями и Разрешенияиз.
• Легко расширять и поддерживать

3.2 Недостатки:

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

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

4.1 RBAC0

RBAC0,Это самый простой и оригинальный способ реализации.,Также другоеRBACМодельизБаза。

В этой модели,Между пользователями и ролями может быть связь «многие ко многим».,То есть пользователь может иметь разные роли в разных сценариях.,Например：Менеджеры проектов также могутда Группа Можно и дольшеда Архитектор。в то же времяКаждая роль имеет как минимум одно разрешение。этотдобрый Модель Вниз,Пользователи и разрешения разделены и независимы.Ну давай же,делать Разрешенияиз Сертификация авторизацииболее гибкий。

4.2 RBAC1

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

Ролевая комната изотношения наследстваможно разделить наодин Общийотношения наследства和受限отношения наследства。один Общийотношения наследство требует только ролевых отношений Наследства — это отношения абсолютного частичного порядка, которые позволяют выполнять множество функций между ролями. И ограниченные отношения наследства далее требует роли отношений наследствадаодиндревовидная структура,Осознайте единое наблюдение между ролями.

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

4.3 RBAC2

RBAC2,На основе RBAC0Моделиз База,выполненныйРолевой контроль доступа。

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

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

• Взаимоисключающие роли:такой жеодин Пользователей можно назначать толькоодин Группа Взаимоисключающие Максимум одна роль в наборе поддерживает принцип разделения обязанностей. Взаимоисключающие Роли относятся к двум ролям, которые ограничивают друг друга и Разрешения. Для этого типа роли пользователю может быть назначена только одна из ролей в определенном действии. Невозможно. получить двух персонажей одновременноиз Право использования.Частоизпример：в аудиторской деятельностисередина,одининдивидуальный Рольне могув то же времяназначен бухгалтером Рольи аудиторы Роль。
• Ограничения мощности:одининдивидуальный Рольназначенныйиз Ограниченное количество пользователей；один Пользователи могут иметьиз Роль Ограниченное количество；такой же Образецодининдивидуальный Рольпереписыватьсяиздоступ Разрешения Количество также должно быть ограничено.,Контролировать расширенные разрешения распространения в системе. Например, Компания из Leaders Limited из;
• Обязательные роли:может быть выделено Рольпредоставляется пользователю только в том случае, если у этого пользователя естьда Другойодин Рольизчлен；переписыватьсяизможет быть выделенодоступ Разрешения Давать Роль,Доступ к Разрешению возможен только в том случае, если у персонажа уже есть другое. Относится к желанию подняться выше из Разрешения.,Чтобы сначала иметь более низкий уровень из Разрешения. Все как в нашей жизни,Президент страныда От заместителя председателясерединавыборыизодин Образец。
• Взаимное исключение во время выполнения:Например,Разрешить одному пользователю иметь две роли членства,Однако эти две роли не могут быть активированы одновременно во время работы.

5. Резюме

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

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

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

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