Управление доступом на основе ролей или RBAC, — это подход к ограничению доступа к цифровым ресурсам на основе роли пользователя в организации. Например, в соответствии с RBAC бухгалтер компании должен иметь доступ к корпоративным финансовым записям, но не к системе управления контентом, используемой для обновления веб-сайта компании, в то время как эти разрешения будут отменены для команды веб-разработчиков этой компании.
Почти каждая организация применяет какие-либо средства контроля доступа к своим цифровым активам — действительно, каждая используемая сегодня операционная система имеет встроенные средства контроля доступа. Средства контроля доступа обычно предоставляют определенные разрешения (и налагают ограничения) отдельным пользователям или группам, которые эти пользователи могут принадлежать. Что отличает модель RBAC от других форм управления доступом, так это то, что пользователи группируются на основе ролей, которые они играют, и разрешения определяются главным образом этими ролями, а не настраиваются для каждого отдельного пользователя. В этой статье вы узнаете, как работает RBAC, и увидите преимущества и недостатки этого подхода.
Как работает RBAC
RBAC в основном основан на том, что известно как принцип наименьших привилегий, что по сути говорит о том, что любой пользователь должен иметь доступ к нужным ему данным и функциям и ничего больше. Это звучит разумно в теории, но одна из центральных дилемм при внедрении контроля доступа заключается в том, как заставить его работать на практике: как определить, что нужно делать пользователям, и как применить разрешения и ограничения ко всем пользователям? что не обременяет админов?
RBAC решает эти проблемы, основываясь на том, что делают пользователи, а не на том, кем они являются. Вместо того, чтобы устанавливать индивидуальный набор разрешений для каждого пользователя, в рамках RBAC существует ограниченный набор предопределенных ролей в организации, и каждый пользователь выполняет одну (или несколько) из этих ролей. Набор разрешений настраивается для каждой роли в соответствии с ее конкретными потребностями и наследуется всеми пользователями, выполняющими эту роль. Если необходимо изменить разрешения для роли, эти изменения аналогичным образом передаются пользователям, что упрощает администрирование системы.
Роли RBAC
Роли, очевидно, лежат в основе управления доступом на основе ролей. Но важно помнить, что определение ролей — это административное и концептуальное упражнение, а не техническое. Что касается базовых систем, каждая из этих ролей — это просто группа пользователей; Ваша организация должна определить логическое разделение ролей для своих сотрудников и тех, кто попадает в каждую категорию, и это одна из наиболее важных частей процесса развертывания RBAC.
Таким образом, роли могут сильно различаться от организации к организации. Тем не менее, большинство предприятий будут устанавливать роли, так или иначе основанные на их собственной внутренней организационной структуре. В своем блоге поставщик систем безопасности UpGuard приводит несколько примеров таких ролей и приложений, к которым у них будет доступ:
- Программная инженерия: GCP, AWS и GitHub
- Маркетинг: HubSpot, Google Analytics, Fb Advertisements и Google Advertisements
- Финансы: Ксеро и АДФ
- Человеческие ресурсы: Рычаг и BambooHR
Также важно отметить, что пользователю может быть назначено более одной роли. Например, может быть роль «сотрудник» базового уровня, которой назначен каждый в вашей организации, которая предоставляет разрешение на общеорганизационные службы, такие как электронная почта и приложения календаря, в дополнение к более специализированным ролям, которые предлагают доступ к данным отдела и Приложения. Также может быть роль «менеджер», которая предоставляет определенным пользователям более широкий доступ к некоторым данным в каждом отделе.
Матрица RBAC
После того как вы определили свои роли, следующим шагом в процессе планирования будет определение прав и ограничений, применимых к каждой из этих ролей. Один из способов спланировать это — использовать матрица RBAC, которая представляет собой таблицу, в которой роли формируют строки, а различные объекты или действия формируют столбцы.
В методе унифицированной архитектуры Дэвида В. Энстрома есть несколько замечательных примеров того, как может выглядеть матрица RBAC. Первый предназначен для конкретного объекта данных в вашей инфраструктуре. Строки представляют некоторые абстрактные роли, которые пользователи могут иметь в организации, а столбцы представляют действия, которые пользователь потенциально может выполнять с этим защищенным объектом. Если роль имеет право на выполнение одного из действий, ячейка, на которой пересекаются столбец и строка, помечается крестиком.
Как видите, вы можете довольно детально определить, что пользователи с разными ролями могут и не могут делать с разными объектами. Следующая таблица, возможно, немного менее абстрактна. Строки — это роли, определяемые названиями должностей, а столбцы — это конкретные объекты, с которыми могут взаимодействовать пользователи с этими ролями. Каждая ячейка содержит буквы действий CRUDE (создание, чтение, обновление, удаление, выполнение) из первой таблицы, которые описывают, что каждая роль может делать с каждым объектом.
Это дает вам представление о том, как RBAC действительно может помочь определить возможности отдельных пользователей на практике. Продавцы верхнего уровня могут создавать новые счета, а сотрудники нижнего уровня могут их только читать. Специализированный менеджер по запасам и общий менеджер отдела могут обновлять записи о продуктах, тогда как сотрудники среднего звена могут только читать их.
Опять же, создание этих матриц — это упражнение, которое вы будете выполнять независимо от какой-либо технической реализации. Цель состоит в том, чтобы зафиксировать вашу организационную структуру и потребности в доступе к данным, которые ваш RBAC в конечном итоге сделает конкретными.
Лучшие практики RBAC
Если вы хотите подробно ознакомиться с передовыми методами реализации RBAC, возможно, вам стоит ознакомиться с INCITS 359-2012, стандартом RBAC, установленным ANSI. Для более краткого чтения, MorganFranklin Consulting предлагает хороший список лучших практик, которые следует учитывать, когда вы начинаете свое путешествие. Вот некоторые из их ключевых советов:
- Воспринимайте RBAC как текущую программу, а не как проект. Не ожидайте, что первоначальный набор ролей и разрешений, которые вы устанавливаете, будет высечен в камне. Вам нужно будет изменить их, когда вы увидите, как RBAC работает на практике, а также по мере роста и изменения вашей организации.
- Очистите плохие данные. Трудно понять, какие роли должны иметь доступ к каким данным, если сама структура данных запутана. Чистые данные — это главный рецепт успешной реализации программы RBAC.
- Назначьте владельца роли, который будет представлять каждую область со стороны бизнеса. Кто обладает лучшими «инсайдерскими знаниями» о каждом отделе? Вам понадобятся эти люди в команде, которая определяет роли в вашей организации.
- Сделайте роли многоразовыми. Если только один человек во всей организации имеет определенную роль, возможно, этим доступом не следует управлять через RBAC. Одной из самых больших ловушек в RBAC является «ролевой взрыв», при котором создается множество все более детализированных ролей, чтобы учесть все нюансы должностных инструкций разных сотрудников. Зайдя слишком далеко по этому пути, вы окажетесь в ситуации, когда у вас будут уникальные роли почти для каждого сотрудника, что, очевидно, сведет на нет многие преимущества RBAC. Вы хотите, чтобы все было как можно проще, чтобы уменьшить административную нагрузку на ИТ.
Преимущества и недостатки RBAC
Надеюсь, на данный момент многие преимущества RBAC очевидны. Модель RBAC позволяет компаниям применять принцип наименьших привилегий, снижая при этом административную нагрузку и вероятность ошибок, возникающих при настройке разрешений для каждого отдельного пользователя. Такое ограничение разрешений может предотвратить внутренние атаки и заблокировать учетные записи, скомпрометированные внешними злоумышленниками, от повышения привилегий.
Кроме того, во многих правилах безопасности и защиты данных указывается, какие должности в компании должны и не должны иметь доступ к конфиденциальным данным. Документированная программа RBAC может помочь организациям соблюдать эти законы.
Тем не менее, RBAC — не панацея. Читая вышеприведенный раздел о матрицах RBAC, вы, возможно, подумали, что их сборка требует много работы, и вы были правы. Хотя RBAC может сэкономить много текущей административной работы, для его увеличения требуется немало работы, что может не окупиться в долгосрочной перспективе, особенно для небольших компаний. В то же время в крупных компаниях с большим количеством отдельных отделов может быть множество различных ролей, а это означает, что сложность RBAC может возрастать с ростом численности персонала.
RBAC против ACL, ABAC и IAM
Имея в виду недостатки RBAC, вы можете рассмотреть несколько альтернатив. Одним из наиболее распространенных является списки контроля доступа, или АКЛ. Если мышление RBAC рассматривает разрешения с точки зрения пользователя и ролей, которые они играют, то подход ACL — с точки зрения данных или функций, с которыми пользователи будут взаимодействовать. ACL — это просто список для каждого объекта данных, в котором указано, кто и какие операции может выполнять с этим объектом. Это концептуально проще и может потребовать меньше работы, чем настройка RBAC, если у вас не так много объектов данных, с которыми нужно работать, но вы можете видеть, что это не масштабируется для большой компании.
Контроль доступа на основе атрибутов (ABAC), Между тем, это парадигма, которая в некотором роде основывается на RBAC. ABAC снимает акцент с пользователей и вместо этого, как следует из названия, фокусируется на атрибуты всех элементов вашей системы, объединяя их вместе в логические наборы правил. Например, в соответствии с парадигмой ABAC, если определенный тип пользователя выполняет определенный тип действия с определенным типом объекта в определенное время суток, все эти атрибуты могут быть приняты во внимание, когда дело доходит до определения того, следует ли разрешение. быть предоставлено. Может быть, каждый может читать и обновлять финансовые отчеты в течение рабочего дня, но только менеджеры в бухгалтерии могут делать это в нерабочее время. ABAC, очевидно, более детализирован, чем RBAC, но также требует гораздо большей административной поддержки.
Есть еще одна аббревиатура, которую вы можете услышать, когда люди говорят о RBAC и подобных парадигмах: IAM, или управление идентификацией и доступом. Однако RBAC и IAM не противостоят друг другу. IAM определяет и управляет ролями и правами доступа отдельных сетевых объектов к различным облачным и локальным приложениям.
Другими словами, RBAC представляет собой один из способов реализации IAM (а ABAC и ACL — другие способы). Это подводит нас к нашему последнему вопросу: как с технической точки зрения реализуется RBAC?
Инструменты, решения и примеры RBAC
Хорошей новостью является то, что вам не нужно создавать решение RBAC с нуля: вы можете использовать одно из многих предложений IAM на рынке, чтобы внедрить решение RBAC для своего бизнеса. Существует несколько наборов IAM — ознакомьтесь со списком ведущих поставщиков от eSecurity Planet и Toolbox — и почти все они позволяют установить RBAC для ваших пользователей. Основные облачные сервисы, такие как Amazon AWS и Microsoft Azure, также предлагают возможности RBAC.
Если вы хотите посмотреть на пример того, как все это работает на практике, вы можете проверить этот пример использования от поставщика IAM Auth0. Этот документ знакомит вас с примером реализации RBAC на их платформе и показывает, как настроить его для ваших нужд. Переход на RBAC может быть путешествием, но вознаграждение может быть большим.
Авторское право © 2022 IDG Communications, Inc.
https://cyberxhack.org/