Автор: Samuel Carter
Автор перевода: Зимцев П.П.
Источник: http://blog.identityautomation.com/rbac-vs-abac-access-control-models-iam-explained
На самом высоком уровне системы управления идентификацией обычно состоят из трех основных элементов: пользователей, систем / приложений и политик. Политики определяют, как пользователи взаимодействуют с различными системами и приложениями.
Большинство продуктов управления идентификацией и доступом (IAM) предоставляют различные методы для реализации политик управления доступом к организационным ресурсам, причем для описания этих методов используется различная терминология. Однако в конечном итоге все формы контроля доступа могут быть сопоставлены с одной из четырех классических моделей: дискреционное управление доступом (DAC), обязательное управление доступом (MAC), управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC).
Хотя этот пост посвящен моделям RBAC и ABAC, я хочу кратко описать первые два для полноты картины.
RBAC контролирует доступ на основе ролей, которые имеют пользователи в системе, и правил, определяющих, какой доступ разрешен для каких пользователей в данных ролях. Как правило, в современных решениях IAM Роль примерно эквивалентна Группе в системе каталогов и представляет собой просто логическую группу из одного или нескольких пользователей, которые имеют общие связи, такие как один и тот же отдел, класс, возраст, физическое местоположение или тип пользователя.
Например, с RBAC пользователь в положении клерка кредиторской задолженности автоматически добавляется в качестве члена (т.е. динамического членства) в роль AP, предоставляя ему или ей доступ к функциям AP в системе учета.
ABAC может управлять доступом на основе трех различных типов атрибутов: пользовательских атрибутов, атрибутов, связанных с приложением или системой, к которой осуществляется доступ, и текущих условий окружающей среды.
Примером ABAC может быть предоставление доступа к системе HR / Payroll только пользователям с типом = сотрудники и отделом = HR, и только в рабочее время в том же часовом поясе, что и компания.
ABAC не только самая гибкая и мощная из четырех моделей контроля доступа, но и самая сложная. На самом деле, технически ABAC способен поддерживать DAC, MAC и RBAC.
По своей сути ABAC обеспечивает детальное управление доступом, что позволяет использовать больше входных переменных в решении по управлению доступом. Любой доступный атрибут в каталоге может использоваться сам по себе или в сочетании с другим для определения правильного фильтра для управления доступом к ресурсу.
Теперь, когда мы лучше понимаем основные различия между двумя моделями, мы можем изучить лучшие практики, которые следует использовать и когда. В то время как RBAC и ABAC могут быть очень сложными предметами, вот четыре простых понятия, на которые вы можете ссылаться не только при запуске вашей реализации IAM, но и на постоянной основе по мере изменения вашей организации и потребностей:
Когда вы можете принимать решения по управлению доступом широкими штрихами, используйте RBAC. Например, предоставление всем учителям доступа к Google или всем подрядчикам доступа к электронной почте. Если вам нужно больше детализации, чем это или нужно принимать решения при определенных условиях, используйте ABAC. Например, предоставление учителям доступа к Google, если они находятся в школе X и преподают класс Y.
Общее практическое правило заключается в том, что вы должны пытаться использовать RBAC до ABAC, поскольку по своей сути элементы управления - это просто поиски или фильтры. Чем больше и сложнее поиск, тем больше вычислительной мощности и времени это занимает. И чем больше пользователей и приложений в организации, тем большее влияние на обработку окажут поиски / фильтры из-за увеличения пространства поиска.
Если вы создаете много очень сложных фильтров RBAC и / или ABAC, вы, вероятно, делаете что-то не так. Немного заблаговременного планирования может помочь вам структурировать данные каталога таким образом, чтобы уменьшить необходимость разработки сложных фильтров / запросов. Однако время от времени вам определенно придется проявить изобретательность, чтобы установить правильный уровень контроля доступа, но это должно быть исключением, а не правилом.
Вы всегда можете использовать RBAC и ABAC вместе в иерархическом подходе. Например, с помощью RBAC для управления тем, кто может видеть, какие модули, а затем с помощью ABAC для контроля доступа к тому, что они видят (или могут делать) внутри модуля. Это похоже на межсетевые экраны на основе WAN и LAN, где WAN выполняет грубую фильтрацию, а затем на основе LAN выполняет более точные проверки.
Помните, что во время реализации инструментов IAM контроль доступа представляет собой набор политик, которые гарантируют пользователям правильный доступ к нужным системам, ресурсам и приложениям. Таким образом, независимо от того, используете ли вы RBAC или ABAC, хорошее IAM-решение должно помочь вам определить, что пользователи могут делать с приложениями, предоставляя множество механизмов для обеспечения нужных людей, получения правильного доступа, к нужным вещам - в нужное время.