Использование этого названия может быть несколько преувеличенным, ведь когда вы видите слово «архитектура», многие люди могут подумать о больших проектах, включающих распределенную систему, высокую степень параллелизма и другие высокоуровневые вещи.
Некоторое время назад я написал два шаблона системы фонового управления с помощью vue и react соответственно.vue-quasar-adminа также3YAdmin. В обоих проектах реализован контроль разрешений на основе RBAC. Поскольку моя работа связана с бэкенд-разработкой, относительно ясно, что разрешения контролируют основные функции, которые должна иметь система управления, и они могут быть универсальными. Я планирую написать статью о разделении фронтенда и бекенда системы управления, а также сделать сводку знаний, которая будет включать в себя знание vue, react, node, .net core и так далее.
термин описание
- Пользователь (субъект): субъект, инициировавший операцию.
- Объект (Object): относится к объектному объекту, на который нацелена операция, например к статье или комментарию.
- Разрешение: используется для обозначения операции с объектом, например, «добавление статьи».
- Код разрешения: код разрешения, например, «ARTICLE_ADD» используется для ссылки на разрешение «добавить статью».
Разрешения иногда также называют действиями или функциями. Например, «добавить статью» можно рассматривать как действие или функцию. Объекты также можно назвать ресурсами.
Общие модели разрешений
- ACL (список управления доступом)
- DAC (Discretionary Access Control) (дискретный контроль доступа)
- MAC (Mandatory Access Control) (обязательный контроль доступа)
- RBAC (управление доступом на основе ролей) (управление доступом на основе ролей)
- ABAC (Attribute-Based Access Control) (управление доступом на основе атрибутов)
ACL (список управления доступом)
ACL — это самый ранний и самый простой механизм управления доступом, представляющий собой список данных, используемых для описания отношений между пользователями и разрешениями. Его принцип очень прост: каждый ресурс оснащен списком, в котором фиксируется, какие пользователи могут выполнять CRUD и другие операции с этим ресурсом. При попытке доступа к этому ресурсу он сначала проверит, имеет ли текущий пользователь права доступа в этом списке, чтобы определить, может ли текущий пользователь выполнить соответствующую операцию.
Например, ACL файлового объекта: Алиса: чтение, запись; Боб: чтение, что означает, что Алиса может и читать, и записывать файл, а Боб может только читать.
Из-за простоты ACL он может осуществлять управление доступом практически без инфраструктуры. Но в то же время очевидны и его недостатки: из-за необходимости ведения большого количества списков прав доступа ACL имеет явные недостатки в производительности. Кроме того, для приложений с большим количеством пользователей и ресурсов управление ACL само по себе может стать очень тяжелой работой.
В первоначальном определении ACL пользователи напрямую связаны с разрешениями, а данные сохраняют взаимосвязь между пользователями и разрешениями. Если разрешения двух пользователей одинаковы, то связь между двумя пользователями и разрешениями необходимо хранить отдельно, что также является дефектом ACL, упомянутым выше. Для решения этих проблем в структуру ACL внесено улучшение: пользователи с одинаковыми разрешениями помещаются в одну группу, и группа привязывается к разрешениям, а пользователь больше не привязывается напрямую к разрешения. И появившийся позже RBAC (управление доступом на основе ролей), роли и группы — схожие понятия, роли напрямую связаны с разрешениями, а пользователи — с ролями.
Поэтому обычно говорят, что ACL больше не является моделью контроля разрешений, напрямую связанной с разрешениями пользователей, его можно рассматривать как простой список контроля доступа. В списке могут храниться отношения между пользователями и разрешениями, или отношения между группами пользователей и разрешениями, или отношения между ролями и разрешениями, или даже отношения между отделами, должностями и так далее.
ACL — это бизнес-правила в системе разрешений. Модели разрешений, такие как RBAC, требуют для работы ACL.ACL обслуживают такие модели разрешений, как RBAC.Правила разрешений в других системах контроля разрешений также называются ACL.
DAC (Discretionary Access Control) (дискретный контроль доступа)
Система идентифицирует пользователя, а затем определит, может ли пользователь выполнять действия от имени пользователя. Может ли пользователь определить, может ли пользователь выполнять действия в соответствии с информацией из списка управления разрешениями (ACL: список управления доступом) или информацией из ACL: Матрица контроля доступа или информация о предмете. Прочтите или измените. Пользователи, имеющие объектные привилегии, также могут назначать разрешения объекта другим пользователям, поэтому такое управление называется «дискреционным».
Поскольку пользователи могут независимо предоставлять свои разрешения другим пользователям, модель DAC может передавать разрешения произвольно, а пользователи могут косвенно получать разрешения на доступ, которых у них нет.Поэтому модель DAC имеет низкий уровень безопасности и не может обеспечить достаточную защиту данных в системе. .
DAC может напрямую использовать физическую модель ACL, разница в том, что в модели DAC пользователи могут назначать свои собственные разрешения другим пользователям (операция в программе состоит в том, чтобы отфильтровать список разрешений в соответствии с идентификатором пользователя и построить список для пользователей, которым будут назначены разрешения в соответствии со списком. новый список разрешений и сохранить)
DAC — это традиционная модель управления доступом UNIX, а также модель управления доступом файловой системы Windows.
В настройке прав доступа к файлам в Windows помимо пользователей есть группы. В чем разница между этой группой и ролью модели RABC, которую мы обсудим позже?
stackoverflow.com/questions/7…
Я не думаю, что нужно слишком четко разделять его, будь то группа или роль, это для лучшего управления и распределения прав, чтобы улучшить самую примитивную модель ACL. Если есть необходимость, можно назначить права даже на отдел, и на должность.
MAC (Mandatory Access Control) (обязательный контроль доступа)
MAC был создан, чтобы компенсировать проблему слишком децентрализованного управления полномочиями DAC. В дизайне MAC каждый объект имеет некоторые идентификаторы разрешений, и каждый пользователь также имеет некоторые идентификаторы разрешений, и то, может ли пользователь управлять объектом, зависит от отношения между идентификаторами разрешений обеих сторон.Это решение об ограничении обычно определяется системой. жесткий лимит. При доступе система сначала сравнивает уровень разрешений доступа пользователя с уровнем безопасности объекта ресурса, а затем решает, может ли пользователь получить доступ к объекту ресурса. Пользователи не могут изменять уровень безопасности себя и объектов ресурсов, только системный администратор или управляющая программа могут контролировать уровень объектов ресурсов и пользователей. Например, в фильмах и на телевидении мы часто видим, что, когда агент спрашивает о конфиденциальном файле, на экране появляется сообщение о том, что «требуется недоступный уровень допуска первого уровня».
MAC очень подходит для классифицированных агентств или других отраслей с сильным чувством иерархии, но не подходит для аналогичных систем бизнес-услуг, поскольку он недостаточно гибок.
MAC может продолжать использовать модель DAC, но пользователи должны быть разделены на уровни, такие как первый уровень, второй уровень и третий уровень. . . , ресурсы объекта также должны быть разделены, такие как секрет, секрет и совершенно секретно. Когда пользователь обращается к ресурсу, он оценивается в соответствии с уровнем пользователя и уровнем доступа к ресурсу. Например, пользователь первого уровня может получить доступ только к конфиденциальным файлам. Если доступ является наиболее конфиденциальным файлом, система отклонит его. Эта серия правил имеет приоритет над DAC.Если MAC и DAC смешаны, сначала необходимо проверить MAC, а затем DAC.
RBAC (управление доступом на основе ролей) (управление доступом на основе ролей)
В механизме управления доступом ACL отношения между пользователями и функциями поддерживаются напрямую, и эта серия отношений представляет собой список разрешений. Когда многие пользователи имеют одинаковые функциональные полномочия, необходимо выполнять утомительные операции по связыванию. RBAC вводит концепцию ролей между пользователями и разрешениями. Пользователи и роли связаны, а список разрешений поддерживает взаимосвязь между ролями и функциями.
RBAC в настоящее время является самой популярной моделью управления доступом. Когда некоторые пользователи имеют одинаковые привилегии, вы можете просто создать роль для этих пользователей, соответствующую функцию, связанную с этой ролью, чтобы создать список разрешений ролей. Когда новые пользователи нуждаются в тех же правах, что и связанный с этой ролью пользователь. А при проверке или подтверждении полномочий пользователя полномочия запрашивать список ролей, к которым принадлежит пользователь.
Конечно, RBAC не идеален, например, если вы хотите установить определенное функциональное разрешение для пользователя, вам может потребоваться создать отдельную роль для этого функционального разрешения, а затем связать конкретного пользователя с этой ролью. Если вы хотите удалить определенные функциональные права пользователя, вам может потребоваться сбросить функциональные права роли, удалить определенные функциональные права из текущей роли, создать новую роль и связать определенные функциональные права, а затем добавить новую роль. роль связана с соответствующим пользователем (вы также можете напрямую проверить работающего пользователя в программе конкретной функции)
Вот более распространенное неправильное использование RBAC: это прямое использование ролей для оценки разрешений. Например, только роль А может удалять статьи.
function delPost(postId){
if(!isRole('A')){
return false;
}
}
Если вам нужна роль B, вы также можете удалить статью. Затем вам нужно изменить код
function delPost(postId){
if(!isRole('A')&&!isRole('B')){
return false;
}
}
Правильный способ — добавить функцию «удалить статью» и связать эту функцию с соответствующей ролью. Суждение основано на функции, а не на роли.
function delPost(postId){
if(!hasPermission('POST_DEL')){
return false;
}
}
В ответ на требование о том, что «только роль А может выполнять операцию удаления», свяжите эту функцию удаления с ролью А, а затем добавьте пользователей, которым требуется разрешение на эту операцию, в роль А. Если другим ролям также требуется это разрешение на операцию, вы можете связать функцию с соответствующей ролью без изменения кода.
На основе ядра RBAC также могут быть сделаны соответствующие расширения, такие как наследование ролей, группирование ролей и т. д. Все эти расширения в определенной степени упрощают управление правами.
ABAC (Attribute-Based Access Control) (управление доступом на основе атрибутов)
Хотя RBAC в настоящее время является наиболее распространенной моделью контроля разрешений. Но в некоторых случаях RBAC не может быть удовлетворен и не может быть реализован. Например, продавец 1 и продавец 2 принадлежат к ролям продавцов и оба имеют права на просмотр заказов клиентов. Когда есть спрос, продавец 1 может просматривать только заказы клиентов в районе Пекина, а продавец 2 может просматривать только заказы клиентов в Шанхае. Этого нельзя достичь, используя только RBAC. С помощью RBAC можно создавать роли в разных регионах, а затем фильтровать данные в соответствии с ролями в программе.Недостатки этого подхода также упоминались ранее, и код может нуждаться в модификации каждый раз, когда меняются требования.
В приведенном выше примере с продавцом, просматривающим заказ, регион является атрибутом заказа, и требование состоит в том, чтобы контролировать управление разрешениями области запроса заказа на основе атрибута этого региона. Этот метод управления доступом называется ABAC (Attribute-Based Access Control) (управление доступом на основе атрибутов), который некоторые люди также называют будущим проектирования систем доступа.
В отличие от обычного способа каким-либо образом связывать пользователей с разрешениями, ABAC выносит решение об авторизации, динамически вычисляя, удовлетворяет ли один или группа атрибутов определенному условию (можно написать простую логику). Атрибуты обычно делятся на четыре категории: атрибуты пользователя (например, возраст пользователя), атрибуты среды (например, текущее время), атрибуты операции (например, чтение) и атрибуты объекта (например, статьи, также известные как атрибуты ресурса), поэтому Теоретически это может быть реализовано очень гибкое управление разрешениями, которое может удовлетворить практически все типы потребностей.
Например, правило: «Разрешить всем классным руководителям свободно входить и выходить из школьных ворот в часы занятий», где «классный руководитель» — атрибут роли пользователя, «время занятий» — атрибут среды, «вход и выход» — операционный атрибут, а "ворота школы" - свойства объекта.
ABAC очень гибкий, но очень сложный в реализации. Это включает в себя динамическое выполнение логики, динамическую фильтрацию данных и т. д., а точнее, динамическое объединение операторов SQL (использование ORM — это динамическая сборка операторов запроса, соответствующих ORM).
Если вам интересно, вы можете поискать ABAC на Github, чтобы посмотреть, есть ли готовые решения на разных языках. Вот один из способов, которым я научился это делать:
Так же пример продавца, просматривающего заказ.На основе RBAC расширяется правило сущности, а заказ является сущностью, то есть для заказа задается ряд правил. Формат хранения правил может быть json или xml, или даже операторами Sql, которые можно анализировать. Например, это правило в Пекине:
{
"regionId":1
}
Район Шанхая:
{
"regionId":3
}
regionIdЭто идентификатор соответствующей области в системе, а также поле заказа или таблицы, связанной с заказом.
При сохранении этого правила требуются содержимое правила (то есть json выше) и сущность правила (то есть заказ, указывающий, что правило предназначено для заказа). Можно также добавить, что это правило применимо к одному или нескольким добавлениям, удалениям, пересмотрам и проверкам.
Создайте правила сущности и свяжите правила с ролями, то есть свяжите правила зоны Пекин с ролями зоны Пекин, а правила зоны Шанхай свяжите с ролями зоны Шанхай.
Когда серверная часть выполняет проверку разрешений, она все равно проверяется в соответствии с методом управления модели RBAC (есть ли у него разрешение на просмотр заказа), а затем в соответствии с текущим объектом операции (то есть сущностью), извлекаются правила соответствующего объекта, связанного с ролью, к которой принадлежит пользователь. Затем проанализируйте правила и динамически соедините операторы Sql или ORM.
Когда нет региональных ограничений (или не настроены правила), Sql может быть
select userId,orderNo,createdDate from T_Order
Правила настроены, после парсинга и склейки может быть
select userId,orderNo,createdDate from T_Order where regionId=1
Вот динамический контроль разрешений, реализованный для этого атрибута региона. В реальном процессе разработки есть много вещей, которые нужно контролировать, проверить контроль поля и контроль диапазона данных. Чтобы соответствовать этим сложным элементам управления, необходимо сформулировать полный набор правил и написать соответствующие программы разбора правил. Например, по правилам конфигурации финальным анализом могут быть различные операторы Sql: , =, как, в, не в и т.д.
Видно, насколько сложно по-настоящему реализовать ABAC. Каждый раз, когда правила анализируются, производительность программы также снижается, даже если используется кеш, вероятность попадания очень мала, потому что многие факторы являются динамическими.
Поэтому, если сценариев, требующих оценки разрешений на основе атрибутов, не так много, рекомендуется использовать RBAC, и тогда вынесение суждений в программе сэкономит время и усилия.
Суммировать
Раннее определение ACL — это механизм управления разрешениями. Этот механизм напрямую поддерживает отношения между пользователями и функциями. Функции — это некоторые операции, определенные для объектов, такие как добавление, удаление, изменение и проверка. Список отношений между пользователями и функциями также называется списком разрешений или списком управления доступом.Теперь ACL обычно ссылается на этот список разрешений или список управления доступом, но отношения, поддерживаемые в нем, не обязательно являются отношениями между пользователями и функциями, которые поддерживаются в RBAC — это отношения между ролями и функциями.
RBAC добавляет в ACL концепцию ролей.Отношения между пользователями и функциями больше не поддерживаются в списке разрешений или списке контроля доступа, а сохраняются отношения между ролями и функциями. ACL можно смешивать с RBAC, чтобы устанавливать разрешения для ролей или непосредственно для пользователей, что более гибко. С помощью идеи ролей можно устанавливать разрешения для групп пользователей, организаций, должностей и т. д., чтобы лучше управлять разрешениями, то есть передавать настройки разрешений от одного человека к определенному типу комбинации.
ABAC очень гибок и очень сложен в реализации.