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

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

Знаете ли вы, что такое управление доступом на основе ролей или RBAC?

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

Список контроля доступа

В 1965 году появилась операционная система с разделением времени под названием Multics (детище Bell Labs и Массачусетского технологического института), которая впервые использовала список контроля доступа (ACL). Я даже не родился в то время, поэтому я отдаю вотум доверия Википедии за эту информацию. Что я знаю из первых рук, так это список контроля доступа к файловой системе (filesystem ACL), использовавшийся в Netware Novell® в начале 1990-х годов, о котором я рассказывал в предыдущей статье этого блога.

Но вернемся к списку контроля доступа: что такое контроль доступа? Это самое простое, что можно объяснить, это не более и не менее, чем простое ограничение для пользователя в отношении ресурса. Либо с помощью пароля, физического ключа или даже ваших биометрических данных, таких как, например, отпечаток пальца.

Список управления доступом – это запись каждого пользователя, который может получить доступ (явно разрешен) или нет (явно запрещен, в любом аспекте). Как вы можете себе представить, это становится утомительным – записывать одного за другим пользователей, а также процессы самой операционной системы или программ, которые на ней работают… Как видите, записывать все записи, известные как записи контроля доступа (ACE), довольно хлопотно.

По примеру прав на файлы, каталоги и далее (например, на целые ресурсы: оптические диски или целые “жесткие диски”) я пришел в прошлом веке к работе с Novell® Netware. Это ACL файловой системы (список контроля доступа к сетевой файловой системе). Затем, после того как наступило тысячелетие, появилась версия 4 NFS ACL, которая собрала и расширила стандартизированным образом все, что мы использовали с 1989 года, когда RFC 1094 создал спецификацию протокола сетевой файловой системы. Мне кажется, что я многое обобщил и должен хотя бы упомянуть об использовании ACL в MS Windows® через Active Directory (AD), сетевых ACL для сетевого оборудования (маршрутизаторы, концентраторы и т.д.) и реализации некоторых баз данных.

Все эти и другие технологии используют концепцию списков контроля доступа, а поскольку все в жизни развивается, возникла концепция групп, имеющих некоторые общие черты, и таким образом стало возможным экономить работу, поддерживая списки доступа в актуальном состоянии. Теперь представьте, что у нас есть один или несколько списков контроля доступа, которые принимают только группы. В 1997 году человек по имени Джон Баркли продемонстрировал, что этот тип списка эквивалентен минимальному контролю доступа на основе ролей, но, тем не менее, RBAC, что подводит нас к сути вопроса…

Управление доступом на основе ролей RBAC

Понятие роли в RBAC выходит за рамки разрешений, это также могут быть четко определенные навыки. Кроме того, можно назначить несколько ролей, в зависимости от потребностей главного героя (пользователь, программное обеспечение, оборудование…). Возвращаясь к примеру с отделом инкассации. Продавец, который уже имеет соответствующую роль, может также иметь роль в инкассации, чтобы анализировать платежи клиентов и фокусировать свои продажи на платежеспособных клиентах. С ролями это сделать относительно легко.

Преимущества RBAC

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

– Сократите расходы, назначив пользователю более одной роли. Нет необходимости покупать новые виртуальные компьютеры, если они могут совместно использоваться с уже созданными группами. Позвольте Pandora FMS контролировать и предоставлять вам информацию для принятия решений о перераспределении временной нагрузки или, при необходимости и только при необходимости, о приобретении дополнительных ресурсов.

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

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

Недостатки RBAC

– Количество ролей может значительно увеличиться. Если в компании 5 отделов и 20 функций, мы можем иметь максимум 100 ролей.

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

– Когда субъекту необходимо временно продлить свои разрешения, RABC может стать трудноразрывной цепочкой. Для этого Pandora FMS предлагает альтернативу, которую я объясню в следующем разделе.

Правила RBAC

Чтобы максимально использовать преимущества модели RBAC, на первом месте всегда стоит разработка концепции ролей и полномочий. Важно, чтобы обработка идентификационных данных для возможности назначения этих ролей также осуществлялась стандартизированным образом, что и пытается сделать ISO/IEC 24760-1 от 2011 года.

Существуют три золотых правила RBAC, которые должны восприниматься как упорядоченные по времени и применяться своевременно:

1. Назначение роли: человек может использовать разрешение, только если ему/ей назначена определенная роль.

2. Авторизация роли: активная роль человека должна быть авторизована для этого человека. Вместе с правилом номер один это правило гарантирует, что пользователи могут брать на себя только те роли, на которые они уполномочены.

3. Разрешение на выдачу разрешений: Лицо может использовать разрешение только в том случае, если разрешение разрешено для активной роли субъекта. Вместе с правилами один и два, это правило гарантирует, что пользователи могут использовать только те разрешения, на которые они уполномочены.

Корпоративная версия Pandora FMS имеет сверхполный RBAC и механизмы аутентификации, такие как LDAP или AD, а также механизмы двойной аутентификации с помощью Google® Auth. Кроме того, с помощью системы тегов, управляемой Pandora FMS, мы можем объединить RBAC с ABAC. Управление доступом на основе атрибутов похоже на RBAC , но вместо ролей оно основано на атрибутах пользователя. В данном случае – присвоенные метки, хотя это могут быть и другие значения, например, местоположение или годы опыта работы в компании.

Но это, это для другой статьи….

Прежде чем мы попрощаемся, помните, что Pandora FMS – это гибкое программное обеспечение для мониторинга, способное контролировать устройства, инфраструктуры, приложения, сервисы и бизнес-процессы. .

Вы хотите узнать больше о том, что может предложить вам Pandora FMS? Узнайте об этом, нажав здесь: https://pandorafms.com/es

Если у вас более 100 устройств для мониторинга, вы можете связаться с нами через следующую форму: https://pandorafms.com/es/contactar/

Также помните, что если ваши потребности в мониторинге более ограничены, в вашем распоряжении есть OpenSource версия Pandora FMS. Более подробную информацию можно найти здесь: https://pandorafms.org/es/

Не стесняйтесь присылать нам свои запросы. Сотрудники Pandora FMS будут рады помочь вам!