Портал №1 по управлению цифровыми
и информационными технологиями

За пределами RBAC

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

Одной из стратегий может быть управление доступом на основании запросов на предоставление прав доступа. Суть её в том, что пользователь, которому нужны дополнительные к уже имеющимся права, запрашивает их самостоятельно при возникновении такой потребности. Запрос проходит этапы проверки, согласования и, будучи одобренным, ведёт к выдаче прав пользователю. Подачу подобных запросов можно автоматизировать, например, через портал самообслуживания.

Чем хороша такая стратегия в паре с ролевой моделью? Во-первых, это использование самой ролевой модели, которую можно связать с кадровой системой. Через неё – с кадровыми событиями, которые можно обрабатывать автоматически и применять к пользователю, назначая ему или отзывая у него соответствующие роли, например:

  • приём нового сотрудника;
  • увольнение сотрудника;
  • перевод сотрудника на другую должность или в другое подразделение;
  • отпуск или временное отсутствие и т.д.

Во-вторых, в ролевой модели предприятия становится возможным определить необходимый и достаточный набор ролей, затраты на поддержание которого в актуальном состоянии становятся целесообразными. Можно обозначить тот разумный минимум ролей, который будет использоваться, а не гоняться за 100%-м охватом всех отдельных прав доступа и назначением их в планируемые роли (что явно утопия). В-третьих, управление доступом через запросы дополняет ролевую модель, закрывая потребности в получении прав там, где ролей уже (или ещё) нет. В-четвёртых, часто повторяющиеся однотипные запросы могут быть основой для принятия решения о создании новой роли и добавлении её в ролевую модель, что уменьшает число запросов.

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

Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Комментариев: 8

  • Альберт

    Для автоматизации потребуется ситема проверки конфликта ролей. Иначе можно дырок в безопастности наделать.

  • Андрей

    Еще есть вопрос появления нового сотрудника, которому нужны права "как у воот этого вот сотрудника". С ростом организации таких вопросов появляется все больше. Тут тогда нужна система выгрузки прав в новую роль, иначе становится очень сложно администрировать накопившиеся "разовые" запросы на предоставление доступа. 

    • Тут тогда нужна система выгрузки прав в новую роль

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

      Если первое, то это регулярный пересмотр и актуализация ролевой модели, в т.ч с учётом групп часто повторяющихся запросов. Если второе, то это назначение ролей "по образцу" + дополнительные полномочия, полученные по отдельным запросам.

      Здесь, на мой взгляд, и проявляется яркое преимущество RBAC – определённость. Полномочия пользователя в разных системах (ресурсах) группируются и формируются в роли. Используя RBAC, легко проводить аудит: ясно, кто из пользователей имеет определённые права доступа, и какие именно.

      • Андрей

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

        • новизну для сервиса, не для организации

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

          • Андрей

            Денис, нет. В статье Вы пишете, что возможно индивидуальное добавление доступов через запросы, т.е. расширение функционала существующей роли. У нас образуется новый, возможно уникальный набор доступов для конкретного сотрудника. Потом появляется "новый" пользователь, которому нужно дать точно такой же уровень доступа, как у того сотрудника, которому мы давали доступ через роль + заявки. Как мы будем предоставлять ему доступ? Искать все заявки, все опции доступа по всем системам? Вот тут нужно то самое средство, о котором я писал в первом комментарии – выгрузка всех прав в новую роль и предоставление этой роли новому сотруднику. 

            • Андрей, здесь есть два варианта решения:

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

              2 – Мы видим, что роль изменять не требуется. Для таких случаев в IDM системах есть запрос "Выдать права/роли как у сотрудника". К сожалению, это есть не во всех системах.

            • Ясно. Спасибо за вопросы!
              1. Мы не расширяем функционал существующей роли (если, конечно, под "ролью" Вы не понимаете весь набор прав доступа пользователя), а дополняем имеющиеся – определённые в виде набора ролей и назначенные конкретному пользователю  – заявками на доступ.
              2. Есть порог, когда количество подобных дополнительных однотипных запросов для сотрудников, находящихся на определённой должности, перерастает в качество – т.е. изменение ролевой модели организации. Текущий набор ролей и прав доступа этих сотрудников анализируется, проектируются и вводятся либо новые роли, либо пересматриваются "старые", куда добавляются дополнительные полномочия, которые ранее сотрудники получали по запросам.
              3. "Средство", которое позволит выгрузить сводку всех прав доступа у отдельного пользователя и выдать аналогичные новому, – это IDM-решения. Но, зачастую, IDM-системы охватывают не все ИТ-системы организации. Поэтому поиск и анализ запросов на выдачу конкретному пользователю определённых прав остаётся. Плюс аудиты.


Добавить комментарий для Александр ОмельченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM