Управление доступом на основе ролей (RBAC) позволяет сетевым администраторам настраивать уровни доступа пользователей в соответствии с их ролями в организации, в то время как управление доступом на основе правил (RuBAC) разрешает доступ, зависящий от отдельных лиц, придерживающихся определенных условий. Используя предопределенную систему управления доступом на основе правил, системные администраторы могут, например, предоставлять доступ к определенным сетевым ресурсам только в стандартное рабочее время.
RuBAC, который часто называют контролем на основе атрибутов, предоставляет пользователям различные уровни доступа к системам на основе заданных критериев, независимо от их роли или положения в организации. Это объяснение исходит от Джо Доулинга, вице-президента по кибербезопасности, управлению идентификацией и доступом в Dell Technologies.
Помимо контроля доступа к сети, RuBAC можно использовать в различных контекстах, таких как контроль доступа к файлам и каталогам или контроль доступа к приложениям, говорит Алаа Негеда, старший архитектор решений и технический директор AlxTel, поставщика телекоммуникационных услуг. Он добавляет, что RuBAC также может быть интегрирован с другими мерами безопасности, такими как брандмауэры, системы обнаружения вторжений и защита паролем.
Настройки RuBAC определяются степенью контроля, предоставляемого пользователям в зависимости от их конкретных ролей в организации. Александр Марквардт, глобальный руководитель отдела управления идентификацией и доступом поставщика аналитического программного обеспечения SAS, отмечает, что RuBAC позволяет управлять доступом на основе дискретных критериев, условий или ограничений. Подход является явным, очень детализированным и фокусируется на отдельных атрибутах или характеристиках субъекта, объекта или операционной среды.
Джей Силберклейт, ИТ-директор компании XPO, поставщика грузовых и логистических услуг, считает, что RuBAC является оптимальным выбором для организаций, которым нужен метод доступа к сети, обеспечивающий максимальную гибкость и индивидуальность. Он отмечает, что правила могут быть быстро изменены без изменения общего определения организационной структуры.
Детализация и ясность — основные преимущества использования RuBAC, отмечает Марквардт. При изучении правила нет двусмысленности, поскольку оно явно разрешает или запрещает доступ к определенному объекту или операции.
Повышенный контроль и адаптивность также являются причинами, по которым многие организации выбирают RuBAC. По словам Марквардта, управление доступом на основе правил является идеальной моделью для предприятий, которым требуются строгие, четкие правила.
RuBAC предоставляет пользователям практически неограниченную гибкость доступа пользователей с минимальными накладными расходами. Как объясняет Зильберклейт, небольшой набор правил можно настроить, чтобы облегчить работу большой пользовательской базы. Этот подход позволяет протестировать или поэкспериментировать с различными уровнями доступа к сети среди подмножества пользователей. Он добавляет, что такой детальный контроль над доступом помогает организациям оставаться гибкими и безопасными.
Основным недостатком RuBAC является уровень контроля и управления, необходимый для установления, настройки, настройки и тестирования правил. Компании также сталкиваются с проблемой обеспечения точности и надежности разрешений по мере развития ролей пользователей. Организациям необходимо начать с четкой стратегии установки и управления RuBAC, предупреждает Даулинг из Dell.
Марквардт отмечает, что последователи могут испытывать трудности с написанием исключений для одного субъекта или одного объекта для широко применяемых правил, отслеживанием этих исключений и точным отчетом о действующих правах и разрешениях.
В. Кертис Престон, главный технический евангелист Druva, называет утомительный процесс установки и постоянные обязанности по обслуживанию RuBAC его основными недостатками, особенно если задействована многофакторная аутентификация (MFA). Однако он утверждает, что, исходя из современных знаний о кибератаках и взломах, это небольшая цена за душевное спокойствие организации и защиту данных.
Негеда признает, что настройка правил RuBAC может быть сложной задачей. Например, может потребоваться определить точные разрешения, необходимые для определенных ролей, или может потребоваться указать имя пользователя или имя группы, связанное с определенной ролью.
Негеда также упоминает, что масштабирование RuBAC может быть затруднено. Создание и поддержка правил для большого количества ресурсов может оказаться сложной задачей, как и определение того, какие пользователи или группы должны иметь доступ к тем или иным ресурсам.
По словам Негеды, существует множество методов развертывания RuBAC, причем использование базы данных для хранения правил является наиболее популярной стратегией. После создания правил они могут быть легко добавлены или обновлены администраторами.
Чтобы свести к минимуму путаницу и сбои, Доулинг рекомендует организациям, рассматривающим возможность перехода на RuBAC, начать с анализа своих текущих бизнес-требований и существующей системы классификации доступа к сети, чтобы определить, какая модель доступа на основе правил или ролей является наиболее подходящей. Если RuBAC является идеальным выбором для вашей организации, следует провести всесторонние интервью с владельцами бизнеса системы, чтобы установить наименее сложный набор правил, которому нужно следовать.
С появлением платформ разработки low-code и no-code, таких как AppMaster , внедрение систем контроля доступа стало еще более важным для защиты приложений и данных. Будь то ролевой, основанный на правилах или гибридный подход, поиск правильного метода управления доступом для вашей организации поможет вам поддерживать безопасную и функциональную сетевую среду.
