Контроль доступа (AC)
То есть Контроль доступа, который вводится одним предложением: «Кто (Кто) что (Как) может делать к какому ресурсу (Что)»
Контроль разрешений является частью конструкции системы и является общим почти для всех систем ToB. Особенно на некоторых традиционных предприятиях со многими уровнями контроль разрешений очень важен.
что такое ресурс
Ресурс — это очень широкое понятие, любая сущность, которую необходимо контролировать, может быть определена как ресурс, например: страница, ссылка, интерфейс, данные.
что за операция
Читайте и пишите, или подробнее: CRUD
что такое разрешение
Операция над определенным ресурсом называется разрешением
Зачем говорить о такой простой вещи?
Разве это не просто шутка?
Простые проблемы станут сложными проблемами по мере увеличения масштаба Вышеупомянутое является просто внеклассными упражнениями, а реальный мир выглядит так:
Предположим, компания имеет масштаб 500 человек, а серверных систем около 10. Давайте временно посчитаем около 500 страниц (не считая прав на чтение и запись на страницах), пользователей этих страниц оцениваем в 200 человек. , примерно разделенных на 60 видов работ, то фактические отношения примерно такие, как показано на следующем рисунке:
Здесь на самом деле не очень сложно, не правда ли, это просто куча таблиц отношений, которые всегда можно расправить. Тем не менее, вышеуказанная структура не остается неизменной: движение персонала, смена должностей, добавление функций, корректировка организационной структуры и т. д. будут выглядеть следующим образом.
Теперь, когда мы рассмотрели сложности, давайте поговорим о некоторых теориях.
Теоретическая модель RBAC
По сути, когда дело доходит до контроля разрешений, первая реакция большинства людей — это следующая модель.
【Роль пользователя】-Исправлена проблема с кем
[Роль - Разрешения] - Решена проблема что и как
Это единственное решение?
Более простая модель: контроль доступа на основе источника
То есть: у кого какие полномочия
Управление доступом на основе ролей
Суть в том, чтобы добавить средний слой [role] для разделения пользователей и разрешений. Суть роли — это набор разрешений
Семейство моделей RBAC 96 в настоящее время является наиболее распространенной теоретической моделью, предложенной Лабораторией технологий информационной безопасности (LIST) Университета Джорджа Мейсона в США.
Наиболее цитируемые статьи по RBAC в Google Scholar:Создайте так ваше тело.gov/CSR C/Media/…
Другие модели, такие как: ARBAC 97 (Administration RBAC), NIST RBAC (стандартизированная модель RBAC NIST в США) и т. д.
1. Поговорим о семействе моделей RBAC 96.
Вводим по одному:
2. RBAC 0 — самая базовая модель RBAC.
Соответствующее отношение между [Пользователь - Роль] и [Роль - Разрешение] может быть 1:N или 1:1, в зависимости от конкретной ситуации.
3. RBAC 1 — модель RBAC с ограниченными ролями
RBAC1 ограничивает роли, расширяет отношения наследования между ролями и решает проблему наследования разрешений, вызванную иерархическими отношениями.
Например, вся фронтенд-разработка, подразделяемая на «бэкенд-разработку фронтенда» и «фронтенд-разработку H5», может основываться на этой модели.
Между ролями существует только отношение наследования.
4. RBAC 2 — модель RBAC на основе RBAC0, добавляющая роли и разрешения.
Разделяется на статическое разделение обязанностей SSD (статическое разделение обязанностей) и динамическое разделение обязанностей DSD (динамическое разделение обязанностей).
Статическое разделение обязанностей SSD
-
Ограничение взаимоисключающих ролей: между ролями существует взаимоисключающая связь, и пользователи могут выбрать только одну из них;
-
Ограничение кардинальности: существует верхний предел количества ролей, которые имеет пользователь, и количество разрешений, соответствующих роли, также ограничено;
-
Предварительные ограничения: между ролями существует предварительная зависимость, и пользователи должны сначала получить роль низкого уровня, прежде чем они смогут получить роль высокого уровня;
Динамическое разделение обязанностей DSD
- Если у пользователя есть две или более ролей, только одна роль может действовать в один и тот же период времени.
Ограничения несколько абстрактны, несколько примеров 🌰
-
Кассир и бухгалтер — это две взаимоисключающие роли, которые не могут выполняться одним и тем же лицом одновременно (взаимоисключающие роли обычно возникают из-за сговора или надзора между двумя разрешениями).
-
Некоторые роли в системе имеют различия высокого и низкого уровня, например, комиссар и менеджер.
5. RBAC 3 — самая полная модель RBAC
RBAC 3 = RBAC 1 + RBAC 2
Реализация
Техническая реализация
Как управлять передним концом
Проще говоря, если элементы управления суждением о состоянии отображаются и скрываются
<el-button type="primary" v-if="hasPermission" @click="awesomeFunc">
一个牛逼的按钮
</el-button>
Что именно можно контролировать
-
Создание меню на основе доступного контента
-
Проверяйте разрешения перед переходом маршрута
-
Табличные данные отображают авторитетность суждения
-
Неавторизованные страницы, напоминания о сообщениях
-
. . .
Как контролировать бэкенд
-
Определить, есть ли у текущего пользователя разрешение интерфейса
-
Запись запросов пользовательского интерфейса (журнал доступа)
общий дизайн персонажей
Роль в модели RBAC является абстракцией, и в реальный проект могут быть добавлены другие промежуточные уровни. Какая модель основана на RBAC, зависит только от квалификации реальных потребностей бизнеса.
1. Пользователь - Роль - Разрешение
То есть самый базовый случай RBAC0, который подходит для большинства сценариев
2. Пользователь - Должность - Роль - Разрешение
Позиция определяет роль, и пользователь имеет соответствующую роль в любой позиции, в которой он находится.
Например: я редактор электронных книг членской линии, и, естественно, моя роль — редактор электронных книг, и я могу получить доступ ко всем страницам, связанным с электронными книгами, в CMS. Через какое-то время я стал одновременно отвечать за редактора комплекта, так что было бы неплохо добавить роль редактора комплекта
3. Другое
Также можно добавить [Обязанности] [Организация/Отдел] и т.д.