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