В этой статье дается полное объяснение управления доступом на основе ролей (RBAC), а также пошаговое руководство по развертыванию, обслуживанию и расширению RBAC для удовлетворения потребностей вашей организации. Вы узнаете о ролях, о том, как их определить и как их использование для регулирования доступа может помочь защитить вашу сеть, снизить административные расходы и обеспечить соблюдение нормативных требований. Мы также увидим несколько примеров управления доступом на основе ролей. Давайте начнем.
Что такое управление доступом на основе ролей (RBAC)?
Концепция предоставления разрешений людям в зависимости от их роли в организации называется управлением доступом на основе ролей (RBAC). Он обеспечивает базовый контролируемый подход к управлению доступом, который менее подвержен ошибкам, чем индивидуальное предоставление разрешений пользователям.
Когда вы используете RBAC для управления доступом к ролям, вы изучаете требования своих пользователей и группируете их по ролям на основе общих обязанностей. Затем для каждого пользователя вы назначаете одну или несколько ролей и одно или несколько разрешений для каждой роли. Поскольку пользователям больше не нужно управлять без разбора, отношения «пользователь-роль» и «роль-разрешения» упрощают выполнение назначений пользователей.
История управления доступом на основе ролей
По крайней мере, с 1970-х годов люди использовали роли и обязанности для управления доступом к коммерческим компьютерным системам. Эти методы, однако, были специальными, и их часто приходилось модифицировать в каждом конкретном случае для каждой новой системы.
Исследователи из Американского национального института стандартов (NIST) не начинали определять систему, известную как управление доступом на основе ролей, до 1992 года. В том же году Феррайоло и Кун опубликовали документ, определяющий универсальный механизм управления доступом, подходящий для гражданских и коммерческое использование, закладывая основу для модели, которую мы используем сегодня.
На протяжении 1990-х и начала 2000-х Феррайоло, Кун и другие усовершенствовали RBAC, опираясь на предыдущую работу по исследованию экономических преимуществ RBAC, определили унифицированную модель и, что наиболее важно, определили формы разделения обязанностей. RBAC был официально принят NIST в качестве отраслевого стандарта в 2004 году.
Как работает управление доступом на основе ролей RBAC?
Перед развертыванием RBAC в бизнесе организация должна тщательно указать разрешения для каждой роли. Это включает в себя точное указание разрешений в категориях, перечисленных ниже:
- Разрешения на изменение данных (например, чтение, запись, полный доступ)
- Доступ к использованию программного обеспечения компании
- Разрешения внутри программы
Чтобы получить максимальную отдачу от RBAC, вы должны сначала смоделировать роли и разрешения. Частью этого является распределение всех обязанностей персонала по конкретным должностям, которые устанавливают соответствующие привилегии. Затем организация может назначать должности на основе задач сотрудников.
Организации могут использовать управление доступом на основе ролей, чтобы назначать одну или несколько ролей каждому пользователю или назначать разрешения индивидуально. Идея состоит в том, чтобы установить разрешения, которые позволяют пользователям выполнять свои обязанности без каких-либо дополнительных настроек.
Технологии управления идентификацией и доступом (IAM) используются организациями для внедрения и мониторинга RBAC. IAM в первую очередь обслуживает крупные организации, регистрируя, отслеживая и обновляя все удостоверения и разрешения. Процесс назначения разрешения называется «подготовкой», а процесс отзыва разрешения — «отменой предоставления». Этот тип системы требует установления единообразного и стандартизированного набора ролей.
Что такое роль RBAC управления доступом на основе ролей?
Роли — это семантика в архитектуре RBAC, которую организации могут использовать для создания своих привилегий. Для определения ролей можно использовать полномочия, ответственность, центр затрат, бизнес-подразделение и другие факторы.
Роль — это набор привилегий пользователя. Традиционные группы, представляющие собой совокупность пользователей, — это не то же самое, что роли. Разрешения напрямую не связаны с удостоверениями в контексте RBAC, а скорее с ролями. Поскольку они организованы вокруг управления доступом, роли заслуживают большего доверия, чем группы. Идентичность меняется чаще, чем функции и действия в обычном бизнесе.
Модель управления доступом на основе ролей RBAC
Стандарт RBAC определяет три формы управления доступом: базовую, иерархическую и ограниченную.
№1. Основной RBAC
Базовая модель определяет ключевые компоненты любой системы управления доступом на основе ролей. Хотя фундаментальный RBAC можно использовать как автономный подход к управлению доступом, он также служит основой как для иерархических, так и для ограниченных моделей.
В результате все RBAC должны следовать трем правилам, изложенным ниже:
- Выбор роли или назначение: Лицо может использовать разрешение только в том случае, если оно выбрало или получило роль.
- Авторизация роли: Активная роль субъекта должна быть авторизована.
- Авторизация разрешений: Субъект может использовать только те разрешения, которые разрешены для активной роли субъекта.
№ 2. Иерархия RBAC
Полагая, что ваша защита уже взломана, вы можете усилить защиту от потенциальных атак, уменьшая эффект взлома. Ограничьте «радиус действия» возможного ущерба, вызванного взломом, путем сегментации доступа и уменьшения поверхности атаки, подтверждения сквозного шифрования и мониторинга вашей сети в режиме реального времени.
№3. Ограниченный RBAC
Этот третий стандарт RBAC расширяет разделение ролей базовой модели. Отношения с разделением обязанностей классифицируются как статические или динамические.
- Один пользователь не может выполнять взаимоисключающие обязанности в отношениях статического разделения обязанностей (SSD) (как определено организацией). Это гарантирует, что, например, один человек не может одновременно совершить и одобрить покупку.
- Пользователь в модели динамического разделения обязанностей (DSD) может иметь противоречивые роли. Однако пользователь не может выполнять обе задачи в одном сеансе. Это ограничение помогает контролировать внутренние проблемы безопасности, например, путем реализации правила двух лиц, которое требует авторизации действия двумя уникальными пользователями.
Примеры управления доступом на основе ролей
RBAC позволяет контролировать действия конечных пользователей как на широком, так и на детальном уровне. Вы можете указать, является ли пользователь администратором, пользователем-специалистом или конечным пользователем, а также сопоставить обязанности и права доступа с должностями сотрудников в организации. Разрешения предоставляются только при достаточном доступе для сотрудников для выполнения своих задач.
Что делать, если описание конечного пользователя изменится? Возможно, вам придется передать их роль другому пользователю вручную, или вы можете назначить роли группе ролей или использовать политику назначения ролей для добавления или удаления членов группы ролей.
Инструмент RBAC может включать следующие обозначения:
- Объем роли управления – он ограничивает, какие элементы может обрабатывать группа ролей.
- Группа ролей управления – Вы можете добавлять и удалять участников из группы ролей управления.
- Роль управления – это типы задач, которые может выполнять данная ролевая группа.
- Назначение роли управления- Это процесс назначения роли группе ролей.
Когда пользователь добавляется в группу ролей, он получает доступ ко всем ролям в этой группе. При их удалении доступ ограничивается. Пользователи также могут быть включены в многочисленные группы, если им требуется временный доступ к определенным данным или приложениям, а затем удалены после завершения проекта.
Другие возможности доступа пользователя могут включать:
- Ключевой контакт для определенной учетной записи или роли.
- Биллинг – доступ к биллинговой учетной записи для одного конечного пользователя.
- Технические пользователи — это те, кто выполняет технические обязанности.
- Административный доступ предоставляется пользователям, осуществляющим административную деятельность.
Альтернативы RBAC: типы контроля доступа
Вместо управления доступом на основе ролей можно использовать другие механизмы управления доступом.
Список контроля доступа (ACL)
Список управления доступом (ACL) — это таблица, в которой перечислены разрешения, связанные с вычислительными ресурсами. Он информирует операционную систему о том, какие пользователи имеют доступ к объекту и какие действия они могут над ним выполнять. У каждого пользователя есть запись, связанная со свойствами безопасности каждого элемента. Для классических систем DAC обычно используется ACL.
ACL против RBAC
С точки зрения безопасности и затрат на администрирование RBAC превосходит ACL для большинства бизнес-приложений. ACL больше подходит для реализации безопасности на уровне отдельных пользователей и для низкоуровневых данных, но RBAC лучше подходит для системы безопасности в масштабе всей компании, контролируемой администратором. Например, ACL может разрешить доступ для записи к определенному файлу, но не может определить, как файл будет изменен пользователем.
Контроль доступа на основе атрибутов (ABAC)
ABAC оценивает набор правил и политик для управления разрешениями на доступ на основе определенных качеств, таких как информация об окружающей среде, системе, объекте или пользователе. Он использует логическую логику, чтобы разрешить или запретить людям доступ на основе сложной оценки атомарных или множественных свойств и их отношений.
На практике это позволяет вам определять правила на расширяемом языке разметки управления доступом (XACML), которые используют комбинации ключ-значение, такие как Роль=Менеджер и Категория=Финансы.
ABAC против RBAC
RBAC основан на предопределенных ролях, тогда как ABAC более динамичен и использует управление доступом на основе отношений. RBAC можно использовать для определения элементов управления доступом в общих чертах, тогда как ABAC обеспечивает большую степень детализации. Например, система RBAC предоставляет доступ всем менеджерам, тогда как политика ABAC предоставляет доступ только менеджерам финансового отдела. ABAC выполняет более сложный поиск, требующий большей вычислительной мощности и времени, поэтому используйте его только тогда, когда RBAC недостаточен.
Преимущества RBAC
- Управление и аудит сетевого доступа имеют решающее значение для информационной безопасности. Доступ может и должен быть разрешен на основе служебной необходимости. Безопасностью легче управлять с сотнями или тысячами сотрудников, ограничивая ненужный доступ к важной информации на основе заявленной роли каждого пользователя в бизнесе. Другие преимущества включают в себя:
- Административная и ИТ-поддержка будет сокращена. Когда сотрудник нанимается или меняет роли, вы можете использовать RBAC, чтобы уменьшить требования к бумажной работе и смене пароля. Вместо этого вы можете использовать RBAC для быстрого добавления и переноса ролей между операционными системами, платформами и приложениями. Это также снижает вероятность ошибки при предоставлении разрешений пользователям. Одним из многих экономических преимуществ RBAC является сокращение времени, затрачиваемого на административную деятельность. RBAC также облегчает интеграцию сторонних пользователей в вашу сеть, назначая им предварительно определенные роли.
- Повышение операционной эффективности. RBAC обеспечивает оптимизированный подход с логическими определениями. Вместо того, чтобы пытаться администрировать низкоуровневый контроль доступа, все роли можно привести в соответствие с организационной структурой бизнеса, что позволит пользователям выполнять свои обязанности более эффективно и автономно.
- Повышение соответствия. Федеральные, государственные и муниципальные ограничения распространяются на все организации. Компании могут легче соблюдать законодательные и нормативные стандарты в отношении конфиденциальности и конфиденциальности с помощью системы RBAC, поскольку ИТ-отделы и руководители могут управлять доступом к данным и их использованием. Это особенно важно для медицинских и финансовых организаций, которые обрабатывают большие объемы конфиденциальных данных, таких как PHI и PCI.
Лучшие практики для внедрения RBAC
Внедрение RBAC в вашей организации не должно происходить легкомысленно. Существует ряд общих этапов, которые необходимо предпринять, чтобы привлечь команду, не вызывая ненужной путаницы или раздражения на рабочем месте. Вот несколько идей для начала.
- Текущее состояние: Составьте список всех программ, аппаратных средств и приложений, обеспечивающих безопасность. Для большинства из них потребуется пароль. Однако вы можете захотеть включить серверные комнаты, которые находятся под замком. Физическая безопасность может быть важным компонентом защиты данных. Также укажите, кто имеет доступ к каждой из этих программ и мест. Это даст вам представление о текущей ситуации с данными.
- Текущие обязанности: Даже если у вас нет формального списка и списка ролей, определение того, что делает каждый отдельный член команды, может быть таким же простым, как быстрый разговор. Попытайтесь организовать команду таким образом, чтобы это не мешало творчеству или текущей культуре (если нравится).
- Создайте политику: Любые изменения должны быть задокументированы для просмотра всеми нынешними и будущими работниками. Даже если вы используете решение RBAC, документ, четко описывающий вашу новую систему, поможет вам предотвратить проблемы.
- Изменения: После того, как текущий статус безопасности и роли известны (и политика установлена), наступает время для реализации изменений.
- Постоянно адаптировать: Вполне вероятно, что первая итерация RBAC потребует некоторой модификации. Вначале вам следует часто оценивать свои обязанности и статус безопасности. Сначала оцените, насколько хорошо работает ваш творческий/производственный процесс, а затем насколько он безопасен.
Заключение
Защита данных является важной бизнес-функцией для любой корпорации. Система RBAC может гарантировать, что информация компании соответствует законам о неприкосновенности частной жизни и конфиденциальности. Кроме того, он может защитить важные деловые операции, такие как доступ к интеллектуальной собственности, что оказывает конкурентное влияние на организацию.
Часто задаваемые вопросы по управлению доступом на основе ролей
Каковы три основных правила для RBAC?
Компоненты RBAC, такие как разрешения ролей, отношения между пользователями и ролями, упрощают назначение пользователей.
Почему используется ACL?
Уменьшение сетевого трафика для повышения производительности сети. Уровень безопасности сети, определяющий, к каким разделам сервера/сети/службы пользователь может получить доступ, а какой – нет. Детальное отслеживание трафика, входящего и исходящего из системы.
В чем разница между контролем доступа на основе ролей и контролем доступа на основе правил?
Уровни доступа сотрудников не определяются средствами управления доступом на основе правил, которые носят превентивный характер. Вместо этого они работают, чтобы предотвратить нежелательный доступ. Ролевые модели активны в том смысле, что они предоставляют сотрудникам набор условий, при которых они могут получить одобренный доступ.
- ДИСКРЕЦИОННЫЙ КОНТРОЛЬ ДОСТУПА: определение и примеры
- ОБЯЗАТЕЛЬНЫЙ КОНТРОЛЬ ДОСТУПА MAC: как это работает
- Инструменты управления Active Directory: что это такое и все, что вам нужно о нем знать
- ОТДЕЛ МАРКЕТИНГА: Обзор, структура, роли, ожидания (+бесплатные советы)
- Виртуальный помощник по административным вопросам: вакансии, услуги, компании, требования и все, что вам нужно.
Рекомендации
