За пределами 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. Андрей

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

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

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

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

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

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

      0
      0
      1. Андрей

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

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

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

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

          0
          0
          1. Андрей

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

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

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

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

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

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

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

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

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

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

              0
              0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)