Теоретические основы компьютерной безопасности: Методические указания к выполнению лабораторных работ, страница 9

Природа разрешений, выделенных роли, существенно отличается от обычных операций чтения, записи, выполнения и т.д., поддерживаемых типич­ными операционными системами. В модели рассматривается авторизованная операция - выполнение программы на множестве связанных элементов дан­ных. Это очень важное понятие позволяет осуществлять авторизацию в терми­нах абстрактных операций, встроенных в процедуры преобразования. Напри­мер, роли кассира в банке могут быть выделены скорее кредитные и дебитные операции с бюджетами, чем более общие операции чтения и записи. Это дает возможность RBAC рассматривать безопасность приложений в терминах опе­раций этих приложений в противоположность универсальным операциям чте­ния и записи в операционных системах общего назначения.

Роли были использованы в некоторых продуктах управления доступом 70-80х гг., например, в RACF фирмы IBM. Для подобных продуктов характерно использование ролей в административных целях. Например, в RACF имеется роль Operator с правом доступа ко всем ресурсам, но без возможности изме­нить разрешения доступа, роль Special с возможностью изменить разрешения доступа, но без права доступа к ресурсам, и роль Auditor с правом доступа к контрольным журналам (содержащая, помимо всего прочего, события, сгенерированные ролями Operator и Special, не имеющими доступа к контрольному журналу).

С основной концепцией роли связано два аспекта:

•   ролям назначаются пользователи и

•  ролям назначаются привилегии и разрешения.

Пользователь, назначенный роли, таким образом, приобретает привиле­гии и разрешения этой роли.

Термин «привилегии» используется для обозначения общих широких полномочий системы. Примерами типичных привилегий существующих продук­тов являются Operator, Auditor т.д.

Под термином «разрешение» будем понимать права доступа к конкрет­ным объектам данных, например, файлам. Большинство операционных систем предоставляют такие разрешения как чтение, запись, исполнение и т.д. Для контроля на прикладном уровне хотелось бы иметь разрешения, связанные с прикладной областью. Например, те же дебитные и кредитные операции над бюджетным объектом. Пользователь, уполномоченный выполнять кредитную операцию над бюджетом, не должен иметь права произвольного доступа чте­ния и записи к бюджетному балансу. Следовательно, очень важно, чтобы RBAC, ориентированное на приложение, каким-либо образом удовлетворяло этому требованию.

Существует два подхода к контролированию разрешений при ориента­ции на приложения:

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

•     Второй подход обеспечивает более тщательный контроль, так что роли кассира в банке выделяется разрешение на выполнение кредит­ных и дебитных операций только над конкретными типами бюджетов.

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

Понятие «назначение пользователей» связано с тем, как ролям назна­чаются пользователи. Основной вопрос, возникающий здесь: является ли на­значение пользователей ролям полностью централизованным и выполняется исключительно служащим системы или существует некоторая децентрализа­ция, посредством чего определенные пользователи получают право назначать других пользователей ролям.

Преимуществом централизованного подхода является обеспечиваемый им строгий контроль и централизация ответственности. Недостатком является увеличение затрат, когда система становится слишком большой. Кроме того, запросы на добавление пользователей ролям идут со стороны пользователей, и хорошая система должна позволять соответствующим пользователям осуще­ствлять это непосредственно с центрального пункта управления. Заметим, что наиболее выгодно использовать здесь RBAC. Можно создавать роли админи­стрирования назначения пользователей и выдавать право на включение в роль новых пользователей, но только для некоторого подмножества ролей в систе­ме.