Недостатки ролевого управления доступом
Среди недостатков ролевого управления доступом необходимо отметить;
• возможность исполнения пользователем нескольких ролей одновременно;
• возможность продолжительного или частого использования роли.
Вопрос использования ролей связан с тем, как пользователь может активизировать различные роли в системе. Одна из возникающих при этом очевидных проблем: может ли пользователь исполнять несколько ролей одновременно? Так, пользователь, имеющий роль врача первой помощи, должен автоматически и одновременно быть в роли врача.
С другой стороны, рассмотрим пользователя, исполняющего роли руководителя проекта и руководителя отдела. Должен ли пользователь исполнять эти роли одновременно? Возможность пользователей одновременно исполнять все роли удобна для тех пользователей, которые приобретают все свои привилегии и разрешения на один сеанс. С другой стороны, это нарушает принцип наименьших привилегий (меньше привилегий - меньше вероятность утечки информации) и увеличивает вероятность возникновения уязвимостей.
Например, как руководитель отдела, пользователь имеет доступ к конфиденциальной информации отдела, которую он может скопировать в проектные документы с помощью троянских коней. Возникает явная необходимость ограничить число способов комбинирования более мощных ролей с более простыми.
Другие проблемы, касающиеся ролей, могут быть связаны с временными ограничениями на то, как долго может сохраняться конкретная роль, или как часто она может использоваться в течение данного промежутка времени. Здесь основной целью является сокращение возможного ущерба от неправильного использования и захвата мощных ролей.
С целью решения подобных проблем предлагаются следующие правила назначения пользователей ролям:
• во многих приложениях некоторые роли считаются взаимоисключающими;
Например, роли руководителя отдела и руководителя проекта не должны одновременно принадлежать одному и тому же субъекту;
• по возможности использовать иерархический принцип.
Например, пользователь может быть зарегистрирован как разработчик аппаратного обеспечения только в том случае, если он уже входит в группу роли разработчика. В этом случае назначение пользователей ролям разработчиков может контролироваться централизованно служащим безопасности, тогда как разрешение этим пользователям выполнять специализированные функции по разработке должно выдаваться только соответствующими пользователями. Это пример того, как могут передаваться дискреционные полномочия при одновременном сохранении для них некоторых централизованных ограничений;
• использовать таймеры и счетчики для ограничения предотвращения бесконтрольного захвата ролей, в особенности, если таких ролей мало и если они служат для выполнения критических служб.
Назначение привилегий и разрешений ролям также может быть централизованным или децентрализованным, как это было выше для назначения пользователей. В этом случае возникают аналогичные проблемы и компромиссы.
Выполнение работы
1. Получить доступ к набору служебных программ «Монитор безопасности»:
· expert.exe (программа преобразования файла описания модели в ехе-файл);
· security.exe (основная программа «Монитора безопасности»).
2. Написать файл описания модели с RBAC при помощи языка описания. Исходные данные задаются преподавателем. Особенности языка и правила определения модели приводятся в Приложении 1.
3. Используя утилиту expert.exe, получить ехе-файл описания модели. Порядок работы с программой expert.exe определена в Приложении 2.
4. Запустить программу security.exe. Подробное описание ее возможностей приведено в Приложении 3.
5. Выбрать в меню FILE созданный ехе-файл.
6. Убедиться в защите информации в системе с реализованным ролевым управлением доступом. Для этого необходимо:
• выполнить для нескольких пар «субъект-объект» те операции, которые определены в файле описания модели и которые имеют истинное условие доступа. Убедиться в успешной реализации таких действий.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.