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

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

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

CleverIDM CleverIDM: Управление учётными записями и доступом

Новая услуга в партнёрстве с Аванпост.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

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

    1. Денис Денисов Автор

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

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

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

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

      1. Андрей

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

        1. Денис Денисов Автор

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

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

          1. Андрей

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

            1. Александр Омельченко

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

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

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

            2. Денис Денисов Автор

              Ясно. Спасибо за вопросы!

              1. Мы не расширяем функционал существующей роли (если, конечно, под "ролью" Вы не понимаете весь набор прав доступа пользователя), а дополняем имеющиеся — определённые в виде набора ролей и назначенные конкретному пользователю — заявками на доступ.

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

              3. "Средство", которое позволит выгрузить сводку всех прав доступа у отдельного пользователя и выдать аналогичные новому, — это IDM-решения. Но, зачастую, IDM-системы охватывают не все ИТ-системы организации. Поэтому поиск и анализ запросов на выдачу конкретному пользователю определённых прав остаётся. Плюс аудиты.

Добавить комментарий

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

Empty