Что такое управление доступом на основе ролей (RBAC)?

Управление доступом на основе ролей (Role-Based Access Control - RBAC) использует определенные роли и привилегии для ограничения доступа авторизованным пользователям к системам. RBAC является основой доступа с наименьшими привилегиями, и его также можно использовать для реализации других моделей доступа, таких как управление доступом на основе атрибутов (Attribute-Based Access Control - ABAC).

Как работает управление доступом на основе ролей?

Идея управления доступом на основе ролей проста: ограничить доступ пользователей к системам и данным только тем минимумом, который им необходим для выполнения их работы, и не более того — эта концепция называется принципом наименьших привилегий (иногда сокращенно PoLP).

В среде доступа на основе ролей роль пользователя в организации определяет конкретные сетевые разрешения, которые ему предоставляются. Это означает, что сотрудники с более низким уровнем доступа не имеют доступа к конфиденциальной информации и ресурсам, но уровни доступа на основе ролей обычно более детализированы. Когда управление RBAC реализовано правильно, пользователи не должны иметь доступа к каким-либо ресурсам за пределами назначенных им областей работы; например, сотрудники отдела маркетинга не должны иметь доступа к средам разработки, и наоборот.

Кроме того, доступ на основе ролей используется для ограничения того, что пользователи могут делать с системой или файлом, к которым им предоставлен доступ. Пользователь может иметь доступ только на чтение к определенным файлам или системам, таким как базы данных, но доступ на чтение/запись к другим.

Сравнение RBAC с ABAC

Управление доступом на основе ролей часто используется как синоним управления доступом на основе атрибутов. В то время как ABAC и RBAC отличаются друг от друга, RBAC часто используется в сочетании с ABAC.

Управление ABAC более детализировано, чем RBAC, и его можно рассматривать как расширение или усовершенствование доступа на основе ролей. В то время как RBAC зависит от роли пользователя в организации, в модели ABAC права доступа пользователей зависят от комбинации атрибутов, а не только от ролей пользователей. К ним относятся, помимо прочего, роль пользователя в организации, откуда он пытается получить доступ к ресурсам, используемое устройство и атрибуты, связанные с системой или приложением, к которым он пытается получить доступ. Это позволяет организациям предоставлять доступ и применять ограничения в соответствии с профилем риска отдельного пользователя.

Например, вы можете запретить своим ИТ-администраторам удаленный доступ к серверным системам, если только они не используют VPN или диспетчер подключений к удаленному рабочему столу, или запретить всем сотрудникам доступ к ресурсам компании, если они не используют устройство, предоставленное компанией.

Сравнение RBAC с ACL

Список управления доступом (Access Control List - ACL) представляет собой список пользователей, имеющих доступ к определенному ресурсу, а также разрешения, которые каждый пользователь имеет по отношению к этому ресурсу (только чтение, чтение-запись и т. д.). ACL являются основой модели избирательного управления доступом (Discretionary Access Control - DAC).

Наиболее распространенным примером ACL и DAC в действии является файловая система Windows, которая позволяет пользователям и администраторам определять отдельные списки ACL для каждого объекта, такого как текстовый документ или папка с файлами.

Списки контроля доступа, обычно состоящие из IP-адресов, также используются сетевыми администраторами для фильтрации трафика к VPN, брандмауэрам веб-приложений (WAF) и сетевым маршрутизаторам и коммутаторам. ACL может содержать список разрешенных IP-адресов или «черный список» запрещенных IP-адресов.

Если вы думаете, что это означает большую работу, вы правы. Ведение массовых списков разрешений и блокировок требует много времени и чревато ошибками, поэтому списки ACL (и модель DAC) полезны только в отдельных случаях с участием небольшого числа пользователей.

Итог: в то время как RBAC определяет привилегии доступа на уровне группы, ACL определяет их на уровне отдельного пользователя или IP-адреса. Это делает RBAC гораздо менее трудоемким и подверженным ошибкам, чем списки контроля доступа, и, следовательно, гораздо более подходящим для бизнес-среды с десятками, сотнями или даже тысячами пользователей.

Каковы преимущества RBAC?

Внедрение управления доступом на основе ролей имеет много преимуществ, в том числе:

Повышение безопасности

Ограничение доступа сотрудников только к тем ресурсам, которые им необходимы для выполнения их работы, не позволяет небрежным или злонамеренным сотрудникам удалять, красть или нарушать целостность файлов и других цифровых активов, таких как базы данных и исходный код.

Кроме того, если внешний злоумышленник украдет набор действующих учетных данных для входа в систему, RBAC и доступ с наименьшими привилегиями предотвратят его перемещение в горизонтальном направлении в сети и повышение привилегий.

RBAC и доступ с наименьшими привилегиями также являются ключевыми компонентами современных моделей сетевого доступа с нулевым доверием.

Поддержка инициатив по соблюдению требований

Доступ на основе ролей позволяет компаниям соответствовать отраслевым и нормативным требованиям, включая HIPAA, GDPR и другие правила защиты данных и конфиденциальности, которые предусматривают контроль конфиденциальности и неприкосновенности персональной идентифицирующей информации и других конфиденциальных данных. Это особенно важно в строго регулируемых отраслях, таких как здравоохранение и финансы, а также в государственных учреждениях.

Сокращение затрат и административных издержек

Предопределенные роли пользователей модели RBAC минимизируют административные издержки при приеме на работу и увольнении сотрудников, когда сотрудники берут на себя новые роли или должностные обязанности в компании или когда организации необходимо предоставить доступ поставщику или стороннему подрядчику. Предоставление доступа новому пользователю или изменение доступа существующего пользователя — это просто вопрос назначения им правильной роли (ролей). Аналогичным образом, когда пользователи увольняются из компании, ИТ-администраторы и администраторы безопасности могут быстро отозвать их доступ к системам.

Предоставляя администраторам информацию о доступе и действиях пользователей, RBAC позволяет организациям определять области, в которых они могут более экономично использовать сетевые ресурсы, такие как пропускная способность и объем хранилищ.

Как реализовать управление доступом на основе ролей

1. Разработайте стратегию, соответствующую потребностям своей компании.

Прежде чем приступить к определению ролей, проведите инвентаризацию своих систем, чтобы определить, к каким ресурсам вам нужно контролировать доступ. Определите системы, которые обрабатывают или хранят конфиденциальную информацию, например клиентские базы данных и среды разработки, а также системы, доступ к которым необходим всем, такие как электронная почта компании и системы запросов в службу поддержки.

Также изучите бизнес-процессы своей компании, технологии, требования соответствия и текущий уровень безопасности. Определите любые существующие пробелы, такие как непоследовательное применение политик в организации.

Имейте в виду, что можно использовать RBAC в сочетании с ABAC или другой моделью, особенно если вы реализуете сетевой доступ с нулевым доверием.

2. Определите роли пользователей.

Теперь пришло время проанализировать свой персонал и сгруппировать пользователей по ролям с одинаковыми потребностями в доступе. Начните с крупного деления – например, сгруппируйте пользователей по отделам, – а затем уточните роли каждого пользователя.

Не задавайте слишком много ролей, так как это противоречит цели использования RBAC. Рассмотрите возможность использования сопоставления команд с ролями, при котором пользователи приписываются непосредственно в команды, которым затем можно назначать свои роли. Это сэкономит время, улучшит согласованность политик, уменьшит количество ошибок и упростит для администраторов использование политик доступа на основе ролей.

Также не попадите в другие распространенные ловушки, такие как недостаточная детализация, перекрытие ролей и чрезмерное количество исключений для разрешений RBAC.

3. Установите должную структуру управления.

После того как вы определите свою стратегию RBAC и роли пользователей, вам потребуется способ применения новых политик, а также процесс управления изменениями, позволяющий изменять их по мере изменения потребностей вашего бизнеса.

Разработайте политику управления доступом, содержащую правила и рекомендации для вашей модели RBAC, включая показатели эффективности, стратегии управления рисками, процедуры переоценки ролей и механизмы обеспечения соблюдения. Четкий набор правил помогает предотвратить «разрастание ролей» и внутренние конфликты между подразделениями и отдельными пользователями.

4. Внедрите свою модель RBAC.

Крупная организация, особенно без ролевой модели, может разворачивать новый план поэтапно, чтобы избежать путаницы пользователей и сбоев в повседневной работе. Учтите, что на этом пути возникнуть проблемы, в том числе проблемы, которые потребуют от вас изменения своего первоначального плана. Это нормально, и, внедряя свой план поэтапно, вам будет легче справиться с ними.

5. Поддерживайте свою модель RBAC.

Пользователи приходят и уходят. Бизнес нуждается в переменах. Технологии меняются. Рынок меняется. При этом система управления доступом на основе ролей не будет поддерживать сама себя. Собирайте отзывы от своих пользователей, постоянно следите за состоянием безопасности и проводите периодические проверки ролей, назначений ролей и журналов доступа, чтобы понять, что работает, а что нужно скорректировать.